Hi Ed
> I'm confused. What are the JDT Java 9 builds?
Those are special builds, built from a special branch. No Java 9 work
will go into the June release of Oxygen.
> Will M6 include everything necessary for explicit use of a Java 9
SDK in a compatibility mode where existing projects are not using any
Java 9 features?
No, M6 won't work out of the box, but this will be fixed with M7(_bug
493761_ <https://bugs.eclipse.org/493761>). If you want to try it with
M6, you have to add"--add-modules=java.se.ee" to the eclipse.ini.
Dani
From: Ed Willink <[email protected]>
To: [email protected]
Date: 08.03.2017 12:08
Subject: Re: [cross-project-issues-dev] Will Your Project Work When
Running on Java 9?
Sent by: [email protected]
------------------------------------------------------------------------
Hi
I'm confused. What are the JDT Java 9 builds?
Will M6 include everything necessary for explicit use of a Java 9 SDK
in a compatibility mode where existing projects are not using any Java
9 features? i.e specifying Java 9 as my JAVA_HOME, and Java 9 as my
installed preference within Eclipse.
Regards
Ed Willink
On 08/03/2017 10:18, Ed Merks wrote:
Dani,
Yes, though you definitely need that if you want to use Window ->
Preferences -> Java -> Installed JREs to be able to point to a Java 9
JDK; as you know that just doesn't work without JDT's Java 9 support
because it won't be recognized as a JDK/JRE otherwise. And of course
project testers definitely want that if they want to be able to
debug-launch their self-hosted project code with a Java 9 JDK to debug
anything that might be going wrong. And in all cases it seems good
(to me) if everyone tests JDT's Java 9 support while they're testing
that Java 9 works also for their running code in the installation.
On 08.03.2017 10:30, Daniel Megert wrote:
Thanks Ed.
I will follow up on this with additional details later this week.
One important thing: you do not need JDT's Java 9 builds in order to
run Eclipse with Java 9. This is only necessary if you want to test
new Java 9 related functionality.
Dani
From: Ed Merks _<[email protected]>_ <mailto:[email protected]>
To: Cross project issues _<[email protected]>_
<mailto:[email protected]>
Date: 08.03.2017 10:05
Subject: [cross-project-issues-dev] Will Your Project Work When
Running on Java 9?
Sent by: [email protected]_
<mailto:[email protected]>
------------------------------------------------------------------------
Hi,
Wayne recently blogged about Eclipse's Java 9 support:
_https://waynebeaton.wordpress.com/2017/03/02/eclipse-ide-oxygen-edition-and-java-9/_
Also, the planning council has been discussing the Oxygen release
schedule with respect to Java 9 support:
_https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02719.html_
Most projects are likely *not *doing anything specific to support the
new feature of Java 9 so probably most of you aren't so concerned
about what you need to do. But it's likely that users will install
Java 9 once it's released (in July) and that makes it likely users
will try to run Eclipse itself with a Java 9 VM. So the question is,
*will your project work when running on Java 9*? Probably, but maybe
not. I would strongly encourage you to test that!
Wayne's blog describes what you need to do. To make testing even
easier, I've automated the setup process with an Oomph Configuration.
What's a configuration you ask?
_https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Automation_and_Specialization_with_Configurations_
I've attached a configuration that does several things.
* The installation portion of the configuration
o adds a p2 task to reference the platform's Y build update
site, i.e., the builds that contain JDT's early access Java 9
support (so whatever product you install, it will consider
installing it from the Y build),
o and adds the --add-modules VM argument to the eclipse.ini (so
launching will actually function).
* The workspace portion of the configuration
o redirects the 4.7 I builds URL to the 4.7 Y builds URL, so if
you using Oomph's targlets to provision your target platform,
and provision an Oxygen target platform, it will provision one
that uses the 4.7 Y builds, so you can debug launch your
project code with a Java 9 IDE,
o and creates a JDT "Installed JRE" that references a Java 9
JDK, and that includes the --add-modules VM argument so you
can launch a self hosting IDE running on Java 9.
You can try the configuration out with the latest installer. Either
update the one you have (from the menu in Simple mode or the toolbar
button at the bottom in advanced mode) or download the latest one from:
_https://wiki.eclipse.org/Eclipse_Installer_
To apply the configuration, you can drag and drop the email attachment
to the title area of the installer (both in simple mode and advanced
mode). Alternatively you can save the configuration attachment and
copy the file itself (or the contents of the file), to the clipboard,
and then apply it (via the menu in simple mode or via the first
toolbar button next to the search field in advanced mode). If you're
in simple model, applying the configuration will notice it has a
workspace portion and will offer to switch to advanced mode, or will
offer just apply the installation portion of the configuration. You
can do either. Now you can proceed to choose a product (and
optionally a project) to provision.
If you're using Java 9 for the first time, and you've only unzipped it
so far, you'll need to make Oomph aware that your Java 9 JDK is
available on your machine.
* In simple mode you can do this as follows. Choose whatever product
you want to install on the first page. On the second page,
choose the "Oxygen" version of that product. For the Java VM
choice, use the folder button to open the Java Virtual Machines
dialog and use the Browse button to locate the Java 9 JDK on your
file system. Once it's displayed, make sure it's selected and
hit OK. This will create an Oxygen installation of whatever
product you've chosen, configured to use a Java 9 VM along with
the right VM arguments so it can actually launch successfully.
* In advanced model you can do this as follows. Choose whatever
product you want to install on the first page and choose the
Oxygen Product Version. Use the folder button next to the Java VM
choice and use the Browse button to locate the Java 9 JDK on your
file system. Make sure it's selected in the combo box. Advance
to the next page (Project page). Here you can choose your Project
setup. If you don't have one, I'll bet your project doesn't have a
lot of external contributors and I'll bet that you spend a lot of
time on manually setting up your workspace. I typically choose
the Oomph project (or EMF project) on the Project page, and then I
advance to the Variables page to select the Oxygen target platform
for testing against the latest platform code.
Whatever steps you take, the result will be to launch an Oxygen
product based on the platform's Oxygen Y build, complete with Java 9
early access support and running on Java 9 early access JVM. If you
choose a project as well, the workspace will be populated with all
your source code using an Oxygen target platform also with Java 9
support and will be compiled against a Java 9 JDK. So you can launch
and debug, without changing your project setup at all.
Probably your project will work just fine, but don't count on it! For
example, Oomph uses a class derived from java.util.Properties in order
to save properties files. The implementation of that class is changed
slightly in Java 9, with the net effect that any properties file we
save ends up being empty, no stack traces or other visible symptoms of
the failure point. The overall effect was that any attempt to
install/update anything in the IDE (or to produce an installation with
the installer application) resulted in an empty config.ini. As you
can imagine, a corrupted config.ini prevents the installation from
running. So it was a pretty catastrophic failure! Thank goodness
it's already fixed, even for the next Neon release.
During testing I also see this stack trace in my Error log:
java.lang.reflect.InaccessibleObjectException: Unable to make field
private static volatile java.net.Authenticator
java.net.Authenticator.theAuthenticator accessible: module java.base
does not "opens java.net" to unnamed module @26749efe
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:335)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:278)
at
java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:175)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:169)
at
org.eclipse.epp.internal.mpc.core.util.ProxyHelper.getDefaultAuthenticator(ProxyHelper.java:116)
at
org.eclipse.epp.internal.mpc.core.util.ProxyAuthenticator.uninstall(ProxyAuthenticator.java:186)
at
org.eclipse.epp.internal.mpc.core.util.ProxyHelper.uninstallAuthenticator(ProxyHelper.java:69)
at
org.eclipse.epp.internal.mpc.core.util.ProxyHelper.releaseProxyService(ProxyHelper.java:60)
at
org.eclipse.epp.internal.mpc.core.MarketplaceClientCorePlugin.stop(MarketplaceClientCorePlugin.java:90)
at
org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:830)
at
org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1)
at java.base/java.security.AccessController.doPrivileged(Native
Method)
at
org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:823)
at
org.eclipse.osgi.internal.framework.EquinoxBundle.stopWorker0(EquinoxBundle.java:947)
at
org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.stopWorker(EquinoxBundle.java:314)
at org.eclipse.osgi.container.Module.doStop(Module.java:636)
at org.eclipse.osgi.container.Module.stop(Module.java:498)
at
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:1669)
at
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1588)
at
org.eclipse.osgi.container.SystemModule.stopWorker(SystemModule.java:270)
at
org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.stopWorker(EquinoxBundle.java:147)
at org.eclipse.osgi.container.Module.doStop(Module.java:636)
at org.eclipse.osgi.container.Module.stop(Module.java:498)
at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:202)
at
org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:165)
at java.base/java.lang.Thread.run(Thread.java:844)
I'm not sure what to make of that, but it suggests that MPC might well
not function when running on Java 9.
So in the end, I think there isn't so much to worry about, but
nevertheless, I strongly encourage each team to test their project's
readiness so we can all avoid hassles and embarrassment when Java 9 is
finally released. I've tried to help make that as easy as possible...
Regards,
Ed[attachment "OxygenJava9EarlyAccessBetaConfiguration.setup" deleted
by Daniel Megert/Zurich/IBM]
_______________________________________________
cross-project-issues-dev mailing list_
[email protected]_
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit_
__https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
_______________________________________________
cross-project-issues-dev mailing list
[email protected]_
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
_______________________________________________
cross-project-issues-dev mailing list
[email protected]_
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
------------------------------------------------------------------------
This email has been checked for viruses by Avast antivirus software. _
__www.avast.com_ <https://www.avast.com/antivirus>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
