How compatible is Java betweeen versions?

[Don Bruder]

Bear with the newbie...

I'm thinking in terms of "new code fed to old compiler". As in, I've got
an older compiler (and due to financial and hardware constraints, I'm
going to continue having the "old" one for the forseeable future) - It
shipped with the JDK 1.1something (I'm very hazy on what version it's
supposed to be, but it APPEARS to be 1.1 or 1.1.1) stuff, if I'm reading
things correctly - but I've got a wad of code I need to work with that
was developed using at least the 1.4.2 JDK - perhaps even newer, but I
can't tell for sure - that I need to compile.

Is throwing this code at the compiler I have going to give me a useful
result, or have things changed enough between 1.1 and 1.4.2 to make the
code I've got unrecognizable garbage to the compiler I have?

On a closely related note, I'm finding that a lot of the java.something
and javax.something imports in the code I'm trying to work with simply
don't exist - As in not there at all, whether in plain sight, disguised
as something else, or otherwise - under the version of the JDK that came
with the compiler I have. Is it advisable/safe/otherwise useful to
simply snatch the code chunks I need from 1.4.2, and use them along with
my existing 1.1whatever-it-is JDK stuff? Or is that going to do nothing
but blow me to the dark side of the moon?

If "mixing and matching" JDK version code is inadvisable, would I be
safe in simply grabbing the 1.4.2 stuff, dumping my 1.1something stuff,
and feeding the compiler on that? (which comes right back to the first
question - Will the 1.1something compiler cope with 1.4.2 JDK elements?)

I've been thinking of the various "java.whatever", "javax.whatever", and
so on modules in terms of my fairly extensive C experience - Figuring
they (at least roughly) correspond to libraries, only they seem to be
stored in source form, rather than object code form. I'm thining that
since they're stored in source form, it should be easy enough to
recompile, allowing me to make this project work. This, of course,
assumes that the compiler isn't going to choke to death on them... Does
this even come somewhat close to being a reasonable assumption?

On the other hand, I'm new enough to Java that I know I can't safely
assume this is reality, and so far, haven't managed to come up with
enough information to decide if it's worth making the attempt or not.
(It's a rather large chunk of code that I'll be trying to work with)

I guess what I'm asking boils down to this:
Can newer Java code be *PRACTICALLY* compiled with an older compiler, or
is the "back-conversion" going to involve more headache than any sane
person would consider dealing with?

 

[jan V]

Hi Don,

Glad to see you've survived the mauling a few days ago (-verbose=brief ...
please!)

Is throwing this code at the compiler I have going to give me a useful
result, or have things changed enough between 1.1 and 1.4.2 to make the
code I've got unrecognizable garbage to the compiler I have?

1.4 introduced the "assert" keyword into the language, so that will make
your 1.1 compiler choke (if asserts are used).

On a closely related note, I'm finding that a lot of the java.something
and javax.something imports in the code I'm trying to work with simply
don't exist - As in not there at all, whether in plain sight, disguised
as something else, or otherwise - under the version of the JDK that came
with the compiler I have. Is it advisable/safe/otherwise useful to
simply snatch the code chunks I need from 1.4.2, and use them along with
my existing 1.1whatever-it-is JDK stuff? Or is that going to do nothing
but blow me to the dark side of the moon?

I guess that may work... provided the .class file embedded version numbers
don't make your old compiler choke.

If "mixing and matching" JDK version code is inadvisable,

I'd say it's unorthodox to say the least, probably inadvisable, yes.

I've been thinking of the various "java.whatever", "javax.whatever", and
so on modules in terms of my fairly extensive C experience - Figuring
they (at least roughly) correspond to libraries, only they seem to be
stored in source form, rather than object code form.

No, actually they're stored in object code form... or to use the correct
language: .class files bundled into jars (ZIP files, essentially).

I'm thining that
since they're stored in source form, it should be easy enough to
recompile, allowing me to make this project work. This, of course,
assumes that the compiler isn't going to choke to death on them... Does
this even come somewhat close to being a reasonable assumption?

Nowadays you can download the COMPLETE source codes for the entire JDK,
including the C source files needed to produce machine-specific files (DLLs,
etc..) used by "native" elements in Java classes.

On the other hand, I'm new enough to Java that I know I can't safely
assume this is reality, and so far, haven't managed to come up with
enough information to decide if it's worth making the attempt or not.
(It's a rather large chunk of code that I'll be trying to work with)

My burning question is: why don't you just work with the 1.4 or 1.5 JDKs?
Why do you have to use a 1.1 compiler? Seems very odd....

 

[Monique Y. Mudama]

["Followup-To:" header set to comp.lang.java.help.] On 2005-08-02, Don
Bruder penned:

Bear with the newbie...

I'm thinking in terms of "new code fed to old compiler". As in, I've
got an older compiler (and due to financial and hardware
constraints, I'm going to continue having the "old" one for the
forseeable future) - It shipped with the JDK 1.1something (I'm very
hazy on what version it's supposed to be, but it APPEARS to be 1.1
or 1.1.1) stuff, if I'm reading things correctly - but I've got a
wad of code I need to work with that was developed using at least
the 1.4.2 JDK - perhaps even newer, but I can't tell for sure - that
I need to compile.

Is throwing this code at the compiler I have going to give me a
useful result, or have things changed enough between 1.1 and 1.4.2
to make the code I've got unrecognizable garbage to the compiler I
have?

I don't understand your use of the term "compiler." I'm thinking what
you mean is IDE, but I'm not sure. If you mean javac, etc, I have no
idea why financial or hardware constraints would limit you.

I think you'll be least miserable if you just bite the bullet and use
a modern JDK. There have been roughly a bazillion additions to the
JDK between 1.1.x and 1.4.x, including IIRC all of Swing. I have an
ancient copy of Java in a Nutshell for 1.1; a coworker has the same
for 1.4. His book seems to be about twice as thick.

I guess what I'm asking boils down to this: Can newer Java code be
*PRACTICALLY* compiled with an older compiler, or is the
"back-conversion" going to involve more headache than any sane
person would consider dealing with?

Dunno about a sane person, but I certainly wouldn't choose to do so.

 

[Roedy Green]

I'm thinking in terms of "new code fed to old compiler". As in, I've got
an older compiler (and due to financial and hardware constraints, I'm
going to continue having the "old" one for the forseeable future)

the Java compilers, both Sun and Jikes, are free, so there is no
reason to use an old one for financial motives. Jet is not free. Is
that what you are referring to?

If you mean the IDE, there are free up to date ones too, such as
Eclipse.

See http://mindprod.com/jgloss/ide.html

Basically the differences between versions are these:

1.1 totally new event model. Almost no one tries for 1.0 compatibility
any more.

1.2 added ArrayList and other collections.


1.3 adding Swing.

1.4 added assertions, nio.

1.5 added generics, enumerations.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

Is throwing this code at the compiler I have going to give me a useful
result, or have things changed enough between 1.1 and 1.4.2 to make the
code I've got unrecognizable garbage to the compiler I have?

Code has not changed, except between 1.0 and 1.1, and even then the
old code still works. It has merely been added to. If you read a 1.3
level textbook you would never be aware you were compiling its
examples with 1.5, other than some warning messages. You can even set
-target 1.3 -source 1.3 to make the compiler conform to the old
language standard.

Java is entering its dotage. You can tell by the ugly ad hoc syntax
for generics and annotations. The underlying class library should be
reborn in something more C# like.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

On a closely related note, I'm finding that a lot of the java.something
and javax.something imports in the code I'm trying to work with simply
don't exist - As in not there at all, whether in plain sight, disguised
as something else, or otherwise - under the version of the JDK that came
with the compiler I have. Is it advisable/safe/otherwise useful to
simply snatch the code chunks I need from 1.4.2, and use them along with
my existing 1.1whatever-it-is JDK stuff? Or is that going to do nothing
but blow me to the dark side of the moon?

That is not a game for the novice. If you want to use Swing, for
example, you had better use at least 1.3.

Some things you have to download like JMF, JavaMail and JAF. Look up
them up in the Java glossary for the download URL.

Just click the main definition word.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

I've been thinking of the various "java.whatever", "javax.whatever", and
so on modules in terms of my fairly extensive C experience - Figuring
they (at least roughly) correspond to libraries, only they seem to be
stored in source form, rather than object code form. I'm thining that
since they're stored in source form, it should be easy enough to
recompile, allowing me to make this project work. This, of course,
assumes that the compiler isn't going to choke to death on them... Does
this even come somewhat close to being a reasonable assumption?

Though you have to the source to most of everything in src.zip, you
don't have the native methods -- ones written in C with platform
specific code. You will find nearly every package has a core of such
methods. The only way to get them is to get the jar with the native
classes.

Just get the latest compiler and be done with it. Whatever problems
you have will be minor compared with the headaches your are
contemplating bringing on yourself mixing versions.


see http://mindprod.com/jgloss/jdk.html


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

I guess what I'm asking boils down to this:
Can newer Java code be *PRACTICALLY* compiled with an older compiler, or
is the "back-conversion" going to involve more headache than any sane
person would consider dealing with?

There are two ways to do back compilation:

1. actually install an old JDK and compile.

2. compile with JDK 1.5 using -target


1. ensures for certain you don't use methods that did not exist back
then.

2. ensures you have the least buggy compiler.

You may notice me asking from time to time when such as such a feature
was introduced. I am doing that so that I know if it safe to use that
feature in version 1.1 code I am trying make backward compatible.

I have my packages grouped by 1.1 1.2 1.3 1.4 and 1.5. I move
packages around as I find it is safe to push them back in
compatibility or say what the hell, and move them to the 1.5 and stop
trying to code with my hands behind my back. I have spend much of the
last month splitting packages into a 1.1 and 1.5 part so that the
backend can be done in 1.5 but the Applet part the public uses is 1.1
or 1.2 compatible. Without Eclipse, this would have been nightmare.

There are some hints in the @since javadoc in Sun's code.

The only way to find out for sure is to run the code on an old 1.1
JVM. I don't have the patience to do that.

you might be interested in my student project to make this work
easier: http://mindprod.com/projects/jdkversion.html

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Thomas Hawtin]

2. compile with JDK 1.5 using -target


1. ensures for certain you don't use methods that did not exist back
then.

You will also want to use -source and -Xbootclasspath to point to the
classes of an old JRE (-bootclasspath on older JDKs). For instance
compiling new StringBuffer().append(new StringBuffer()) on 1.4 with
-source 1.3 -target 1.3 still wont run on 1.3.

2. ensures you have the least buggy compiler.

I don't know. With the changes to 1.5 has it come back up to the very
high standards of the last 1.4.2? True of older versions. I remember
getting very frustrated as a project went live and I couldn't run my
alterations as JDK 1.1 javac was producing illegal byte code.

Tom Hawtin

 

[Don Bruder]

How many replies are you going to post for a single message???

Though you have to the source to most of everything in src.zip, you
don't have the native methods -- ones written in C with platform
specific code. You will find nearly every package has a core of such
methods. The only way to get them is to get the jar with the native
classes.

Just get the latest compiler and be done with it.

For my hardware/OS combination, that appears to mean "the one I've got
now". Unless you're aware of a Java implementation for MacOS 9.1 and
earlier that speaks "modern" Java.

If you're planning on saying something similar to "Then upgrade your
OS", save it. I'm up against the wall with this machine. And if you in
turn intend to say "Then get a new machine", stow THAT, too. Unless, of
course, you're planning on handing me the money for it.

Which is where the financial limitations I mentioned come into play -
There's no way in hell I'm going out and buying a new computer at this
point - Between the "don't want to" and the "can't afford to even if I
needed to to save my life", I'm stuck with what I've got. I've got the
proverbial "champagne taste" - I DO like the idea of having the biggest,
newest, etc., but unfortunately, I'm stuck with a "drink tapwater and be
glad you've got that instead of sewage" budget when it comes to buying
computer hardware.

So I make do with what I have. But, my PowerMac 7500, even jacked up to
a G4 processor as it is, simply *WILL NOT* install MacOS X, regardless
of how many times and ways I try to finagle it into happening, and
despite hundreds of people online all telling me that they've got THEIR
7500 to run X. To run the copy of it I've got sitting here on the desk,
I need new hardware - Something I simply cannot afford.

Which is why I'm asking to begin with.

And please, spare me the smart-ass commentary about obsolete hardware -
not everybody is fortunate enough to be able to afford the
latest-and-greatest.

 

[Thomas Weidenfeller]

How many replies are you going to post for a single message???

Roedy is an old regular who's, lets say, eccentric answering style is
tolerated because of his background and because he did make lots and
lots of contributions to the community, including his huge Java
glossary. Now, where are your contributions? And no, your whining about
the quality of the answers you got last time in response to your newbie
first-post doesn't count.

If you're planning on saying something similar to "Then upgrade your
OS", save it. I'm up against the wall with this machine. And if you in
turn intend to say "Then get a new machine", stow THAT, too. Unless, of
course, you're planning on handing me the money for it.

[...]

And please, spare me the smart-ass commentary about obsolete hardware -
not everybody is fortunate enough to be able to afford the
latest-and-greatest.

Wow, you are working very hard to make friends here. Keep up the good
work. I am sure your plan will work out fine.

/Thomas

 

[Jon Martin Solaas]

Bear with the newbie...

I'm thinking in terms of "new code fed to old compiler". As in, I've got
an older compiler (and due to financial and hardware constraints, I'm
going to continue having the "old" one for the forseeable future) - It
shipped with the JDK 1.1something (I'm very hazy on what version it's
supposed to be, but it APPEARS to be 1.1 or 1.1.1) stuff, if I'm reading
things correctly - but I've got a wad of code I need to work with that
was developed using at least the 1.4.2 JDK - perhaps even newer, but I
can't tell for sure - that I need to compile.

Is throwing this code at the compiler I have going to give me a useful
result, or have things changed enough between 1.1 and 1.4.2 to make the
code I've got unrecognizable garbage to the compiler I have?

That depends a lot on the code ... like you suggest in the rest of your
posting which I don't quote here.

Here are some thoughts to consider:

The java compiler itself, javac, isn't really that much more
resource-consuming in version 1.4+ than in version 1.1, I bet there are
just as large differences in resource consumption between compilers for
the same language-version from different vendors (jikes/ibm versus
javac/sun etc.) So, if you're on a budget, it's really not that much
point in sticking with an old compiler.

The programs you compile matters a lot more. If they require a lot of
extra libs/jars that does come with new jdk-versions and not the old
version you want to use, you'd still have to use those libraries/jars,
thus making both your development environment and the compiled programs
just as resource-consuming as if compiled with a modern jdk/compiler.
Swing programs are resource-consuming even if you hack/extend your
jdk/jre 1.1 to handle them. And the 1.1 compiler does require a certain
amount of resources to compile them as well. *Maybe* a *little* less
than a 1.4 compiler would, but I'd say you don't have much to gain
here...The only real overhead you'd experience using say jdk 1.4.X is
diskspace used for jars/libs that is neither included in your old jdk
nor used by your source, but still included in jdk 1.4.X. But, once
again, if you can't afford those few extra megabytes of diskwaste I'd be
surprised if your hardware is suitable for java development at all.

under the version of the JDK that came
with the compiler I have. Is it advisable/safe/otherwise useful to

I think you are confused, the compiler is *in* the jdk, it is not the
jdk that is inside the compiler. You probably mean some Java ide tool
like Netbeans, Café (an ancient one), JBuilder or some such.

Try to describe exactly what your development environment consist of and
you'll probably get better help. Perhaps you have bought a java
development tool that is configurable and can easily use a recent jdk
that you can download from sun for free, as well as the old one that was
originally bundled? That way you can still use your snappy and less
resource consuming ide-tool with a recent java jdk.

I guess what I'm asking boils down to this:
Can newer Java code be *PRACTICALLY* compiled with an older compiler, or
is the "back-conversion" going to involve more headache than any sane
person would consider dealing with?

I think you'd just have to post the source to get an accurate answer.
Even though the language itself hasn't *really* changed that much, which
is what really matters to the compiler, still stuff has been added in
recent language versions (assertions, generics etc) and if that is used
you'd just run into syntax errors that you can't get around.

Changes has been made to central classes too, for instance regex support
in String. If such features are used in the source, you'd have to
rewrite (and use an external regex lib or steal it from a recent jdk) or
try to use the new versions of those classes/libs with the old compiler.
Definitely a headache, but it could work if you have lots of spare time
you just don't know how to spend otherwise.

Finally I wonder, if you have a lot of source that someone else has
developed in a recent development environment, don't you think there
also exist a number of project-files with various build parameters,
dependencies and such, that you could benefit from using, rather than
trying to set up everything to work with your old environment?

 

[Chris Uppal]

Is throwing this code at the compiler I have going to give me a useful
result, or have things changed enough between 1.1 and 1.4.2 to make the
code I've got unrecognizable garbage to the compiler I have?

What matters is not so much the Java compiler (the language that it recognises)
as the Java /platform/. The platform is the set of Java classes that all Java
programs (including the compiler) are allowed to assume will exist. The
platform has changed /very considerably/ over the years.

Trying to get 1.4.x Java source to compile with a 1.1 compiler would be
difficult but not impossible (depending on how many compromises you were
willing to make). Getting to run without the right platform would be simply
impossible.

So, the question is: can you duplicate the Java 1.4.x platform using only a 1.1
compiler and a 1.1 JVM ? I would say that the answer is no. The platform's
/implementation/ is likely to be tied in to that of the target JVM quite
tightly, so even if you can find the source, that is not very likely to help.
There will be /some/ source from a 1.4.x distribution that will compile and run
correctly on a 1.1 JVM, but there will also be a lot (I have no real idea how
much) that will just fail. Unfortunately, the stuff that is heavily
JVM-dependent tends to be core features (such as reflection) that are required
in order for everything else to work.

So I don't think that trying to "port" the platform is very viable. At the
very least, expect to spend months or years on the effort. And, by the time
you've finished, Java will have moved on, so you'll have to start again. Only
/this/ time you'll be working with source that assumes a 1.5 or later
compiler -- and that will be much harder to force through a 1.1 compiler
because the language has just had an enormous amount of crap added to it.

You /may/ be able to proceed in a small way. Only attempting to port, stub
out, or emulate, the stuff that you actually need. That /might/ be possible,
especially if you are not making much use of external libraries, and certainly
not touching massive technology-sets like J2EE.

But, broadly speaking, I would say that unless you are a Java expert /AND/ have
a love of quixotically difficult projects, then you are going to be wasting a
lot of time. As I say, think in terms of months and years -- not hours and
minutes.

On the other hand, I'm new enough to Java that I know I can't safely
assume this is reality, and so far, haven't managed to come up with
enough information to decide if it's worth making the attempt or not.
(It's a rather large chunk of code that I'll be trying to work with)

That raises another couple of problems. One is that -- as a Java newbie -- you
won't have much idea of what Java and its libraries looked like circa 1.1, and
finding documentation might be difficult. (On the positive side, at least you
could buy old books cheaply). The second is that if you are trying to work
with a large chunk of code that has been written, and will continue to be
developed, without regard to your limited position, then the /best/ that can
happen is that you'll hold the project up. More likely it will simply become
impossible to proceed. How could anyone else trust any modifications you made
to the code when you are using (and testing in) such a non-standard environment
?

I guess what I'm asking boils down to this:
Can newer Java code be *PRACTICALLY* compiled with an older compiler, or
is the "back-conversion" going to involve more headache than any sane
person would consider dealing with?

No sane person would try it -- not if they want to stay sane....

-- chris