Re: [cross-project-issues-dev] Announcing JDK 9 support for EclipseNeon

["David M Williams" <david_williams@xxxxxxxxxx>]

I guess my question, after reading "proprietary"
(non-spec'd, available only through APIs) is how that works with projects
like "OpenJDK"? (vs. Oracle, and others).
Is it that kind of "proprietary"?
That they will have to come up with their own "format" that works
with the APIs? 

I am just curious, but, seems kind of
like a time waster, if I am interpreting the word correctly. 
I guess it could be a "point of
competition", for better or for worse, on who has the most efficient
format? 





From:      
 "Stephan Herrmann"
<stephan.herrmann@xxxxxxxxx>
To:      
 "Cross project
issues" <cross-project-issues-dev@xxxxxxxxxxx>, cross-project-issues-dev@xxxxxxxxxxx,
Date:      
 10/28/2015 12:48 PM
Subject:    
   Re: [cross-project-issues-dev]
Announcing JDK 9 support for Eclipse        Neon
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

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<tom.schindl@xxxxxxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx

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 <mike.milinkovich@xxxxxxxxxxx>
> To: Daniel Megert <daniel_megert@xxxxxxxxxx>, Cross project
issues
> <cross-project-issues-dev@xxxxxxxxxxx>
> Date: 10/28/2015 02:49 AM
> Subject: Re: [cross-project-issues-dev] Announcing JDK 9 support for
> Eclipse Neon
> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 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_
> __mike.milinkovich@eclipse.org_ <mailto:mike.milinkovich@xxxxxxxxxxx>
> +1.613.220.3223 (mobile)
> _
> _EclipseCon Europe 2015
> <http://www.eclipsecon.org/europe2015>_______________________________________________
> 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
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
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


---- ursprüngliche Nachricht Ende ----
_______________________________________________
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