From mark.reinhold at oracle.com Fri Feb 15 13:39:39 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Feb 2013 13:39:39 -0800 Subject: Java SE 8 EDR Specification: DRAFT 1 In-Reply-To: References: <20130114231019.21918114D@eggemoggin.niobe.net>, Message-ID: <20130215133939.434552@eggemoggin.niobe.net> [ Finally getting back to this thread after a couple weeks of travel ... ] 2013/1/21 20:18 -0800, Steve Poole : > 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 stripped. ... 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 From mark.reinhold at oracle.com Fri Feb 15 13:39:54 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Feb 2013 13:39:54 -0800 Subject: Java SE 8 EDR Specification: DRAFT 1 In-Reply-To: <50FEBD2C.4050706@redhat.com> References: <20130114231019.21918114D@eggemoggin.niobe.net>, , <50FEBD2C.4050706@redhat.com> Message-ID: <20130215133954.334757@eggemoggin.niobe.net> 2013/1/22 0:24 -0800, Andrew Haley : > ... > > 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 stripped. 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 From mark.reinhold at oracle.com Mon Feb 18 15:16:05 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 18 Feb 2013 15:16:05 -0800 Subject: Profiles rationale Message-ID: <20130218151605.259338@eggemoggin.niobe.net> Attached below is some text that could be added after the "Content" subsection of the "Profiles" section (?8) of the EDR draft. Comments? - Mark ---- **Rationale** The contents of the various Profiles are motivated as follows: - The `compact1` Profile contains the smallest set of packages that is feasible without omitting any classes or methods. The logging (`java.util.logging`) and SSL/TLS (`javax.net.ssl`) packages are additionally included because it is expected that many applications running on even the smallest Profile will require these facilities. The `compact1` Profile is a suitable migration target for applications that currently target CDC 1.1 (JSR 218) and Foundation Profile 1.1 (JSR 219). It includes every package specified in those JSRs, including the "Security Optional Packages" in JSR 219, except for `java.security.acl` (a legacy API which nobody uses) and the `javax.microedition.io` and `javax.microedition.pki` packages (which are Java ME-specific). - The `compact2` Profile adds packages for remote method invocation (RMI), database access (JDBC), and XML processing. This Profile is a suitable migration target for applications that currently target CDC 1.1 and Foundation Profile 1.1 and, additionally, one or more of the following Specifications: - RMI Optional Package Specification 1.0 (JSR 66) - JDBC Optional Package for CDC/Foundation Profile (JSR 169) - XML API for Java ME (JSR 280) - The `compact3` Profile adds packages for instrumentation, management, naming, scripting, and compilation as well as further packages for database access, security, and cryptography. This Profile is intended for applications that require most of the full Platform except for the desktop user-interface packages (AWT, Swing, etc.), web services (JAX-WS, JAXB, and SAAJ), and CORBA. From mark.reinhold at oracle.com Mon Feb 18 15:19:07 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 18 Feb 2013 15:19:07 -0800 Subject: Commentary on stripped implementations Message-ID: <20130218151907.291978@eggemoggin.niobe.net> Attached below is some explanatory text that could be added to the "Stripping" section (?9) of the EDR draft. Comments? - Mark ---- This Specification neither mandates nor forbids any particular means of creating stripped Implementations, so long as the above constraints are satisfied. At a high level, a stripped Implementation can be created in two steps: 1. Analyze the combined Implementation and application code to identify elements that are never used, either directly or indirectly. Such elements may be Java code, in the form of packages, classes, interfaces, fields, or methods. They may also be other kinds of implementation elements, in the form of static data files or native-code procedures, objects, or libraries. 2. Remove the unused elements from the combined code and package all of the remaining code into a single binary image. A precise answer for the first step cannot, in general, be computed completely automatically since it is equivalent to solving the Halting Problem. Practical tools for creating stripped Implementations therefore usually rely upon a combination of heuristics, manual analysis, and automatic analysis to compute an approximate answer. It is highly recommended that the binary image created in the second step be fully tested, with the goal of achieving 100% coverage of the remaining application code, in order to ensure that all required elements of the Implementation are present. From aph at redhat.com Tue Feb 19 01:44:11 2013 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Feb 2013 09:44:11 +0000 Subject: Profiles rationale In-Reply-To: <20130218151605.259338@eggemoggin.niobe.net> References: <20130218151605.259338@eggemoggin.niobe.net> Message-ID: <5123496B.6050500@redhat.com> On 02/18/2013 11:16 PM, mark.reinhold at oracle.com wrote: > Attached below is some text that could be added after the "Content" > subsection of the "Profiles" section (?8) of the EDR draft. > > Comments? That's very much better. Thanks. Andrew.