The OpenJDK as the default Java on Linux

Hi All,  (this post is x-posted to the java7developer blog and the ljc blog)

Recently I've received a bunch of private correspondence from people confused/worried over the change in the default Java packaging for Linux. For many Linux distributions, the official Sun/Oracle version of Java has been packaged up as the default Java for the platform. However, due to a recent licensing change, this will no longer be the case! So, is this a positive or a negative thing for the Java and open source ecosystem? Read on for my take on it :-)

Background

Dalibor Topic announced that With Java SE 7 and JDK 7 being released, and with OpenJDK as the official Java SE 7 reference implementation, that it was finally time to retire the non open source "Operating System Distributor License for Java" (DLJ).

What does it mean for me?

The knock on effect of this is that Linux distributions will on longer package Oracle's Java (== OpenJDK wrapped up in some proprietary bits and pieces) as the default Java. This can/will cause problems for some Java users initially as there are a smattering of bugs (especially in the Swing UI libs) still left in the OpenJDK that affect programs like PCGen. However, some Linux distributions had already taken this path some years ago, most notably Ubuntu and the last remaining bugs are being cleaned up pretty quickly.

Positive or Negative?

Overall, I think this is a positive step in the right direction for free and open Java on Linux platforms. This sentiment was welcomed by well known open source advocate Simon Phipps in a twitter post. The fact the the OpenJDK is now the reference implementation (combined with efforts to open up the issue tracker for the OpenJDK) means that means that a vast host of Java/Linux end users can now directly improve 'official Java' for all of us. 

I want the Oracle version!

Linux users who need to use the proprietary parts of the Oracle JDK 6 or Oracle JDK 7 binaries can of course as usual simply get the gratis download at http://oracle.com/java under the same terms as users on other platforms. However, if it is due to a 'bug' that is discovered I strongly encourage those users to submit a bug report to the OpenJDK project, so that any issues can be fixed for all of us.

Opinions and further questions are welcome!

Thanks,

Martijn

JavaOne schedule

Here is my JavaOne schedule:  I can't mimic the nice colouring that Steve On Java has, but hey :-).


Please note the JCP EC meeting is open and free for all to join (Sunday 15:45) - we need the voice of the community there, so come along!


I'll actually be speaking at:

• 30440 - Java User Groups and the JCP (Sunday 14:30)
• 23647 - JCP and the Developer Community (Monday 11:00)
• 23641 - Meet the Executive Committee Candidates (Monday 1900)
• 23645 - Lightning Talks: JSRs in Progress (Wednesday 0830)
• 25303 - The Diabolical Developer (Redux)  (Wednesday 1500)
• 25303 - The Diabolical Developer (Redux) - repeat!  (Wednesday 1630)
• 37780 - Java Community Keynote (Thursday 0845)

Let me know if you want to catch up!  I'll be fairly flexible about turning up to most sessions, the benefit of attending a conference like JavaOne is as much isn't catching up with friends an colleagues as much as anything else :-)

JBoss - separating application logs without using monolithic jboss-log4j.xml

A minor irritant we've discovered in implementing applications for Jboss AS is that that the logging configuration for applications has to go through their monolithic jboss-log4j.xml file.

So we've managed to find a work-around (after some investigation of the Jboss class loaders and some trial and error).  This technique has been confirmed for jboss-eap-4.3 and jboss-4.2.3.GA but will likely work for other versions.

If you want to have split application logs and have that log4j.xml based configuration separated out (e.g. Not have it all in the jboss-log4j.xml file) then you can do the following.

1.) Your WAR/EAR must contain log4j-1.2.16.jar. It must be 1.2.16 or later as earlier versions don't work.

2.) The class loading for that WAR or EAR must have its java2ParentDelegation=false. So for example the jboss-app.xml file will look something like this:


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE jboss-app PUBLIC

      "-//JBoss//DTD J2EE Application 1.4//EN"

      "http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd">

<jboss-app>

  <loader-repository>${your domain}:archive=${your app name}.ear

    <loader-repository-config>java2ParentDelegation=false</loader-repository-config>

  </loader-repository>

</jboss-app>

Now this means that the WAR/EAR will use the log4j-1.2.16.jar for logging within its own classloader, i.e. It will not use Jboss's log4j.jar library (and therefore the jboss-log4j.xml won't be used).

3.) In the MANIFEST.MF file in your WAR/EAR archive you need to set a Class-Path: entry that shows the location (directory) where the log4j.xml file that you want to use will reside. For example if your EAR file is deployed in the deploy directory, your Class-Path reference might be something like this:

Class-Path: ../conf/log/${application name}/

4.) Your log4j.xml file should just be an ordinary one, with no references to any special jboss classes. However, it will have an appender with the specifc name for the log file for the application you want to log for, e.g.

  <appender name="${module.name}" class="org.apache.log4j.RollingFileAppender">

    <param name="File" value="${jboss.server.home.dir}/log/${module.name}.log"/>

    <param name="Threshold" value="INFO"/>

    <param name="Append" value="true"/>

    <param name="MaxFileSize" value="2MB"/>

    <param name="MaxBackupIndex" value="20"/>

    <layout class="org.apache.log4j.PatternLayout">

      <param name="ConversionPattern" value="%d{yyyyMMdd HH:mm:ss.SSS} %-5p [%t] %C{1}.%M(): %x %m%n"/>

    </layout>

  </appender>

5.) OPTIONAL: You can still have all of your logging also go to the shared central $JBOSS_HOME/${instance}/log/server.log file by adding the following to your log4j.xml file:

  <appender name="all" class="org.apache.log4j.RollingFileAppender">

    <param name="File" value="${jboss.server.home.dir}/log/server.log"/>

    <param name="Threshold" value="INFO"/>

    <param name="Append" value="true"/>

    <param name="MaxFileSize" value="2MB"/>

    <param name="MaxBackupIndex" value="20"/>

    <layout class="org.apache.log4j.PatternLayout">

      <param name="ConversionPattern" value="%d{yyyyMMdd HH:mm:ss.SSS} %-5p [%t] %C{1}.%M(): %x %m%n"/>

    </layout>

  </appender>

I've updated the Jboss community wiki with this information (thanks for pointing out the location Jaikiran!).

PCGen - An awesome online community

Hi all,

Just a brief note on one of the important points in running a successful Open Source community. A key ingredient is to give immediate feedback to users that post on your forums and mailing lists.

An attitude of 'Go and find it yourself Newb!' is not a particularly healthy way to attract new users to your community. Don't forget that a new user is potentially a new volunteer for your project!

PCGen _excels_ in this area, no question big or small is left to rot on its boards and the responses are always cheery and polite. If you're looking for an example of how to respond to your users, look no further than the various mailing lists that exist under the PCGen banner (you can find them via the website).

The Ubuntu forums are another fames place for this type of attitude and it's certainly helped build their popularity as well.

So here's a public thank you to the tireless volunteers and community users who take the time and effort to continuously reply to the tons of queries we get at PCGen, well done to you all!