>>I also feel, that rather than reinventing the wheel the JSR47 group
should
>>incorporate the log4j API rather than recreating it. The
standards put forth
>>by the JSR group will eventually replace any similarly functioning
external A
>PI
>>due to its incorporation into the JDK. For the number of
people who already
>>use log4j, such as myself, it feels that Sun by way of including
this new API
>>in the JDK is forcing users of log4j to switch. I understand
that there are
This is just business as usual at Sun. The position may sound
extreme,
but the continued marginalization of third party Java solutions is
destructive to the Java development community. It could almost
be
justified if the stuff that made its way into the core or a standard
was actually better than what was already out there, but most of the
time it's not and blatantly ignores the lessons learned by those who
have studied the problem for far longer and had the benefit of many
years of deployment and user feedback. A one year JSR working
group
operating in a vacuum generally produces results that are inferior to
a
solution with 4+ years of evolution.
Disclaimer: These are general comments that I do not intend to
specifically
apply to JSR-47. I have not reviewed JSR-47 or compared it to log4j,
so
I cannot comment on its quality. Nonetheless, the fact that none of
the
developers of the most popular Java logging API were invited to serve
as
a working group expert is a gross oversight. I can say the same
thing
about several other JSRs.
I hate to be such a complainer, but it really makes you feel
helpless.
The only recourse we have is to constantly poll the JCP site and
provide
as much feedback as possible when a JSR draft is released, which is
usually
too late to make any significant changes. Here's an article providing
a
general criticism about the Java Community Process:
daniel