Java SE 8 EDR Specification: DRAFT 1

[mark.reinhold at oracle.com]

[ Finally getting back to this thread after a couple weeks of travel ... ]

2013/1/21 20:18 -0800, Steve Poole <spoole at uk.ibm.com>:
> Generally IBM is OK with the draft - however what IBM would like to see in
> increased detail is your expectations/plans/objectives for profiles and
> stripped implementations.
> 
> You have shared basic information about profiles before but as far as I
> recall the introduction of stripped implementations is new and so you
> really need to expand upon the subject; Ideally before you publish the
> draft. What would probably be a good approach is for you to explain the
> scenarios you have in mind for stripped implementations

Good idea, I'll do that.

>                                                         and potential
> future profiles.

I'm not sure what you mean here.  This Specification proposes three
specific Profiles.  No future Profiles are contemplated, though in
theory a future SE Platform JSR could define additional Profiles.

>                  For profiles we'd also like to see more details over the
> specification lifecycle of a profile.

What do you mean by "specification lifecycle"?

> The new rules for allowing subsets within the specification are continuing
> in the spirit of avoiding fragmentation which is an objective we support.
> The simple fact of knowing that a package definition in a profile is
> guaranteed to be 100% fully compatible with any larger profile containing
> the same is clear and understandable.
> However, while we can see the potential benefits of profiles to the
> specification, they could, if not probably worded and enforced,  have a
> significant negative impact to implementers and customers alike.

I understand your concern, but do you have specific suggestions as to
how to improve the wording of the Profiles section in the draft?

>                                                                   More so
> with stripped implementations.  We can probably infer your thoughts for
> 'stripped implementations' as described but we need to see them on paper.
> For instance, we'd like more details over language such as "must not load
> any Java code that is not part of itself"   and " its use of other
> reflective facilities must be severely constrained"

As Andrew pointed out in his comments, part of the problem with that
text is that it says too much.  It's not actually necessary to spell
out exactly how, e.g., reflection can and cannot be used.  Such limits,
insofar as they exist, are consequences of the fundamental constraint
that any stripped Implementation is bundled together with all of the
Java code that will ever run upon it.

So I'm thinking that paragraph should now read:

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

... and then be followed by a non-normative paragraph to giving some
examples of how stripping might be done.

>                                                      I'd ask that you
> share the types of scenario you had in mind for stripped implementations
> and allowing some level of EG debate before publishing the draft.

Will do, in a followup message.

> A few more comments:
> 
> General:
> Sometimes Lambdas are capitalized and sometimes they aren't.

Good catch, will fix.

> Section 2 : Structure and Status
> "or revised in Maintenance Releases of existing such JSRs."   - strange
> english at the end?

Strange how?  Do you have a suggested rewording?

> "The Public Review version of this Specification will also include draft
> updates to the Java Virtual Machine Specification and the Java Language
> Specification"   - when we will get to see these draft updates?

I don't have a precise ETA as yet.

> Section 4: Component JSR Specifications
> JSR status - can you provide information about the current status of the
> JSR's listed and when they are expected to deliver into the Java 8 RI?

The statuses of the listed JSRs are available on their respective
jcp.org pages, to which links are provided.  Isn't that good enough?
The problem with including such statuses directly in the Specification
is that they will inevitably become incorrect.

As to expected deliveries into the RI, I don't think it's appropriate
for the Specification to include such scheduling information, which
anyway is readily available elsewhere [1].

> Section 8 Profiles
> " the deferral of a full module system to a future release.. "   two full
> stops at the end

Will fix.

> "If an Implementation of this Specification implements a Profile then it
> must be complete, i.e., it must implement every element of that Profile" -
>  what does 'element' mean in this context?

"Element of that Profile" here means "every class and interface in every
package in that Profile".  I'll expand the wording.

Thanks for the comments,
- Mark


[1] http://openjdk.java.net/projects/jdk8/milestones