Skip to Main Content
Forums

Java APIs

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

java.lang.UnsupportedClassVersionError

843793Jul 11 2005 — edited Jul 15 2005
hi!

I have a simple RMI app that writes something on a text file (client) and prints the file content (server). During execution, it gives this error:

Exception in thread "main" java.lang.UnsupportedClassVersionError: server/ServerImpl (Unsupported major.minor version 49.0)

i following these steps from http://engronline.ee.memphis.edu/advjava/misc/rmi2.htm:

File Directory: C:\RMISample\*.java
Class Directory: C:\RMISample\server\*.class, C:\RMISample\client\*.class

1. Place interface class, which extends Remote on the client and server.
2. Place class extending RemoteObject on server.
3. Generate stubs and skeleton by running rmic. Copy the stubs to the client.
4. Start the registry on server.
5. Start program that creates and registers objects on the server.
6 Run program that looks up server objects and invokes remote methods.

I'm not sure how to do steps 5 and 6, though (i did java server.ServerImpl)

thanks in advance...

Comments

843793
there we go again...

You're running a 1.4 or earlier JVM and are trying to run 1.5 classfiles.
843793
thanks jwenting...

how can i make it compatible with jdk1.5?
843793
it already is :)

It's your Java RUNTIME which is 1.4 or older, while your compiler is 5.0 and thus generates 1.5 classfiles.

Make sure you get rid of any old java and javaw exes on your path (doublecheck your path environment as well as your windows directory (and everything under it).
843793
Answer: use the -target switch when compiling, this will generate 1.4 compatible bytecode from a 1.5 compiler.

The lack of forward compatible bytecode has been a real 'deal-breaker' for using 1.5 in any type of RMI or Jini applications.

Sun really blew it on this one.
EJP
Sun really blew it on this one.
How? They introduced new features into 1.5, changed the class file format to support them, and provided a switch so you could get the 1.4 format. The only alternatives to this are (a) to find a way to support the new features without class file format changes, which was not possible AFAIK, or (b) not to introduce the new features.
843793
This has a major, devastating impact specifically on mobile code based applications. With an installed base of 1.4 and lower JREs numbering in the millions; a class file format change is effectively equivalent to a complete VM architecture change. I am still astonished at Sun's foolhardy disregard for compatibility.

For most applications, the benefit of having compatible bytecode far outweighs any new, yet incompatible, features.

Hopefully Sun can figure out, as you wrote, how to support these new features in a compatible format, with the release of 1.6. Then 1.5 would rightly become the embarrassing mistake Sun refuses to talk about.

In essence, 1.5 is an absolute 'no-go', in the massively distributed computing community.

Ultimately, they forked their user base, without even realising it.
EJP
This happened in 1.4 as well didn't it? and 1.3?

I've been a compiler vendor and let me assure you that it is unrealistic to expect complete compatibility between releases when you are adding features: sometimes you just have to break things.

The important thing is to provide a way to get the old behaviour, and Sun have done this. If you want 1.4 code you can get it, if you want the new features you can get them, you just can't have both at the same time.
843793
Seems to me the OP doesn't understand the real world.

What's holding up Tiger adoption is mainly inertia at this time. Companies have projects running on 1.4 and aren't willing to risk moving to a new version of the language in the middle of those projects (never mind that the porting risks are minimal as I know from personal experience).
dcminter
The lack of forward compatible bytecode has been a
real 'deal-breaker' for using 1.5 in any type
of RMI or Jini applications.

Sun really blew it on this one.
You're describing backwards compatibility. Forwards compatibility is precisely what Sun delivered.
843793
To Dave: No, the problem is forward compatibility. I.e. the new classes do not work in older JREs. Granted, forward compatibility much harder to maintain than backward compatibility.

To Esmond: The problem is an incompatible class format change, this is a really big deal. For example, I develop for an embedded J2ME platform, which is only 1.1.8 compatible. I use the 1.4.2 JDK and it works just fine. If use 1.5, without the -target switch, it will crashes.
843793
1.4 classfiles won't work under a 1.1 JVM unless you take special care (like using the -target flag and not using anything introduced since 1.1).
Nothing different with 1.5.

If you want to use 1.5 features, get your JVM supplier to supply a 1.5 compatible JVM.

Don't blame Sun for your own lack of understanding and stupid ideas.
843793
> 1.4 classfiles won't work under a 1.1 JVM unless you take special care
> (like using the -target flag and not using anything introduced since 1.1).
> Nothing different with 1.5.

Incorrect. They work perfectly; exactly the opposite is true for 1.5.

> If you want to use 1.5 features, get your JVM supplier to supply a 1.5 compatible JVM.

Again incorrect. No specification exists for J5ME. Besides, some of us actually develop for customer's VMs.

> Don't blame Sun for your own lack of understanding and stupid ideas.

Yet still you wonder why no one takes you seriously?
dcminter
To Dave: No, the problem is
forward compatibility. I.e. the new
classes do not work in older JREs. Granted, forward
compatibility much harder to maintain than
backward compatibility.
You have the terms exactly the wrong way around.

Backwards compatibility is when today's compilation works on yesterday's platform. Forwards compatibility is the opposite.

Forwards compatibility guarantees that the code you write today will work tomorrow.
843793
The terms are unquestionably unintuitive.

So I tracked down an authoritative definition, just for you:

http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=forward+compatibility&action=Search

So, one day, should we ever meet up; you owe me a beer ;-)
dcminter
Ahem. I think the beers are on you.

I said: "Forwards compatibility guarantees that the code you write today will work tomorrow."

FOLDOC says: "[...] a forward compatible system needs to cope gracefully with unknown future features" (my emph.)
dcminter
Actually perhaps I do owe you a beer. I'm looking at this from the perspective of the class file: My compiled output will work in the current version and all future versions. Hence it is forward compatible (copes with unknown future changes).

You're looking at it from the perspective of the JVM. My JVM will work with contemporary class files but may barf on future ones.

Interesting. I'm going to have to have a think about that...

Dave.
843793
It is an interesting mental exercise. :-)
843793
> 1.4 classfiles won't work under a 1.1 JVM
unless you take special care
(like using the -target flag and not using
g anything introduced since 1.1).
Nothing different with 1.5.

Incorrect. They work perfectly; exactly the
opposite is true for 1.5.
Wrong.
J2ME 1.1 (which you're talking about here) is backed by J2SE 1.4.
That's why your 1.4 classfiles work on it.
J2SE 1.4 classfiles don't work on a J2SE 1.1 JVM.
> If you want to use 1.5 features, get your JVM
supplier to supply a 1.5 compatible JVM.

Again incorrect. No specification exists for J5ME.
Besides, some of us actually develop for
customer's VMs.
That's your problem, not Sun's.
If there's no 1.5 compatible JVM for the platform it's up to the platform manufacturer to provide a JVM.
If there's no 1.5 compatible J2ME spec, tough luck on you and go back to a spec that is supported.
> Don't blame Sun for your own lack of
understanding and stupid ideas.

Yet still you wonder why no one takes you seriously?
Still wondering why you're as selfcentered as a top?
You don't seem to even know the differences in versioning between editions.
843793 
/ignore jwenting
Hated to do that, but unfortunately I have a very low tolerance for trolls.
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=troll
dcminter
If you're ignoring him why are you responding to him? Frankly your responses are the more troll-like.
EJP
The only other alternative apart from no new features would be for Sun to release JDK 1.5, JEE 1.5, J2ME 1.5 &c all at the same time. This big bang theory is not practical either.
1 - 21
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Aug 12 2005
Added on Jul 11 2005
#remote-method-invocation-rmi
21 comments
143 views