The Java Community Process - Is Sun Listening?

cgu queries: "For those who are familiar with it, log4j is one of the most widely used Java libraries today. Sun Microsystems intends to ship an obviously inferior package with JDK 1.4. Is the Java Community Process just a fig leaf allowing Sun to ignore existing development efforts? What has been the experience of other Java developers with the JCP?" There's a bit of history here, so you'll probably want to check out the log4j pages linked to, above. This is a large concern for any language which has developed a community around it, who hopes to assist in its further development. So is Sun paying attention to the community that has rallied around Java or is the Java Community Process just paying lipservice to the intended ideal?

Comments

Re:This doesn't matter.

[aboyko]

No, this isn't comparable to that case at all. This concerns the default logging package available to all Java classes. With a standard implementation (which log4j quite arguably has been in the Java community, for several years) every code package can be written to use the same logging interface, knowing that it's up to the application to actually decide where and how and at what level the logging should be presented.

By providing a different, incompatible log interface in JDK 1.4, Sun provides strong incentive to developers to stop using log4j and instead switch to the "new standard". The result is that an existing "community standard" gets shoved out of the way by Sun's strongarm. The result is confusion, as developers waste time deciding which log package to use instead of just writing code. This is especially bizarre when log4j is an Jakarta project at apache.org; Jakarta is heavily supported by Sun, and there's no way Sun hadn't heard of log4j, given its widespread use. One must assume, then, that weird politics were involved...

The submitter of the question, it should be noted, is the author of log4j, but that doesn't invalidate his very good question, or his excellent and widely used work. Me, I'm just a happy user of log4j; if you write Java, you should be too.

This doesn't matter.

[topham]

You can fool all of the people some of the time, and some of the people all the time, but you can't fool all of the people all of the time.

Now, just replace fool with please and your done.

This is comparable to choosing to implement something other than Electric Fence in C; the impact on the entire community is negligable. If I choose to use a different logger it will not seriously impact anyone outside of the development group. It may mean the default is less than optimal, and people will use it without knowing there is an alternative which is better, but these are the same people who wouldn't know such a library existed now anyway.

Neither is wonderful

[Twylite]

Although I have not followed the process carefully, I have looked into both log4j and the JSR specification, and find both to be, well, less than ideal.

First, I am going to assume that the author(s) of log4j made representations on the relevent JSR, and didn't just keep quiet until it closed. The points they have brought up (in this article and in the log4j docs) are very true, and the JSR is certainly an inferior API.

However, Java is becoming increasingly bulked up with useless functionality. While debugging/logging is far from useless, the API presented by log4j is (in binary size) heavy, and IMNSHO a nightmare to use.

The idea of creating types to represent categories, used in both APIs, is a classic example of object overkill. Instead of simplifying code to make it easier to maintain, both these systems add an unnecessary amount of compilation to keep track of the category (amongst other things).

The ideal debug/log system should take a single line to invoke, and not have additional overheads.

Instead of striving for ultimate functionality in a less-than-perfect world, Java should be aiming for a small but effecient and highly usable core set of classes, and leave the bloatware to third-party libraries.

We still have and need a market for third-party software, and it is only through the innovation of extending a simple core that we can grow good software.

The JRE has bloated now from 5.5Mb to 8.8Mb. I've already had to develop two projects in C++ because I can make the distribution less than 650kb and not have to hastle (remote) customers to download and install the JRE ... this is worsening the problem.

Sun is on a mission to create the Ultimate Set of APIs, and call it Java. The "community" is on a mission to get everything they don't want to do themselves shoved into an Ultimate Library. Somewhere we need experienced, knowledgable experts who work in industry with languages, people, design and requirements, to moderate the whole process.

Twylite

Re:Neither is wonderful

[Twylite]

I will attempt to explain myself a little better (while the boss isn't looking). Maybe nightmare was a little strong, but there are still far simpler (yet as functioal) ways of archieving the same result. Let's start with the basic documentation examples:

Category cat = Category.getInstance("com.foo");
cat.setPriority(Priority.INFO);
cat.warn("Low fuel level.");

Problem #1: Ignoring the setPriority() call, this is identical in functionality to Debug.warn("com.foo", "Low fuel level.") [a static method], but requires extra source and binary space. Even if you have a static instance of a Category, the effect is the same: the category associates a string name with a "channel" of log output.

Why does this make a different? Clarity. Brevity. Simplicity. And it effects the use of aspect debugging: It is often useful to have log or trace statements associated not with a class or method, but the logical routine (which is a set of function calls to achieve some abstract result).

For example: Say I have a banking application (for an ATM) and one of the routines is "draw money". This is a clearly definable routine, and runs through many methods. Some methods are dedicated to "draw money", even though they are in different classes and different packages. When debugging, I wish to easily trace the path of the "draw money" routine (read: "grep 'draw money' debug.log).

Categories (and log4j in general) do not simplify this activity.

Hierarchical categories are of some benefit, but mostly they make it easier to determine what areas of code should have logging enabled or disabled.

The suggested use of categories in the documentation introduces unnecessary redundancy: the class name is already known, yet used to create a unique category and assist in enabling or disabling logging based on class/package hierarchies.

Take this scenario: In a multithreaded application I have several packages and dozens of classes. I have isolated a bug to one of ten methods across three classes, which are called by each other in some order. I want to reconfigure my logging output to display only debug statements from these methods, and then only when they are in a thread with a particular name.

This may seem to be a very specific problem, but there are more general cases of use for logging and especially remote debugging of live applications.

For its size and complexity log4j cannot simplify some of the logging tasks I consider "basic", forcing me to add extra lines of code I don't want to see. Taking one line out of a 10 line method makes it one line more readable ... and in a team development scenario where maintainance is important, I find that very significant.

I know this isn't a great dissertation on the evils of log4j, but its a start ;) As I'm typing this I'm savaging my bandwidth with the 2.18Mb download of log4j-1.1.2 ; has it struct anyone that this is awefully big for logging software ...?

Re:Neither is wonderful

[Twylite]

The ideal debug/log system should take a single line to invoke, and not have additional overheads.

No, this is not the ideal. You are oversimplifying the truth. In large projects, it is desirable to keep logging abstracted from the problem at hand ...

And using a single line to invoke a log statement prevents this how?
debug(facility, message); Quite simple, have multiple levels (the method call), facilities, etc.

Maybe I wasn't clear enough, and/or my words have been misunderstood. A certain amount of overhead to set up logging configuration is acceptable. Log statements should be a single line, with no overhead (say having to create/obtain a category object).

Log4J, for all its "complexity", lacks the ability to specify, from a central configuration point, a filter to determine what statements go where. Log4J's filtering is based on categories and nested diagnostic contexts, both of which are hard-coded into the software.

From a single-line debug statement (which includes a facility) it is an easy matter to filter based on any knowledge available: source file, class, method, thread, facility, priority, message content. It would become a matter of altering the configuration file to have "all FATAL messages from thread XYZ containing the word Wombat get logged to this.file".

Oh yes, that situation is n complexity, if you don't count the configuration overhead (1 line: Debug.loadConfig(file); ). In this situation Log4J is n+1 complexity, plus the use of NDCs are requiried. That adds a push and pop at times, so the complexity ranges from n+1 to n+4.

With regards to speed,

I never mentioned speed; it is not an issue in my development.

With regards to size, the core library is 78K. The complete library (core + utility classes that you can mix and match to your needs) is 159K. ... Is this going to make or break your hard drive capacity or is this simply an aesthetic gripe?

Hard drive capacity is obviously not a concern. Download size is a concern. Add 159k for the 8 new APIs introduced in the latest JDK version, and you have an extra 1.28Mb of libraries. And extra 1.28Mb that pushes Java more over the "reasonable download" limit.

A lot of people in the US (I'm assuming you are) don't realise how poor bandwidth is in some area of the world. I'm in a "moderate" bandwidth area - 56k dialup is common, ISDN is starting to make an appearance, and medium companies have dedicated 64k or 128k sync lines. Convincing someone to download an 8.8Mb file is not easy.

So are you complaining that people want to reuse code or that they don't want to waste time reinventing the wheel (two sides of the same coin)?

I have three complaints:

1. Sun is stifling growth and development of third-party components. Although I no longer directly depend on this for income, I know many people and organisations that do. One of Java's strengths is the suitability to component development.

Few people need all the APIs that are included in the JRE. Most software I have need to distribute does not require JDBC or Swing, for example. This is true of a huge amount of Java software. The JRE should be a runtime core, not an all-encompassing library.

I appreciate the need for code reuse, and the Java libraries are the single main reason I prefer the platform; but there is a point at which it becomes overkill. Distribute a core JRE, and have downloadable "extension" libraries, that software distributors can list are required for the functioning of their product.

3. (and most important) By adding the API to Java, Sun makes it a standard. Developers are keen to take advantage of standards, and the capabilities provided, so they will use them in preference to third-party components or APIs, even if the alternatives are superior. This is exactly the problem Log4J is facing: it is a better solution to the problem than Sun's intended solution, yet the inclusion of JSR47 will mean that most Java development will now use the Sun standard API. In other words, an API should NOT be included in the JRE core unless it is either fundamental to the modelling of the language, or is accepted as a de facto standard and the best known solution to the problem.

And finally, your C++ anecdote is somewhat misleading. I think you're taking for granted that the standard C and C++ libraries are installed by default on many systems.

Erm...no. The applications in question were compiled with Borland C++ Builder, and those libraries aren't standard on 'doze. The distribution was statically linked, completely. Once packages into a compressed self-executable install bundle, it was 673kb. A similar (but not fully functional) Java program to perform the same function was 112kb in a JAR, and required the JRE (with Swing, of course).

If you don't like Java, then don't use it.

On the contrary, I like Java. I have been using it since 1995. I would like to use Java exclusively, and am trying to convince managers and customers that it is a better solution. Unfortunately Sun's handling of certain issues, like the continual inclusion of new APIs -- especially when they're not necessary the best or accepted standards -- complicates the issue.

As a result I have had to resort to using the right tool for the job ... and for the jobs I have mentioned that tool was C++ (in fact, the project was specified as VB but the VB runtime is also too large to download, or to expect the customer to have...).

You can take a small, highly powerful jackhammer into a mine to rescue trapped workers ... but its useless unless you can get the 1 ton pneumatic generator close enough to connect the hose ...