Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 389759

Summary:

Problem compiling org.eclipse.jdt.compiler.tool with IBM JDK

Product:

[Eclipse Project] JDT

Reporter:

John Arthorne <john.arthorne>

Component:

Core

Assignee:

JDT-Core-Inbox <jdt-core-inbox>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

Olivier_Thomann, pwebster, stephan.herrmann

Version:

4.3

Target Milestone:

---

Hardware:

OS:

Windows 7

Whiteboard:

stalebug

Attachments:

Description	Flags
Logging of the error	none

Description John Arthorne

2012-09-17 15:58:36 EDT

For details see this thread:

http://dev.eclipse.org/mhonarc/lists/cbi-dev/msg00739.html

Someone is attempting to compile jdt.compiler.tool against an IBM JDK. This fails, reporting a type hierarchy consistency error. The same compile against the Sun/Oracle JDK completes fine. 

I don't know what this "inconsistent hierarchy" error means, but it is suspicious that it compiles with one JDK and not another.

Here is the text of the error:

[ERROR] The type java.lang.String cannot be resolved. It is indirectly referenced from required .class files
[ERROR] /opt/pwebster/git/cbi/r4/eclipse.platform.releng.aggregator/eclipse.jdt.core/org.eclipse.jdt.compiler.tool/src/org/eclipse/jdt/internal/compiler/tool/ArchiveFileObject.java:[36,0]
[ERROR] public class ArchiveFileObject implements JavaFileObject {
[ERROR] ^^^^^^^^^^^^^^^^^
[ERROR] The hierarchy of the type ArchiveFileObject is inconsistent
[ERROR] 2 problems (2 errors)

Comment 1 Olivier Thomann

2012-09-17 16:12:06 EDT

Would it be possible to get an xml log from this compilation?
Passing "-log <path to an xml file>" on the compiler's command line.

This would help to find out if the classpath is properly set up.

Comment 2 Stephan Herrmann

2012-09-17 19:39:48 EDT

Reminds me of that peculiarity whereby IBM JDK isn't happy with just <jre_home>/lib/*.jar on the classpath but also needs s.t. like <jre_home>/lib/amd64/default/jclSC160/vm.jar.

If that's missing, there's no class java.lang.String (and not even java.lang.Object), which could explain the above error.

I don't know enough about toolchain.xml to tell if this should be covered.

Comment 3 Olivier Thomann

2012-09-17 19:56:03 EDT

The batch compiler does a pretty good job at setting the bootclasspath if none is provided. Is it possible to get more details on how the batch compiler is invoked inside tycho builds?

Comment 4 Paul Webster

2012-09-18 11:57:44 EDT

Created attachment 221205 [details]
Logging of the error

I'm running in a mode where tycho is providing the classpath based on the BREE:

[DEBUG] Manifest minimal BREE: OSGi profile 'JavaSE-1.6' { source level: 1.6, target level: 1.6}
[DEBUG] Effective BREE: OSGi profile 'JavaSE-1.6' { source level: 1.6, target level: 1.6}
[DEBUG] Effective source/target: 1.6/1.6

the classpath tycho passes in is captured in the log, but as Stephan mentioned it doesn't contain jre/lib/amd64/default/jclSC160/vm.jar

PW

Comment 5 Eclipse Genie

2020-02-20 12:38:06 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.