invoking java 7 jar in java 6 client code.

Manjit

I have java 6 running in my machine.I compile my java 6 client that is invoking third party java 7 API (jar file).While compiling I get warning that

"major version 51 is newer than 50,the highest major version supported by this compiler.It is recommended that the compiler be upgraded"

I ignore the warning ,and run my client.

Then I get this error "UnsupportedClassVersionError...Unsupported major minor version 51.0

Interestingly I get the above error in the second call below !I thought the error should have been received in the first call itself.

            //java 7 api call

            ApiFactory.initialize();

            //another java 7 api call

            ApiSecurityCallback securityCB = new DefaultSecurityCallback("Guest", "Guest");

Infact I was expecting compilation error !

Can someone solve the mystery.

thanks

manjit

handat

Exactly. By using third party APIs compiled with version 7, you are potentially running code that is not compatible, hence the warning during compile. Unless the APIs were compiled with JDK 7 using the -target option designating version 6 or below compatible bytecode, then this is expected.

morgalr

Here is where my head goes from experiences I have had:

You are compiling only your code and referencing the library from the more recent version. The entry points are supported as in the previous versions of Java, so until you actually get to runtime and reference code that is not supported, you are good to go.

I have run many a project that has been compiled on later versions of java than clients support, and it works, as long as you do not use any features of the new version not supported in the old.

Les

rpc1

Simply run project in java 7 environment. You can't run jars compiled with java 7 in Java 6 enviroment

morgalr

Actually you can, or at least you used to be able to do so, if, and only if, you don't use ANY of the new features listed in the newer environment.  We compiled and ran version 5 from version 6 and from version 7 for quite some time.

<edit added comment>

Actually you should probably make that we ran on a Java 2 based server when we developed using 3, then 4, then 5.  Each time we had to make sure we didn't use any of the features that were not byte code identical to version 2.

</edit added comment>

handat

Exactly. By using third party APIs compiled with version 7, you are potentially running code that is not compatible, hence the warning during compile. Unless the APIs were compiled with JDK 7 using the -target option designating version 6 or below compatible bytecode, then this is expected.

Unknown

Can someone solve the mystery.

You can solve that mystery yourself by using Java 7 to execute jars/classes compiled for Java 7.

If you want us to evaluate/analyze your code then you need to post ALL of the needed code.

No one can debug/analyze code that they cannot see. We have NO IDEA what jar/class files your code is using or what ApiFactory class you are referring to.

You say it is a Java 7 call - please post a link to the Oracle Java 7 API for the ApiFactory class in Java 7.

836548

You need to understand, What is compile time error and runtime error.

The error you mentioned has nothing to do with compile time, as it got the supportive class which identifies the method and nothing wrong with syntax.

It gave runtime time error, as it didn't find the supportive version of JDK with which it was compiled earlier.

Manjit

Thanks handat.This is what I believe might happened.I confirmed with the API developer too .Thanks again

Manjit

Thank you Morgair.Did some research based on what you said,and got more informations.

Thanks again

morgalr

And that is exactly what I said in my original post--the entry points are the same, but the byte code is not compatible from the 7 for at least some features used.

Unknown

And that is exactly what I said in my original post--the entry points are the same, but the byte code is not compatible from the 7 for at least some features used.

It isn't necessarily what 'features' are used.

Each class file has the major and minor versions embedded in the header. The class loader of the runtime checks the version numbers against the version of the runtime and simply won't load later class files.

See the Class File Format chapter of the JVM Spec

https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html