Sorry for the multiple threads. Note that M6 will hopefully deal
with magical option handling in the Equinox runtime, but of course
specifying "Java 9
as my installed preference" if by that Ed means using JDT's
"Installed JREs" preference page to point at a Java 9 JDK, that
won't be something supported by M6 but only by JDT's special
branch. Please correct me if I'm wrong (though that's of course
the behavior I'm seeing and expecting.)
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.
- 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
_______________________________________________
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