[jboss-as7-dev] manual way to do logging?

[David M. Lloyd]

On 06/07/2012 04:47 PM, Jim Crossley wrote:
> I really have no skin in this game, but I'm following with deep interest
> because 1) Bill, David, Jason, et al are all very smart and opinionated,
> 2) I happen to believe jboss-logging is over-engineered (though I'm
> willing to give the benefit of doubt to those with deeper understanding
> of the requirements it was designed to meet) and 3) the exchanges are
> often at reality-show levels (fun!). :)
>
> Especially this one:
>
> "David M. Lloyd"<david.lloyd at redhat.com>  writes:
>
> [...]
>
>>>> Calling it a "behemoth" doesn't make it one.
>>>
>>> Let's see:
>>>
>>> 1. Write interface(s) with a method for each thing you want to log
>>> (annotated of course).
>
> [...]
>
>> 1 is a strength so I'm assuming you're not arguing about that.
>
> Wow. That's pretty dismissive of the #1 reason he cites.
>
> Sure I'm a polyglot and all, but sometimes I think you guys too readily
> discount the cost of achieving the perceived benefits of type-safety.
>
> "I want to log a message."
> "Sure, just create an interface and add a method for it."
> "I'm sorry, did you say 'interface'?"
> "Yes, and don't forget to annotate it."
> "WTF?"

Well "pain" is subjective, obviously.  But if you examine the 
prospective implementations top to bottom, you'll see that ours performs 
better, in addition to solving requirements that Bill thinks are 
irrelevant but are in fact not optional.  Believe it or not but we *did* 
this analysis.

> If having to create an interface method for each thing you want to log
> doesn't exceed your "developer pain threshold" then it's set way too
> high (or your IDE is numbing the pain) and that will inevitably lead to
> complex, over-engineered systems.

Log and message operations execute in O(1) time; only the languages used 
are loaded, and JIT can optimize the piss out of the resultant simple 
classes.  I don't see what you're saying here because all I'm reading is 
FUD, and particularly weak FUD to boot.  It's so very very easy to spit 
out truisms without bothering to do the homework to find out what you're 
actually talking about.

Next person to throw around the term "over-engineered" gets to be the 
next one to rewrite the AS.  It's just FUD unless you define it.  I 
define it to be "contains extraneous features".  This logging mechanism 
contains no extraneous features; everything in it is meant to meet a 
specific requirement and it does so admirably.

> So you have to acknowledge that cost before Bill or anyone not
> intimately familiar with the logging requirements will appreciate how
> much value he's getting. And it better be a crapload 'cause that cost is
> HIGH!

It's really not.  The only way I can measure cost is in runtime 
performance, development overhead, and (and this is the punch line) the 
translation team, who actually have a MUCH LARGER stake in this than any 
of us.  And I think we hit it out of the park in all three areas.

How many projects are there that you can think of that could even be 
arsed with real research and requirements gathering in the first place, 
rather than just shitting out some random code and then going on a rock 
star tour to promote it?  If meeting requirements exactly to a T is 
"over-engineering" then call me the over-engineer.

> Sorry to prolong the dialog, but you guys don't seem to be
> communicating.

There has been more than enough communication.  There has not been any 
real useful contributions though; just the likes of "OMG, interfaces are 
so bloated".  Are they?  Well shit, let's tear down the house.

If someone else can provide an implementation that solves all the 
requirements (including, yes, compile-time verification) that is 
demonstrably better in the three axes above, I'm more than happy to 
concede the point.  But if all you're going to do is piss and whine, 
you're just wasting everyone's time.

-- 
- DML