From brian.goetz at oracle.com Thu Nov 2 16:41:37 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 2 Nov 2017 12:41:37 -0400 Subject: Next EG Meeting In-Reply-To: <257c147b-71d2-48ca-a935-88c0b75e7f6c@default> References: <257c147b-71d2-48ca-a935-88c0b75e7f6c@default> Message-ID: <9310e4d0-0557-3759-ce07-8ae97740ba63@oracle.com> > Working arrangements > -------------------- > > - Meetings > - Andrew recommended monthly meetings. Given the upcoming conferences and holidays, I propose that our next meeting be Friday Dec 1.?? I'll send out a time poll separately. As a reminder, we should all be looking at the dashboards: ??? JEP: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17511 ??? CSR: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17600 to track the flow of spec-relevant features into the platform spec. From brian.goetz at oracle.com Thu Nov 2 16:51:45 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 2 Nov 2017 12:51:45 -0400 Subject: JSR 383 & the newer version-string scheme In-Reply-To: <20171102094801.372565426@eggemoggin.niobe.net> References: <20171102094801.372565426@eggemoggin.niobe.net> Message-ID: <059e6e42-9cfe-8b9c-abc0-77182b5ffa46@oracle.com> As a heads-up, there are discussions in OpenJDK regarding the proposed version scheme.? A proposal has been made; there will be a JEP, but you may be interested in following the discussion before that. Latest proposal: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html From iris.clark at oracle.com Fri Nov 3 21:23:30 2017 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 3 Nov 2017 14:23:30 -0700 (PDT) Subject: JavaDoc API and diffs for Java SE 18.3 build 30 posted Message-ID: The JavaDoc API and diffs against build 30 (18.3+29 vs 18.3+30 and 9+181 vs 18.3+30) are now available: http://cr.openjdk.java.net/~iris/se/18.3/build/30/ The removal of javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPES is an engineering error. The field will be restored in a subsequent build. Thanks, Iris From volker.simonis at gmail.com Mon Nov 13 17:39:07 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 13 Nov 2017 18:39:07 +0100 Subject: JSR 383 & the newer version-string scheme In-Reply-To: <059e6e42-9cfe-8b9c-abc0-77182b5ffa46@oracle.com> References: <20171102094801.372565426@eggemoggin.niobe.net> <059e6e42-9cfe-8b9c-abc0-77182b5ffa46@oracle.com> Message-ID: Another interesting topic which is currently under review and according to the developers is planned for jdk 10 (although it has not yet been targeted): JEP 309: Dynamic Class-File Constants https://bugs.openjdk.java.net/browse/JDK-8177279 Updates to the Java Virtual Machine Specification https://bugs.openjdk.java.net/browse/JDK-8189199 Minimal ConstantDynamic support https://bugs.openjdk.java.net/browse/JDK-8186046 Tool support for ConstantDynamic https://bugs.openjdk.java.net/browse/JDK-8186209 http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ Minimal set of bootstrap methods for dynamic constants https://bugs.openjdk.java.net/browse/JDK-8187742 http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ Note that this change requires porting effort for the non-Oracle platforms and independent implementations and also for tools because it extends the class file format. Regards, Volker On Thu, Nov 2, 2017 at 5:51 PM, Brian Goetz wrote: > As a heads-up, there are discussions in OpenJDK regarding the proposed > version scheme. A proposal has been made; there will be a JEP, but you may > be interested in following the discussion before that. > > Latest proposal: > http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html > From iris.clark at oracle.com Tue Nov 14 05:18:44 2017 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 13 Nov 2017 21:18:44 -0800 (PST) Subject: JavaDoc API and diffs for Java SE 18.3 build 31 posted Message-ID: <478ff8ad-793b-4164-ad07-a766f817798c@default> The JavaDoc API and diffs against build 31 (18.3+30 vs 18.3+31 and 9+181 vs 18.3+31) are now available: http://cr.openjdk.java.net/~iris/se/18.3/build/31/ Thanks, Iris From brian.goetz at oracle.com Tue Nov 14 07:51:35 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 Nov 2017 07:51:35 +0000 Subject: JSR 383 & the newer version-string scheme In-Reply-To: References: <20171102094801.372565426@eggemoggin.niobe.net> <059e6e42-9cfe-8b9c-abc0-77182b5ffa46@oracle.com> Message-ID: <32E9DF79-95F5-4D87-A3B5-91B9C1FD8E66@oracle.com> We?d certainly welcome any review of these features. But, please be careful drawing assumptions from the ?fix version? on sub-bugs of a JEP ? this is not a statement of planning, as much as a statement of optimism on the part of an individual developer. I can state definitively that Oracle has no plans to propose JEP 309 (which subsumes most of the individual issues you list) for 10. It is simply too late for a change like this ? which affects the class file format and therefore is high risk. This is what ?missing the train? looks like; while the development window has not closed for 10, some changes are too big or risky to take in this close to the departure time, so while it looks like the train is still waiting on the platform, this feature has in fact missed it. But that?s OK. There?s another train coming soon. > On Nov 13, 2017, at 5:39 PM, Volker Simonis wrote: > > Another interesting topic which is currently under review and > according to the developers is planned for jdk 10 (although it has not > yet been targeted): > > JEP 309: Dynamic Class-File Constants > https://bugs.openjdk.java.net/browse/JDK-8177279 > > Updates to the Java Virtual Machine Specification > https://bugs.openjdk.java.net/browse/JDK-8189199 > > Minimal ConstantDynamic support > https://bugs.openjdk.java.net/browse/JDK-8186046 > Tool support for ConstantDynamic > https://bugs.openjdk.java.net/browse/JDK-8186209 > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ > > Minimal set of bootstrap methods for dynamic constants > https://bugs.openjdk.java.net/browse/JDK-8187742 > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ > > Note that this change requires porting effort for the non-Oracle > platforms and independent implementations and also for tools because > it extends the class file format. > > Regards, > Volker > > On Thu, Nov 2, 2017 at 5:51 PM, Brian Goetz wrote: >> As a heads-up, there are discussions in OpenJDK regarding the proposed >> version scheme. A proposal has been made; there will be a JEP, but you may >> be interested in following the discussion before that. >> >> Latest proposal: >> http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html >> From volker.simonis at gmail.com Tue Nov 14 08:11:02 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Nov 2017 09:11:02 +0100 Subject: JSR 383 & the newer version-string scheme In-Reply-To: <32E9DF79-95F5-4D87-A3B5-91B9C1FD8E66@oracle.com> References: <20171102094801.372565426@eggemoggin.niobe.net> <059e6e42-9cfe-8b9c-abc0-77182b5ffa46@oracle.com> <32E9DF79-95F5-4D87-A3B5-91B9C1FD8E66@oracle.com> Message-ID: Hi Brian, thanks a lot for the clarification. On Tue, Nov 14, 2017 at 8:51 AM, Brian Goetz wrote: > We?d certainly welcome any review of these features. But, please be careful > drawing assumptions from the ?fix version? on sub-bugs of a JEP ? this is > not a statement of planning, as much as a statement of optimism on the part > of an individual developer. > Well if it is neither the information in the JEP/JBS nor the statements of the involved developers which is "relevant" for planning, it is indeed impossible for an external contributor (or EG member) to guess what Oracle plans to do within the OpenJDK/Java. So maybe you could adjust the corresponding information in the JEP/JBS accordingly once you know for sure you "don't plan" to do something ? > I can state definitively that Oracle has no plans to propose JEP 309 (which > subsumes most of the individual issues you list) for 10. It is simply too > late for a change like this ? which affects the class file format and > therefore is high risk. > That's totally fine for me. But as I've already expressed before, it is really hard for an external observer to find out what will be in the next release and what will be postponed. An open planning process for OpenJDK would be really helpful here although that's probably not a topic for this group. Thanks, Volker > This is what ?missing the train? looks like; while the development window > has not closed for 10, some changes are too big or risky to take in this > close to the departure time, so while it looks like the train is still > waiting on the platform, this feature has in fact missed it. But that?s OK. > There?s another train coming soon. > > > On Nov 13, 2017, at 5:39 PM, Volker Simonis > wrote: > > Another interesting topic which is currently under review and > according to the developers is planned for jdk 10 (although it has not > yet been targeted): > > JEP 309: Dynamic Class-File Constants > https://bugs.openjdk.java.net/browse/JDK-8177279 > > Updates to the Java Virtual Machine Specification > https://bugs.openjdk.java.net/browse/JDK-8189199 > > Minimal ConstantDynamic support > https://bugs.openjdk.java.net/browse/JDK-8186046 > Tool support for ConstantDynamic > https://bugs.openjdk.java.net/browse/JDK-8186209 > > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ > > Minimal set of bootstrap methods for dynamic constants > https://bugs.openjdk.java.net/browse/JDK-8187742 > > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ > > Note that this change requires porting effort for the non-Oracle > platforms and independent implementations and also for tools because > it extends the class file format. > > Regards, > Volker > > On Thu, Nov 2, 2017 at 5:51 PM, Brian Goetz wrote: > > As a heads-up, there are discussions in OpenJDK regarding the proposed > version scheme. A proposal has been made; there will be a JEP, but you may > be interested in following the discussion before that. > > Latest proposal: > http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html > > From volker.simonis at gmail.com Tue Nov 14 18:29:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Nov 2017 19:29:18 +0100 Subject: Java Certification and downport of features to older releases Message-ID: Hi, I want to ask for you opinion regarding the following scenario: 1. A vendor X decides to provide LTS support for a specific Java release N 2. 6 month later, the new N+1 short term-release of Java introduces a nice new language feature F (let's say something like local variable type inference). 3. Vendor X doesn't want to support release N+1 because it is only a short term release. But feature F is quite appealing and there's a high demand for it, so he decides to downport it to his Java release N. The new feature F is protected by a command line switch. Questions: a. Can vendor X certify his new N release as being Java N compatible? I would say yes, because even if feature F wouldn't be protected by a command line switch, the TCK for version N can not contain any tests which check the absence of support for feature F. b. Can vendor X claim that his JDK is Java N compatible but additionally supports feature F from Java N+1? So this is the more interesting question for which I don't know the answer. Even if he wouldn't be allowed to claim it, as a matter of fact he could still support it and his clients could use it. I think with the previous release model, we didn't had such kind of problems because of the long time frame between two releases. But with the new, frequent release cadence and the fact that non-LTS releases will be only supported for 6 months, the scenario sketched above could be quite attractive. On the one hand, such an approach could be beneficial for Java, because it would give features which are introduced in non-LTS releases a much broader adoption and visibility (few people will probably use non-LTS releases in production). That's good to have, before we bake such a feature into an LTS release. On the other hand, it could lead to a certain amount of fragmentation, if different implementations of Java N support different (if any) additional features from Java N+1, N+2, etc. What do you think? Thank you and best regards, Volker PS: I know that the question of LTS vs. non-LTS releases is not relevant for the EG. But the question of certification and claiming compatibility is? From brian.goetz at oracle.com Wed Nov 15 00:10:45 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 15 Nov 2017 00:10:45 +0000 Subject: Java Certification and downport of features to older releases In-Reply-To: References: Message-ID: <40212898-CE65-4A7A-B55E-6D8984159673@oracle.com> I would suggest you ask JLE. Sent from my iPad > On Nov 14, 2017, at 6:29 PM, Volker Simonis wrote: > > Hi, > > I want to ask for you opinion regarding the following scenario: > > 1. A vendor X decides to provide LTS support for a specific Java release N > 2. 6 month later, the new N+1 short term-release of Java introduces a > nice new language feature F (let's say something like local variable > type inference). > 3. Vendor X doesn't want to support release N+1 because it is only a > short term release. But feature F is quite appealing and there's a > high demand for it, so he decides to downport it to his Java release > N. The new feature F is protected by a command line switch. > > Questions: > > a. Can vendor X certify his new N release as being Java N compatible? > > I would say yes, because even if feature F wouldn't be protected by a > command line switch, the TCK for version N can not contain any tests > which check the absence of support for feature F. > > b. Can vendor X claim that his JDK is Java N compatible but > additionally supports feature F from Java N+1? > > So this is the more interesting question for which I don't know the > answer. Even if he wouldn't be allowed to claim it, as a matter of > fact he could still support it and his clients could use it. > > > I think with the previous release model, we didn't had such kind of > problems because of the long time frame between two releases. But with > the new, frequent release cadence and the fact that non-LTS releases > will be only supported for 6 months, the scenario sketched above could > be quite attractive. > > On the one hand, such an approach could be beneficial for Java, > because it would give features which are introduced in non-LTS > releases a much broader adoption and visibility (few people will > probably use non-LTS releases in production). That's good to have, > before we bake such a feature into an LTS release. > > On the other hand, it could lead to a certain amount of fragmentation, > if different implementations of Java N support different (if any) > additional features from Java N+1, N+2, etc. > > What do you think? > > Thank you and best regards, > Volker > > PS: I know that the question of LTS vs. non-LTS releases is not > relevant for the EG. But the question of certification and claiming > compatibility is? From iris.clark at oracle.com Mon Nov 20 18:04:24 2017 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 20 Nov 2017 10:04:24 -0800 (PST) Subject: JavaDoc API and diffs for Java SE 18.3 build 32 posted Message-ID: The JavaDoc API and difffs against build 32 (18.3+31 vs 18.3+32 and 9+181 vs 18.3+32) are now available: http://cr.openjdk.java.net/~iris/se/18.3/build/32/ Thanks, Iris From brian.goetz at oracle.com Mon Nov 20 18:20:43 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 20 Nov 2017 13:20:43 -0500 Subject: Fwd: [JCP]JSR-383(Java SE 18.3) Public review - JEP 116:Extended Validation SSL Certificates In-Reply-To: <1504356EFC539645A05071690EB7D549F2760D@cmbmb410a.exg.bpr.btm.co.jp> References: <1504356EFC539645A05071690EB7D549F2760D@cmbmb410a.exg.bpr.btm.co.jp> Message-ID: <83f8f4e6-6f34-50d1-d9d0-36b2600f8f72@oracle.com> This was received via the comments box. The content is out of scope for the SE EG, but I will forward it to the appropriate list (). -------- Forwarded Message -------- Subject: [JCP]JSR-383(Java SE 18.3) Public review - JEP 116:Extended Validation SSL Certificates Date: Fri, 17 Nov 2017 10:33:41 +0000 From: kyosuke_yamagata at mufg.jp To: java-se-spec-comments at openjdk.java.net CC: youji_3_fujikura at mufg.jp, takahiro_ishifuku at mufg.jp, kazuhiro_2_itakura at mufg.jp, tomoyuki_3_iguchi at mufg.jp, kenya_2_saito at mufg.jp, hiromi_18_takahashi at mufg.jp JSR-383 developer all Hi, I?m Kyosuke Yamagata. I can't send E-mail by mail form(Expert Group Comments) because of the office network policy. So I send this mail to you. I work for Mitsubishi UFJ Information Technology. Our company is in charge of Mitsubishi UFJ financial group system development, operation and maintenance. And then , We are in charge of in-house Java framework. Our Java framework depends heavily on Java SE and Java EE technologies. I reviewed JEP 116: Extended Validation SSL Certificates in JSR-383(Java SE 18.3) Public review I think it's great. On the other hand, to make things even better, I would like to suggest the following: We can import Self-signed certificates as Root certificate. It used in SSL/TLS connections both Client-side and Server-side, and isn't necessarily EV SSL certificates. When the API takes these Non-EV SSL certificates, what kind of information does return? API user wants to take some information of the certificate without having to worry about what kind of certificate using, I think. For example, if I got some exceptions by using API, I MUST inject the judging code that this certificate is EV or Non-EV into my code. I want to support this usecase by this JEP(or other APIs). This content is the personal opinion by the contributor, not the official opinion of our company. Best regards. From iris.clark at oracle.com Wed Nov 22 18:01:29 2017 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 22 Nov 2017 10:01:29 -0800 (PST) Subject: JSR 383 (Java SE 18.3) Public Review Specification -- DRAFT Message-ID: Hi. A draft of the Public Review Specification is available here: http://cr.openjdk.java.net/~iris/se/18.3/pr/java-se-18.3-pr-spec-01/ This draft includes the following changes: - Spec, Section 6: The EDR only contained the final three paragraphs of 379, "Modules" subsection "Constraints on all modules in an Implementation" [0]. The following entire subsections from 379 "Modules" [1] are now incorporated by reference: "Constraints on Java SE modules", "Constraints on all modules in an Implementation", "Relaxing strong encapsulation", "Overriding module declarations", and "Upgradeable modules". - Annexes 1 and 2: Updates based on build 32 promotion. - Annex 3: Draft versions of The Java Language Specification (JLS) and the Java Virtual Machine Specification (JVMS) were added. Our JSR continues to run on a tight schedule. As with EDR, we'll take a snapshot of the current Specification (without changebars) and submit it for publication. I anticipate PR submission to the PMO one week hence, Wed 29 Nov. As always, we welcome any feedback on this, future weekly builds, and other work in progress. Thanks, iris [0] http://cr.openjdk.java.net/~iris/se/18.3/edr/java-se-18.3-edr-spec/#Conformance [1] http://cr.openjdk.java.net/~iris/se/9/java-se-9-fr-spec/#Modules From iris.clark at oracle.com Wed Nov 29 17:59:30 2017 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 29 Nov 2017 09:59:30 -0800 (PST) Subject: JavaDoc API and diffs for Java SE 18.3 build 33 posted Message-ID: <08a726cb-fb68-4dfb-b0ec-9e6363835d5b@default> The JavaDoc API and diffs for build 33 (18.3+32 vs 18.3+33 and 9+181 vs 18.3+33) are now available: http://cr.openjdk.java.net/~iris/se/18.3/build/33/ Thanks, Iris