From mark.reinhold at oracle.com Mon Jan 14 15:10:19 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 14 Jan 2013 15:10:19 -0800 Subject: Java SE 8 EDR Specification: DRAFT 1 Message-ID: <20130114231019.21918114D@eggemoggin.niobe.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 From mark.reinhold at oracle.com Tue Jan 15 11:02:48 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 15 Jan 2013 11:02:48 -0800 Subject: Java SE 8 schedule update Message-ID: <20130115190248.0D89C95D@eggemoggin.niobe.net> FYI, I've updated our JCP milestone schedule [1]. These are based, roughly, on the dates we managed to hit for Java SE 7 (JSR 336) [2]. - Mark [1] http://openjdk.java.net/projects/jdk8/spec/ [2] http://jcp.org/en/jsr/detail?id=336 From SPOOLE at uk.ibm.com Tue Jan 22 04:18:52 2013 From: SPOOLE at uk.ibm.com (Steve Poole) Date: Tue, 22 Jan 2013 12:18:52 +0000 Subject: Java SE 8 EDR Specification: DRAFT 1 In-Reply-To: <20130114231019.21918114D@eggemoggin.niobe.net> References: <20130114231019.21918114D@eggemoggin.niobe.net> Message-ID: hi Mark. 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 and potential future profiles. For profiles we'd also like to see more details over the specification lifecycle of a profile. 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. 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" 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. A few more comments: General: Sometimes Lambdas are capitalized and sometimes they aren't. Section 2 : Structure and Status "or revised in Maintenance Releases of existing such JSRs." - strange english at the end? "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? 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? Section 8 Profiles " the deferral of a full module system to a future release.. " two full stops at the end "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? Cheers Steve Poole 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 From aph at redhat.com Tue Jan 22 08:24:12 2013 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Jan 2013 16:24:12 +0000 Subject: Java SE 8 EDR Specification: DRAFT 1 In-Reply-To: References: <20130114231019.21918114D@eggemoggin.niobe.net> Message-ID: <50FEBD2C.4050706@redhat.com> 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 >