Ed,
JDT is working on a branch specifically for Java 9 support as
documented here:
https://wiki.eclipse.org/Java9
The results are published in the platform's so-called Y builds.
The results are not on the Oxygen train and are not currently
targeting to be released with Oxygen.0. So no, M6 will not
include anything for Java 9 support and no you cannot specify
a Java 9 SDK in the "Installed JREs" preferences page with M6 (nor
with Oxygen.0).
Furthermore, as described in the Wiki and in Wayne's blog, the
IDE itself will not run on a Java 9 VM, unless you
specify the right magical VM argument. And even when you do,
everything might not function because few of us have
tested this. One part of Oomph was very broken and it appears MPC
is also somewhat broken. Most other things appear to be okay, but
that's why I would strongly encourage each team to test their own
project functionality, and to help test JDT's Java 9
support (at least in terms of compatibility for current
development which doesn't actually exploit Java 9 features) while
they're at it because that will help ensure that when Java 9
itself releases, Eclipse work well with it, and when Oxygen.1
releases, JDT's Java 9 support will work well too (at least in
terms of compatibility).
I believe JDT does not need to run on a Java 9 VM in order to
support Java 9 development, but Dani can best explain that when he
provides additional details later in the week.
On 08.03.2017 12:08, Ed Willink wrote:
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.
- The installation portion of the
configuration
- 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),
- and adds the --add-modules VM
argument to the eclipse.ini (so launching will
actually function).
- The workspace portion of the
configuration
- 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,
- 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
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
|