[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Announcing JDK 9 support for Eclipse Neon

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

Inactive hide details for Wayne Beaton ---10/29/2015 05:48:43 AM---I just spoke directly with Mark Reinhold. It is absolutely aWayne Beaton ---10/29/2015 05:48:43 AM---I just spoke directly with Mark Reinhold. It is absolutely an expected use case that users/organizat

From: Wayne Beaton <wayne@xxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx
Date: 10/29/2015 05:48 AM
Subject: Re: [cross-project-issues-dev] Announcing JDK 9 support for Eclipse Neon
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx





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




--
Wayne Beaton
@waynebeaton
The Eclipse Foundation

EclipseCon
          Europe 2015_______________________________________________
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

GIF image

GIF image