Java SE 8 EDR Specification: DRAFT 1

[mark.reinhold at oracle.com]

2013/1/22 0:24 -0800, Andrew Haley <aph at redhat.com>:
> ...
> 
> 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.

Correct.

>                       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?

More thought has gone into the definition of the proposed Profiles than
is explained in the draft Specification, and I agree that more should be
said.  The compact1 Profile, in particular, is specifically designed to
be a suitable migration target for applications that currently target
CDC 1.1 (JSR 218) and Foundation Profile 1.1 (JSR 219).

I'll draft some additional text and send it for comment in a separate
message.

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

That's true, but a real module system will still bring significant
advantages.

> "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?

Whether to break compatibility, and if so how and to what degree, will
be up to the Java SE 9 EG.  The intent of this language is to make it
clear that there might be some minor differences when moving from
Profiles to modules.

> 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?

No, someone cannot define their own subset and make it available for
use by other applications.  The Specification, in combination with its
license, will enforce that (though some slight changes to the wording
of the latter may be required.)

> "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.

Yes, that whole paragraph could be simplified.  How about:

  This Specification therefore permits an Implementation that is
  packaged together with all of the Java code that will ever run upon
  it to omit, partially or entirely, elements that are never, under any
  circumstances, depended upon by that code.  Such an Implementation is
  said to be <i>stripped</i>.

I'll add another, non-normative paragraph to give some examples of how
stripping might be done.

>                                                                    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?

No, there are no plans to include a stripping mechanism in JDK 8.

Thanks for the comments,
- Mark