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.
The JavaDataObject returned from ClassElement.forName("java.lang.String").getCookie(DataObject.class) provides a compiler cookie. However, when this cookie is added to the compiler job the resulting job fails with the error message java/lang/String.java [0:0] No file named java/lang/String.java exists on disk in src.zip. Therefore it may not be compiled with an external compiler. You may need to check it out from version control or save some changes to it. This seems to be a regression and also non intuitive behavior. Classes which cannot be compiled and will produce this error message should not return a compile cookie. I am attaching a test program to demonstrate the problem.
Created attachment 9047 [details] test code demonstrating the behavior
Qbuild - QBE200302050100
Make sure that src.zip is mounted in the filesystem. This may be reasonable for users who would like to debug into jdk source.
This is not regression. This behavior is there from beginning. The only difference is that in NB 3.4 and later editor module mounts src.zip automatically. I don't understand why you want to compile java.lang.String. Can you, please, explain it?
If NB 3.4 and later mounts src.zip automatically then this is a regression for S1S. If src.zip is not mounted, then the test code given will not produce a failure. The point is that we don't want to compile java.lang.String and expect that the getCookie(CompilerCookie.Compile.class) should return null. In S1S we use the compiler dependency mechanism to force java compilation before EJB validation (which includes the primary key class of entity beans). In the past this worked as expected when a non composite primary key was used (java.lang.String, java.lang.Integer); however, now these classes appear to be compilable and are attempted as part of the compilation set. This is basically the result of the program I enclosed. As I see this there are several solutions: 1. Use the criteria causing the external compiler error message (or appropriate criteria based on the compiler type) to determine if a cookie should be displayed. This would also prevent inappropriate display of Build, Compile, and Clean actions when invoking the context menu of a src file from src.zip (make this visible) and then check the context menu. This would also have the side effect of having these menus displayed correctly for other non compilable source. 2. Not automount src.zip as a hidden file or not at all in the user classpath. If this were done the user would either not see the problem if the classpath mount were seperate or see the src.zip either way would make the problem easy to diagnose. 3. Do nothing. We could then either attempt to exclude from certain paths from compilation (this could be tricky past the standard java* as the sun based packages are not standardized and could present a problem for developers within sun). I like #1 as this would present a consistent user view for other source which cannot be compiled.
BTW: Why don't you use JavaMake to manage Java source dependecies?
The decision on which files to compile has to be extracted from a deployment descriptor, so we have to seed the compiler with something. The new project system will eliminate this problem as an ejb project can have a dependency on the compiled classes (which hopefully will use javamake for java dependency analysis).
So - if you have special preferences what classes to compile and what not, please apply the filter on your side. Currently it seems that you query a DataObject for java.lang.String and rely on an undocumented (and invalid) property that there's no compilable source for it.
The problem is determining what not to compile. I will apply the filter which is a workaround for the compile cookie being active for files which cannot be compiled.
Added workaround to S1S
Thank you, Chris.