Community
Participate
Working Groups
If I understand bug 527353 correctly, then o.e.osgi is moving away from static profiles to dynamically computing that information from the JVM. OTOH, I still see org.eclipse.jdt.internal.launching.environments.ExecutionEnvironment.getProfileProperties() retrieving JavaSE-9.profile, which btw declares that it is not finalized (maybe never will?). In bug 527353 comment 8 I'm seeking advice whether/how JDT could leverage the dyncamically computed information. Symptom of the current situation: packages, e.g., in javafx.* are not covered by any positive access rule and hence excluded from features like code completion, see https://stackoverflow.com/questions/48969679/how-to-enable-auto-import-in-eclipse-for-javafx-classes/48973377
One quick idea: since JDT/Core implements the same algorithm from JEP 261 as o.e.osgi does, do we at all need to read the list of system packages from any profile, or could we just say the default accessibility is entirely managed by jigsaw, not by profiles (still overridable by explicit access rules, if for whatever reasons users might need this)?
I am fine with it. So this should be targeted to beta 18_3 I assume?
(In reply to Stephan Herrmann from comment #1) > One quick idea: since JDT/Core implements the same algorithm from JEP 261 as > o.e.osgi does, do we at all need to read the list of system packages from > any profile, or could we just say the default accessibility is entirely > managed by jigsaw, not by profiles (still overridable by explicit access > rules, if for whatever reasons users might need this)? If these can be overridden that'll make everyone happy.
So how do we go about it? any suggestion?
Just to add the reference so that it is not lost - see bug 531263 comment #1: org.eclipse.jdt.launching.environments.IExecutionEnvironment.getComplianceOptions() return null for EE 10.
I'm currently looking into this. A quick question: what would be a proper way for detecting that an org.eclipse.jdt.launching.environments.IExecutionEnvironment has compliance 9 or greater? - does a helper exist (e.g., based on env.getId() ("JavaSE-9"))? - should we still read the profile to get the compliance level, but then simply ignore the list of system packages?
New Gerrit change created: https://git.eclipse.org/r/119000
(In reply to Eclipse Genie from comment #7) > New Gerrit change created: https://git.eclipse.org/r/119000 Draft. Is this too naive? Note, that here I'm still using the profile to retrieve the compliance level. I can confirm that - this makes javafx classes available in content assist by default. - it is still possible to restrict access via explicit access rules.
(In reply to Stephan Herrmann from comment #8) > (In reply to Eclipse Genie from comment #7) > > New Gerrit change created: https://git.eclipse.org/r/119000 > > Draft. > > Is this too naive? > > Note, that here I'm still using the profile to retrieve the compliance level. > > I can confirm that > - this makes javafx classes available in content assist by default. > - it is still possible to restrict access via explicit access rules. Yes, otherwise looks fine but as we are not going to have the profile any more, we need to decide on how to handle that. How do we create the profile at run time like Osgi.
What information previously obtained from the profile is needed? - the compliance (can we simply compute "9" from "JavaSE-9"?) - the list of packages is *not* needed as per my patch - what else?
(In reply to Stephan Herrmann from comment #10) > What information previously obtained from the profile is needed? > - the compliance (can we simply compute "9" from "JavaSE-9"?) > - the list of packages is *not* needed as per my patch > - what else? COMPILER_COMPLIANCE, COMPILER_SOURCE, COMPILER_CODEGEN_TARGET_PLATFORM and COMPILER_RELEASE All bascially pointing 9 or 10 or so on. So If we don't find a profile file from OSGI, can we just read the release file and find the version and set it ?
My proposal - IExecutionEnvironment and the schema executionEnvironments will need a new attribute for compliance (As the release file will not be available if the corresponding Java version is not available with the user). This can be used instead of OSGI Profile to populate the initial properties. This will also be required for proper ordering of Execution Environments in the preference page. Does it sound ok?
(In reply to Sarika Sinha from comment #12) > My proposal - > IExecutionEnvironment and the schema executionEnvironments will need a new > attribute for compliance (As the release file will not be available if the > corresponding Java version is not available with the user). And o.e.j.launching/plugin.xml will continue to provide these extensions, so for known environments, we will always have the compliance available without the aid of OSGi, right? This would fit nicely into the existing gerrit, replacing the use of environment.getComplianceOptions() The only thing I'm not sure of is: do we want to support future Java releases, or only those known at the time when o.e.j.launching is released? If the pattern JavaSE-<version> is fixed long term (which honestly I don't know), then a simple string matching would achieve the same and be more open. Another question: is adding a field in an extension point a breaking / incompatible change? Other than those, your proposal sounds good to me.
(In reply to Stephan Herrmann from comment #13) > > The only thing I'm not sure of is: do we want to support future Java > releases, or only those known at the time when o.e.j.launching is released? > > If the pattern JavaSE-<version> is fixed long term (which honestly I don't > know), then a simple string matching would achieve the same and be more open. > > Another question: is adding a field in an extension point a breaking / > incompatible change? > > Other than those, your proposal sounds good to me. I am planning to make it optional, so I guess it should not be a breaking change(Will check the rules again), but yes it will definitely be an API change and will have to seek PMC approval. I don't plan to put for future releases right now.
(In reply to Sarika Sinha from comment #14) > (In reply to Stephan Herrmann from comment #13) > > > > The only thing I'm not sure of is: do we want to support future Java > > releases, or only those known at the time when o.e.j.launching is released? > > > > If the pattern JavaSE-<version> is fixed long term (which honestly I don't > > know), then a simple string matching would achieve the same and be more open. > > > > Another question: is adding a field in an extension point a breaking / > > incompatible change? > > > > Other than those, your proposal sounds good to me. > > I am planning to make it optional, so I guess it should not be a breaking > change(Will check the rules again), but yes it will definitely be an API > change and will have to seek PMC approval. > > I don't plan to put for future releases right now. fine by me
Adding an optional attribute to an extension point doesn't need PMC approval. > I don't plan to put for future releases right now. But definitely something to invest. The less manual/static work we have to do for a new release the better. Please open a bug report for that and cc us.
This should go into 3a and 4.8.
There are two more properties used from the profile : org.eclipse.jdt.core.compiler.problem.assertIdentifier org.eclipse.jdt.core.compiler.problem.enumIdentifier They are error since 1.5 It was warning for - J2SE-1.4.profile OSGi_Minimum-1.2.profile CDC-1.1_Foundation-1.1.profile It was ignore in the initial ones - CDC-1.0_Foundation-1.0.profile OSGi_Minimum-1.0.profile OSGi_Minimum-1.1.profile J2SE-1.2.profile J2SE-1.3.profile Need to find out how is that arrived at so that launching can also populate it.
(In reply to Dani Megert from comment #16) > Adding an optional attribute to an extension point doesn't need PMC approval. > > > > I don't plan to put for future releases right now. > > But definitely something to invest. The less manual/static work we have to > do for a new release the better. Please open a bug report for that and cc us. We will need to add attribute in org.eclipse.jdt.launching.environments.IExecutionEnvironment which will I guess need pmc approval. We already have Bug 531843 for Adding support for running unreleased JDKs with a warning.
(In reply to Sarika Sinha from comment #19) > > We will need to add attribute in > org.eclipse.jdt.launching.environments.IExecutionEnvironment which will I > guess need pmc approval. > I am working to avoid it so that getComplianceOptions can handle it internally.
(In reply to Sarika Sinha from comment #20) > (In reply to Sarika Sinha from comment #19) > > > > > We will need to add attribute in > > org.eclipse.jdt.launching.environments.IExecutionEnvironment which will I > > guess need pmc approval. > > > I am working to avoid it so that getComplianceOptions can handle it > internally. If the correct thing is to add the APIs, then we should do so and ask the PMC. The interface does not allow to be extended or implemented, so, adding stuff there is safe.
New Gerrit change created: https://git.eclipse.org/r/119469
Gerrit change https://git.eclipse.org/r/119469 was merged to [BETA_JAVA_18_3]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=93425086022ed4c127717fe75c609f5bf5d3e230
Gerrit change https://git.eclipse.org/r/119000 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=11e35800aeaa1d92986860d5d3bd6a0ff5554dfc
New Gerrit change created: https://git.eclipse.org/r/119565
Gerrit change https://git.eclipse.org/r/119565 was merged to [BETA_JAVA_18_3]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=89c62baa1ebcb971cf65b98c0db25ed10296ae6d
Thanks Stephan!!
*** Bug 528073 has been marked as a duplicate of this bug. ***
Verified using Eclipse SDK Version: Photon (4.8) Build id: I20180322-0645
(In reply to Stephan Herrmann from comment #8) > (In reply to Eclipse Genie from comment #7) > > New Gerrit change created: https://git.eclipse.org/r/119000 > > Draft. > > Is this too naive? > > Note, that here I'm still using the profile to retrieve the compliance level. > > I can confirm that > - this makes javafx classes available in content assist by default. > - it is still possible to restrict access via explicit access rules. While adding the N&N entry, I got a doubt, shouldn't we use the release level instead of compliance level ?
(In reply to Sarika Sinha from comment #30) > (In reply to Stephan Herrmann from comment #8) > > (In reply to Eclipse Genie from comment #7) > > > New Gerrit change created: https://git.eclipse.org/r/119000 > > > > Draft. > > > > Is this too naive? > > > > Note, that here I'm still using the profile to retrieve the compliance level. > > > > I can confirm that > > - this makes javafx classes available in content assist by default. > > - it is still possible to restrict access via explicit access rules. > > While adding the N&N entry, I got a doubt, shouldn't we use the release > level instead of compliance level ? I haven't followed the details of --release, but doesn't setting release imply use of the same level as compliance? OTOH, is a release level always available?
(In reply to Stephan Herrmann from comment #31) > > > > While adding the N&N entry, I got a doubt, shouldn't we use the release > > level instead of compliance level ? > > I haven't followed the details of --release, but doesn't setting release > imply use of the same level as compliance? OTOH, is a release level always > available? Will check out the details!!
I think then, we can remove these entries from /org.eclipse.jdt.launching/plugin.xml - <environment description="%environment.description.13" id="JavaSE-9" ruleParticipant="org.eclipse.jdt.internal.launching.environments.DefaultAccessRuleParticipant"> </environment> <environment description="%environment.description.14" id="JavaSE-10" compliance="10" ruleParticipant="org.eclipse.jdt.internal.launching.environments.DefaultAccessRuleParticipant"> </environment> Then the check for COMPILER_COMPLIANCE is not required. @Stephan, what do you think?
(In reply to Sarika Sinha from comment #33) > I think then, we can remove these entries from > /org.eclipse.jdt.launching/plugin.xml - Removing via Bug 536224.
