I wanted to find out why HQ will not work with JDK 1.5. More specifically why HQ clients have to be on JDK 1.6. When we try using the HQ run-time libraries on a JMS client using JDK 1.5, we get:

Exception in thread "Thread-10" java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)

Why are the class files not backward compatible with JDK 1.5? Even though JDK 1.5 is EOL, that does not mean that all customers have made the switch to JDK 1.6. HQ could use JDK 1.6, but the byte code needs to be backward compatible. For a message production like HQ, where the bits (jar files) from the product have to be independently deployed with each JMS client, requiring a specific version of the JDK is a very harsh limitation. We have a 100+ JMS clients and its impractical to have to upgrade each one. Also in some cases we do JMS messaging from inside a third party product (eg. Tibco BusinessWorks). The specific version of the third party product that we use requires JDK 1.5. So if I wanted to use HQ, I would need to upgrade my entire BW infrastructure. Which is impractical.

The reason the HornetQ community project moved to Java 6 only, was because this is a general policy across all JBoss projects. Java 5 is EOL'ed etc, and if we stick to Java 5 that holds back the progress of the project since we cannot benefit from new language features or classes / APIs only available in Java 6.

Now, from a *product* point of view. The EAP product is Java 6 only, this is a decision made by Red Hat product managers, not the HornetQ project team. We have no control over that.

We can't limit the HornetQ server to Java 5 only, but we could consider producing an extra client library from our build - a special Java 5 client.

However, we can't really support a Java 5 client forever, since otherwise it will hold back what we do on the client side.

If the previous posting from Clebert is accurate that there is only a single java class that is being used which is JDK 1.6 specific, then I would say from the end-user perspective that the class should be replaced with one that will work with JDK 1.5. We have got to consider EAP and HQ differently. EAP is self-contained. HQ is not. Each messaging/JMS client needs to be packaged with 5 different jar files from the HQ install to function correctly. Messaging clients are distributed by definition and its impractical to ask for all clients to upgrade. If I have to upgrade a dozen or so EAP 4.X installs with EAP 5.X installs, thats possible. If I have to upgrade 100+ messaging clients and possibly other third party products, thats not going to happen.

As you may have seen, I have already opened a JBoss ticket on this issue. I do believe that for the officially supported JBoss messaging platform, Redhat product managers need to rethink the consequences of their decision. As I said in the ticket, what if I were an existing JBoss messaging 1.X customer with an extensive installed base. Would you expect all your JBoss messaging clients to upgrade to JDK 1.6? I quote what was said by a different user in a related thread (http://community.jboss.org/thread/152873):

This is an issue for us (and I am guessing a number of other organisations) where there are a number of legacy systems which are not certified for java 6. I'd like to use HornetQ as our enterprise JMS however the rework for testing and upgrading to an unsupported version of Java makes this non trivial (impossible).

Thanks

Aspi Engineer

These are the HQ libraries that we use on the client side to do JMS messaging. All of these will need to be made JDK 1.5 compatible.

I'm speaking here from a technical point of view: ATM we can easily support java 1.5 at the client. It's just that this can't be forever. (Otherwise we would still have to support JDK 1.2)

This would be a great news for me! I have been evaluating various JMS providers to replace the one used in our company, HornetQ 2.0.0.GA looked great - but then I had to ditch HornetQ because since the version 2.1.0.GA it became apparent that it cannot be used (and I mean a fully supported use, under paid RedHat support) by clients running with Java 5. Upgrading all legacy Java 5 clients to Java 6 would be such a huge task that it would prevent prevent our JMS provider upgrade project at all.

I'm speaking here from a technical point of view: ATM we can easily support java 1.5 at the client. It's just that this can't be forever. (Otherwise we would still have to support JDK 1.2)

This would be a great news for me! I have been evaluating various JMS providers to replace the one used in our company, HornetQ 2.0.0.GA looked great - but then I had to ditch HornetQ because since the version 2.1.0.GA it became apparent that it cannot be used (and I mean a fully supported use, under paid RedHat support) by clients running with Java 5.

That hasn't been decided yet. If we can make a strong enough case, we may be able to convince the powers that be that Java 5 client support is important.

This is not a new discussion, however, I am still looking for a solution.

I noticed that hornetQ-2.1.2.final is being delivered with two client jar files that are Java 5 specific. That is great. However as Aspi Engineer pointed out, there are 5 jar files required for the client to run stand-alone.

Aspi Engineer wrote:

These are the HQ libraries that we use on the client side to do JMS messaging. All of these will need to be made JDK 1.5 compatible.

hornetq-core-clientnettyhornetq-jms-clientjboss-jms-apijnp-client

What do we do with the other 3?

I have also attempted to compile the code myself for java 5 as was recommended at the end of discussion...

This is not a new discussion, however, I am still looking for a solution.

I noticed that hornetQ-2.1.2.final is being delivered with two client jar files that are Java 5 specific. That is great. However as Aspi Engineer pointed out, there are 5 jar files required for the client to run stand-alone.

Aspi Engineer wrote:

These are the HQ libraries that we use on the client side to do JMS messaging. All of these will need to be made JDK 1.5 compatible.

hornetq-core-clientnettyhornetq-jms-clientjboss-jms-apijnp-client

What do we do with the other 3?

I have also attempted to compile the code myself for java 5 as was recommended at the end of discussion...

If you are going to provide client jar files for us poor users that run with java 5 - can you provide all of the required client jar files?

If I am way off base can you please let me know that as well.

Thanks.

HornetQ does not require JNDI to function.

If you're just using core only hornet-core-client.jar and netty.jar are required on the client side.

If you're using JMS then you also need hornet-jms.client.jar (which contains the thin client side JMS layer) and jboss-jms-api.jar (which contains the JMS API classes).

If you want to use JNDI on the client side (this is *not* a requirement of HornetQ), then you also need the JNDI client jars for the JNDI provider you are using (those are the other jars).

(This is covered in the user manual)

HornetQ *does not* build the JNDI jars. They are not part of the HornetQ project. They're actually part of JBoss application server. If the JBoss AS guys not to support Java 5 any more on the client, that's not our decision to make, we don't have any control of that.

Having said that, I'm pretty sure there are JDK 5 compatible ones in AS4 or 5.

HQ 2.1.2 ships with Java 5 specific versions of hornetq-core-client and hornetq-jms-client. Using these two java 5 specific jar files, plus the regular jboss-jms-api, jnp-client and netty jar files from the same 2.1.2. distribution, you should be able to run a java 5 JMS client.

Howevre there may be compatability issues if the client and server versions of HQ do not match up. For example, I know from experience that 2.1.0.CR1 client libraries fail to send/receive messages from a 2.1.2.Final server. Other combinations may or may not work,