From gavin.bierman at oracle.com Tue Sep 3 14:50:43 2024 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 3 Sep 2024 14:50:43 +0000 Subject: Project Amber: Draft JEPs for JDK 24 Message-ID: <268AC9C7-B466-455D-A44D-53E5C0B5D2CB@oracle.com> Dear all, I have prepared draft JEPs for the following features from Project Amber that we propose to preview in JDK 24: - Flexible Constructor Bodies (Third Preview) https://openjdk.org/jeps/8338287 - Implicitly Declared Classes and Instance Main Methods (Fourth Preview) https://openjdk.org/jeps/8335984 - Module Import Declarations (Second Preview) https://openjdk.org/jeps/8335987 I emphasise that these are all drafts, but please send any feedback/comments to this list or direct to me. Many thanks, Gavin PS: Aggelos has already announced the draft JEP for a further Project Amber feature: Primitive Types in Patterns, instanceof, and switch (Second Preview) https://openjdk.org/jeps/8335876 From alex.buckley at oracle.com Wed Sep 4 19:33:50 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 4 Sep 2024 12:33:50 -0700 Subject: [module-imports] Importing java.se? In-Reply-To: <293ebacc-3d73-4984-9608-70ce181aecb4@oracle.com> References: <0d6df64f-8ad7-4350-9252-ee47d65703a9@berlin.de> <78a3467d-16bd-4082-a118-ae75e1b09894@oracle.com> <293ebacc-3d73-4984-9608-70ce181aecb4@oracle.com> Message-ID: <1a1a7525-4f47-48bc-8b42-91cd088a0bf3@oracle.com> On 7/17/2024 1:38 PM, Alex Buckley wrote: > On 7/17/2024 1:01 PM, Stephan Herrmann wrote: >> Where will the update be posted? > > JEP 261 will be updated inline, in a way that distinguishes the original > Java 9 rule from the Java 11 rule. Updated: https://openjdk.org/jeps/261#Root-modules >> Meanwhile I found this in the announcement on jigsaw-dev: >> ???? "As the policy is JDK-specific it means there aren't any >> specification changes." >> >> How does this match to the existence of a compiler that is not part of >> JDK? Should that compiler not implement the change? > > JEP 261 has scope SE, not scope JDK, so it was intended that the default > set of root modules is a characteristic of the Java Platform, not just > the OpenJDK implementation. We'll need to look into why java.lang.module > says the default set of root modules is implementation specific, and why > the CSR ended up with scope JDK. We have filed a bug to address the SE-versus-JDK matter: https://bugs.openjdk.org/browse/JDK-8338743 Note that `import module java.se` (or any other aggregator module) will still not be possible from code on the class path unless there is a *further* change to the definition of the default set of root modules. Alex From gavin.bierman at oracle.com Wed Sep 25 09:30:18 2024 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Wed, 25 Sep 2024 09:30:18 +0000 Subject: [module-import] Modules transitively requiring module java.base Message-ID: Dear all, People playing with JEP 476 - Module Import Declarations - have been surprised when importing an aggregator module such as `java.se`, that they also needed to `import module java.base`. This is because the `java.se` module which, as an aggregator module, consists of only `requires transitive` directives, does not contain the directive `requires transitive java.base`. Currently Java forbids any module declaring a transitive dependence on the `java.base` module. This restriction was sensible in the original module system design as all modules have an implicit dependence on `java.base`, and so such a directive was pointless. But with the module import feature where module declarations are used to derive a set of packages to be imported, this directive is useful and so should be allowed. We propose in the next preview of this feature to lift the language restriction on `requires transitive java.base`, and also to change the implementation of the `java.se` module so that it `requires transitive java.base`. (I have updated the draft JEP: https://openjdk.org/jeps/8335987) Let me know your thoughts on this proposal either on this list, or direct to me. Thanks, Gavin From amaembo at gmail.com Wed Sep 25 09:44:12 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 25 Sep 2024 11:44:12 +0200 Subject: [module-import] Modules transitively requiring module java.base In-Reply-To: References: Message-ID: I support this change, thank you! Tagir On Wed, Sep 25, 2024, 11:30 Gavin Bierman wrote: > Dear all, > > People playing with JEP 476 - Module Import Declarations - have been > surprised when importing an aggregator module such as `java.se`, that > they also needed to `import module java.base`. This is because the ` > java.se` module which, as an aggregator module, consists of only > `requires transitive` directives, does not contain the directive `requires > transitive java.base`. Currently Java forbids any module declaring a > transitive dependence on the `java.base` module. > > This restriction was sensible in the original module system design as all > modules have an implicit dependence on `java.base`, and so such a directive > was pointless. But with the module import feature where module declarations > are used to derive a set of packages to be imported, this directive is > useful and so should be allowed. > > We propose in the next preview of this feature to lift the language > restriction on `requires transitive java.base`, and also to change the > implementation of the `java.se` module so that it `requires transitive > java.base`. (I have updated the draft JEP: > https://openjdk.org/jeps/8335987) > > Let me know your thoughts on this proposal either on this list, or direct > to me. > > Thanks, > Gavin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Sep 25 10:25:48 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 Sep 2024 12:25:48 +0200 (CEST) Subject: [module-import] Modules transitively requiring module java.base In-Reply-To: References: Message-ID: <240758622.16581452.1727259948693.JavaMail.zimbra@univ-eiffel.fr> > From: "Tagir Valeev" > To: "Gavin Bierman" > Cc: "amber-dev" , "amber-spec-experts" > > Sent: Wednesday, September 25, 2024 11:44:12 AM > Subject: Re: [module-import] Modules transitively requiring module java.base > I support this change, thank you! > Tagir I agree, this is a useful addition. R?mi > On Wed, Sep 25, 2024, 11:30 Gavin Bierman < [ mailto:gavin.bierman at oracle.com | > gavin.bierman at oracle.com ] > wrote: >> Dear all, >> People playing with JEP 476 - Module Import Declarations - have been surprised >> when importing an aggregator module such as ` [ http://java.se/ | java.se ] `, >> that they also needed to `import module java.base`. This is because the ` [ >> http://java.se/ | java.se ] ` module which, as an aggregator module, consists >> of only `requires transitive` directives, does not contain the directive >> `requires transitive java.base`. Currently Java forbids any module declaring a >> transitive dependence on the `java.base` module. >> This restriction was sensible in the original module system design as all >> modules have an implicit dependence on `java.base`, and so such a directive was >> pointless. But with the module import feature where module declarations are >> used to derive a set of packages to be imported, this directive is useful and >> so should be allowed. >> We propose in the next preview of this feature to lift the language restriction >> on `requires transitive java.base`, and also to change the implementation of >> the ` [ http://java.se/ | java.se ] ` module so that it `requires transitive >> java.base`. (I have updated the draft JEP: [ https://openjdk.org/jeps/8335987 | >> https://openjdk.org/jeps/8335987 ] ) >> Let me know your thoughts on this proposal either on this list, or direct to me. >> Thanks, >> Gavin -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Fri Sep 27 07:25:32 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 27 Sep 2024 09:25:32 +0200 Subject: [sealed] SafeVarargs and sealed classes Message-ID: Hello! Using generic varargs in non-final (in particular, interface) methods is still painful in Java, as one cannot annotate them as @SafeVarargs, so every callsite has an unwanted warning about generic array creation. Closed sealed hierarchies allow to control all the implementations and explicitly mark all of them with @SafeVarargs. In this case, we could improve the situation if we allow marking the parent method as well. E.g., consider the following code: import java.util.Optional; public class Main { public sealed interface Service permits ServiceImpl { @SuppressWarnings("unchecked") // cannot use @SafeVarargs here void process(Optional... params); } public static final class ServiceImpl implements Service { @SafeVarargs @Override public final void process(Optional... params) { for (Optional param : params) { param.ifPresent(System.out::println); } } } void test(Service service, ServiceImpl serviceImpl) { // Warning: warning: [unchecked] unchecked generic array creation service.process(Optional.of(1), Optional.of(2), Optional.empty()); // No warning thanks to SafeVarargs serviceImpl.process(Optional.of(1), Optional.of(2), Optional.empty()); } } Here, we cannot use the Service::process method without an unchecked warning about generic array creation. Which is bad, as we have closed hierarchy and explicitly marked all the implementations as safe. To improve the situation, I suggest the following additions to the Java language specification: 1. Allow marking non-final, non-private methods (abstract or not) with @SafeVarargs if they are declared inside a sealed or final (*) class / interface 2. If a vararg method overrides / implements another vararg method marked with SafeVarargs, then the overriding method must be marked with SafeVarargs as well; otherwise a compilation error occurs. 3. If a non-sealed class / interface is declared, all its visible methods are examined. If any of them is overridable and marked with SafeVarargs, then a compilation error occurs. (*) Extending this to final classes is not quite necessary, but it looks logical addition and allows to omit final method modifier inside final class. With these rules, the code above could be rewritten as: import java.util.Optional; public class Main { public sealed interface Service permits ServiceImpl { @SafeVarargs // now allowed, as we are inside sealed interface void process(Optional... params); } public static final class ServiceImpl implements Service { @SafeVarargs // must be specified @Override public void process(Optional... params) { // possible to omit 'final' here for (Optional param : params) { param.ifPresent(System.out::println); } } } void test(Service service, ServiceImpl serviceImpl) { // No warning anymore thanks to SafeVarargs service.process(Optional.of(1), Optional.of(2), Optional.empty()); // No warning thanks to SafeVarargs serviceImpl.process(Optional.of(1), Optional.of(2), Optional.empty()); } } What do you think? With best regards, Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: