On-Line compiler not correctly rejecting code..

[Andrew Thompson]

I have struck a problem with my on-line compiler
<http://www.physci.org/javac.jsp?bcp=MS>
that has me stumped. It was first revealed in
this conversation on c.l.j.gui.
<http://google.com/groups?th=9ff93a6bfc7ff231>

Long story short, when compiling against the
1.1 VM, the On-Line compiler will reject
_some_ code that uses post 1.1 classes,
but not _all_ code.

Case in point..
<sscce>
import java.awt.*;
public class Graphic2Din1_1 extends Frame {
public void paint(Graphics g) {
Graphics2D g2d = (Graphics2D)g.create();
double d = 1.238765d;
g2d.rotate(d);
}
}
</sscce>

G2D was not defined until 1.2, but the on-line
compiler will happily report the compile was a
success.

OTOH, if you import the CardLayout code,
which uses Color constants introduced in 1.4,
the code will _not_ compile.

** Even more confusingly, my version at
home will correctly reject both. **

Based on that, I uploaded all the files again,
...with the same result!?! The home version correctly
rejects the code, the on-line version accepts it.

Now I have put a 'out.print' statement at the top
that tells me the rt.jar against which it is pointing
the -bootclasspath. It is, as it should be, 'rt1_1_4.jar'
(I put them all in the same directory, so had to
give each a unique name)

I checked the size of the rt1_1_4.jar on the site
'5615Kb', the local jar is reporting 5616,
so I am confident I have the right jar, since
there is not other rt.jar within 2 Meg of
that size.

Does anyone have any ideas as to what I have
overlooked, or further tests I might do, to
help narrow the problem down?

 

[Rob Shepherd]

I have struck a problem with my on-line compiler
<http://www.physci.org/javac.jsp?bcp=MS>
that has me stumped. It was first revealed in
this conversation on c.l.j.gui.
<http://google.com/groups?th=9ff93a6bfc7ff231>

Long story short, when compiling against the
1.1 VM,

What about if you specify -source 1.X . Does this make a difference. Can you select which
version the uploaded source written in?

 

[Andrew Thompson]

What about if you specify -source 1.X .

I do not believe the -source option is relevant
here. It deals with assertions.

According to the tooldocs..
"When release is set to 1.3, the compiler does not
support assertions. The compiler defaults to the 1.3
behavior if the -source flag is not used."

OTOH, the -bootclasspath is intended to
compile source against the classes specifically
available in a particular Java release (using the
rt.jar itself).

...Does this make a difference. Can you select which
version the uploaded source written in?

I am not sure what you mean.

I leave it to the user to specify which
version of Java to compile against, and
would like to support.. 1.1 MS, 1.1 Sun,
1.2, 1.3, 1.4 and (when my server updates
to 1.5), 1.5 as well.

So.. _I_ do not select the version the
the source is written in, but yes, the
_user_ can specify -bootclasspath by
selecting options down the bottom of the
compiler page. E.G.
<http://www.physci.org/javac.jsp?bcp=12>
will (pre)select the -bootclasspath 1.2.2 and
-target 1.2. Whereas..
<http://www.physci.org/javac.jsp?bcp=14>
Will select -bootclasspath 1.4 and -target 1.4

If the user arrives at the page through
<http://www.physci.org/javac.jsp> the compiler
will default to 1.4, but the user can change
the options before compiling.

 

[John C. Bollinger]

I have struck a problem with my on-line compiler
<http://www.physci.org/javac.jsp?bcp=MS>
that has me stumped. It was first revealed in
this conversation on c.l.j.gui.
<http://google.com/groups?th=9ff93a6bfc7ff231>

Long story short, when compiling against the
1.1 VM, the On-Line compiler will reject
_some_ code that uses post 1.1 classes,
but not _all_ code.
[...]

G2D was not defined until 1.2, but the on-line
compiler will happily report the compile was a
success.

OTOH, if you import the CardLayout code,
which uses Color constants introduced in 1.4,
the code will _not_ compile.

I find it a bit suspicious that version 1.2 features are accepted but
version 1.4 features are rejected. Is that consistent? What about 1.3
features? You wrote a bit about how you're checking, but it still
sounds almost as if the wrong bootclasspath is being used, either
because the wrong one is named or because the name refers to the wrong
content.

** Even more confusingly, my version at
home will correctly reject both. **

Based on that, I uploaded all the files again,
..with the same result!?! The home version correctly
rejects the code, the on-line version accepts it.

That _is_ strange. Is there any chance that the online version is
somehow getting the 1.2 or 1.3 rt.jar in its compilation classpath?
Inheriting one of them from the environment, for instance? If you are
spawning a seperate process for the compilation (as you should) then try
using the version of Runtime.exec that allows you to specify the
environment (which is a good security practice anyway).

Now I have put a 'out.print' statement at the top
that tells me the rt.jar against which it is pointing
the -bootclasspath. It is, as it should be, 'rt1_1_4.jar'
(I put them all in the same directory, so had to
give each a unique name)

I checked the size of the rt1_1_4.jar on the site
'5615Kb', the local jar is reporting 5616,
so I am confident I have the right jar, since
there is not other rt.jar within 2 Meg of
that size.

Does anyone have any ideas as to what I have
overlooked, or further tests I might do, to
help narrow the problem down?

Can you check the compilation classpath as well? And quadruple check
that the jar names on both systems really refer to the same jars?

 

[Roedy Green]

G2D was not defined until 1.2, but the on-line
compiler will happily report the compile was a
success.

The compiler is only concerned with language features an the presence
of the needed classes. Don't expect a new compiler to warn you when
you use a class that was not available back then, just when you use a
language feature that was not available.

 

[Andrew Thompson]

I have struck a problem with my on-line compiler
<http://www.physci.org/javac.jsp?bcp=MS> ....
Long story short, when compiling against the
1.1 VM, the On-Line compiler will reject
_some_ code that uses post 1.1 classes,
but not _all_ code. [...]
G2D was not defined until 1.2, but the on-line
compiler will happily report the compile was a
success.

OTOH, if you import the CardLayout code,
which uses Color constants introduced in 1.4,
the code will _not_ compile.

I find it a bit suspicious that version 1.2 features are accepted but
version 1.4 features are rejected. Is that consistent? What about 1.3
features?

I think it's time for me to do a more
comprehensive check. I will use code
that should allow me to check each level.

Possibly a slight adaption of my
JavaVersionApplet would suffice.

..You wrote a bit about how you're checking, but it still
sounds almost as if the wrong bootclasspath is being used, either
because the wrong one is named or because the name refers to the wrong
content.
....
That _is_ strange. Is there any chance that the online version is
somehow getting the 1.2 or 1.3 rt.jar in its compilation classpath?

The default environment of the server is 1.4,
The 1.2/1.3 Jars are only available if I
override the default bootclasspath.
[ of course this would still cause similar
problems as if it were picking up the 1.2/1.3
rt.jar. ]

Inheriting one of them from the environment, for instance? If you are
spawning a seperate process for the compilation (as you should) then try
using the version of Runtime.exec that allows you to specify the
environment (which is a good security practice anyway).

I will examine this more closely, but perhaps I should
clarify that I do not do a Runtime.exec(). Instead I
dive (rather naughtily, I hear*) straight into the sun
tools classes and call the javac class directly.

* They are not documented and Sun specifically
advises they may be open to change at any moment
(or words to that effect)

Perhaps I should drag some of my code out
of WEB-INF so I can easily display it (for
others to tear to shreds)..

Can you check the compilation classpath as well? And quadruple check
that the jar names on both systems really refer to the same jars?

Shall do. I'll get back when I know any
more (or at least have more detailed results).

 

[Andrew Thompson]

The compiler is only concerned with language features an the presence
of the needed classes. Don't expect a new compiler..

I am always using the compiler built into
the 1.4 environment.

..to warn you when
you use a class that was not available back then,

I use the -bootclasspath to compile against
the actual jars. (Yep, I do have all...
58.6(!) Meg of the 1.1.4, 1.1.8, 1.2.2, 1.3.1
and 1.5 jars - 1.4 comes as part of the
server-side environment, I will need to upload
and use 1.4 specifically, when the server
moves to 1.5)

...just when you use a
language feature that was not available.

I do not quite understand what you mean by
'language feature'. Could you clarify?

 

[Roedy Green]

I do not quite understand what you mean by
'language feature'. Could you clarify?

e.g. assert.
generics,
enumerations.

 

[John C. Bollinger]

That _is_ strange. Is there any chance that the online version is
somehow getting the 1.2 or 1.3 rt.jar in its compilation classpath?

The default environment of the server is 1.4,
The 1.2/1.3 Jars are only available if I
override the default bootclasspath.
[ of course this would still cause similar
problems as if it were picking up the 1.2/1.3
rt.jar. ]

Inheriting one of them from the environment, for instance? If you are
spawning a seperate process for the compilation (as you should) then try
using the version of Runtime.exec that allows you to specify the
environment (which is a good security practice anyway).

I will examine this more closely, but perhaps I should
clarify that I do not do a Runtime.exec(). Instead I
dive (rather naughtily, I hear*) straight into the sun
tools classes and call the javac class directly.

In that case, it is at least conceivable that the compiler is resolving
some classes via the ClassLoader with which it itself was loaded, and
that ClassLoader is hooked up to the Java 1.4 runtime classes. That
does not, however, explain why any version 1.4 classes would be rejected
by the compiler.

You wrote elsewhere that you are always using the compiler from the
version 1.4 tools. Perhaps classes on which the compiler itself depends
are accepted? That wouldn't explain why it works locally but fails on
the server, though.

This is a weird one. I don't know that I have any good suggestions.


John Bollinger
(e-mail address removed)

 

[Andrew Thompson]

This is a weird one. I don't know that I have any good suggestions.

I have decided to rewrite the code as a servlet.

a) To make it presentable for public scrutiny.
b) To refactor the various disparate .jsp files
I am currently using.

The answer may hit me as I am doing that.

Otherwise I will have a simpler example,
with better test cases - ready to present
in public.

I'll post results back to this thread, but it
may take me a while to get it done.

Thanks to all who have contributed so far..