Community
Participate
Working Groups
4.8 M3a Tons of exceptions logged to console when switching EE to JavaSE-1.8. In total I get 1365 lines spit into the OS console. I'm marking this as critical since I have no clue what the impact is. Also, nothing in put into the .log. Test Case: 1. Start new workspace with Java 9 (make sure you have an OS log console) 2. Create Java project 'P' 3. Add a Java 1.8 JRE 4. Switch the BREE for 'P' to 'JavaSE-1.8' ==> tons of exceptions logged to OS console. See attached file.
Created attachment 271412 [details] Exceptions in console
I think this is expected. When there's a classpath change, we try to generate the delta and in the process try to resolve the package fragment roots. But now they are not part of project's build path anymore. Looks like we get one exception for each module. BTW, I don't see the errors in the console (but I tried with the most recent I build).
(In reply to Jay Arthanareeswaran from comment #2) > I think this is expected. You can maybe explain it, but it is for sure not expected to end in the console. > BTW, I don't see the errors in the console (but I tried with the most recent > I build). Yeah, I wanted to give a stable build. I also used the latest I-build (eclipse-SDK-I20171108-2000-win32-x86_64).
I don't know why I am not seeing it in the console, but I see why it happens. It's a print stack statement in PackageFragmentRoot.getModuleDescription() which should be removed.
(In reply to Jay Arthanareeswaran from comment #2) > I think this is expected. When there's a classpath change, we try to > generate the delta and in the process try to resolve the package fragment > roots. But now they are not part of project's build path anymore. This is true, but in order to compute a precise delta we should perhaps ignore the underlying ELEMENT_NOT_ON_CLASSPATH. Otherwise we are going to report removal of all roots in the JRT even if the project had access only to a few roots/modules (see how computePackageFragmentRoots() applies filtering IFF defaultRootModules() returns non-null). Or is it OK, to send removal delta for s.t. that was never present? Also note that there's a second "e.printStackTrace()" in JrtPackageFragmentRoot.getModule()
As the filtering in computePackageFragmentRoots() has a finger in this pie, I should add that I'm not 100% sure, the implementation of limit-modules and default roots (for the unnamed module) is done in the best possible way. (See also bug 526688 for some UI aspects of this). When I added this filtering right into computePackageFragmentRoots() I was attracted by the simplicity of effectively hiding all modules which should not be observable. As mentioned in bug 526688 this requires additional efforts if you want to access a type from a "hidden" module, be it for open type, completion or the like. This can be done, but ... ... I never considered the following alternative: instead of excluding hidden modules from the resolved classpath, we could perhaps use (a new kind of) AccessRestriction to signal: this module exists (physically) but is not normally observable. While similar to existing logic, attaching AccessRestrictions to a module would require additional implementation efforts across several layers of the architecture. Before further investigating feasibility of this alternative, which approach do you think better represents the intended semantics? (a) Effectively exclude not-observable modules from the project's classpath. (b) Include all modules but attach access restrictions to those that are not part of the module graph. Intuitively I'd say, access restrictions are more like a missing "exports" and using them to signal absence from the module graph might be misuse. Thoughts?
While the question in comment 6 is connected to this bug, unfortunately neither option seems to give us a free lunch in this bug: the following predicate from JEP 261 requires indeed to inspect the details of each module available via JRT: "every ... module ... that exports at least one package, without qualification, ..." This can only be answered if we really have the IModuleDescription :( I could only think of caching the computed list of module names inside the JrtPackageFragmentRoot. Yea, maybe that would also reduce some of the performance problems we still have ... Would such cache require updating when limit-modules is changed on the classpath entry or when the current project goes from unnamed to named module (or vice versa)? Or could we assume that all these modifications will trigger computing new package fragment roots anyway?
(In reply to Stephan Herrmann from comment #6) > Before further investigating feasibility of this alternative, which approach > do you think better represents the intended semantics? > > (a) Effectively exclude not-observable modules from the project's classpath. > > (b) Include all modules but attach access restrictions to those that are not > part of the module graph. > > Intuitively I'd say, access restrictions are more like a missing "exports" > and using them to signal absence from the module graph might be misuse. > > Thoughts? I also think access restrictions aren't the right thing here. Independent of the technical issues that are now raised, writing to the console should be stopped. If we think we need to raise an error it should go to the .log.
(In reply to Dani Megert from comment #8) > (In reply to Stephan Herrmann from comment #6) > Independent of the technical issues that are now raised, writing to the > console should be stopped. If we think we need to raise an error it should > go to the .log. I have replaced the print statements with logs: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=c2dfc61096af6f99f12808c54d0848932a39943a (In reply to Stephan Herrmann from comment #7) > Would such cache require updating when limit-modules is changed on the > classpath entry or when the current project goes from unnamed to named > module (or vice versa)? > Or could we assume that all these modifications will trigger computing new > package fragment roots anyway? I don't think so. This would require some work, I guess.
(In reply to Jay Arthanareeswaran from comment #9) > (In reply to Stephan Herrmann from comment #7) > > Would such cache require updating when limit-modules is changed on the > > classpath entry or when the current project goes from unnamed to named > > module (or vice versa)? > > Or could we assume that all these modifications will trigger computing new > > package fragment roots anyway? > > I don't think so. To which part of the "or"?
(In reply to Jay Arthanareeswaran from comment #9) > (In reply to Stephan Herrmann from comment #7) > > Would such cache require updating when limit-modules is changed on the > > classpath entry or when the current project goes from unnamed to named > > module (or vice versa)? > > Or could we assume that all these modifications will trigger computing new > > package fragment roots anyway? > > I don't think so. This would require some work, I guess. This could deserve new assessment after bug 466299 got resolved, which includes processing deltas regarding extra attributes (like limit-modules and friends). Anyway, caching would only possibly reduce the number of log entries, not avoid them completely.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
