Java SE 8 EDR Specification: DRAFT 1

[Andrew Haley]

I didn't get this message until today.  That may, of course, be
because of a fault in our email system.  Nevertheless, I'll reply
even though I haven't had time to forward Draft 1 to others in
Red Hat.

This draft umbrella JSR is mostly just a list of JSRs, which is as it
should be.  These are mostly uncontentious or have been discussed at
length on other mailing lists.

My greatest concern is to do with Profiles.  As I understand it, a
primary motivation of Project Jigsaw was the modularization of the
Java SE Platform itself, but this JSR introduces Profiles without any
reference to Jigsaw.  I am concerned that, without Jigsaw, this
effectively introduces (apparently) arbitrary subsets of the system --
something that in the past we've striven to avoid.  Also, because
there is no modularization mechanism to allow anyone to define
different subsets, these exact subsets are more significant than they
would be with Jigsaw.  Do any of them correspond to particular CDC
profiles, for example?

Also, if the platform is subsetted without Jigsaw, some of the
motivation to get Jigsaw done goes away.

"It is expected that the modular Platform to be defined in a future
release will include modules corresponding almost exactly to the
Profiles defined here, so that applications that use Profiles can
easily be migrated to use modules."  Does this imply the intention to
break binary or source compatibility for applications that use
Profiles?

The description of stripped implementations is problematic.  While
it's plain what is intended, we can't send this draft out for comment
until we know what it actually means.

A bundled JDK is not intended to be used by anything other than the
"sole application that will run on it".  So, such a stripped
implementation doesn't cause any compatibility problems.  Or does it?
Could someone define their own subset that would be available for use
by other applications, or should there be licensing mechanisms to
prevent that?

"An application packaged with a stripped Implementation must not load
any Java code that is not part of itself, and its use of other
reflective facilities must be severely constrained."  Perhaps it isn't
necessary to spell all this out in detail -- simply to say that
applications which bundle the JDK don't have to bundle all of it.  In
the absence of any implementation, stripping is a bit mysterious.  Do
you expect the JDK8 Reference Implementation to include any mechanism
to support stripped implementations?

Andrew.





> From:   mark.reinhold at oracle.com
> To:     java-se-8-spec-experts at openjdk.java.net, 
> Date:   14/01/2013 23:18
> Subject:        Java SE 8 EDR Specification: DRAFT 1
> Sent by:        java-se-8-spec-experts-bounces at openjdk.java.net
> 
> 
> 
> The first draft of the Early Draft Review Specification is available
> here:
> 
>   http://cr.openjdk.java.net/~mr/se/8/java-se-8-edr-spec.01.html
> 
> As explained in section 2, many details will be added between now and the
> Public Review Specification.  The goal of the EDR is to give a general
> summary of the expected content of the release and to highlight notable
> changes (e.g., profiles and stripped implementations) that are not
> covered by Component JSRs.
> 
> I'd like to submit this to the JCP PMO for the formal Early Draft Review
> next week.  Please let me know by 17:00 UTC next Tuesday, 22 January, of
> any changes you'd like me to make to this document before I submit it,
> or if you think that further discussion is required.
> 
> Thanks,
> - Mark
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>