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.reinh...@oracle.com> wrote:
2013/8/30 0:35 -0700, david.bosscha...@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
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
