javac -source 1.6 -target 1.4

K

Kenneth P. Turvey

In a post to this newsgroup recently I mentioned that I've never seen
source and target used where there was a difference in the values
supplied. A reader on this newsgroup replied indicating that normally
they were different in his application of them.

I thought this was interesting since I would very much like to be able to
target 1.3 or 1.4 class files using source code that included the 1.5
changes, including the new looping construct and the assert keyword (I
know that generics won't work). Even if I couldn't get these later
language constructs, one would expect that the 1.6 compiler would do a
better job than the 1.3 or 1.4 one would.

So I decided to try this out. I couldn't get it to work at all when
applying it to some of my already written source code (and including the
-bootclasspath option), so I thought I would try a simple hello world
example.

This is the class I'm trying to compile:

----
public class Main {
public static void main(String[] args) {
System.out.println("This is a test app");
}
}
----

It can't get much simpler than that.

When I try to compile it and target the 1.5 class file format, this is
what I get:

----
kt@lovelace:~/src/TestApp/src/testapp$ javac -source 1.6 \
-target 1.5 Main.java
javac: source release 1.6 requires target release 1.6
----

Would somebody tell me what magic I need to do to get the Sun 1.6 compiler
to target an earlier version of the class file?

Thank you.
 
K

Kenneth P. Turvey


Ok, thanks. I got it to compile to a 1.5 class file and then to a 1.3
class file. The only problem is that I still can't get it to compile to a
1.3 version of the class file without specifying a 1.3 source as well.

What I really want is something like this:

javac -source 1.5 -target 1.3 -bootclasspath /my/jre/lib/rt.jar Main.java

Unfortunately it only seems to work correctly when source and target have
the same value. Am I missing something here?

Thank you.
 
A

Andrew Thompson

In a post to this newsgroup recently I mentioned that I've never seen
source and target used where there was a difference in the values
supplied.  ..

I was scanning Lew's link when I noticed that
the page actually mentions the compiler itself
*presumes* different options for certain values
of -target. See the second and third items in
the bulleted list.

<http://java.sun.com/javase/6/docs/technotes/tools/solaris/
javac.html#crosscomp-options>

And I am (almost) certain that
- Not even language constructs such as foreach
can be back ported. (Though it would be
interesting to see an example that proves that.)
- Whatever the 1.6 compiler does that might be
better than earlier compilers (if anything),
will become redundant once the code is loaded
into a JRE.
 
Z

Zig

In a post to this newsgroup recently I mentioned that I've never seen
source and target used where there was a difference in the values
supplied. A reader on this newsgroup replied indicating that normally
they were different in his application of them.

I thought this was interesting since I would very much like to be able to
target 1.3 or 1.4 class files using source code that included the 1.5
changes, including the new looping construct and the assert keyword (I
know that generics won't work). Even if I couldn't get these later
language constructs, one would expect that the 1.6 compiler would do a
better job than the 1.3 or 1.4 one would.

I think the "-source" exists in order to make the compiler aware that the
source code was written in a version older than the language itself.
Namely, -source 1.3 should allow you to correctly compile any code still
using variables named "assert" or "enum".

I guess Sun's compiler doesn't permit a source attribute > your target
attribute. For the most part newer language features do require the newer
VM (foreach needs method definitions on java.lang.Iterable), though
foreach on an array could work in theory. You might could find another
compiler besides Sun's that can do this, but I guess Sun didn't see much
value in this support?

HTH,

-Zig
 
K

Kenneth P. Turvey

On Fri, 14 Mar 2008 21:44:40 -0700, Andrew Thompson wrote:

[Snip]
- Whatever the 1.6 compiler does that might be
better than earlier compilers (if anything),
will become redundant once the code is loaded
into a JRE.

Maybe not. The compiler might make optimizations in generating the
classfile that the JRE wouldn't know how to make.
 
K

Kenneth P. Turvey

On Sat, 15 Mar 2008 01:01:40 -0400, Zig wrote:

[Snip]
I think the "-source" exists in order to make the compiler aware that
the source code was written in a version older than the language itself.
Namely, -source 1.3 should allow you to correctly compile any code still
using variables named "assert" or "enum".

Disappointing, but I guess it makes sense. I guess I can still use the
later version of the compiler even if my source isn't able to use the
modern 1.5 features.
I guess Sun's compiler doesn't permit a source attribute > your target
attribute. For the most part newer language features do require the
newer VM (foreach needs method definitions on java.lang.Iterable),
though foreach on an array could work in theory. You might could find
another compiler besides Sun's that can do this, but I guess Sun didn't
see much value in this support?

I guess the people at Sun haven't been writing applets.
 
R

Roedy Green

I guess Sun's compiler doesn't permit a source attribute > your target
attribute

I think that is generally true, but when target is 1.1 or 1.2 you have
to set source to 1.3.
 
A

Andrew Thompson

On Sat, 15 Mar 2008 01:01:40 -0400, Zig wrote:

[Snip] ...
I guess Sun's compiler doesn't permit a source attribute > your target
attribute. For the most part newer language features do require the
newer VM (foreach needs method definitions on java.lang.Iterable),
though foreach on an array could work in theory. You might could find
another compiler besides Sun's that can do this, but I guess Sun didn't
see much value in this support?

I guess the people at Sun haven't been writing applets.  

Not only have they been shying away from writing
applets, they also seem to have gone through a
process of removing most of them from their site.

But I am curious as to what you meant by that.

What target version (for the applets) are you
talking about? Why that version?
 
A

Andreas Leitgeb

Kenneth P. Turvey said:
On Fri, 14 Mar 2008 21:44:40 -0700, Andrew Thompson wrote:
[Snip]
- Whatever the 1.6 compiler does that might be
better than earlier compilers (if anything),
will become redundant once the code is loaded
into a JRE.

Maybe not. The compiler might make optimizations in generating the
classfile that the JRE wouldn't know how to make.

From what I've gathered reading this group, the jre is supposed to
optimize at least as well, if not *much* better, than how the compiler
even possibly could. This is because the jre has more input: e.g.
it can place inline other classes' methods...

I felt happier back in the days, where I could "see" in the disassembled
code, what the optimizer really did, than now, where I see grossly
un-optimal bytecode, and have to hope/believe the jre doing it's job well,
with no way to look over it's shoulders (other than examining the
jre's source-code, of course). I could of course program a benchmark
that reflects my particular needs, and watch the timings, and most
likely see how the newer jre beats the old one but it just isn't the
same :-/
 
K

Kenneth P. Turvey

What target version (for the applets) are you
talking about? Why that version?

Just a few versions behind the latest to give the people on client
machines a bit more time to upgrade their Java installation. Not many are
running 1.6.
 
A

Andrew Thompson

Just a few versions behind the latest to give the people on client
machines a bit more time to upgrade their Java installation.  Not many are
running 1.6.

Oh. That was both a let down and a relief.

I was worried you were going to say something
silly like..
- "Need to code for 1.1 so it will work in
all browsers" (will never happen)
- "Need to support MSVM"
('are you *insane*?' the best thing we can do
for the end user with an MSVM is to warn them
their computer is insecure, then redirect them
to Sun)

OK. Just had to get that out of my system.

..Carry on.
 
J

Jack

Kenneth P. Turvey a écrit :
Ok, thanks. I got it to compile to a 1.5 class file and then to a 1.3
class file. The only problem is that I still can't get it to compile to a
1.3 version of the class file without specifying a 1.3 source as well.

What I really want is something like this:

javac -source 1.5 -target 1.3 -bootclasspath /my/jre/lib/rt.jar Main.java

see retroweaver
 
A

andypymont

It looks interesting.  Have you used it?  Does it work as advertised?  

Not retroweaver, but I've used retrotranslator, a similar tool, to
convert a 1.6 .jar, using several 1.5+ features, to a 1.4 .jar, and it
does the job really nicely. I'd recommend it.

Of course, my .jar was an application, not an applet, so YMMV - but
it's certainly worth a try.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top