As of version 0.8 of the JSR47 specification the
java.util.logging
API resembles log4j even more
than was the case previously. The way the two APIs name their
components may differ but otherwise their degree of
resemblance is quite striking.
Changes introduced in the latest 0.8 draft include
configuration order independence, appender inheritance,
resource bundle inheritance, error handlers and lazy inference
of caller information. In other words, even if the priority
levels remain unchanged and somewhat bogus, the majority of
the points raised in my critique
of JSR47 are now obsolete.
Consequently, it is fair to say that our campaign to
influence the JSR47 API handsomely bore fruit. I wish to thank
the hundreds of concerned users who have expressed their
support for log4j. My gratitude goes to Jason Hunter for
arranging the appropriate communication channel to Sun. Graham
Hamilton, the JSR47 specification lead, was very open and
receptive during our exchanges.
From the user standpoint, there remain two critical
differences. First, JSR47 requires JDK 1.4 whereas log4j is
compatible with JDK 1.1 and later. Second, log4j offers much
more functionality. It supports a rich configuration language,
at least a dozen appenders and layouts as well as many other
useful features.
Efforts to backport JSR47 to earlier JDKs are doomed to fail
because the java.util.logging
package is located
under the java
namespace. This will cause
backported code to systematically throw a
SecurityException
under JDK 1.3. Moreover, Java
is a trademark owned by Sun Microsystems. As such, the
backported code will be under the threat of litigation as long
as Sun can be expected to defend its trademark.
If you take the time to study the terms of the final draft of
the JSR47 specification, you will discover a copyright notice
containing the following text.
Sun hereby grants you a fully-paid, non-exclusive, non-transferable,
worldwide, limited license (without the right to sublicense), under
Sun's intellectual property rights that are essential to practice
the Specification, to internally practice the Specification solely
for the purpose of creating a clean room implementation of the
Specification that: (i) includes a complete implementation of
the current version of the Specification, without subsetting or
superset-ting; (ii) implements all of the interfaces and
functionality of the Specification, as defined by Sun, without
sub-setting or supersetting; (iii) includes a complete
implementation of any optional components (as defined by Sun in the
Specification) which you choose to implement, without subsetting or
supersetting; (iv) implements all of the interfaces and
functionality of such optional components, without subsetting or
supersetting; (v) does not add any additional packages,
classes or interfaces to the "java.*" or "javax.*" packages or
subpackages (or other pack-ages defined by Sun); (vi)
satisfies all testing requirements available from Sun relating to
the most recently pub-lished version of the Specification six (6)
months prior to any release of the clean room implementation or
upgrade thereto; (vii) does not derive from any Sun source
code or binary code materials; and (viii) does not include
any Sun source code or binary code materials without an appropriate
and separate license from Sun. The Specification contains the
proprietary information of Sun and may only be used in accordance
with the license terms set forth herein. This license will terminate
immediately without notice from Sun if you fail to comply with any
provision of this license. Upon termination or expiration of this
license, you must cease use of or destroy the Specification.
Given these business terms it is not possible for log4j or
other independent parties to implement the JSR47
specification. Here is how the Apache Software foundation, a
member of the JCP Executive Committee, voted on this
JSR.
The Apache Software Foundation is grateful for the significant
efforts of the JSR 47 spec lead, Graham Hamilton, toward addressing
the technical concerns raised by the members and lead of Apache's
log4j project. Regretfully, under the Merlin business terms, log4j
(or any other potential independent implementation of this
specification) cannot make use of the Specification, not can anyone
implement this specification for earlier J2SE platforms (J2SE 1.2,
1.3), and it is on this basis that Apache cannot support this JSR.
This problems is not specific to JSR47. Most other JSR
specifications contain similar business terms which are not
exactly designed to facilitate independent implementations.