Project Jigsaw: Phase Two

[Martijn Verburg]

Hi Mark,

Some quick feedback after a scan through the
http://openjdk.java.net/projects/jigsaw/goals-reqs/03.

It's a well-thought out document, I was pretty much nodding in agreement
throughout, appreciate that it takes massive effort to put out something
like this! Some specific feedback:

Actual Question:
------------------------

Not proposing to modularise JDK implementations - completely understand why
this should be tackled this time around. I was wondering whether it could
be a useful goal to have a std mechanism to ship a JVM with just the one
implementation of say a GC or JIT implementation for sake of space and
performance. Could this perhaps be explored in a later incarnation of
Jigsaw given the work to start standardising some of the logging and
interactions with JVM(s) through serviceability APIs etc?

Comments:
-----------------

Probably me waffling on - but maybe it helps some new folks with why I'm
motivated as an end user so to speak.

1.) Standard, JDK-specific, and JDK-internal modules - Good, will be great
to have more definition around internals like Unsafe, makes it clearer for
Joe/Jane Java.

2.) Launch time configuration - Really liked this idea, we already have
some pain with testing against various Java 8 profiles.

3.) Upgradeable modules - Perfect, this will help with some of the ASM and
JAXP type of integrations where the 3rd party lib upgrades much faster than
the 2-year Java release cycle.

4.) OS-specific module packaging - You probably already know how happy this
is going to make Linux SAs, it'll be nice to stop having to defend ("big
binary ball") Java against some of my colleagues in that role :-).

I suspect MacPorts / Homebrew will follow along, but as they're not Apple
endorsed packaging per say.  Still, I'll get hold of the port folks, they
may be useful in uncovering corner cases when it's time to test a prototype.

5.) I broadly agree with the Non-requirements - I do wonder how many people
out in the wild will fall foul of the runtime internals consistent state (I
agree it's their own fault, but still.)

6.) Huge +1 for the Security and maintainability section, will be great for
the mechanical sympathy folks (apologies for the buzz term) who want a well
defined set of safe JDK APIs they can use (or not).

7.) A better replacement for Classpath - yes please.

The dynamic runtime stuff I'm still not sure on, need to think about some
of the weird runtime loading jury riggs I've seen recently.

Thanks again Mark, it's good to see this starting up again.

Cheers,
Martijn


On 2 July 2014 17:47, <mark.reinhold at oracle.com> wrote:

> Project Jigsaw has, for the last several years, been in an exploratory
> phase in which we've designed and prototyped one particular approach [1]
> to addressing a draft set of requirements [2].
>
> It's now time to switch gears and focus on creating a production-quality
> design and implementation suitable for JDK 9 and thence Java SE 9, as
> previously proposed [3].
>
> To begin this phase I've drafted a new document to collect goals and
> requirements [4].  It reflects a new emphasis on security, as motivated
> by recent experience [5], it takes into account lessons learned from the
> prototype, and it's written at a broader and more abstract level than the
> previous document [2] so as not to over-constrain the solution space.
> This document will be one of the starting points of the upcoming Java
> Platform Module System JSR.
>
> Please send comments and suggestions on the new goals and requirements
> document [4] to this list, jigsaw-dev at openjdk.java.net.
>
> Jigsaw as a whole will bring enormous changes to the JDK; it would be
> unwise to wait until it's completely finished before merging any of it.
> Our intent, therefore, is to proceed in large steps, each of which will
> have a corresponding JEP.  The first three JEPs, which I'll also post
> here for review, will propose a specific modular structure for the JDK,
> reorganize the JDK source code (but not binaries) along those lines,
> and then later modularize the binary images.
>
> A fourth JEP will introduce the module system itself, which will be
> aligned with the module-system JSR.  It may seem odd that the module
> system JEP comes last, but the earlier JEPs need make only minimal
> assumptions about its capabilities, hence work on them can proceed
> in parallel with work on the module-system JEP and JSR.
>
> - Mark
>
>
> [1] http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
> [2]
> http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12
> [3] http://mreinhold.org/blog/on-the-next-train
> [4] http://openjdk.java.net/projects/jigsaw/goals-reqs/03
> [5] http://mreinhold.org/blog/secure-the-train
>