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