This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 186120

Summary: cannot compile; claims package missing; is part of rt.jar
Product: java Reporter: emiddio <emiddio>
Component: CompilerAssignee: Dusan Balek <dbalek>
Status: RESOLVED WONTFIX    
Severity: normal    
Priority: P3    
Version: 6.x   
Hardware: PC   
OS: Windows 7 x64   
Issue Type: DEFECT Exception Reporter:
Attachments: project that will not build
project that will not build -- use this one

Description emiddio 2010-05-13 22:42:21 UTC
Created attachment 98972 [details]
project that will not build

took some openjdk 6 source, made a sub project -- the stuff that supports
com.sun.net.httpserver.

made 2 or 3 classes needed -- empty/minimal classes;

but 1 class it complains about does exist -- in rt.jar

so why cant it build ???

if i re-create the same class locally to my project in java it will
compile.

project zip attached
Comment 1 emiddio 2010-05-16 19:38:13 UTC
Created attachment 99058 [details]
project that will not build -- use this one

the code for this project is the API code; Sun's implementation for the API is the code in sun.net.httpserver -- which is not in the project. -- but is referenced
in 1 place -- where the Default implementation is used -- again its part of rt.jar
Comment 2 Jan Lahoda 2010-05-18 01:24:13 UTC
Do you mean that the project cannot be build using ant? I can reproduce that (using the second attached project), and I do not think this is much related to NetBeans. The standard build is done using the javac from your JDK. The javac since JDK6 does not compile against rt.jar, but against a special symbol file (lib/ct.sym). This file does not contain private classes introduced in JDK6, including the one required by "comSunNetHttpserver5/src/com/sun/net/httpserver/spi/HttpServerProvider.java" from your project. If needed, the current javac allows to override this behavior using the following compiler argument:
-XDignore.symbol.file
(AFAIK this is a private option that may be removed in the future.)
Comment 3 emiddio 2010-05-18 18:19:38 UTC
i want to continue the dialog about this issue;

i accept your explanation -- but i want more clarification.

you imply this is something since jdk6 ??? please confirm ?

also ---

how is one to "debug" or run a program that uses classes from rt.jar ??

-- i mean -- suppose i want to debug some classes contained in rt.jar.

i grab the particular jdk6 sources i'm interested in and make mods to them and build a project -- but when i debug the project -- my "projects" classes are not used -- the classes used are those contained in rt.jar .

in the past the only way i could debug them -- (that i was able to think of),
was to un-jar rt.jar in to a dir; replace the classes with my modified ones,
then re-jar rt.jar and put it into the jdk6 location(s).

this seems clumsy -- is there an easier way -- and a better way ?

thanks
Comment 4 emiddio 2010-05-19 19:33:17 UTC
if i add rt.jar to my project as a library jar -- it will still not compile.

so how am i to make use of classes in rt.jar not listed in lib/ct.sym in a
way that does not use a "private javac option" ???

thanks
Comment 5 Jan Lahoda 2010-05-25 17:35:23 UTC
AFAIK, the ct.sym is new in JDK6. It contains stubs for all classes that existed in JDK5 (for compatibility with existing programs that would use private JDK classes), but does not contain implementation classes that were introduced in JDK6 (only API classes). This is to prevent application developers to accidentally use JDK's private classes (as such applications would be unportable and may not run on future versions of JDK). Note that this is not really a NB thing - this is the behavior of javac from the JDK. I do not know about any way to disable this except deleting ct.sym or the option mentioned above.

Regarding loading the classes: JVM uses two classpath's: classpath and bootclasspath. rt.jar is on the bootclasspath and has precedence over anything on the "custom" classpath, which is used by the application. The usual way to override classes on bootclasspath is to start the JVM with "-Xbootclasspath/p:<location-where-to-find-classes>" option, which prepends the given jars (and presumably also directories) to bootclasspath.
Comment 6 Dusan Balek 2010-06-07 11:21:02 UTC
Standard javac behavior. There is nothing to do on the NetBeans side.