Hi Wayne,
Thanks for the update! I just checked again the JEPs available online and
found no mention of automatic modules or being able to create Jimages. So,
looks like these are getting added to the requirements list even as we
speak. However, it would be nice if these also find their way to the
documents sooner than later. Could you please check with Mark or his team
and if they are planning to update the specification any time soon?
Thanks,
Jay
From: Wayne Beaton <[email protected]>
To: [email protected]
Date: 10/29/2015 05:48 AM
Subject: Re: [cross-project-issues-dev] Announcing JDK 9 support for
Eclipse Neon
Sent by: [email protected]
I just spoke directly with Mark Reinhold.
It is absolutely an expected use case that users/organizations will build
jimages that include their own code, third-party modules, and JDK modules.
There is a lot of perceived value in being able to ship a single image file
rather than a bunch of JARs, modularized JARs, or JMOD files.
As Tom said earlier in this thread, loose JAR files will manifest in a
single "unnamed" module that automatically has access to everything in the
image. This will mean that--blocked access to internal APIs
notwithstanding--everything will basically work as it does today. But, the
expectation is that libraries will start shipping as modules.
There's been a lot of talk this week about migration strategies by moving
JARs out of the unnamed module into "automatic" modules and then proper
modules.
I believe that Java developers will expect to be able to get help
building/verifying the module-info.jar file, define and export modules, and
include both jimage and jmod files in their build path. Note that the
compiler will be expected to respect visibility restrictions. I think that
being able to output a jimage is a nice-to-have at this point.
Wayne
On 28/10/15 12:47 PM, Stephan Herrmann wrote:
Tom,
I don't see a conflict between Jay's and your observations:
Yes, users will be able to create / compile / package modules.
No, users will not create Jimage files.
Whether or not it is a module is a conceptual question. It needs
a module-info.java / module-info.class and there you are.
The Jimage format, by contrast is a purely technical question
of how bits and pieces are encoded / packaged.
JDK uses Jimage to ship their libraries, user modules are
shipped as jars.
So when you convert a "legacy" user library into a module,
technically that would be a jar -> jar transformation.
Makes sense?
Stephan
----- ursprüngliche Nachricht ---------
Subject: Re: [cross-project-issues-dev] Announcing JDK 9 support for
Eclipse Neon
Date: Mi 28 Okt 2015 04:30:11 CET
From: Tom Schindl<[email protected]>
To: [email protected]
From the j1 session(s) - I attended I can not share this! They've
been
talking about making modules out of libraries jars.
Jars on the classpath get automatically wrapped into 1 virtual module
at
runtime. My understanding was that all you need to to do is to call a
command line app to make a module from a jar (which although
autogenerates the module-info.java).
There are chances although that I completely screwed this up. There's
been a ton of informations on all this stuff and without at least
having
had a hands on it's really easy to mix things up.
Tom
On 27.10.15 19:35, Jayaprakash Arthanareeswaran wrote:
My understanding (from JEP 220) is that these run-time images
are
created specifically for the JDK/JRE and the IDE is only
expected to
read these.
User defined modules will either be in source form or JAR form.
One of
the goals of the JEP 220 is this:
"Restructure the JDK and JRE run-time images to draw a clear
distinction
between files that developers, deployers, and end-users can
rely upon
and, when appropriate, modify, in contrast to files that are
internal to
the implementation and subject to change without notice. "
The way I see it, a Jimage is purely meant to be part of a JDK
and
nowhere else.
Regards,
Jay
Inactive hide details for Mike Milinkovich ---10/28/2015
02:49:43
AM---On 27/10/2015 5:18 PM, Daniel Megert wrote: > >
"InsteadMike
Milinkovich ---10/28/2015 02:49:43 AM---On 27/10/2015 5:18 PM,
Daniel
Megert wrote: > > "Instead, API is provided for reading the
content of
From: Mike Milinkovich <[email protected]>
To: Daniel Megert <[email protected]>, Cross project
issues
<[email protected]>
Date: 10/28/2015 02:49 AM
Subject: Re: [cross-project-issues-dev] Announcing JDK 9
support for
Eclipse Neon
Sent by: [email protected]
------------------------------------------------------------------------
On 27/10/2015 5:18 PM, Daniel Megert wrote:
> "Instead, API is provided for reading the content of such
image."
==> The format is not specified but APIs allow to read the
content.
Maybe I am wrong, but since we are a Java IDE don't we also
have to
*write* the content of such files?
--
Mike Milinkovich_
[email protected]_
<mailto:[email protected]>
+1.613.220.3223 (mobile)
_
_EclipseCon Europe 2015
<http://www.eclipsecon.org/europe2015>
_______________________________________________
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
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon
Europe 2015
_______________________________________________
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
