-
1. Re: HornetQ and JDK 1.5
clebert.suconic Jun 18, 2010 11:01 AM (in response to aengineer)Someone asked this same questions about 2 days ago:
http://community.jboss.org/thread/152873?tstart=0
I guess we should keep 1.5 by default on our target and source properties during compilation.
But on the server, we require java 1.6, as there is a Collection class that is only available on java 1.6
I will propose also a compilation target in our build system to ensure we won't add new java 1.5 dependencies on the client. (at least not until we decide nobody is using it any more).
-
2. Re: HornetQ and JDK 1.5
timfox Jun 18, 2010 4:52 PM (in response to clebert.suconic)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.
-
3. Re: HornetQ and JDK 1.5
aengineer Jun 18, 2010 1:11 PM (in response to timfox)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.
hornetq-core-client
netty
hornetq-jms-client
jboss-jms-api
jnp-client -
4. Re: HornetQ and JDK 1.5
clebert.suconic Jun 18, 2010 3:44 PM (in response to aengineer)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)
-
5. Re: HornetQ and JDK 1.5
leosbitto Jun 18, 2010 4:01 PM (in response to clebert.suconic)Clebert Suconic wrote:
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.
-
6. Re: HornetQ and JDK 1.5
timfox Jun 18, 2010 4:39 PM (in response to leosbitto)Leos Bitto wrote:
Clebert Suconic wrote:
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.
-
7. Re: HornetQ and JDK 1.5
garneke11 Oct 4, 2010 11:42 AM (in response to timfox)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-client
netty
hornetq-jms-client
jboss-jms-api
jnp-clientWhat 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...
http://community.jboss.org/thread/152873?tstart=0
However, I was unsuccessful.
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.
-
8. Re: HornetQ and JDK 1.5
clebert.suconic Oct 4, 2010 9:31 PM (in response to garneke11)We're only supporting clients on JDK 1.5. Server will be 1.6+.
-
9. Re: HornetQ and JDK 1.5
timfox Oct 5, 2010 4:28 AM (in response to garneke11)Kent Garner wrote:
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-client
netty
hornetq-jms-client
jboss-jms-api
jnp-clientWhat 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...
http://community.jboss.org/thread/152873?tstart=0
However, I was unsuccessful.
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.
-
10. Re: HornetQ and JDK 1.5
aengineer Oct 5, 2010 10:30 AM (in response to aengineer)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,
- Aspi Engineer
Putnam Investments
-
11. Re: HornetQ and JDK 1.5
clebert.suconic Oct 5, 2010 11:05 AM (in response to aengineer)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,
That's regardless of JDK 1.5, which will be fixed on the next version (2.2 and 2.3 will further improve it) with the versioning support on the protocol.
-
12. Re: HornetQ and JDK 1.5
garneke Oct 5, 2010 11:09 AM (in response to aengineer)Thanks for your help.
-
13. Re: HornetQ and JDK 1.5
timfox Oct 5, 2010 11:13 AM (in response to clebert.suconic)Clebert Suconic wrote:
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,
That's regardless of JDK 1.5, which will be fixed on the next version (2.2 and 2.3 will further improve it) with the versioning support on the protocol.
+1
Protocol compatibility is an orthogonal issue to Java compatbility.
Currently, you MUST use the versions of HornetQ client and server shipped with any particular release together. This is deliberate.
Going ahead we will probably introduce some more flexible rules for protocol compatibility.