Fwd: Jigsaw prototype, take 2

[David Bosschaert]

I always thought that JEP 161 was a great start for as much modularization
as the JRE itself needs (which was always the root requirement of Jigsaw).
I know it currently has 3 profiles, but we could always add more going
forward.

As regards to performance. It should definitely improve performance
somewhat since you don't always load the whole rt.jar. I'm not sure I fully
understand the 'transform module content during installation' piece but I
question why you would need an actual module system for this. Could the
Java runtime not do this under the hood as an internal optimization?

I know JEP 161 isn't a 'real' module system, but I question why the JRE
itself would actually need a full blown module system for it's own
purposes. For people building on top of Java SE there are other module
systems already available such as OSGi and JBoss Modules.

Best regards,

David

On 5 September 2013 05:33, Gregg Wonderly <greggwon at cox.net> wrote:

> Indeed!  An incremental improvement over time is the best way to provide
> something, get feedback, adjust, and continue.  In the end, there is not
> enough time in the day for perfect, and there is little change that perfect
> will last for very long.  So compromise and delivery of something to start
> with, might be the best choice.
>
> Ultimately, if Oracle would just allow developers to "prune" the jars to
> what we need, and/or remake the binary part of what we are using to have
> exactly and only what we need, that would make for the best approach.
>
> The fact of the matter is that few people are actually deploying Java as a
> "platform".  They are deploying it as a "runtime environment", and that
> means that they know the extent of the feature set that they need.
>
> Java as a generic platform has failed because Sun and Oracle now, have
> failed to understand the importance of supporting the desktop environment
> with something that was "library" like, and instead, staying focused on the
> Jave-EE platform world where "new content" is deployed into the runtime
> environment and thus requires the "totality" of the platform, because you
> just never know what might be deployed.
>
> On the desktop and most "applications" that aren't tied to Java-EE, Java
> is used like a library, and thus people really don't understand why they
> can't just use what they need, and pull the reset "out".
>
> There is no benefit that Sun/Oracle receive from disallowing this in
> licensing.  Instead, they've managed to make sure that Java is not
> desirable for anything other than large scale application deployment.
>
> Gregg Wonderly
>
>
> On 9/4/2013 9:44 PM, Neil Bartlett wrote:
>
>> And yet, JEP 161 addresses the most pressing requirement from Java
>> developers: a smaller, more embeddable JRE.
>>
>> Furthermore it actually seems to be deliverable within a reasonable
>> time scale (JDK8) rather than a continually slipping, indeterminate
>> future.
>>
>> - Neil
>>
>> On Wed, Sep 4, 2013 at 11:35 PM,  <mark.reinhold at oracle.com> wrote:
>>
>>> 2013/8/30 0:35 -0700, david.bosschaert at gmail.com:
>>>
>>>> My understanding is that JEP 161 (http://openjdk.java.net/jeps/**161<http://openjdk.java.net/jeps/161>)
>>>> already
>>>> addresses many requirements for modularizing the Java runtime. JEP 161
>>>> should address the concerns around creating a scalable platform and
>>>> improve
>>>> performance.
>>>>
>>>> I would like to understand what requirements in addition to JEP 161 this
>>>> prototype aims to address.
>>>>
>>> JEP 161 is an interim solution to the problem of scaling the platform.
>>> It "modularizes" the platform in only the crudest sense, defining just
>>> three modules.  If an application uses just one API from the largest
>>> profile and otherwise requires only the smallest profile then there is
>>> no choice but to use an implementation of the largest profile.
>>>
>>> As to performance, JEP 161 doesn't address that at all.  The kinds of
>>> performance improvements we've always aimed to enable with Jigsaw
>>> involve transforming module content during installation.
>>>
>>> - Mark
>>>
>>
>