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

[David M. Lloyd]

On 06/07/2012 03:16 PM, Bill Burke wrote:
>
>
> On 6/7/12 3:19 PM, David M. Lloyd wrote:
>> On 06/07/2012 02:06 PM, Bill Burke wrote:
>>>
>>>
>>> On 6/6/12 7:09 PM, Jason Greene wrote:
>>>> On Jun 6, 2012, at 5:32 PM, Bill Burke<bburke at redhat.com>     wrote:
>>>>>
>>>>> P.S. BTW Jason, I did comment multiple times on TAG-3 years ago.  I'd be happy to forward the emails.  What I said then was:  I don't want to be dependent on yet another logging abstraction and questioned why we were spending so many engineering hours on one.
>>>>
>>>>
>>>> Sure you ignored everyone's use cases, everyone's research and findings and then spent what 10 seconds of real thought to dump out some drivel about how everyone is over engineering and wasting time?
>>>
>>> I think the reasons for my approach to logging are valid.  I was wrong
>>> to assume 2 years ago that a simple old-school approach would be offered
>>> in parallel to the behemoth you created.  Sucks that my dead-simple
>>> approach cannot be accommodated.
>>
>> 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).
> 2. Add a maven plugin to generate code in your project
> 3. add generated code to your project
> 4. add X classes to your project and the permgen space associated with them.
> 5. Create a hard dependency to JBoss Logging or yet another maven plugin
> to shade in that dependency

I think I see where you're mistaken.

1 is a strength so I'm assuming you're not arguing about that.  2 is 
false; there is no maven plugin necessary, it's just a compile time dep 
(same as any annotation processor).  3 happens automatically.  4 is 
false; only the class corresponding to the loaded locale is loaded.

> vs.
>
> log.info(ID, Object... args);
> String msg = localization.generateMessage(ID, Object... args);

Uses at a minimum the same memory complained about in 4 plus more since 
you're actually duplicating the strings in your permgen, having lost the 
advantage of class loader interning.  Still requires a file with all 
your messages (equivalent to #1, just in a different syntactical form - 
one which your IDE can't help you with as much).  Loses type safety. 
Hoists most of the work to run time and increases runtime complexity 
substantially compared to a class that simply returns a string.

I can make a long bullet list about your solution as well.

> 2 function calls compared to X extra Classes, Y extra methods, Z extra
> annotations, one extra maven plugin, generated code, and an extra hard
> library dependency unless you shade it in with an additional maven plugin.
>
> To gain:
>
> * in all probability, an array index instead of a hash lookup to locate
> a message format.

An array index into your 1,000,000 element sparse array holding all your 
message IDs?  Or perhaps you'll count up from zero leaving no gaps, 
ever.  I don't see this as an improvement.

> * "Type safety".  for an interface that has *ONLY ONE REFERENCE* and of
> which type safety is meaningless considering all you're doing is
> generating strings.

It's only meaningless until your code trips a hard-to-reproduce bug, 
only to discover that you misspelled or mis-IDed your message and now 
you have a wrong or missing error message.  Or your program blows up on 
an exception because your format string is wrong (or one particular 
translation is) and you have no compile-time checking for it.  This *has 
happened* already and our compile time checking can detect and avoid 
this situation.  It *will* happen in a solution such as yours without 
compile-time tooling.  And once you have that you might as well go the 
rest of the way.

> Yup, pretty much a behemoth.

I don't see it, man.  The tooling is lightweight and the result has 
proven to be fast at runtime *and* very nice to use and convenient at 
development time.  We evaluated *all* the requirements - not just the 
ones you just thought of now - and came up with a solution that works 
well for everyone (except for you).  You need to let it go.

-- 
- DML