views:

107

answers:

2

I'm a little confused about JBOSS and running it under different JDKs. For example, let's say I'm running JBOSS 5.1, and before starting it I set my JAVA_HOME to point to JDK5. Let's also assume that my JEE application is compiled under JDK6. If I deploy the JEE app (compiled under JDK6) to JBOSS, when I try to look up my EJBs I get errors like:

javax.naming.NameNotFoundException: tc_test_project not bound

But if I recompile my code under JDK5 and redeploy it, it works fine and is able to lookup the EJBs ok.

Likewise, I can set JAVA_HOME to JDK6 and start JBOSS, and my code (compiled under JDK6) will run ok under that scenario (it's able to find the EBJs, etc.).

So it seems that your JEE app needs to be compiled under the same JAVA_HOME that the JBOSS server is going to be running under, or am I misunderstanding something? Just wanted to get confirmation, thanks.

+5  A: 

The application must be compiled with the same or lower version of the JDK used to launch JBOSS. This is because the application will use the same JVM.

rodrigoap
Thanks for the clarification.
dcp
A: 

No, you should be able to compile with JDK6 as long as you pass -target 1.5 as an option so it outputs java 1.5 class files. Add -source 1.5 if you want to be flagged for using newer language features.

So it can be compiled with a newer JDK as long as you target the version of the VM that the application will be running under (and are only using features that exist in the target VM).

Rob Spieldenner
Doesn't that sort of defeat the purpose?
dcp
Its usefulness is on your local box so you can compile to any version, where as your production servers may have version restrictions (due to contractual or security issues).
Rob Spieldenner
This is not a safe thing to do. You can easily develop code that relies on classes and API's that don't exist in your target environment, thus giving you class not found errors. The target options will not fix this, it only addresses language features.
Robin
@Robin You can use https://animal-sniffer.dev.java.net/ to solve the problem you mention.
Pascal Thivent
@Pascal - Thanks for the info. Great for checking an existing codebase for compatibility, although if it was new code I would still just use the appropriate JDK.
Robin