I used to use log4j because it was most popular, but recently decided to try JDK logger in my current project. I like that it is built into the JDK so there are no .jar dependencies, version conflicts, etc. All I need it to do is write to a disk file using a format String I specify, rotate logs after x KB, and to keep only y archived files. I'm just as satisfied with it as I was with log4j.

A while ago I did some reading about the history of logging frameworks to try and understand the hostility many developers still have towards JDK logger. From what I can tell log4j was the first widely popular logging framework in Java. Later, its ideas and general API design were standardized in JDK 1.4. The names of some things were changed, but the concepts are the same. There were many developers who did not want to require "the new" Java 1.4 so they continued with log4j. Later the commons-logging wrapper was created to provide libraries and applications the ability to use either log4j or JDK logger depending on what is present in the environment. Even today with the pending release of Java 1.7 many developers use log4j or commons-logging instead of the built in JDK logger.

My question to you is what is wrong with the JDK logger? Why do some people say it was disaster? Why don't you use it? I am not trying to start a flamewar, I am genuinely interested. Is it because log4j comes with many more built-in appenders such as NTEventLogAppender, JMSAppender, and SMTPAppender? I figure the JDK logger has only basic core handlers/appenders for the same reason JSF comes only with basic HTML UI components.

The other night I downloaded Java 6 Update 10 (JDK) and installed it on my Windows Vista laptop to test drive the new applets plugin. I found that some applets show off the speedy startup time better than others. For example, I would say that every one of the applets at Applet Depot loads and is usable nearly instantaneously. Interestingly, the DotToDot applet crashed Firefox 3 many times, but works now?

On the other hand, every one of Report Mill's JavaFX Gallery applets take a good 10-30 seconds or longer to load. I have to watch the orange Java logo and progress bar while they load. Even after they load, some of them show a blank screen for 10+ seconds. I wonder what they are doing differently? Does the progress bar in the orange Java logo indicate how much of the applet and/or dependencies have been downloaded so far? I know you can replace the orange Java logo with a custom animated GIF, but I don't know how you would make it interact with the applet plugin to be able to draw a progress bar like that.

This is an email I sent to the JSF 2.0 expert group. Since the final draft is scheduled for December 12 2008 I recommend JSF users contact the expert group NOW if you agree with my suggestions below, and if you have other gripes with JSF. jsr-314-comments-AT-jcp-DOT-org

The h:selectOneRadio renders an HTML table containing each radio button listed in f:selectItems or f:selectItem facets using most of the attributes in the h:selectOneRadio tag.

There are situations where the table layout is not desirable, such as in a table row where only one row among several may be selected. To do this with h:selectOneRadio I can place the following in each table row:

There are two issues with this:

1) The output of each one looks like this:

when all I really want is this:

Also there are many tables in my HTML output that have id="subscriptions" now which is illegal. If the h:selectOneRadio tag's existing layout attribute had a new "none" constant that rendered only the input component, then this issue would be resolved.

2) I must use a f:selectItem facet which seems unnecessary when wanting to output a single UI component, and it also makes it difficult or impossible to use in facelets templates. I've tried to think of ways h:selectOneRadio could be changed to render a radio button when no h:selectItem(s) are present (like h:selectBooleanCheckbox), and using a new name/groupName attribute. I don't think that will work because h:selectOneRadio's id attribute is used as both table id and for the name attribute in each rendered input component. The value attribute would probably clash too.

What JSF really needs is an equivalent of h:selectBooleanCheckbox that renders only one input component (no table), lets me specify the name/groupName, and works with facelets. I've suggested a new component in the past and the expert group decided not to do it in JSF 2.0 because the focus should be on extensibility etc. instead of new input components. If you search on Google for jsf radio button you'll be flooded with tons and tons of people coming up with hacks for using radio buttons in JSF. Every component library also has their version of radio button that makes it usable. If I want a usable radio button I currently need to add a component suite and all of it's bloated dependencies to my pages.

I still think adding a usable radio button component should be done in JSF 2.0, but if it can't be done then my first suggestion would be a good compromise for now.

I am really interested in hearing the expert group's thoughts on this. Do you guys use JSF in production systems, and haven't you found h:selectOneRadio to be too inflexible to be useful beyond the most basic of UIs?