Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #426884 +++ The same changes that were necessary for Java 1.8 support are necessary for Java 1.9 support.
Created attachment 270345 [details] Add in Java 9 support
Rob, any bug in a maintenance stream should have project lead review. This change will go into WTP 3.9.1a and WTP 3.10.
Why 3.9.1a? why not 3.9.2?
(In reply to Fred Bricon from comment #3) > Why 3.9.1a? why not 3.9.2? Because 3.9.1a is the release that should provide good support for Java 9.
(In reply to Dani Megert from comment #4) > Because 3.9.1a is the release that should provide good support for Java 9. Yes I get that, I'm questioning the versioning scheme. You can still release 3.9.3 for Oxygen.2, 3.9.4 for Oxygen.3, and so forth.
Fred, a bug is not the best place to discuss the WTP versioning (a vote was called for on the PMC mailing list). Simply put, the Eclipse Planning Council decided to call the quick update to Oxygen.1 that provides Java 9 and JUnit 5 support Oxygen.1a. The Eclipse Platform is calling their release 4.7.1a. As such, it makes sense for WTP to follow suit and call its minimal release with Java 9 support WTP 3.9.1a.
Patch looks good from my perspective, but I have one question. Do we want JDK 9 to be the default fallback version on line 96? https://bugs.eclipse.org/bugs/attachment.cgi?id=270345&action=diff#src/org/eclipse/jst/common/project/facet/core/StandardJreRuntimeComponent.java_sec4 - rcv = StandardJreRuntimeComponent.VERSION_1_8; + rcv = StandardJreRuntimeComponent.VERSION_1_9;
(In reply to Nick Boldt from comment #7) > Patch looks good from my perspective, but I have one question. > > Do we want JDK 9 to be the default fallback version on line 96? > > https://bugs.eclipse.org/bugs/attachment.cgi?id=270345&action=diff#src/org/ > eclipse/jst/common/project/facet/core/StandardJreRuntimeComponent.java_sec4 > > - rcv = StandardJreRuntimeComponent.VERSION_1_8; > + rcv = StandardJreRuntimeComponent.VERSION_1_9; Nick, It has always been the case that, when the exact JRE level cannot be determined, the latest version is the default. I am just continuing that practice.
Where *does* it try to determine the right level?
Few things: 1) The patch looks clean and good. I don't see anything too objectionable there. 2) While I recognize that upping the default to the next java version is past practice, it does seem that java 9 is likely to cause a lot of issues to a lot of application servers, eclipse, osgi containers, and a good number of other frameworks. If someone insisted we don't bump the default, or could provide a good reason not to, I wouldn't object. But, in the absence of such a request, I also won't insist we keep the default j8 either. 3) Is this seriously all that's necessary to add j9 support? Does the j9 facet only do things like configure the classpath container? While I of course trust you, it'd be nice to get a written confirmation on this. Assuming nobody makes a formal request re: 2), and Carl confirms 3) is all that's required, then I +1 this. Final note: I'm a bit dismayed to see that the patch is provided as an attachment instead of a gerrit request ;) Didn't we recently set up gerrit for wtp-common? =P
(In reply to Rob Stryker from comment #10) > Few things: > > 1) The patch looks clean and good. I don't see anything too objectionable > there. > > 2) While I recognize that upping the default to the next java version is > past practice, it does seem that java 9 is likely to cause a lot of issues > to a lot of application servers, eclipse, osgi containers, and a good number > of other frameworks. If someone insisted we don't bump the default, or could > provide a good reason not to, I wouldn't object. But, in the absence of such > a request, I also won't insist we keep the default j8 either. > > 3) Is this seriously all that's necessary to add j9 support? Does the j9 > facet only do things like configure the classpath container? While I of > course trust you, it'd be nice to get a written confirmation on this. > > > Assuming nobody makes a formal request re: 2), and Carl confirms 3) is all > that's required, then I +1 this. > > Final note: I'm a bit dismayed to see that the patch is provided as an > attachment instead of a gerrit request ;) Didn't we recently set up gerrit > for wtp-common? =P 1) Good, I will mark it as reviewed 2) To answer Nitin's question and explain here, the code right above the default attempts to match the JVM version string with the appropriate level. Note that setting the latest version as a default is a good practice, since Java is supposed to be backwards-compatible, so we are better off setting the highest Java version as an assumption, instead of a lower, more stable one that may cause compilation errors due to use of API in a higher java version. (Java EE does the same with its defaults.) 3) This adds in the Java 9 facet. Yes, there isn't much code to add in a new Java facet. As to this being a patch instead of a gerrit request, well, old dog, new tricks.
Committed to master for WTP 3.9.1a and WTP 3.10.0 M3
New Gerrit change created: https://git.eclipse.org/r/106021
Gerrit change https://git.eclipse.org/r/106021 was merged to [master]. Commit: http://git.eclipse.org/c/webtools-common/webtools.common.git/commit/?id=23766a164140cf34c037c6066386b64769e8f7c7
Sorry, I have maybe a stupid question but: Why is the facet number 1.9 Would it not be nicely to use the nes Java version scheme: facet 9 So you have a similar value like for the javac source/target properties see: https://docs.oracle.com/javase/9/tools/javac.htm 1.8 The compiler accepts code with features introduced in Java SE 8. 8 Synonym for 1.8. 9 The default value. The compiler accepts code with features introduced in Java SE 9.
Agreed with Michael, this should be Java Facet 9. If we start introducing 1.9 now, we'll never be able to fix it later.
The patch is wrong anyway. Creating a Java 1.9 web project results in: - Java compiler level does not match the version of the installed Java project facet. - Unbound classpath container: 'JRE System Library [JavaSE-1.9]' in project 'xdfg' I'll submit a gerrit changeset which fixes it once I finish my tests
New Gerrit change created: https://git.eclipse.org/r/106050
https://git.eclipse.org/r/#/c/106050/ changes Facet from 1.9 to 9 Creating a web project targeting Facet 9 now works without errors. m2e-wtp can convert a simple jar project compiled with Java-SE9 into an EJB or WAR project, the proper facet being applied automatically. No changes required in m2e-wtp. I thought about going 9.0 to stay consistent with other facets, but there's no such thing as Java 9.0, nor will there be 9.x.
thanks fred I have a look at it
New Gerrit change created: https://git.eclipse.org/r/106058
Gerrit change https://git.eclipse.org/r/106058 was merged to [master]. Commit: http://git.eclipse.org/c/webtools-common/webtools.common.git/commit/?id=7dbec4d768f69b8f46d9e68d74673cf6beb0eb85
New Gerrit change created: https://git.eclipse.org/r/106109
Gerrit change https://git.eclipse.org/r/106109 was merged to [master]. Commit: http://git.eclipse.org/c/webtools-common/webtools.common.git/commit/?id=aed1fc923dec3f879c3cd6d1c9ac6abb1d91461b
(In reply to Eclipse Genie from comment #21) > New Gerrit change created: https://git.eclipse.org/r/106058 Fred, you asked why I had to leave the one 1_9 variable in there- Web Services had already committed code that referenced that variable, and the build would have been broken until they changed their reference- that's why I marked it as @Deprecated and added a comment that that would be removed before we shipped 3.9.1a. All of the changes that I made have been committed, and this issue seems to be resolved.
Thanks for the explanation Carl
Can we set the target milestone for this? We're starting to get duplicate reports opened.
*** Bug 525673 has been marked as a duplicate of this bug. ***
