[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Will Your Project Work When Running on Java 9?

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). 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 <ed@xxxxxxxxxxxxx>
To:        cross-project-issues-dev@xxxxxxxxxxx
Date:        08.03.2017 12:08
Subject:        Re: [cross-project-issues-dev] Will Your Project Work When Running on Java 9?
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx




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 <ed.merks@xxxxxxxxx>
To:        
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        
08.03.2017 10:05
Subject:        
[cross-project-issues-dev] Will Your Project Work When Running on        Java 9?
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx





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. 

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. 
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

cross-project-issues-dev@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
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

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev