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.
NB4.1, JDK1.5.0_02 Steps to reproduce: - run IDE from zip file - open project (when the project has set different than default platform - for example 1.4.2) - when you open project, dialog with unresolved problems rises -> and scanning dialog starts scan of rt.jar and src.zip of default platform (JDK1.5.0) I think, we don't need to wait for scanning of rt.jar and src.zip of platform I won't use.
This is currently as designed and should first be addressed in the projects infrastructure. The javacore does not know that there are some unresolved references. It depends on the classpath API (which is all it should depend on) and just scans the things on the classpath. Seems that the project infrastructure returns the default JDK on the classpath of a given project if the reference to the specific JDK is broken. Reassigning to java/project for consideration.
The j2seplatform returns the default platform since it was a requirement from javacore. If it is not needed it can be removed. But in such a case all the references to java.* javax.* packages will be marked as errors! Is it what we want? In my opinion WANTFIX.
OK, changing this behavior would bring more problems than it would solve. Closing as WONTFIX.
If I understand it correctly: We are scanning rt.jar and src.zip of Java Platform which isn't supposed be used any more. Am I right? Why do we do that? Who is asking for parsing of "the default Java platform" even if this platform will be never used? ... when user defines her own platform, why do we scan the default one ? We have to scan the user's defined platform, if it fails, don't parse the default one.
> We are scanning rt.jar and src.zip of Java Platform which isn't supposed be used > any more. Am I right? I am not sure. AFAIK the default platform *is* going to be used unless the broken reference to other platform is not resolved. You seem to be asking for changing this behavior - i.e. not using the default platform if the specific one is not found. If so, this has to be implemented on the projects side. Reassigning. If the solution in projects creates further problems (some exceptions, etc.) in javacore, provide diff of the change in projects and reassign to javacore for finishing.
If I understand it correctly, Marian is mainly concerned about the time (and memory) consumed by scanning platform that won't be used. I think this could be solved in the following way (only an overall idea, a lot of details would still need to be solved): If a project with broken references (of any kind) would be opened, a modal dialog allowing the user to fix the broken things would appear. The user would (or would not) solve the broken references and confirm the dialog. After this the classpath for the project would be set (according to current rules), and therefore the (correct) platform would be set&scanned. This would solve this problem with uselessly scanning the platform, and would not cause any problems with import removing, etc. Of course, one of the things that would need to be solved is the UI for more than one broken project.
The modal dialog is not acceptable, user may want to open the project without resolving the broken references, eg. copy a fragment of code. The only solution is not to return the default platform for project with broken platform, this will cause the project's bootpath to be empty. I've implemented the patch and found the following problems: 1) The error marking in the java file does not work and logs error into console. 2) Fix imports removes references to rt.jar classes, the fix imports should probably run only on the non broken projects. Do we want to integrate the patch? If so, the error marking should not log an error that java.lang is not on bootpath and fix import should be probably also fixed.
Created attachment 24126 [details] Diff of j2seproject
Solved: 1) The error marking in the java file does not work and logs error into console. Checking in src/org/netbeans/modules/javacore/jmiimpl/javamodel/ResourceImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ResourceImpl.java,v <-- ResourceImpl.java new revision: 1.100; previous revision: 1.99 done 2) Fix imports solved by Dan already. Reassigning back to Tomas Z. Tomasi, please commit your patch. Thanks.
Checking in j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/BootClassPathImplementation.java; /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/BootClassPathImplementation.java,v <-- BootClassPathImplementation.java new revision: 1.6; previous revision: 1.5 done
verified in NB5.0(200511201900)
Reorganization of java component