Bug 36733 - Java compilation errors after editing installed VMs
Summary: Java compilation errors after editing installed VMs
Status: RESOLVED DUPLICATE of bug 34658
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 major (vote)
Target Milestone: 3.0 M1   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-21 17:57 EDT by Ert Dredge CLA
Modified: 2003-06-02 06:13 EDT (History)
0 users

See Also:


Attachments
Error stack trace (2.44 KB, text/plain)
2003-04-21 17:58 EDT, Ert Dredge CLA
no flags Details
Uncompilable code (5.42 KB, text/plain)
2003-04-21 23:55 EDT, Ert Dredge CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ert Dredge CLA 2003-04-21 17:57:27 EDT
After installing Eclipse 2.1 on Mac OS X running JVM 1.3.1, I've upgraded to JVM 1.4.1.  I added the 
new JVM to Eclipse's available JVMs and switched to using 1.4.1.

Doing this only by default adds ui.jar and classes.jar from the new JVM by default, and I wanted to 
use javax.net.*, which is in jsse.jar.  (This is a bit of a bug, as it took me a little bit to figure out 
why the javax.net package wasn't automatically available to me, as command-line javac compiled 
without complaint from 1.4.1)  So I added jsse.jar as an external JAR to the 1.4.1 JVM definition.

Since that time, however, I've been unable to compile my project that previously compiled fine 
(apart from the javax.net issue).  Trying to edit the JVM took some effort, as editing it with the 
project opened caused Eclipse to hang.  I've managed to get jsse.jar out of the JVM config, but it's 
still not compiling.

My next steps appear to be going back to 1.3.1, and trying to reconfigure 1.4.1 again.

Stack trace from the build attempt, which is awkwardly available in the task list, is attached, 
showing an ArrayIndexOutOfBoundsException in 
org.eclipse.jdt.internal.compiler.parser.Parser.check(Parser.java:615) caused by line number zero 
(!) of one of my sources.
Comment 1 Ert Dredge CLA 2003-04-21 17:58:17 EDT
Created attachment 4656 [details]
Error stack trace
Comment 2 Philipe Mulet CLA 2003-04-21 21:24:05 EDT
There seems to be an internal error while the compiler is performing. We trap 
these exceptions, and surface them as error attached to position 0 in the unit. 
In this scenario, we cannot successfully parse the unit. Could you attach the 
source of the unit causing grief (SimpleSerialJava) ?

Olivier - please investigate. This feels like the parser tables are causing 
grief under MacOS. Is this a VM bug rather ?
Comment 3 Ert Dredge CLA 2003-04-21 23:55:38 EDT
Created attachment 4657 [details]
Uncompilable code

This code compiled fine for months - I don't think it's anything particular to
this piece of code, but rather that it happened to be the first class that
Eclipse was trying to compile.
Comment 4 Ert Dredge CLA 2003-04-22 00:01:49 EDT
Added the offending java class, although I suspect that it had more to do with the fact that it was 
the first class to be compiled, not that there was something problematic in this class itself.

Checking the build, I realized that it was Eclipse SDK-M4-macosx-carbon (circa 1/22/03) and not 
the full release of 2.1.  I installed the full release of 2.1 and it's compiling fine now, although I 
don't know whether that's simply because of the fresh install or if something's been fixed in the 
latest build.  I have yet to try adding jsse.jar, however.
Comment 5 Olivier Thomann CLA 2003-04-22 08:42:12 EDT
This is the bug with the initialization of the parser tables under 1.4.1. It has
been fixed between M4 and 2.1. This is why it is fixed now.
Duplicate of bug 34658.
Please enter another bug report against JDT/Debug for the fact that jsse.jar is
not automatically included on MacOS among the JDK1.4.1. libraries.

*** This bug has been marked as a duplicate of 34658 ***