3:39 p.m.
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(a)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