Target VM Microsoft? or Java Lint to check for MS VM compatibility?

[Vincent Cate]

In my JBuilder8 I can only target my applet for different JDKs or
"All JDKs". I do not have a "target MS JVM" option.

So my applet (http://spacetethers.com/spacetethers.html) worked
in all Sun JDKs, but would not run under a microsoft VM,
which most IE users in the real world seem to be running.

I found out that the problem was things like:

Vector.remove(x) needs to be Vector.removeElement(x)
Vector.add(x) needs to be Vector.addElement(x)
Vector.add(x,y) needs to be Vector.insertElementAt(y,x)

And other such things. I suspect that the very earliest Java only
had the ones at the right and Microsoft never added the ones on
the left. I would rather use just the ones on the right, and
have done so now (found with help from someone not using JBuilder).
With this my applet is now far more portable.

But is there any way to get JBuilder to keep me from using anything
that would not work on a Microsoft VM?

Is there something like "lint" for C that I can use for my Java to
find anything that does not work on Microsoft?

I understand that I could ask all my users to install a Sun JDK,
and I do put a link right on the applet page, but I was still
loosing all kinds of users because they thought my applet was broken.

I worry that any day I might use something that breaks my applet
for my Microsoft users without knowing it.

-- Vince

 

[Andrew Thompson]

In my JBuilder8 I can only target my applet for different JDKs or
"All JDKs". I do not have a "target MS JVM" option.

Hi Vincent!

Coincidentally I have been interested in pretty
much that same question. ;-)

You might find these posts by Chris and
Michael to be very useful.
http://www.google.com/[email protected]
pond.net.au

(I go sleep now..)

 

[Chris Smith]

In my JBuilder8 I can only target my applet for different JDKs or
"All JDKs". I do not have a "target MS JVM" option.

But is there any way to get JBuilder to keep me from using anything
that would not work on a Microsoft VM?

If JBuilder has the option to target Java version 1.1, choose that. You
may have to actually download a 1.1 JDK and tell JBuilder where it is.
Or, you could just occasionally try compiling your applet with a 1.1
compiler, and call that your "lint" tool.

I seem to recall that Microsoft is even a few APIs short of 1.1, but I
don't remember the details. In any case, I don't think it's possible
any longer to get Microsoft's Java development tools, so straight 1.1 is
the closest you'll find.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tim Tyler]

In any case, I don't think it's possible any longer to get Microsoft's
Java development tools, so straight 1.1 is the closest you'll find.

"SDKJava40.exe"

- http://kitty.2y.net/ftp/pub/ProgramResource/

Searching for that filename should turn up more copies.

Of course, I make no warranty about their authenticity.

You probably don't need their SDK to test on their JVM.

....but you *do* need to test on their JVM if you want to run there.

 

[Vincent Cate]

(e-mail address removed) (Tom)

Until then, compile to version 1.1 and you should be OK.

I do that and it is not OK. Microsoft does not have Vector.add()
for example. Maybe it "should be OK" but lawyers can argue that.

Chris Smith ([email protected])

I seem to recall that Microsoft is even a few APIs short of 1.1, but
I don't remember the details.

Yes, they are a few short. My problem is that JBuilder does not help
me avoid these few.

Québec ([email protected])

I have played a lot with that and I recomend: stay with Microsoft
jvm, jvc.exe, jview.exe.

If I test under Microsoft's jvm, and I test everything, I could find out
if there are problems. But I would like for either my compiler or
some other tool to just warn me not to use things Microsoft does
not have. Also, it is not easy to see what is wrong at least when
I have run it from a browser. If it does not have the byte code
for Vector.add() it does not print out an error message saying
"Microsoft does not support Vector.add()" as it just does not
recognize the byte code.

Tim Tyler:

You probably don't need their SDK to test on their JVM.

...but you *do* need to test on their JVM if you want to run there.

If my compiler (or some lint type tool) could tell me what methods
I had to avoid, I don't think I would have to test on their JVM,
at least for the problems I have seen.

I don't mind avoiding methods that Microsoft does not have in their
JVM, but it seems wrong to have to use their SDK. I like
JBuilder's "target all JDKs" so I can only use things on JDK 1.1
and I get warnings of anything "deprecated" in future JDKs.

Still looking for a "Java portability lint" ...

-- Vince

 

[Chris Smith]

(e-mail address removed) (Tom)

I do that and it is not OK. Microsoft does not have Vector.add()
for example. Maybe it "should be OK" but lawyers can argue that.

The Java API version 1.1 also doesn't have Vector.add() The
java.util.List-based names for Vector functions were only added with the
advent of the Collections API in 1.2. I'm guessing, then, that you only
think you are doing that, and that you aren't really doing it at all.

When I said Microsoft is short a few APIs from 1.1, I didn't mean
something so fundamental as Vector. I think I recall something about
RMI, something about JNI, and something about minor details of
reflection.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrew Thompson]

....
When I said Microsoft is short a few APIs from 1.1, I didn't mean
something so fundamental as Vector. I think I recall something about
RMI, something about JNI, and something about minor details of
reflection.

Definitely nothing like that in the Applet concerned..
http://www.physci.org/codes/display.jsp?fl=codes/java/spacetethers.zip!/spac
etethers/Applet1.java

The rest of the source can be seen here..
http://www.physci.org/codes/index.jsp?zip=/codes/java/spacetethers.zip&sub=s
pacetethers/

In NN 4.78 (running a 1.1.5 JVM) it was rendering
the entire plot surface (bar the button) as black,
though not showing any exceptions.

[ BTW - my news reader keeps complaining
about the non existent group 'comp.lang.java.developer',
deleted ]

 

[Vincent Cate]

The Java API version 1.1 also doesn't have Vector.add() The
java.util.List-based names for Vector functions were only added with the
advent of the Collections API in 1.2. I'm guessing, then, that you only
think you are doing that, and that you aren't really doing it at all.

I just checked again and in my JBuilder I have "target VM: All Java SDKs"
which I thought makes things that are 1.1 compatible. Other choices are
"Java 2, v 1.2 and later", as well as 1.3, and 1.4. Maybe I am only
compatible with "Java 2, v 1.1" and Microsoft is at "Java 1, v 1.1"?
Or is JBuilder is goofing up? Or am I confused about something else?

When I said Microsoft is short a few APIs from 1.1, I didn't mean
something so fundamental as Vector. I think I recall something about
RMI, something about JNI, and something about minor details of
reflection.

Using Vector.addElement() works fine, so it is not that they don't
have Vector.

-- Vince

 

[Vincent Cate]

The Java API version 1.1 also doesn't have Vector.add() The
java.util.List-based names for Vector functions were only added with the
advent of the Collections API in 1.2. I'm guessing, then, that you only
think you are doing that, and that you aren't really doing it at all.

I just installed j2sdk1.4.2_03 from Sun on a Linux machine and even
here when I compile with "-target 1.1", I can have Vector.add()
and it compiles fine (as does under JBuilder). But Microsoft JVM seems to
need Vector.addElement(). So it is not just JBuilder that thinks
it is ok in 1.1.

It is not just my imagination. Really.

Still wishing for some "portability lint" program for Java ...

-- Vince

 

[Raymond DeCampo]

I just installed j2sdk1.4.2_03 from Sun on a Linux machine and even
here when I compile with "-target 1.1", I can have Vector.add()
and it compiles fine (as does under JBuilder). But Microsoft JVM seems to
need Vector.addElement(). So it is not just JBuilder that thinks
it is ok in 1.1.

It is not just my imagination. Really.

That makes perfect sense. The -target switch only says that it will
make byte code that is compatible with the given JVM. However, that
does not mean that the 1.1 versions of the JFC classes are used. Keep
in mind that the compiler is separate from the JFC classes. So the
compiler is generating byte code that will be compatible with 1.1 JVMs,
however, it is using the 1.4 JFC classes as a reference. There is
nothing to tell the compiler that Vector.add() does not exist in 1.1 JFC
classes and the Vector class it sees has it.

According to the javac documentation, you should use the -bootclasspath
and -extdirs options as well to achieve full cross compilation.

Here's the relevant portion of the javac documentation:

<quote>
Here we use the Java 2 SDK javac to compile code that will run on a
1.1 VM.

% javac -target 1.1 -bootclasspath jdk1.1.7/lib/classes.zip \
-extdirs "" OldCode.java

The -target 1.1 option ensures that the generated class files will
be compatible with 1.1 VMs. In the Java 2 SDK javac compiles for 1.2 by
default.

The Java 2 SDK's javac would also by default compile against its
own bootstrap classes, so we need to tell javac to compile against JDK
1.1 bootstrap classes instead. We do this with -bootclasspath and
-extdirs. Failing to do this might allow compilation against a Java 2
Platform API that would not be present on a 1.1 VM and fail at runtime.
</quote>

So it looks like this is a case of RTFM.

HTH,
Ray

 

[Tor Iver Wilhelmsen]

I just checked again and in my JBuilder I have "target VM: All Java SDKs"
which I thought makes things that are 1.1 compatible.

No, you need to install JDK 1.1.8 and use that at the target JDK in
your project.

 

[Chris Smith]

Definitely nothing like that in the Applet concerned..
http://www.physci.org/codes/display.jsp?fl=codes/java/spacetethers.zip!/spac
etethers/Applet1.java

The rest of the source can be seen here..
http://www.physci.org/codes/index.jsp?zip=/codes/java/spacetethers.zip&sub=s
pacetethers/

In NN 4.78 (running a 1.1.5 JVM) it was rendering
the entire plot surface (bar the button) as black,
though not showing any exceptions.

I didn't have the chance to look in detail, but it looks like an
unintentional discrepancy, rather than an intentional change like we
were discussing here. This is a good argument for testing on the target
VM regardless of whether you can get compiler checks in place... but the
compiler checks are still fine.

[ BTW - my news reader keeps complaining
about the non existent group 'comp.lang.java.developer',
deleted ]

Indeed, the group shouldn't exist; however, some servers carry more than
the standard big-8 groups, even in big-8 namespaces, and some posters
choose to post in them without checking their validity.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

I just installed j2sdk1.4.2_03 from Sun on a Linux machine and even
here when I compile with "-target 1.1", I can have Vector.add()
and it compiles fine (as does under JBuilder).

The "-target" flag doesn't do what you think it does. What you actually
need to do is download a 1.1 version of Java, and compile with that.
There was another thread recently that got into what those flags really
do; if you're interested, have Google look for "-target" and "-source"
in recent threads (last couple weeks at most) from comp.lang.java.*.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Vincent Cate]

The "-target" flag doesn't do what you think it does. What you actually
need to do is download a 1.1 version of Java, and compile with that.

You are right. I did that and it does complain about Vector.add() in
that case. So now I can tell what I should not use for 1.1 JVM
compatibility. Thanks!

In my defense, I quote from the man page for Sun's 1.4 javac:

-target version
Generates class files that will work on VMs with the specified version.
[...] The versions supported are:

1.1 Ensures that generated class files will be compatible
with 1.1 and 1.2 VMs.
[...]

What the man page says "-target" does is not what it really does. The
"will work", "Ensures", and "will be compatible" all don't mean what
they seem to mean.

So now I will compile on 1.4 to make sure I am ok with current Java
(not using anything "deprecated") and then on 1.1 to make sure my code
does not use anything that 1.1 does not have. Not exactly compile
once run anywhere.

Is this what other people do?

-- Vince

 

[Chris Smith]

In my defense, I quote from the man page for Sun's 1.4 javac:

-target version
Generates class files that will work on VMs with the specified version.
[...] The versions supported are:

1.1 Ensures that generated class files will be compatible
with 1.1 and 1.2 VMs.
[...]

What the man page says "-target" does is not what it really does. The
"will work", "Ensures", and "will be compatible" all don't mean what
they seem to mean.

The option actually does exactly what the man page says that they do,
and nothing more. That is, the option generates class files that will
work on the given virtual machine, but they do *not* police your use of
libraries that will be available on that version of the Java platform.
When you compile with the "-target" option, the format of the resulting
class file is compatible the the given virtual machine. If you provided
libraries matching your usage (for example, if you wrote a replacement
for java.util.Vector with an add() method and arranged the boot
classpath to find that instead of the standard system class), the
application would work fine.

[Incidentally, the fact that it would be illegal to distribute such an
application is not considered by the compiler, since it is not a
lawyer.]

The problem is that when you read that the generated class file would be
compatible with that version of the Java virtual machine, you also
assumed that it would work with the set of APIs that's commonly
distributed with that VM as part of the J2SE. This is not the case.
The virtual machine and the Java core API are different things, and
there is no guarantee that the application you compile with a '-target'
option will work with a specific core API.

So now I will compile on 1.4 to make sure I am ok with current Java
(not using anything "deprecated") and then on 1.1 to make sure my code
does not use anything that 1.1 does not have. Not exactly compile
once run anywhere.

Is this what other people do?

Not really. Mostly, other people compile and test against a single VM
version or small set of versions, and then require that for their code
(in fact, often install that with their application). Users who fiddle
so as to change the version of the Java platform in use then accept
responsibility for breaking the application, if indeed they do so.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation