Home/ Questions/Q 7802013
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T01:07:45+00:00

The question first, the story will follow: Is it safe to mix different bytecode

  • 0

The question first, the story will follow:

Is it safe to mix different bytecode version in a class hierarchy? What are the risks?

For a case, Class C extends B, Class B extends Class A. Class A implements Interface I.
My question would involve following example scenarios:

  • Class A compiled to Java 1.6 bytecode, and have 1.6 features such as generics, etc. The heirs, which are B and C was compiled to 1.4 bytecode.
  • Interface I compiled to 1.6, while the implementor compiled to 1.4.
  • Other exotic inheritance scenario involving different version of bytecode.

I have tried as many scenarios I could imagine and it seems to run just fine. However I still feel the urge to ask here as I only know Java at the surface; i know how to code and tweak Java but don’t really know what happen under the hood.

Now for those minds who can’t help themselves to ask “why would you need to do that???”.

I’m in a project to assess the migration of legacy Java 1.4 Swing app, connected to EJB 2 via RMI, to Java 1.6 Swing connected to newer version of App Server running on top of 1.6 also. The J2EE platform will still be 1.4 (EJB 2).

The migration will not be “recompile everything to 1.6”, but it will be “code and compile new features to 1.6”.
The way they do things is like this:
They only have one path in the CVS, everyone commits there. No tags/branches whatsoever to get the production code.
Whenever a new feature need to be added, they get the JARs from production server, explode them, replace or add new classes as needed, repackage the jars, put them back to server.
Therefore, if they will use Java 6 to compile and using the above method for deployment, there will be a lot of exotic mixes of 1.4 and 1.6 bytecodes.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The JVM byte code is not siginificantly different between Java 1.0 and Java 6. In Java 7 they add one new instruction. Woohoo.

    There are so little changes in how the byte code works that

    • The JVM doesn’t support nested classes accessing private members of outer classes, this works through generated code.
    • The JVM doesn’t support runtime checks for generics e.g you cannot new T() where T is a generic.

    Basically, they make the JVM smarter and faster but until recently changing the model of how the byte code works has been avoided at all costs.

    • 0