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.
| Summary: | Allow bootclasspath classes to be on classpath (and bootclasspath to be empty) | ||
|---|---|---|---|
| Product: | java | Reporter: | Jaroslav Tulach <jtulach> |
| Component: | Source | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | apireviews, tzezula |
| Priority: | P2 | Keywords: | API_REVIEW_FAST |
| Version: | 7.4 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Attachments: |
Fallback to compile classpath before changing the source level
Patch seeking for java/lang/Object on bootClassPath first with unit test |
||
May I proceed with integration? Bck2Brwsr generated projects are broken in "7.4" due to having no bootclasspath... JL01: I would like to know why this is a correct approach - it depends on the bootclasspath being empty, and will fail if the BCP won't be empty for any reason. E.g. adding a module that will prepend a jar on all (maven) bootclasspaths is (and will be) mostly OK, but will destroy the benefits of the patch. I believe it would be cleaner if the correct bootclasspath would be reported from the project. JL02: Tests? JL03: Performance: is there an evaluation on how much slower this is/will be and a plan to evaluate and resolve potential performance regressions? JL04: Please prevent repeated evaluation of bootClassPath.getRoots() (should also remove the need to change indendation level). MK1 do we have a different client than Bck2Brwsr? at least potentially.. For the J2SEProject's boot classpath it's not uncommon to have a root added by 3rd party module using ClassPathModifier which makes the empty boot classpath nonempty. (In reply to comment #2) > JL01: I would like to know why this is a correct approach I'd like to know that as well, but as you told me to implement the patch this way, I did it. Have you changed your mind? I'd prefer to skip the empty boot classpath check, if that is what you are calling for. Tell me whether to follow that direction. Re. JL03 & MK01: The reason why these classes are searched on classpath only if bootclasspath is empty is to eliminate any performance penalty for non-bck2brwsr projects. Please tell me which specific scenario to compare performance and I'll do it. (In reply to comment #5) > (In reply to comment #2) > > JL01: I would like to know why this is a correct approach > > I'd like to know that as well, but as you told me to implement the patch this > way, I did it. Have you changed your mind? Hm, I am not sure I told you that. From our offline conversation, you asked if it could search compile classpath, and I (reluctantly) admitted it might (citing possible performance problems). The question is: why is the project not providing the correct bootclasspath? > > I'd prefer to skip the empty boot classpath check, if that is what you are > calling for. Tell me whether to follow that direction. You mean consult compile CP always? That is surely not what I am calling for - as I said offline, some people have pretty long compile classpath, so the performance impact of that could be pretty big. > > Re. JL03 & MK01: The reason why these classes are searched on classpath only if > bootclasspath is empty is to eliminate any performance penalty for > non-bck2brwsr projects. Please tell me which specific scenario to compare > performance and I'll do it. Deciding what needs to be tested before a change is made is part of the change, so up to you to determine, I guess - what is needed to check so that our performance does not regress? How do we solve a performance regression if it occurs? (In reply to comment #5) > > Re. JL03 & MK01: The reason why these classes are searched on classpath only if > bootclasspath is empty is to eliminate any performance penalty for > non-bck2brwsr projects. Please tell me which specific scenario to compare > performance and I'll do it. you probably misread my comment. I asked if only client requiring this is your pet project. Even if no performance penalty occurs, it's still questionable in my eyes then. Unless it becomes official oracle project of course.. (In reply to comment #7) > you probably misread my comment. I asked if only client requiring this is your > pet project. Even if no performance penalty occurs, it's still questionable in > my eyes then. Unless it becomes official oracle project of course.. Should my changes negatively influence Oracle, then yes. On the other hand NetBeans is open source and preventing pet-lovers to donate improvements is not the best way to prove that. To answer your question, I believe this is a general issue everyone supporting technology which requires different rt.jar runs into. Often people solve it by writing own project type or specific IDE code (GWT, Android, Oracle Cloud and its whitelist). However that is often a barrier in adoption, which this change requests tries to lower. I've seen similar need when working on support for Lejos - in general anything smaller than JavaSE has a need to replace rt.jar. Re. performance and empty/non-empty boot classpath: Now I believe a better indicator for seeking classpath is missing java.lang.Object on bootclasspath. I'll adjust my patch according to all your comments. >Should my changes negatively influence Oracle, then yes. The only way how to prove that it's not the case is to write a performance test showing that the change does not affect performance. >Re. performance and empty/non-empty boot classpath: Now I believe a better >indicator for seeking classpath is missing java.lang.Object on bootclasspath. should be: is missing java.lang.Object on bootclasspath and source path. Created attachment 133492 [details]
Patch seeking for java/lang/Object on bootClassPath first with unit test
Performance assessment. I've added temporary logging around the initial check:
long bef = System.currentTimeMillis();
if (bootClassPath.findResource("java/lang/Object.class") == null) { // NOI18N
// empty bootClassPath also check classpath
classPath = cpInfo.getClassPath(PathKind.COMPILE);
}
System.err.println("additional check took: " + (System.currentTimeMillis() - bef) + " ms");
Scenario 1: Run on JDK7 and create new JavaApplication project.
Result: 0ms - the code in question does not even run. I have to admit I don't know how to create a JavaApplication project that would use something older than JDK6.
Conclusion: To check that bootclasspath is using proper JDK new than 1.4 costs nothing.
Scenario 2: Open the Maven project which defines
"netbeans.ignore.jdk.bootclasspath" property (as defined by enhancement 223682).
Result: 0ms - the check runs, but takes little time
Conclusion: To check that one runs on non-JDK project takes nothing.
Please add your comments and suggestions. I'd like to integrate this week.
Tomáš Z. expressed so-so approval of the latest patch in our hallway conversation. I'll integrate tomorrow, then. core-main#6e589803106f Integrated into 'main-golden', will be available in build *201304172301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/6e589803106f User: Jaroslav Tulach <jtulach@netbeans.org> Log: #225261: If bootclasspath does not contain Object, seek for it in classpath |
Created attachment 130556 [details] Fallback to compile classpath before changing the source level Bck2brwsr reimplements core Java classes. It moreover splits them into multiple modules. In order to get proper view of classes available on the platform, it is desirable to skip classpath completely (done as enhancement 223682). However if I do it, it turns out that the java.source module switches to -source 1.3 (as it cannot find AssertionError or StringBuilder). I have them only on classpath, and the java.source searches only bootclasspath or the sourcepath. Here is a little patch that works in my case. When the bootclasspath is empty (and it is because of enhancement 223682), also search compile classpath.