From scolebourne at joda.org Mon Feb 12 23:50:11 2024 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 12 Feb 2024 23:50:11 +0000 Subject: Value object equality & floating-point values In-Reply-To: References: <1908581584.3891098.1707598626337.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On Mon, 12 Feb 2024 at 21:16, Dan Smith wrote: > Stephen Colebourne suggested a normalization approach to floating-point field storage: > > >> * For each `float` or `double` field in a value class, the constructor > >> will generate normalization code > >> * The normalization is equivalent to `longBitsToDouble(doubleToLongBits(field))` > >> * Normalization also applies to java.lang.Float and java.lang.Double > >> * == is a Bitwise implementation, but behaves like Representational > >> for developers > > The Oracle-internal discussion last spring covered similar ground. There are different ways to stack it, but what they have in common is an interest in eradicating NaN encoding variations as some sort of unwanted anomaly. I get that this is often the case (for the tiny fraction of programmers who ever encounter NaN in the first place). But let's not overlook the fact that, since 1.3, there's an API that explicitly supports these encodings and promises to preserve them (Double.doubleToRawLongBits and Double.longBitsToDouble). Note that Double is a value class that wraps a field of type 'double'. Flattening out NaN encoding differences in the wrapped field would break that API. This claim doesn't stand up to scrutiny I'm afraid. longBitsToDouble() says this: "Note that this method may not be able to return a double NaN with exactly same bit pattern as the long argument" https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#longBitsToDouble-long- The whole paragraph is a vital read for anyone following this thread. To put it simply, the spec *already allows* normalization (for the very good reason that no Java developer should ever be exposed to different NaNs). I'm really serious about this topic - because the proposed solution is simply not appropriate for Java as a blue collar language. Stephen From joe.darcy at oracle.com Tue Feb 13 02:54:41 2024 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 12 Feb 2024 18:54:41 -0800 Subject: Value object equality & floating-point values In-Reply-To: References: <1908581584.3891098.1707598626337.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On 2/12/2024 3:50 PM, Stephen Colebourne wrote: > On Mon, 12 Feb 2024 at 21:16, Dan Smith wrote: >> Stephen Colebourne suggested a normalization approach to floating-point field storage: >> >>>> * For each `float` or `double` field in a value class, the constructor >>>> will generate normalization code >>>> * The normalization is equivalent to `longBitsToDouble(doubleToLongBits(field))` >>>> * Normalization also applies to java.lang.Float and java.lang.Double >>>> * == is a Bitwise implementation, but behaves like Representational >>>> for developers >> The Oracle-internal discussion last spring covered similar ground. There are different ways to stack it, but what they have in common is an interest in eradicating NaN encoding variations as some sort of unwanted anomaly. I get that this is often the case (for the tiny fraction of programmers who ever encounter NaN in the first place). But let's not overlook the fact that, since 1.3, there's an API that explicitly supports these encodings and promises to preserve them (Double.doubleToRawLongBits and Double.longBitsToDouble). Note that Double is a value class that wraps a field of type 'double'. Flattening out NaN encoding differences in the wrapped field would break that API. > This claim doesn't stand up to scrutiny I'm afraid. > > longBitsToDouble() says this: > "Note that this method may not be able to return a double NaN with > exactly same bit pattern as the long argument" > https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#longBitsToDouble-long- > The whole paragraph is a vital read for anyone following this thread. See also the more recent added text discussing "Floating-point Equality, Equivalence, and Comparison:" https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Double.html#equivalenceRelation > > To put it simply, the spec *already allows* normalization (for the > very good reason that no Java developer should ever be exposed to > different NaNs). The origin of that paragraph stems from idiosyncrasies of? 64-bit double support on the x87 FPU -- tl;dr a format changing load/store instruction rather than a move instruction had to be used to get values on and off the floating-point stack. Fortunately, JEP 306: "Restore Always-Strict Floating-Point Semantics" removed most such issues from a spec perspective, which had not been a serious concern from an implementation perspective for some time. > > I'm really serious about this topic - because the proposed solution is > simply not appropriate for Java as a blue collar language. So-called "NaN boxing" -- storing and extracting extra information from NaN significands -- seems to be a more-common-than-rare implementation technique for some language runtimes; it come up reasonably frequently on Hacker News as one data point. I don't think it is necessary for the Java SE specs or JDK implementation to go out of their way to support NaN boxing, but I don't think it is necessary to prevent the technique from being used either. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Tue Feb 13 15:48:03 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 13 Feb 2024 15:48:03 +0000 Subject: Value object equality & floating-point values In-Reply-To: References: <1908581584.3891098.1707598626337.JavaMail.zimbra@univ-eiffel.fr> Message-ID: [PSA that this discussion has ended up in the wrong mailing list, please be sure to send further replies to valhalla-spec-observers and remove amber-spec-observers.] On Feb 12, 2024, at 6:54?PM, Joe Darcy wrote: On 2/12/2024 3:50 PM, Stephen Colebourne wrote: On Mon, 12 Feb 2024 at 21:16, Dan Smith wrote: Stephen Colebourne suggested a normalization approach to floating-point field storage: * For each `float` or `double` field in a value class, the constructor will generate normalization code * The normalization is equivalent to `longBitsToDouble(doubleToLongBits(field))` * Normalization also applies to java.lang.Float and java.lang.Double * == is a Bitwise implementation, but behaves like Representational for developers The Oracle-internal discussion last spring covered similar ground. There are different ways to stack it, but what they have in common is an interest in eradicating NaN encoding variations as some sort of unwanted anomaly. I get that this is often the case (for the tiny fraction of programmers who ever encounter NaN in the first place). But let's not overlook the fact that, since 1.3, there's an API that explicitly supports these encodings and promises to preserve them (Double.doubleToRawLongBits and Double.longBitsToDouble). Note that Double is a value class that wraps a field of type 'double'. Flattening out NaN encoding differences in the wrapped field would break that API. This claim doesn't stand up to scrutiny I'm afraid. longBitsToDouble() says this: "Note that this method may not be able to return a double NaN with exactly same bit pattern as the long argument" https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#longBitsToDouble-long- The whole paragraph is a vital read for anyone following this thread. See also the more recent added text discussing "Floating-point Equality, Equivalence, and Comparison:" https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Double.html#equivalenceRelation To put it simply, the spec *already allows* normalization (for the very good reason that no Java developer should ever be exposed to different NaNs). The origin of that paragraph stems from idiosyncrasies of 64-bit double support on the x87 FPU -- tl;dr a format changing load/store instruction rather than a move instruction had to be used to get values on and off the floating-point stack. Fortunately, JEP 306: "Restore Always-Strict Floating-Point Semantics" removed most such issues from a spec perspective, which had not been a serious concern from an implementation perspective for some time. I'm really serious about this topic - because the proposed solution is simply not appropriate for Java as a blue collar language. So-called "NaN boxing" -- storing and extracting extra information from NaN significands -- seems to be a more-common-than-rare implementation technique for some language runtimes; it come up reasonably frequently on Hacker News as one data point. I don't think it is necessary for the Java SE specs or JDK implementation to go out of their way to support NaN boxing, but I don't think it is necessary to prevent the technique from being used either. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Feb 23 09:56:08 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 23 Feb 2024 10:56:08 +0100 (CET) Subject: module-import declaration Message-ID: <1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr> Hello, I've just read the draft of the third version of the implicit class JEP https://openjdk.org/jeps/8323335 There is a funny paragraph about why there is a need for an import module syntax. """ One theme of this JEP is the elegant evolution of simple programs to proper declared classes that can reside in larger codebases; there is no beginners' dialect that must be translated away. In other words, it should be simple to evolve an implicitly declared class to an explicitly declared class. As implicitly declared classes automatically import (as needed) all the accessible classes and interfaces of every exported package in the module java.base, there should be a way to specify this in a traditional compilation unit with explicit class declarations. To this end, we add a new kind of import declaration: the module-import declaration. It imports (as needed) all the accessible classes and interfaces of every exported package in a given module. """ So the thought process is: we do not want a dialect for beginners, but we want an import all, so we are introducing a feature nobody ask for, called module-import so look, this is not a dialect, this is an implicit import-module java.base. That's a funny ! Taking a step back, I'm not sure that the idea of an "import all" is even a good idea. It makes the notion that classes are organized in packages hidden so the notion of package documentation (important for beginners) disappear. Simple SQL examples with an "import java.sql.*" and a reference to a class "Date" to not compile anymore. We know that import * has a bad behavior when upgrading dependencies, so hidding many import * behind a new import-module syntax means students will have to unlearn import-module later. regards, R?mi From brian.goetz at oracle.com Fri Feb 23 14:49:21 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 23 Feb 2024 09:49:21 -0500 Subject: module-import declaration In-Reply-To: <1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr> References: <1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr> Message-ID: (I think we've had this discussion already?? Seems eerily familiar.) I realize that some people think star-imports are a bad idea, and some style guides recommend against it.? But these are preferences, which make sense in certain situations, and not in others. This argument goes: since star imports are bad, adding even more powerful star imports is definitely bad.? But the premise is flawed, so this argument does not hold. _The judge rules that "star imports are bad" arguments are inadmissible in this case._ As a thought experiment, if we had modules from Java 1.0, would we have stopped at package-star imports and not module-star imports? This seems unlikely.? Packages and modules are tools for grouping related classes, which are likely to be used together.? Saying "I want to use facility X" is an entirely reasonable thing.? Some facilities are packaged in a single package, so existing star-import works for them, but some are spread out over several packages that are almost always imported together (look at any "how to use Jackson" article, and you'll see that you have to import at least from jackson.core and jackson.databind to get much done.)? Arguably we should have added module-star imports in 9, but this was impractical given the constraints at the time. Turning to the "does it help beginners / simple programs" question, modules are a more sensible granularity of imports for simple programs.? Such a program would prefer to say "I want to use Jackson", not "I want to use these three Jackson packages", or "I want to use these seventeen Jackson classes." As to the "onramp" angle, imports and packages are yet another program-structuring tool that benefits larger programs.? Having to learning them on day one is counterproductive. > We know that import * has a bad behavior when upgrading dependencies, so hidding many import * behind a new import-module syntax means students will have to unlearn import-module later. (I think I've asked you before to keep away from the cheap high-school-debating tricks...)? This is a misuse of "unlearn". Unlearning in this context refers to a dead-end convenience, which hides what is going on but can't be used for more than the simplest cases, and therefore has to be completely discarded and the user starts over.? (This is an onramp to the wrong highway.) But this most surely isn't that. Users can progress smoothly from "implicit java.base import" -> "explicit java.base import" -> "explicit package import" -> "explicit class import" as the more fine-grained tools start to add value.? But I suspect it will be a long time for most users before they would ever have to go past module imports; seeing a list of module imports at the top is a pretty clear statement of what the classes dependencies are.? I don't see anything to unlearn here, ever; all I see is a simple form that can naturally be expanded to a fussier form as the specificity of the fussy form is needed, and which is revealed to be little more than said expansion. > Simple SQL examples with an "import java.sql.*" and a reference to a class "Date" to not compile anymore. Yes, it is unfortunate that there is this collision in java.base. But this argument is not compelling; I have yet to see a program that imports java.sql.* that doesn't also import java.util.*.? So every user has to navigate this collision anyway. On 2/23/2024 4:56 AM, Remi Forax wrote: > Hello, > I've just read the draft of the third version of the implicit class JEP > https://openjdk.org/jeps/8323335 > > There is a funny paragraph about why there is a need for an import module syntax. > > """ > One theme of this JEP is the elegant evolution of simple programs to proper declared classes that can reside in larger codebases; there is no beginners' dialect that must be translated away. In other words, it should be simple to evolve an implicitly declared class to an explicitly declared class. As implicitly declared classes automatically import (as needed) all the accessible classes and interfaces of every exported package in the module java.base, there should be a way to specify this in a traditional compilation unit with explicit class declarations. > > To this end, we add a new kind of import declaration: the module-import declaration. It imports (as needed) all the accessible classes and interfaces of every exported package in a given module. > """ > > So the thought process is: we do not want a dialect for beginners, but we want an import all, so we are introducing a feature nobody ask for, called module-import so look, this is not a dialect, this is an implicit import-module java.base. > > That's a funny ! > > > Taking a step back, I'm not sure that the idea of an "import all" is even a good idea. > > It makes the notion that classes are organized in packages hidden so the notion of package documentation (important for beginners) disappear. > Simple SQL examples with an "import java.sql.*" and a reference to a class "Date" to not compile anymore. > We know that import * has a bad behavior when upgrading dependencies, so hidding many import * behind a new import-module syntax means students will have to unlearn import-module later. > > regards, > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Feb 26 05:43:38 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 26 Feb 2024 00:43:38 -0500 Subject: module-import declaration In-Reply-To: References: <1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr> Message-ID: In response to R?mi's point that no one wants this feature, I spent a lot of time tutoring students who would frequently get tripped up on imports and keeping track of them. This feature would have been a big help to plenty of them back then. I understand that it has some pain points (java.util.Date/java.sql.Date), but that's definitely not reason enough to forgo this feature. On Fri, Feb 23, 2024 at 12:41?PM Brian Goetz wrote: > (I think we've had this discussion already? Seems eerily familiar.) > > I realize that some people think star-imports are a bad idea, and some > style guides recommend against it. But these are preferences, which make > sense in certain situations, and not in others. > > This argument goes: since star imports are bad, adding even more powerful > star imports is definitely bad. But the premise is flawed, so this > argument does not hold. > > _The judge rules that "star imports are bad" arguments are inadmissible in > this case._ > > As a thought experiment, if we had modules from Java 1.0, would we have > stopped at package-star imports and not module-star imports? This seems > unlikely. Packages and modules are tools for grouping related classes, > which are likely to be used together. Saying "I want to use facility X" is > an entirely reasonable thing. Some facilities are packaged in a single > package, so existing star-import works for them, but some are spread out > over several packages that are almost always imported together (look at any > "how to use Jackson" article, and you'll see that you have to import at > least from jackson.core and jackson.databind to get much done.) Arguably > we should have added module-star imports in 9, but this was impractical > given the constraints at the time. > > Turning to the "does it help beginners / simple programs" question, > modules are a more sensible granularity of imports for simple programs. > Such a program would prefer to say "I want to use Jackson", not "I want to > use these three Jackson packages", or "I want to use these seventeen > Jackson classes." > > As to the "onramp" angle, imports and packages are yet another > program-structuring tool that benefits larger programs. Having to learning > them on day one is counterproductive. > > We know that import * has a bad behavior when upgrading dependencies, so hidding many import * behind a new import-module syntax means students will have to unlearn import-module later. > > > (I think I've asked you before to keep away from the cheap > high-school-debating tricks...) This is a misuse of "unlearn". Unlearning > in this context refers to a dead-end convenience, which hides what is going > on but can't be used for more than the simplest cases, and therefore has to > be completely discarded and the user starts over. (This is an onramp to > the wrong highway.) But this most surely isn't that. > > Users can progress smoothly from "implicit java.base import" -> "explicit > java.base import" -> "explicit package import" -> "explicit class import" > as the more fine-grained tools start to add value. But I suspect it will > be a long time for most users before they would ever have to go past module > imports; seeing a list of module imports at the top is a pretty clear > statement of what the classes dependencies are. I don't see anything to > unlearn here, ever; all I see is a simple form that can naturally be > expanded to a fussier form as the specificity of the fussy form is needed, > and which is revealed to be little more than said expansion. > > > Simple SQL examples with an "import java.sql.*" and a reference to a > class "Date" to not compile anymore. > > Yes, it is unfortunate that there is this collision in java.base. But > this argument is not compelling; I have yet to see a program that imports > java.sql.* that doesn't also import java.util.*. So every user has to > navigate this collision anyway. > > > > > > On 2/23/2024 4:56 AM, Remi Forax wrote: > > Hello, > I've just read the draft of the third version of the implicit class JEP > https://openjdk.org/jeps/8323335 > > There is a funny paragraph about why there is a need for an import module syntax. > > """ > One theme of this JEP is the elegant evolution of simple programs to proper declared classes that can reside in larger codebases; there is no beginners' dialect that must be translated away. In other words, it should be simple to evolve an implicitly declared class to an explicitly declared class. As implicitly declared classes automatically import (as needed) all the accessible classes and interfaces of every exported package in the module java.base, there should be a way to specify this in a traditional compilation unit with explicit class declarations. > > To this end, we add a new kind of import declaration: the module-import declaration. It imports (as needed) all the accessible classes and interfaces of every exported package in a given module. > """ > > So the thought process is: we do not want a dialect for beginners, but we want an import all, so we are introducing a feature nobody ask for, called module-import so look, this is not a dialect, this is an implicit import-module java.base. > > That's a funny ! > > > Taking a step back, I'm not sure that the idea of an "import all" is even a good idea. > > It makes the notion that classes are organized in packages hidden so the notion of package documentation (important for beginners) disappear. > Simple SQL examples with an "import java.sql.*" and a reference to a class "Date" to not compile anymore. > We know that import * has a bad behavior when upgrading dependencies, so hidding many import * behind a new import-module syntax means students will have to unlearn import-module later. > > regards, > R?mi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Feb 26 15:22:29 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 26 Feb 2024 10:22:29 -0500 Subject: module-import declaration In-Reply-To: <545454737.14362076.1708932741858.JavaMail.zimbra@univ-eiffel.fr> References: <1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr> <545454737.14362076.1708932741858.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <15cd4caf-b8ff-4ff4-8eb4-5218594d17c5@oracle.com> On 2/26/2024 2:32 AM, forax at univ-mlv.fr wrote: > Oh, so you do not know why import star/wildcard is considered evil. > > The main reason is that an import * is considered as a security > malpractice. Hyperbole is not helpful here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Feb 26 07:32:21 2024 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 26 Feb 2024 08:32:21 +0100 (CET) Subject: module-import declaration In-Reply-To: References: <1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <545454737.14362076.1708932741858.JavaMail.zimbra@univ-eiffel.fr> Oh, so you do not know why import star/wildcard is considered evil. The main reason is that an import * is considered as a security malpractice. When you have a CVE on a library, you want to be able to rapidly pick the next version of that library that fix the security issue. This can be done automatically, there are tools for that. If the application codes contain some import *, the fix may be more involved that just updating the version number in the POM if the library also has introduced new types in between the version used and the version that fix the bug, the new types may conflict with the types of other libraries. Using import * delays the time to fix a security issue, so import * itself is considered as security problem. There are other implications, if a lot of people are using import *, we as JDK developers will be concerned to add new type to java.lang (which is by default imported with a wildcard) because it would break the source compatibility. And even in the small, as a trainer/teacher you want your examples to work with the next versions of the JDK even if those JDK versions introduce new types. Not using import * is not a stylistic/preference choice. R?mi > From: "Brian Goetz" > To: "Remi Forax" , "amber-spec-experts" > > Sent: Friday, February 23, 2024 3:49:21 PM > Subject: Re: module-import declaration > (I think we've had this discussion already? Seems eerily familiar.) > I realize that some people think star-imports are a bad idea, and some style > guides recommend against it. But these are preferences, which make sense in > certain situations, and not in others. > This argument goes: since star imports are bad, adding even more powerful star > imports is definitely bad. But the premise is flawed, so this argument does not > hold. > _The judge rules that "star imports are bad" arguments are inadmissible in this > case._ > As a thought experiment, if we had modules from Java 1.0, would we have stopped > at package-star imports and not module-star imports? This seems unlikely. > Packages and modules are tools for grouping related classes, which are likely > to be used together. Saying "I want to use facility X" is an entirely > reasonable thing. Some facilities are packaged in a single package, so existing > star-import works for them, but some are spread out over several packages that > are almost always imported together (look at any "how to use Jackson" article, > and you'll see that you have to import at least from jackson.core and > jackson.databind to get much done.) Arguably we should have added module-star > imports in 9, but this was impractical given the constraints at the time. > Turning to the "does it help beginners / simple programs" question, modules are > a more sensible granularity of imports for simple programs. Such a program > would prefer to say "I want to use Jackson", not "I want to use these three > Jackson packages", or "I want to use these seventeen Jackson classes." > As to the "onramp" angle, imports and packages are yet another > program-structuring tool that benefits larger programs. Having to learning them > on day one is counterproductive. >> We know that import * has a bad behavior when upgrading dependencies, so hidding >> many import * behind a new import-module syntax means students will have to >> unlearn import-module later. > (I think I've asked you before to keep away from the cheap high-school-debating > tricks...) This is a misuse of "unlearn". Unlearning in this context refers to > a dead-end convenience, which hides what is going on but can't be used for more > than the simplest cases, and therefore has to be completely discarded and the > user starts over. (This is an onramp to the wrong highway.) But this most > surely isn't that. > Users can progress smoothly from "implicit java.base import" -> "explicit > java.base import" -> "explicit package import" -> "explicit class import" as > the more fine-grained tools start to add value. But I suspect it will be a long > time for most users before they would ever have to go past module imports; > seeing a list of module imports at the top is a pretty clear statement of what > the classes dependencies are. I don't see anything to unlearn here, ever; all I > see is a simple form that can naturally be expanded to a fussier form as the > specificity of the fussy form is needed, and which is revealed to be little > more than said expansion. >> Simple SQL examples with an "import java.sql.*" and a reference to a class > > "Date" to not compile anymore. > Yes, it is unfortunate that there is this collision in java.base. But this > argument is not compelling; I have yet to see a program that imports java.sql.* > that doesn't also import java.util.*. So every user has to navigate this > collision anyway. > On 2/23/2024 4:56 AM, Remi Forax wrote: >> Hello, >> I've just read the draft of the third version of the implicit class JEP [ >> https://openjdk.org/jeps/8323335 | https://openjdk.org/jeps/8323335 ] There is >> a funny paragraph about why there is a need for an import module syntax. >> """ >> One theme of this JEP is the elegant evolution of simple programs to proper >> declared classes that can reside in larger codebases; there is no beginners' >> dialect that must be translated away. In other words, it should be simple to >> evolve an implicitly declared class to an explicitly declared class. As >> implicitly declared classes automatically import (as needed) all the accessible >> classes and interfaces of every exported package in the module java.base, there >> should be a way to specify this in a traditional compilation unit with explicit >> class declarations. >> To this end, we add a new kind of import declaration: the module-import >> declaration. It imports (as needed) all the accessible classes and interfaces >> of every exported package in a given module. >> """ >> So the thought process is: we do not want a dialect for beginners, but we want >> an import all, so we are introducing a feature nobody ask for, called >> module-import so look, this is not a dialect, this is an implicit import-module >> java.base. >> That's a funny ! >> Taking a step back, I'm not sure that the idea of an "import all" is even a good >> idea. >> It makes the notion that classes are organized in packages hidden so the notion >> of package documentation (important for beginners) disappear. >> Simple SQL examples with an "import java.sql.*" and a reference to a class >> "Date" to not compile anymore. >> We know that import * has a bad behavior when upgrading dependencies, so hidding >> many import * behind a new import-module syntax means students will have to >> unlearn import-module later. >> regards, >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Mon Feb 26 17:53:28 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 26 Feb 2024 18:53:28 +0100 Subject: module-import declaration In-Reply-To: References: <1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hello! On Fri, Feb 23, 2024 at 4:18?PM Brian Goetz wrote: > > Simple SQL examples with an "import java.sql.*" and a reference to a > class "Date" to not compile anymore. > > Yes, it is unfortunate that there is this collision in java.base. But > this argument is not compelling; I have yet to see a program that imports > java.sql.* that doesn't also import java.util.*. So every user has to > navigate this collision anyway. > > I think, there still will be a standard way to disambiguate the collision, which works with star-imports: import module java.base; import module java.sql; import java.util.Date; // Now, unqualified Date refers to java.util.Date, everybody is happy, and the import table is still very compact. With best regards, Tagir Valeev. > > > > > On 2/23/2024 4:56 AM, Remi Forax wrote: > > Hello, > I've just read the draft of the third version of the implicit class JEP > https://openjdk.org/jeps/8323335 > > There is a funny paragraph about why there is a need for an import module syntax. > > """ > One theme of this JEP is the elegant evolution of simple programs to proper declared classes that can reside in larger codebases; there is no beginners' dialect that must be translated away. In other words, it should be simple to evolve an implicitly declared class to an explicitly declared class. As implicitly declared classes automatically import (as needed) all the accessible classes and interfaces of every exported package in the module java.base, there should be a way to specify this in a traditional compilation unit with explicit class declarations. > > To this end, we add a new kind of import declaration: the module-import declaration. It imports (as needed) all the accessible classes and interfaces of every exported package in a given module. > """ > > So the thought process is: we do not want a dialect for beginners, but we want an import all, so we are introducing a feature nobody ask for, called module-import so look, this is not a dialect, this is an implicit import-module java.base. > > That's a funny ! > > > Taking a step back, I'm not sure that the idea of an "import all" is even a good idea. > > It makes the notion that classes are organized in packages hidden so the notion of package documentation (important for beginners) disappear. > Simple SQL examples with an "import java.sql.*" and a reference to a class "Date" to not compile anymore. > We know that import * has a bad behavior when upgrading dependencies, so hidding many import * behind a new import-module syntax means students will have to unlearn import-module later. > > regards, > R?mi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Feb 26 17:58:40 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 26 Feb 2024 12:58:40 -0500 Subject: module-import declaration In-Reply-To: References: <1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <84c79fb5-383f-49e7-83ac-03b71450654b@oracle.com> Yes, this is exactly as I expected it would work.? Just as single-import takes precedence over on-demand package import, it would do so over on-demand module import as well (since the latter is just a "macro" for a bunch of on-demand package imports.) On 2/26/2024 12:53 PM, Tagir Valeev wrote: > Hello! > > On Fri, Feb 23, 2024 at 4:18?PM Brian Goetz > wrote: > > > Simple SQL examples with an "import java.sql.*" and a reference > to a class "Date" to not compile anymore. > > Yes, it is unfortunate that there is this collision in java.base.? > But this argument is not compelling; I have yet to see a program > that imports java.sql.* that doesn't also import java.util.*.? So > every user has to navigate this collision anyway. > > > I think, there still will be a standard way to disambiguate the > collision, which works with star-imports: > > import module java.base; > import module java.sql; > import java.util.Date; > > // Now, unqualified Date refers to java.util.Date, everybody is happy, > and the import table is still very compact. > > With best regards, > Tagir Valeev. > > > > > > On 2/23/2024 4:56 AM, Remi Forax wrote: >> Hello, >> I've just read the draft of the third version of the implicit class JEP >> https://openjdk.org/jeps/8323335 >> >> There is a funny paragraph about why there is a need for an import module syntax. >> >> """ >> One theme of this JEP is the elegant evolution of simple programs to proper declared classes that can reside in larger codebases; there is no beginners' dialect that must be translated away. In other words, it should be simple to evolve an implicitly declared class to an explicitly declared class. As implicitly declared classes automatically import (as needed) all the accessible classes and interfaces of every exported package in the module java.base, there should be a way to specify this in a traditional compilation unit with explicit class declarations. >> >> To this end, we add a new kind of import declaration: the module-import declaration. It imports (as needed) all the accessible classes and interfaces of every exported package in a given module. >> """ >> >> So the thought process is: we do not want a dialect for beginners, but we want an import all, so we are introducing a feature nobody ask for, called module-import so look, this is not a dialect, this is an implicit import-module java.base. >> >> That's a funny ! >> >> >> Taking a step back, I'm not sure that the idea of an "import all" is even a good idea. >> >> It makes the notion that classes are organized in packages hidden so the notion of package documentation (important for beginners) disappear. >> Simple SQL examples with an "import java.sql.*" and a reference to a class "Date" to not compile anymore. >> We know that import * has a bad behavior when upgrading dependencies, so hidding many import * behind a new import-module syntax means students will have to unlearn import-module later. >> >> regards, >> R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: