Bug 225261 - Allow bootclasspath classes to be on classpath (and bootclasspath to be empty)
Allow bootclasspath classes to be on classpath (and bootclasspath to be empty)
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Source
7.4
PC Linux
: P2 (vote)
: 7.4
Assigned To: Jaroslav Tulach
issues@java
: API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-23 21:24 UTC by Jaroslav Tulach
Modified: 2013-04-18 02:19 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Fallback to compile classpath before changing the source level (3.41 KB, patch)
2013-01-23 21:24 UTC, Jaroslav Tulach
Details | Diff
Patch seeking for java/lang/Object on bootClassPath first with unit test (8.84 KB, patch)
2013-04-14 19:27 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2013-01-23 21:24:58 UTC
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.
Comment 1 Jaroslav Tulach 2013-03-05 21:21:40 UTC
May I proceed with integration? Bck2Brwsr generated projects are broken in "7.4" due to having no bootclasspath...
Comment 2 Jan Lahoda 2013-03-06 16:24:48 UTC
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).
Comment 3 Milos Kleint 2013-03-06 16:29:42 UTC
MK1 do we have a different client than Bck2Brwsr? at least potentially..
Comment 4 Tomas Zezula 2013-03-06 16:53:48 UTC
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.
Comment 5 Jaroslav Tulach 2013-03-12 09:33:32 UTC
(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.
Comment 6 Jan Lahoda 2013-03-12 10:10:22 UTC
(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?
Comment 7 Milos Kleint 2013-03-12 10:14:53 UTC
(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..
Comment 8 Jaroslav Tulach 2013-03-14 09:08:34 UTC
(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.
Comment 9 Tomas Zezula 2013-03-14 09:54:24 UTC
>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.
Comment 10 Jaroslav Tulach 2013-04-14 19:27:47 UTC
Created attachment 133492 [details]
Patch seeking for java/lang/Object on bootClassPath first with unit test
Comment 11 Jaroslav Tulach 2013-04-14 19:44:57 UTC
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.
Comment 12 Jaroslav Tulach 2013-04-15 13:51:58 UTC
Tomáš Z. expressed so-so approval of the latest patch in our hallway conversation. I'll integrate tomorrow, then.
Comment 13 Jaroslav Tulach 2013-04-16 07:39:02 UTC
core-main#6e589803106f
Comment 14 Quality Engineering 2013-04-18 02:19:28 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo