Jigsaw prototype, take 2
greggwon at cox.net
Wed Sep 4 21:33:58 PDT 2013
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
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.
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
> - 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) already
>>> addresses many requirements for modularizing the Java runtime. JEP 161
>>> should address the concerns around creating a scalable platform and improve
>>> 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
More information about the jigsaw-dev