From victorwssilva at gmail.com Sun May 8 02:36:27 2022 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Sat, 7 May 2022 23:36:27 -0300 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses Message-ID: The java.time package was released in Java 8, far back in 2014, more than 8 years ago. It has been a long time since then. Before that, we had the dreadful infamous java.util.Date, java.util.Calendar, java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat and a few other lesser-known obscure cases. There are plenty of reasons to avoid using Date, Calendar, DateFormat and their subclasses, otherwise there would be few to no reasons for java.time to be conceived. Applications and libraries which used or relied on those legacy classes already had plenty of time to move on and provide java.time.* alternatives. No skilled java programmer uses the legacy classes in new applications except when integrating with legacy APIs. Using those classes nowadays should be considered at least a bad programming practice, if not something worse (source of bugs, security issues, etc). Novices, unskilled, careless and lazy programmers who should know better still happily continue to use the legacy classes, pissing off those who are more enlightened. So, my proposal is pretty simple: It is time to put a @Deprecated in all of those (not for removal, though). First, let's deprecate all of them. Second, any method in the JDK returning or receiving any of those as a parameter should be equally deprecated. If there is no replacement method using the relevant classes or interfaces in the java.time package, one should be created (which is something probably pretty straightforward). If any of those methods is abstract or is part of an interface, then we have a small problem, and it should be solved on a case-by-case analysis, preferentially by providing a default implementation. I'm sure that some cases should still exist, but I doubt that any of them would be a showstopper. The negative impact is expected to be very small. Popular products like Spring and Jakarta either already moved on and provided java.time.* alternatives to their APIs or could do that quickly and easily. Anyone who is left behind, would only get some [deserved] deprecation warnings. On the positive impact side, more than just discouraging the usage of the ugly and annoying API of Date, Calendar and DateFormat for people who should know better, those classes are a frequent source of bugs that are hard do track and to debug due to their mutability and thread unsafety. Thus, we are already way past the time to make the compiler give a warning to anyone still using them. What do you think? From peter.lawrey at gmail.com Sun May 8 07:25:44 2022 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Sun, 8 May 2022 08:25:44 +0100 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: Hi I would add that a JSR 310 backport is available for Java 6 & 7. So even those needing to support 6 can drop use of these classes. https://www.threeten.org/threetenbp/ Regards Peter On Sun, 8 May 2022, 03:43 Victor Williams Stafusa da Silva, < victorwssilva at gmail.com> wrote: > The java.time package was released in Java 8, far back in 2014, more than 8 > years ago. It has been a long time since then. Before that, we had the > dreadful infamous java.util.Date, java.util.Calendar, > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat > and a few other lesser-known obscure cases. > > There are plenty of reasons to avoid using Date, Calendar, DateFormat and > their subclasses, otherwise there would be few to no reasons for java.time > to be conceived. > > Applications and libraries which used or relied on those legacy classes > already had plenty of time to move on and provide java.time.* alternatives. > > No skilled java programmer uses the legacy classes in new applications > except when integrating with legacy APIs. > > Using those classes nowadays should be considered at least a bad > programming practice, if not something worse (source of bugs, security > issues, etc). > > Novices, unskilled, careless and lazy programmers who should know better > still happily continue to use the legacy classes, pissing off those who are > more enlightened. > > So, my proposal is pretty simple: It is time to put a @Deprecated in all of > those (not for removal, though). > > First, let's deprecate all of them. Second, any method in the JDK returning > or receiving any of those as a parameter should be equally deprecated. If > there is no replacement method using the relevant classes or interfaces in > the java.time package, one should be created (which is something probably > pretty straightforward). > > If any of those methods is abstract or is part of an interface, then we > have a small problem, and it should be solved on a case-by-case analysis, > preferentially by providing a default implementation. I'm sure that some > cases should still exist, but I doubt that any of them would be a > showstopper. > > The negative impact is expected to be very small. Popular products like > Spring and Jakarta either already moved on and provided java.time.* > alternatives to their APIs or could do that quickly and easily. Anyone who > is left behind, would only get some [deserved] deprecation warnings. > > On the positive impact side, more than just discouraging the usage of the > ugly and annoying API of Date, Calendar and DateFormat for people who > should know better, those classes are a frequent source of bugs that are > hard do track and to debug due to their mutability and thread unsafety. > Thus, we are already way past the time to make the compiler give a warning > to anyone still using them. > > What do you think? > From ethan at mccue.dev Sun May 8 07:46:13 2022 From: ethan at mccue.dev (Ethan McCue) Date: Sun, 8 May 2022 08:46:13 +0100 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: To play devil's advocate here 1. I'll assert without proof that in general people are very sensitive to new warnings. If you upgrade your app 22 -> 23 and suddenly you get a bunch of depreciation warnings that would hold back adoption in the ecosystem in a small but significant way 2. Deprecation isn't really the "right" concept. Date isn't an "unsupported path", and calling .toInstant on it and the reverse would be the supported way of working with the myriad apis that take and return Dates. My first stab at describing the situation would be something like @Prefer(Instant.class) On Sun, May 8, 2022, 8:28 AM Peter Lawrey wrote: > Hi > I would add that a JSR 310 backport is available for Java 6 & 7. So even > those needing to support 6 can drop use of these classes. > > https://www.threeten.org/threetenbp/ > > Regards Peter > > On Sun, 8 May 2022, 03:43 Victor Williams Stafusa da Silva, < > victorwssilva at gmail.com> wrote: > > > The java.time package was released in Java 8, far back in 2014, more > than 8 > > years ago. It has been a long time since then. Before that, we had the > > dreadful infamous java.util.Date, java.util.Calendar, > > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > > java.sql.Timestamp, java.util.GregorianCalendar, > java.text.SimpleDateFormat > > and a few other lesser-known obscure cases. > > > > There are plenty of reasons to avoid using Date, Calendar, DateFormat and > > their subclasses, otherwise there would be few to no reasons for > java.time > > to be conceived. > > > > Applications and libraries which used or relied on those legacy classes > > already had plenty of time to move on and provide java.time.* > alternatives. > > > > No skilled java programmer uses the legacy classes in new applications > > except when integrating with legacy APIs. > > > > Using those classes nowadays should be considered at least a bad > > programming practice, if not something worse (source of bugs, security > > issues, etc). > > > > Novices, unskilled, careless and lazy programmers who should know better > > still happily continue to use the legacy classes, pissing off those who > are > > more enlightened. > > > > So, my proposal is pretty simple: It is time to put a @Deprecated in all > of > > those (not for removal, though). > > > > First, let's deprecate all of them. Second, any method in the JDK > returning > > or receiving any of those as a parameter should be equally deprecated. If > > there is no replacement method using the relevant classes or interfaces > in > > the java.time package, one should be created (which is something probably > > pretty straightforward). > > > > If any of those methods is abstract or is part of an interface, then we > > have a small problem, and it should be solved on a case-by-case analysis, > > preferentially by providing a default implementation. I'm sure that some > > cases should still exist, but I doubt that any of them would be a > > showstopper. > > > > The negative impact is expected to be very small. Popular products like > > Spring and Jakarta either already moved on and provided java.time.* > > alternatives to their APIs or could do that quickly and easily. Anyone > who > > is left behind, would only get some [deserved] deprecation warnings. > > > > On the positive impact side, more than just discouraging the usage of the > > ugly and annoying API of Date, Calendar and DateFormat for people who > > should know better, those classes are a frequent source of bugs that are > > hard do track and to debug due to their mutability and thread unsafety. > > Thus, we are already way past the time to make the compiler give a > warning > > to anyone still using them. > > > > What do you think? > > > From brian.goetz at oracle.com Mon May 9 19:43:00 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 9 May 2022 15:43:00 -0400 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: The problem with such a proposal is that applications are not the only user of Date. Libraries -- including the JDK -- have baked Date into their APIs. A simple example is java.security.Timestamp::getTimestamp, which returns a Date.? This one is easier because it is a final class, and could acquire a getTimestampAsLocalDate method, and deprecate getTimestamp.? But even this gives a hint of the pain users are in for; the good name is taken, and since we don't overload on return types, we'd have to pick a lesser name.? And users would forever be confronted with the choice of the less desirable but better-named getTimestamp, and the more desirable but worse-named getTimestampAsLocalDate. A more difficult example is java.security.cert.X509Certificate, with: ??? public abstract Date getNotAfter(); This is a public abstract method in a public abstract class. This means that remediating this use is even more difficult.? We can add a default method that returns LocalDate that converts from Date, and then update existing implementations to swap what they view their canonical representation as, but there's still going to be an abstract method returning Date, that new implementations will be confronted with.? So it will be pretty weird to have an abstract method in a public abstract class / interface that returns a deprecated type. And, after all this, I still don't see a path to removing it in the next 10 years.? So this seems like a lot of contortion and rewriting and putting users in confusion positions for mostly symbolic benefit. > The negative impact is expected to be very small. Popular products like > Spring and Jakarta either already moved on and provided java.time.* > alternatives to their APIs or could do that quickly and easily. Anyone who > is left behind, would only get some [deserved] deprecation warnings. As I hope you now see, you're ignoring a whole category of not-at-all-small impact. On 5/7/2022 10:36 PM, Victor Williams Stafusa da Silva wrote: > The java.time package was released in Java 8, far back in 2014, more than 8 > years ago. It has been a long time since then. Before that, we had the > dreadful infamous java.util.Date, java.util.Calendar, > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat > and a few other lesser-known obscure cases. > > There are plenty of reasons to avoid using Date, Calendar, DateFormat and > their subclasses, otherwise there would be few to no reasons for java.time > to be conceived. > > Applications and libraries which used or relied on those legacy classes > already had plenty of time to move on and provide java.time.* alternatives. > > No skilled java programmer uses the legacy classes in new applications > except when integrating with legacy APIs. > > Using those classes nowadays should be considered at least a bad > programming practice, if not something worse (source of bugs, security > issues, etc). > > Novices, unskilled, careless and lazy programmers who should know better > still happily continue to use the legacy classes, pissing off those who are > more enlightened. > > So, my proposal is pretty simple: It is time to put a @Deprecated in all of > those (not for removal, though). > > First, let's deprecate all of them. Second, any method in the JDK returning > or receiving any of those as a parameter should be equally deprecated. If > there is no replacement method using the relevant classes or interfaces in > the java.time package, one should be created (which is something probably > pretty straightforward). > > If any of those methods is abstract or is part of an interface, then we > have a small problem, and it should be solved on a case-by-case analysis, > preferentially by providing a default implementation. I'm sure that some > cases should still exist, but I doubt that any of them would be a > showstopper. > > The negative impact is expected to be very small. Popular products like > Spring and Jakarta either already moved on and provided java.time.* > alternatives to their APIs or could do that quickly and easily. Anyone who > is left behind, would only get some [deserved] deprecation warnings. > > On the positive impact side, more than just discouraging the usage of the > ugly and annoying API of Date, Calendar and DateFormat for people who > should know better, those classes are a frequent source of bugs that are > hard do track and to debug due to their mutability and thread unsafety. > Thus, we are already way past the time to make the compiler give a warning > to anyone still using them. > > What do you think? From peter.lawrey at gmail.com Mon May 9 20:13:54 2022 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Mon, 9 May 2022 21:13:54 +0100 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: Hi, The only way forward is to have code checkers, possibly built-in, to suggest alternatives. Getting novices to use them is also a challenge. BTW This is an example of how hard it is to kill poor code. At one point, I edited a few hundred copies of this block of code on StackOverflow, but below is an example from 2022. I assume the original author used DataInputStream.readLine() before realising he should use BufferedReader. I found an example from 2002, possibly the original. A google search suggested there are about 3k copies of this code around. https://www.google.com/search?q=%22Get+the+object+of+DataInputStream%22 FileInputStream fstream = new FileInputStream("D:adresse.txt"); // Get the object of DataInputStream DataInputStream in = new DataInputStream(fstream); BufferedReader br = new BufferedReader(new InputStreamReader(in)); Regards, Peter. On Mon, 9 May 2022 at 20:44, Brian Goetz wrote: > The problem with such a proposal is that applications are not the only > user of Date. Libraries -- including the JDK -- have baked Date into > their APIs. > > A simple example is java.security.Timestamp::getTimestamp, which returns > a Date. This one is easier because it is a final class, and could > acquire a getTimestampAsLocalDate method, and deprecate getTimestamp. > But even this gives a hint of the pain users are in for; the good name > is taken, and since we don't overload on return types, we'd have to pick > a lesser name. And users would forever be confronted with the choice of > the less desirable but better-named getTimestamp, and the more desirable > but worse-named getTimestampAsLocalDate. > > A more difficult example is java.security.cert.X509Certificate, with: > > public abstract Date getNotAfter(); > > This is a public abstract method in a public abstract class. This means > that remediating this use is even more difficult. We can add a default > method that returns LocalDate that converts from Date, and then update > existing implementations to swap what they view their canonical > representation as, but there's still going to be an abstract method > returning Date, that new implementations will be confronted with. So it > will be pretty weird to have an abstract method in a public abstract > class / interface that returns a deprecated type. > > And, after all this, I still don't see a path to removing it in the next > 10 years. So this seems like a lot of contortion and rewriting and > putting users in confusion positions for mostly symbolic benefit. > > > The negative impact is expected to be very small. Popular products like > > Spring and Jakarta either already moved on and provided java.time.* > > alternatives to their APIs or could do that quickly and easily. Anyone > who > > is left behind, would only get some [deserved] deprecation warnings. > > As I hope you now see, you're ignoring a whole category of > not-at-all-small impact. > > > On 5/7/2022 10:36 PM, Victor Williams Stafusa da Silva wrote: > > The java.time package was released in Java 8, far back in 2014, more > than 8 > > years ago. It has been a long time since then. Before that, we had the > > dreadful infamous java.util.Date, java.util.Calendar, > > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > > java.sql.Timestamp, java.util.GregorianCalendar, > java.text.SimpleDateFormat > > and a few other lesser-known obscure cases. > > > > There are plenty of reasons to avoid using Date, Calendar, DateFormat and > > their subclasses, otherwise there would be few to no reasons for > java.time > > to be conceived. > > > > Applications and libraries which used or relied on those legacy classes > > already had plenty of time to move on and provide java.time.* > alternatives. > > > > No skilled java programmer uses the legacy classes in new applications > > except when integrating with legacy APIs. > > > > Using those classes nowadays should be considered at least a bad > > programming practice, if not something worse (source of bugs, security > > issues, etc). > > > > Novices, unskilled, careless and lazy programmers who should know better > > still happily continue to use the legacy classes, pissing off those who > are > > more enlightened. > > > > So, my proposal is pretty simple: It is time to put a @Deprecated in all > of > > those (not for removal, though). > > > > First, let's deprecate all of them. Second, any method in the JDK > returning > > or receiving any of those as a parameter should be equally deprecated. If > > there is no replacement method using the relevant classes or interfaces > in > > the java.time package, one should be created (which is something probably > > pretty straightforward). > > > > If any of those methods is abstract or is part of an interface, then we > > have a small problem, and it should be solved on a case-by-case analysis, > > preferentially by providing a default implementation. I'm sure that some > > cases should still exist, but I doubt that any of them would be a > > showstopper. > > > > The negative impact is expected to be very small. Popular products like > > Spring and Jakarta either already moved on and provided java.time.* > > alternatives to their APIs or could do that quickly and easily. Anyone > who > > is left behind, would only get some [deserved] deprecation warnings. > > > > On the positive impact side, more than just discouraging the usage of the > > ugly and annoying API of Date, Calendar and DateFormat for people who > > should know better, those classes are a frequent source of bugs that are > > hard do track and to debug due to their mutability and thread unsafety. > > Thus, we are already way past the time to make the compiler give a > warning > > to anyone still using them. > > > > What do you think? > From ethan at mccue.dev Mon May 9 21:39:26 2022 From: ethan at mccue.dev (Ethan McCue) Date: Mon, 9 May 2022 17:39:26 -0400 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: > code checkers, possibly built-in Maybe instead of tackling Date specifically lets ask "What would it look like for the JDK to have a built-in fully featured linter." The capabilities provided by javac's lints like -Xlint:deprecation are a subset of the capabilities of a more fully featured linter like SonarCube. There is no reason SonarCube's bottom line should be any of our concern, so there isn't any conceptual reason the JDK couldn't include something akin to clippy - "jlint"? - and have that be the place to really flesh out how tooling should communicate the nuance / "best practices" around older apis. On Mon, May 9, 2022 at 4:15 PM Peter Lawrey wrote: > Hi, > The only way forward is to have code checkers, possibly built-in, to > suggest alternatives. > Getting novices to use them is also a challenge. > > BTW This is an example of how hard it is to kill poor code. At one point, I > edited a few hundred copies of this block of code on StackOverflow, but > below is an example from 2022. > I assume the original author used DataInputStream.readLine() before > realising he should use BufferedReader. I found an example from 2002, > possibly the original. > > A google search suggested there are about 3k copies of this code around. > https://www.google.com/search?q=%22Get+the+object+of+DataInputStream%22 > > FileInputStream fstream = new FileInputStream("D:adresse.txt"); > // Get the object of DataInputStream > DataInputStream in = new DataInputStream(fstream); > BufferedReader br = new BufferedReader(new InputStreamReader(in)); > > Regards, > Peter. > > On Mon, 9 May 2022 at 20:44, Brian Goetz wrote: > > > The problem with such a proposal is that applications are not the only > > user of Date. Libraries -- including the JDK -- have baked Date into > > their APIs. > > > > A simple example is java.security.Timestamp::getTimestamp, which returns > > a Date. This one is easier because it is a final class, and could > > acquire a getTimestampAsLocalDate method, and deprecate getTimestamp. > > But even this gives a hint of the pain users are in for; the good name > > is taken, and since we don't overload on return types, we'd have to pick > > a lesser name. And users would forever be confronted with the choice of > > the less desirable but better-named getTimestamp, and the more desirable > > but worse-named getTimestampAsLocalDate. > > > > A more difficult example is java.security.cert.X509Certificate, with: > > > > public abstract Date getNotAfter(); > > > > This is a public abstract method in a public abstract class. This means > > that remediating this use is even more difficult. We can add a default > > method that returns LocalDate that converts from Date, and then update > > existing implementations to swap what they view their canonical > > representation as, but there's still going to be an abstract method > > returning Date, that new implementations will be confronted with. So it > > will be pretty weird to have an abstract method in a public abstract > > class / interface that returns a deprecated type. > > > > And, after all this, I still don't see a path to removing it in the next > > 10 years. So this seems like a lot of contortion and rewriting and > > putting users in confusion positions for mostly symbolic benefit. > > > > > The negative impact is expected to be very small. Popular products like > > > Spring and Jakarta either already moved on and provided java.time.* > > > alternatives to their APIs or could do that quickly and easily. Anyone > > who > > > is left behind, would only get some [deserved] deprecation warnings. > > > > As I hope you now see, you're ignoring a whole category of > > not-at-all-small impact. > > > > > > On 5/7/2022 10:36 PM, Victor Williams Stafusa da Silva wrote: > > > The java.time package was released in Java 8, far back in 2014, more > > than 8 > > > years ago. It has been a long time since then. Before that, we had the > > > dreadful infamous java.util.Date, java.util.Calendar, > > > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > > > java.sql.Timestamp, java.util.GregorianCalendar, > > java.text.SimpleDateFormat > > > and a few other lesser-known obscure cases. > > > > > > There are plenty of reasons to avoid using Date, Calendar, DateFormat > and > > > their subclasses, otherwise there would be few to no reasons for > > java.time > > > to be conceived. > > > > > > Applications and libraries which used or relied on those legacy classes > > > already had plenty of time to move on and provide java.time.* > > alternatives. > > > > > > No skilled java programmer uses the legacy classes in new applications > > > except when integrating with legacy APIs. > > > > > > Using those classes nowadays should be considered at least a bad > > > programming practice, if not something worse (source of bugs, security > > > issues, etc). > > > > > > Novices, unskilled, careless and lazy programmers who should know > better > > > still happily continue to use the legacy classes, pissing off those who > > are > > > more enlightened. > > > > > > So, my proposal is pretty simple: It is time to put a @Deprecated in > all > > of > > > those (not for removal, though). > > > > > > First, let's deprecate all of them. Second, any method in the JDK > > returning > > > or receiving any of those as a parameter should be equally deprecated. > If > > > there is no replacement method using the relevant classes or interfaces > > in > > > the java.time package, one should be created (which is something > probably > > > pretty straightforward). > > > > > > If any of those methods is abstract or is part of an interface, then we > > > have a small problem, and it should be solved on a case-by-case > analysis, > > > preferentially by providing a default implementation. I'm sure that > some > > > cases should still exist, but I doubt that any of them would be a > > > showstopper. > > > > > > The negative impact is expected to be very small. Popular products like > > > Spring and Jakarta either already moved on and provided java.time.* > > > alternatives to their APIs or could do that quickly and easily. Anyone > > who > > > is left behind, would only get some [deserved] deprecation warnings. > > > > > > On the positive impact side, more than just discouraging the usage of > the > > > ugly and annoying API of Date, Calendar and DateFormat for people who > > > should know better, those classes are a frequent source of bugs that > are > > > hard do track and to debug due to their mutability and thread unsafety. > > > Thus, we are already way past the time to make the compiler give a > > warning > > > to anyone still using them. > > > > > > What do you think? > > > From victorwssilva at gmail.com Tue May 10 03:00:24 2022 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Tue, 10 May 2022 00:00:24 -0300 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: Well, I tried to track every case in the public API of the JDK individually and analyze each of them, one by one. TL;DR - If you are concerned only with the harder cases (like Brian Goetz pointed out), skip directly to items 11, 12 and 13 below. [1] First, those cases below should be fairly easy, just overload the methods and constructors with versions taking java.time.Instant instead of the legacy classes: - java.security.Timestamp(Date, CertPath) - java.security.cert.CertificateRevokedException(Date, other parameters) - java.util.Timer.schedule(TimerTask, Date) - java.util.Timer.schedule(TimerTask, Date, long) - java.util.Timer.scheduleAtFixedRate(TimerTask, Date, long) - java.util.concurrent.locks.AbstractQueuedLongSynchronizer.ConditionObject.awaitUntil(Date) - java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject.awaitUntil(Date) - java.util.concurrent.locks.Condition.awaitUntil(Date) - javax.management.timer.Timer.addNotification(many overload versions) - javax.management.timer.TimerMBean.addNotification(many overload versions) - javax.print.attribute.DateTimeSyntax(Date) - javax.print.attribute.DateTimeAtCompleted(Date) - javax.print.attribute.DateTimeAtCreation(Date) - javax.print.attribute.DateTimeAtProcessing(Date) - javax.print.attribute.JobHoldUntil(Date) - javax.security.auth.kerberos.KerberosTicket(a lot of parameters) - javax.swing.RowFilter.dateFilter(ComparisonType, Date, int...) - javax.swing.SpinnerDateModel(Date, Comparable, Comparable, int) - javax.xml.datatype.Duration.addTo(Date) - javax.xml.datatype.Duration.getTimeInMillis(Date) - javax.xml.datatype.Duration.getTimeInMillis(Calendar) [2] Those are the methods that return java.util.Date. Maybe in some cases the best name was really be already taken, but they are still easy to solve: - java.security.KeyStoreSpi.getCreationDate(String) - Add a getCreationInstant(String) method. - java.security.Timestamp.getTimestamp() - Add a getInstant() method. - java.security.cert.CertificateRevokedException.getInvalidityDate() - Add a getInvalidityInstant() method. - java.security.cert.CertificateRevokedException.getRevocationDate() - Add a getRevocationInstant() method. - javax.management.timer.Timer.getDate(Integer) - Add a getInstant(Integer) method. - javax.management.timer.TimerMBean.getDate(Integer) - Add a getInstant(Integer) method. - javax.print.attribute.DateTimeSyntax.getValue() - Add a getInstant() method. - javax.security.auth.kerberos.KerberosTicket.getAuthTime() - Add a getAuthInstant() method. - javax.security.auth.kerberos.KerberosTicket.getEndTime() - Add a getEndInstant() method. - javax.security.auth.kerberos.KerberosTicket.getStartTime() - Add a getStartInstant() method. - javax.security.auth.kerberos.KerberosTicket.getRenewTill() - Add a getLatestExpiration() method. - javax.swing.SpinnerDateModel.getDate() - Add a getInstant() method. [3] Those are getter and setter pairs of java.util.Date (or something with Date within its generics): - java.security.cert.PKIXParameters.getDate() and setDate(Date) - Add a getValidity() and setValidity(Instant) methods. - java.security.cert.X509CRLSelector.getDateAndTime() and setDateAndTime(Date) - Add differently named methods. - javax.swing.SpinnerDateModel.getStart() and setStart(Comparable) - Add getStartInstant() and setStartInstant(Comparable). - javax.swing.SpinnerDateModel.getEnd() and setEnd(Comparable) - Add getStartInstant() and setEndInstant(Comparable). For them, setting the Instant would also set the Date and vice-versa. Granted, the best names were already taken, but this isn't a big deal and definitely not a reason for keeping using java.util.Date. [4] There are other few special easy cases: - Field javax.management.openmbean.SimpleType.DATE - Just provide SimpleType.INSTANT, SimpleType.LOCAL_DATE, SimpleType.LOCAL_DATE_TIME, etc. - Package javax.security.cert (not to be confused with java.security.cert) - Deprecated for removal. It is time for it to go. [5] Getting into the SQL realm, the classes java.sql.CallableStatement, java.sql.PreparedStatement, java.sql.ResultSet, javax.sql.RowSet and javax.sql.rowset.BaseRowSet feature the following methods: - getDate(int) - getDate(String) - setDate(int, java.sql.Date) - setDate(String, java.sql.Date) - getTime(int) - getTime(String) - setTime(int, java.sql.Time) - setTime(String, java.sql.Time) - getTimestamp(int) - getTimestamp(String) - setTimestamp(int, java.sql.Timestamp) - setTimestamp(String, java.sql.Timestamp) Those are mostly straightforward. Just add methods taking or returning java.time.LocalDate instead of java.sql.Date, java.time.LocalTime instead of java.sql.Time and java.time.LocalDateTime instead of java.sql.Timestamp. Also, it is tempting to create alternatives for other classes within java.time package, like Instant, OffsetDateTime, ZonedDateTime or ChronoLocalDate, if possible. [6] The java.sql.SQLInput, java.sql.SQLOutput, javax.sql.rowset.serial.SQLInputImpl and javax.sql.rowset.serial.SQLOutputImpl also features those methods: - readDate() - readTime() - readTimestamp() - writeDate(java.sql.Date) - writeTime(java.sql.Time) - writeTimestamp(java.sql.Timestamp) The solution would be the same as in [5]. [7] All the methods listed in [5] also have an overload taking a java.util.Calendar parameter, which is used for time zone information as far as I can tell. I am not really sure of what to do with them, but I'm pretty sure that it should not be something complicated. Without looking deep in the issue, maybe adding a version which uses java.time.ZoneId instead of java.util.Calendar is enough. But maybe ZonedDateTime and OffsetDateTime come to play here. [8] Those methods: - java.text.spi.DateFormatProvider.getDateInstance(int, Locale) - java.text.spi.DateFormatProvider.getDateTimeInstance(int, int, Locale) - java.text.spi.DateFormatProvider.getTimeInstance(int, Locale) We just overload them with versions returning java.time.format.DateTimeFormatter and taking enums instead of ints. [9] Those: - javax.swing.text.DateFormatter(DateFormat) - javax.swing.text.DateFormatter.setFormat(DateFormat) Just overload them with java.time.format.DateTimeFormatter. [10] This method: - javax.swing.JSpinner.DateEditor.getFormat() Just add a getFormatter() method returning a java.time.format.DateTimeFormatter. [11] There are those pair of getters and setters: - java.security.cert.X509CRLSelector.getCertificateValid() and setCertificateValid(Date) - java.security.cert.X509CertSelector.getPrivateKeyValid() and setPrivateKeyValid(Date) Adding just differently named methods is ok and simple enough, although their names could be a bit cumbersome. However, the X509CRLSelector and X509CertSelector classes suffer from the same problem that SimpleDateFormat suffers. Users might think that sharing them between threads without locking as long as no setters are called is safe, a presumption that is false as stated in the javadocs. A better alternative, but way off of the scope of this thread, would be to provide immutable alternative for those classes. [12] Now, let's see the problematic case pointed out by Brian Goetz, since those are abstract methods: - java.security.cert.X509CRL.getNextUpdate() - java.security.cert.X509CRL.getThisUpdate() - java.security.cert.X509CRLEntry.getRevocationDate() - java.security.cert.X509Certificate.getNotAfter() - java.security.cert.X509Certificate.getNotBefore() The X509CRL, X509CRLEntry and X509Certificate classes should really been interfaces. Anyway, users aren't expected to be directly extending those classes and none of them have public subclasses. Instead, users should rely on java.security.cert.CertificateFactory class to get instances of these. Hence, adding Instant returning methods should not have be a big problem for 99% of the expected use cases. It is also noteworthy that the X509Certificate class feature the deprecated abstract getIssuerDN() method, so this won't be the first time that it runs to a similar design problem. [13] And to close it up, there are those abstract methods also: - javax.xml.datatype.Duration.addTo(Calendar) - javax.xml.datatype.Duration.normalizeWith(Calendar) - javax.xml.datatype.DatatypeFactory.newXMLGregorianCalendar(GregorianCalendar) - javax.xml.datatype.DatatypeFactory.getTimeZone(int) - javax.xml.datatype.XMLGregorianCalendar.toGregorianCalendar() - javax.xml.datatype.XMLGregorianCalendar.toGregorianCalendar(TimeZone, Locale, XMLGregorianCalendar) XMLGregorianCalendar is tightly coupled with GregorianCalendar (not unexpected considering the class name). But, since users are expected to get instances of Duration and XMLGregorianCalendar only through the DatatypeFactory which in turn should only be instantiated through its static factory methods, this means that only JAXP implementors are expected to be directly extending those classes and 99% of the use cases are ok. Further, these classes really deserved to be better bridged to java.time classes. [FINISH] And, as far as I can tell, those are all the places which should be changed. The following classes would be then be deprecated: java.sql.Date, java.sql.Time, java.sql.Timestamp, java.text.DateFormat, java.text.SimpleDateFormat, java.util.Date, java.util.Calendar, java.util.GregorianCalendar, java.util.TimeZone, java.util.SimpleTimeZone. The package javax.security.cert removed (not to be confused with java.security.cert). Also, even if you decide that java.util.Date, java.util.Calendar and java.util.GregorianCalendar should not be deprecated, the refactorings listed above seem to be very worth to perform anyway. Maybe deprecating only some of them (like java.sql.Date, java.sql.Time and java.sql.Timestamp) is a good start. Finally, I don't think that just because that are a few abstract methods in the deep guts of the JDK which few programmers use directly and because the best possible name method were taken over in roughly those same deep guts classes that this is a sufficient justification to stop deprecating these horrible classes. Em seg., 9 de mai. de 2022 ?s 18:39, Ethan McCue escreveu: > > code checkers, possibly built-in > > Maybe instead of tackling Date specifically lets ask "What would it look > like for the JDK to have a built-in fully featured linter." > > The capabilities provided by javac's lints like -Xlint:deprecation are a > subset of the capabilities of a more fully featured linter like SonarCube. > There is no reason SonarCube's bottom line should be any of our concern, so > there isn't any conceptual reason the JDK couldn't include something akin > to clippy - "jlint"? - and have that be the place to really flesh out how > tooling should communicate the nuance / "best practices" around older apis. > > > > On Mon, May 9, 2022 at 4:15 PM Peter Lawrey > wrote: > >> Hi, >> The only way forward is to have code checkers, possibly built-in, to >> suggest alternatives. >> Getting novices to use them is also a challenge. >> >> BTW This is an example of how hard it is to kill poor code. At one point, >> I >> edited a few hundred copies of this block of code on StackOverflow, but >> below is an example from 2022. >> I assume the original author used DataInputStream.readLine() before >> realising he should use BufferedReader. I found an example from 2002, >> possibly the original. >> >> A google search suggested there are about 3k copies of this code around. >> https://www.google.com/search?q=%22Get+the+object+of+DataInputStream%22 >> >> FileInputStream fstream = new FileInputStream("D:adresse.txt"); >> // Get the object of DataInputStream >> DataInputStream in = new DataInputStream(fstream); >> BufferedReader br = new BufferedReader(new InputStreamReader(in)); >> >> Regards, >> Peter. >> >> On Mon, 9 May 2022 at 20:44, Brian Goetz wrote: >> >> > The problem with such a proposal is that applications are not the only >> > user of Date. Libraries -- including the JDK -- have baked Date into >> > their APIs. >> > >> > A simple example is java.security.Timestamp::getTimestamp, which returns >> > a Date. This one is easier because it is a final class, and could >> > acquire a getTimestampAsLocalDate method, and deprecate getTimestamp. >> > But even this gives a hint of the pain users are in for; the good name >> > is taken, and since we don't overload on return types, we'd have to pick >> > a lesser name. And users would forever be confronted with the choice of >> > the less desirable but better-named getTimestamp, and the more desirable >> > but worse-named getTimestampAsLocalDate. >> > >> > A more difficult example is java.security.cert.X509Certificate, with: >> > >> > public abstract Date getNotAfter(); >> > >> > This is a public abstract method in a public abstract class. This means >> > that remediating this use is even more difficult. We can add a default >> > method that returns LocalDate that converts from Date, and then update >> > existing implementations to swap what they view their canonical >> > representation as, but there's still going to be an abstract method >> > returning Date, that new implementations will be confronted with. So it >> > will be pretty weird to have an abstract method in a public abstract >> > class / interface that returns a deprecated type. >> > >> > And, after all this, I still don't see a path to removing it in the next >> > 10 years. So this seems like a lot of contortion and rewriting and >> > putting users in confusion positions for mostly symbolic benefit. >> > >> > > The negative impact is expected to be very small. Popular products >> like >> > > Spring and Jakarta either already moved on and provided java.time.* >> > > alternatives to their APIs or could do that quickly and easily. Anyone >> > who >> > > is left behind, would only get some [deserved] deprecation warnings. >> > >> > As I hope you now see, you're ignoring a whole category of >> > not-at-all-small impact. >> > >> > >> > On 5/7/2022 10:36 PM, Victor Williams Stafusa da Silva wrote: >> > > The java.time package was released in Java 8, far back in 2014, more >> > than 8 >> > > years ago. It has been a long time since then. Before that, we had the >> > > dreadful infamous java.util.Date, java.util.Calendar, >> > > java.text.DateFormat and their subclasses java.sql.Date, >> java.sql.Time, >> > > java.sql.Timestamp, java.util.GregorianCalendar, >> > java.text.SimpleDateFormat >> > > and a few other lesser-known obscure cases. >> > > >> > > There are plenty of reasons to avoid using Date, Calendar, DateFormat >> and >> > > their subclasses, otherwise there would be few to no reasons for >> > java.time >> > > to be conceived. >> > > >> > > Applications and libraries which used or relied on those legacy >> classes >> > > already had plenty of time to move on and provide java.time.* >> > alternatives. >> > > >> > > No skilled java programmer uses the legacy classes in new applications >> > > except when integrating with legacy APIs. >> > > >> > > Using those classes nowadays should be considered at least a bad >> > > programming practice, if not something worse (source of bugs, security >> > > issues, etc). >> > > >> > > Novices, unskilled, careless and lazy programmers who should know >> better >> > > still happily continue to use the legacy classes, pissing off those >> who >> > are >> > > more enlightened. >> > > >> > > So, my proposal is pretty simple: It is time to put a @Deprecated in >> all >> > of >> > > those (not for removal, though). >> > > >> > > First, let's deprecate all of them. Second, any method in the JDK >> > returning >> > > or receiving any of those as a parameter should be equally >> deprecated. If >> > > there is no replacement method using the relevant classes or >> interfaces >> > in >> > > the java.time package, one should be created (which is something >> probably >> > > pretty straightforward). >> > > >> > > If any of those methods is abstract or is part of an interface, then >> we >> > > have a small problem, and it should be solved on a case-by-case >> analysis, >> > > preferentially by providing a default implementation. I'm sure that >> some >> > > cases should still exist, but I doubt that any of them would be a >> > > showstopper. >> > > >> > > The negative impact is expected to be very small. Popular products >> like >> > > Spring and Jakarta either already moved on and provided java.time.* >> > > alternatives to their APIs or could do that quickly and easily. Anyone >> > who >> > > is left behind, would only get some [deserved] deprecation warnings. >> > > >> > > On the positive impact side, more than just discouraging the usage of >> the >> > > ugly and annoying API of Date, Calendar and DateFormat for people who >> > > should know better, those classes are a frequent source of bugs that >> are >> > > hard do track and to debug due to their mutability and thread >> unsafety. >> > > Thus, we are already way past the time to make the compiler give a >> > warning >> > > to anyone still using them. >> > > >> > > What do you think? >> > >> > From ron.pressler at oracle.com Tue May 10 09:40:00 2022 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 10 May 2022 09:40:00 +0000 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: <1F608F8D-CA3C-471F-8B81-CC77D9964833@oracle.com> I think the issue is that "deprecated" means different things to different people, and, to be fair, its meaning has shifted over the years. For some developers it means "strongly unrecommended; do not use in new code." But for the JDK developers it means, "dangerous to leave in; remove even from old code". We now deprecate things: 1. whose use is so egregious that it can reasonably be treated as an error (and many people treat compiler warnings as errors), and/or 2. that could reasonably be removed at some point in the future. Date doesn't satisfy either one of these conditions. So to "strongly unrecommend" Date in some mechanical way would probably require a new kind of annotation that means what the first group I mentioned means, and possibly a new kind of compiler warning that shouldn't be treated as an error. ? Ron > On 8 May 2022, at 03:36, Victor Williams Stafusa da Silva wrote: > > The java.time package was released in Java 8, far back in 2014, more than 8 > years ago. It has been a long time since then. Before that, we had the > dreadful infamous java.util.Date, java.util.Calendar, > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat > and a few other lesser-known obscure cases. > > There are plenty of reasons to avoid using Date, Calendar, DateFormat and > their subclasses, otherwise there would be few to no reasons for java.time > to be conceived. > > Applications and libraries which used or relied on those legacy classes > already had plenty of time to move on and provide java.time.* alternatives. > > No skilled java programmer uses the legacy classes in new applications > except when integrating with legacy APIs. > > Using those classes nowadays should be considered at least a bad > programming practice, if not something worse (source of bugs, security > issues, etc). > > Novices, unskilled, careless and lazy programmers who should know better > still happily continue to use the legacy classes, pissing off those who are > more enlightened. > > So, my proposal is pretty simple: It is time to put a @Deprecated in all of > those (not for removal, though). > > First, let's deprecate all of them. Second, any method in the JDK returning > or receiving any of those as a parameter should be equally deprecated. If > there is no replacement method using the relevant classes or interfaces in > the java.time package, one should be created (which is something probably > pretty straightforward). > > If any of those methods is abstract or is part of an interface, then we > have a small problem, and it should be solved on a case-by-case analysis, > preferentially by providing a default implementation. I'm sure that some > cases should still exist, but I doubt that any of them would be a > showstopper. > > The negative impact is expected to be very small. Popular products like > Spring and Jakarta either already moved on and provided java.time.* > alternatives to their APIs or could do that quickly and easily. Anyone who > is left behind, would only get some [deserved] deprecation warnings. > > On the positive impact side, more than just discouraging the usage of the > ugly and annoying API of Date, Calendar and DateFormat for people who > should know better, those classes are a frequent source of bugs that are > hard do track and to debug due to their mutability and thread unsafety. > Thus, we are already way past the time to make the compiler give a warning > to anyone still using them. > > What do you think? From scolebourne at joda.org Tue May 10 10:11:53 2022 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 10 May 2022 11:11:53 +0100 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: I think this is a great list of places that could be changed in the JDK. I think the problems we have are: 1) there is no alternative in certain cases for those who wish to completely avoid the old classes 2) the JDK gives @Deprecated an unusually strong interpretation 3) it is a lot of work to systematically go through and address all the cases in the list below (and there are higher priority tasks) The net result is that there is no complete migration path off the old classes, even in the far future. I would personally like to see suitable overloads in java.util.concurrent and TimerTask prioritised, but I don't have the spare time to work on them myself. thanks Stephen On Tue, 10 May 2022 at 04:03, Victor Williams Stafusa da Silva wrote: > > Well, I tried to track every case in the public API of the JDK individually > and analyze each of them, one by one. > > TL;DR - If you are concerned only with the harder cases (like Brian Goetz > pointed out), skip directly to items 11, 12 and 13 below. > > [1] First, those cases below should be fairly easy, just overload the > methods and constructors with versions taking java.time.Instant instead of > the legacy classes: > > - java.security.Timestamp(Date, CertPath) > - java.security.cert.CertificateRevokedException(Date, other parameters) > - java.util.Timer.schedule(TimerTask, Date) > - java.util.Timer.schedule(TimerTask, Date, long) > - java.util.Timer.scheduleAtFixedRate(TimerTask, Date, long) > - > java.util.concurrent.locks.AbstractQueuedLongSynchronizer.ConditionObject.awaitUntil(Date) > - > java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject.awaitUntil(Date) > - java.util.concurrent.locks.Condition.awaitUntil(Date) > - javax.management.timer.Timer.addNotification(many overload versions) > - javax.management.timer.TimerMBean.addNotification(many overload versions) > - javax.print.attribute.DateTimeSyntax(Date) > - javax.print.attribute.DateTimeAtCompleted(Date) > - javax.print.attribute.DateTimeAtCreation(Date) > - javax.print.attribute.DateTimeAtProcessing(Date) > - javax.print.attribute.JobHoldUntil(Date) > - javax.security.auth.kerberos.KerberosTicket(a lot of parameters) > - javax.swing.RowFilter.dateFilter(ComparisonType, Date, int...) > - javax.swing.SpinnerDateModel(Date, Comparable, Comparable, > int) > - javax.xml.datatype.Duration.addTo(Date) > - javax.xml.datatype.Duration.getTimeInMillis(Date) > - javax.xml.datatype.Duration.getTimeInMillis(Calendar) > > [2] Those are the methods that return java.util.Date. Maybe in some cases > the best name was really be already taken, but they are still easy to solve: > > - java.security.KeyStoreSpi.getCreationDate(String) - Add a > getCreationInstant(String) method. > - java.security.Timestamp.getTimestamp() - Add a getInstant() method. > - java.security.cert.CertificateRevokedException.getInvalidityDate() - Add > a getInvalidityInstant() method. > - java.security.cert.CertificateRevokedException.getRevocationDate() - Add > a getRevocationInstant() method. > - javax.management.timer.Timer.getDate(Integer) - Add a getInstant(Integer) > method. > - javax.management.timer.TimerMBean.getDate(Integer) - Add a > getInstant(Integer) method. > - javax.print.attribute.DateTimeSyntax.getValue() - Add a getInstant() > method. > - javax.security.auth.kerberos.KerberosTicket.getAuthTime() - Add a > getAuthInstant() method. > - javax.security.auth.kerberos.KerberosTicket.getEndTime() - Add a > getEndInstant() method. > - javax.security.auth.kerberos.KerberosTicket.getStartTime() - Add a > getStartInstant() method. > - javax.security.auth.kerberos.KerberosTicket.getRenewTill() - Add a > getLatestExpiration() method. > - javax.swing.SpinnerDateModel.getDate() - Add a getInstant() method. > > [3] Those are getter and setter pairs of java.util.Date (or something with > Date within its generics): > > - java.security.cert.PKIXParameters.getDate() and setDate(Date) - Add a > getValidity() and setValidity(Instant) methods. > - java.security.cert.X509CRLSelector.getDateAndTime() and > setDateAndTime(Date) - Add differently named methods. > - javax.swing.SpinnerDateModel.getStart() and setStart(Comparable) - > Add getStartInstant() and setStartInstant(Comparable). > - javax.swing.SpinnerDateModel.getEnd() and setEnd(Comparable) - Add > getStartInstant() and setEndInstant(Comparable). > > For them, setting the Instant would also set the Date and vice-versa. > Granted, the best names were already taken, but this isn't a big deal and > definitely not a reason for keeping using java.util.Date. > > [4] There are other few special easy cases: > > - Field javax.management.openmbean.SimpleType.DATE - Just provide > SimpleType.INSTANT, SimpleType.LOCAL_DATE, SimpleType.LOCAL_DATE_TIME, etc. > - Package javax.security.cert (not to be confused with java.security.cert) > - Deprecated for removal. It is time for it to go. > > [5] Getting into the SQL realm, the classes java.sql.CallableStatement, > java.sql.PreparedStatement, java.sql.ResultSet, javax.sql.RowSet and > javax.sql.rowset.BaseRowSet feature the following methods: > > - getDate(int) > - getDate(String) > - setDate(int, java.sql.Date) > - setDate(String, java.sql.Date) > - getTime(int) > - getTime(String) > - setTime(int, java.sql.Time) > - setTime(String, java.sql.Time) > - getTimestamp(int) > - getTimestamp(String) > - setTimestamp(int, java.sql.Timestamp) > - setTimestamp(String, java.sql.Timestamp) > > Those are mostly straightforward. Just add methods taking or returning > java.time.LocalDate instead of java.sql.Date, java.time.LocalTime instead > of java.sql.Time and java.time.LocalDateTime instead of java.sql.Timestamp. > > Also, it is tempting to create alternatives for other classes within > java.time package, like Instant, OffsetDateTime, ZonedDateTime or > ChronoLocalDate, if possible. > > [6] The java.sql.SQLInput, java.sql.SQLOutput, > javax.sql.rowset.serial.SQLInputImpl and > javax.sql.rowset.serial.SQLOutputImpl also features those methods: > > - readDate() > - readTime() > - readTimestamp() > - writeDate(java.sql.Date) > - writeTime(java.sql.Time) > - writeTimestamp(java.sql.Timestamp) > > The solution would be the same as in [5]. > > [7] All the methods listed in [5] also have an overload taking a > java.util.Calendar parameter, which is used for time zone information as > far as I can tell. I am not really sure of what to do with them, but I'm > pretty sure that it should not be something complicated. Without looking > deep in the issue, maybe adding a version which uses java.time.ZoneId > instead of java.util.Calendar is enough. But maybe ZonedDateTime and > OffsetDateTime come to play here. > > [8] Those methods: > > - java.text.spi.DateFormatProvider.getDateInstance(int, Locale) > - java.text.spi.DateFormatProvider.getDateTimeInstance(int, int, Locale) > - java.text.spi.DateFormatProvider.getTimeInstance(int, Locale) > > We just overload them with versions returning > java.time.format.DateTimeFormatter and taking enums instead of ints. > > [9] Those: > > - javax.swing.text.DateFormatter(DateFormat) > - javax.swing.text.DateFormatter.setFormat(DateFormat) > > Just overload them with java.time.format.DateTimeFormatter. > > [10] This method: > > - javax.swing.JSpinner.DateEditor.getFormat() > > Just add a getFormatter() method returning a > java.time.format.DateTimeFormatter. > > [11] There are those pair of getters and setters: > > - java.security.cert.X509CRLSelector.getCertificateValid() and > setCertificateValid(Date) > - java.security.cert.X509CertSelector.getPrivateKeyValid() and > setPrivateKeyValid(Date) > > Adding just differently named methods is ok and simple enough, although > their names could be a bit cumbersome. However, the X509CRLSelector and > X509CertSelector classes suffer from the same problem that SimpleDateFormat > suffers. Users might think that sharing them between threads without > locking as long as no setters are called is safe, a presumption that is > false as stated in the javadocs. A better alternative, but way off of the > scope of this thread, would be to provide immutable alternative for those > classes. > > [12] Now, let's see the problematic case pointed out by Brian Goetz, since > those are abstract methods: > > - java.security.cert.X509CRL.getNextUpdate() > - java.security.cert.X509CRL.getThisUpdate() > - java.security.cert.X509CRLEntry.getRevocationDate() > - java.security.cert.X509Certificate.getNotAfter() > - java.security.cert.X509Certificate.getNotBefore() > > The X509CRL, X509CRLEntry and X509Certificate classes should really been > interfaces. Anyway, users aren't expected to be directly extending those > classes and none of them have public subclasses. Instead, users should rely > on java.security.cert.CertificateFactory class to get instances of these. > Hence, adding Instant returning methods should not have be a big problem > for 99% of the expected use cases. It is also noteworthy that the > X509Certificate class feature the deprecated abstract getIssuerDN() method, > so this won't be the first time that it runs to a similar design problem. > > [13] And to close it up, there are those abstract methods also: > > - javax.xml.datatype.Duration.addTo(Calendar) > - javax.xml.datatype.Duration.normalizeWith(Calendar) > - > javax.xml.datatype.DatatypeFactory.newXMLGregorianCalendar(GregorianCalendar) > - javax.xml.datatype.DatatypeFactory.getTimeZone(int) > - javax.xml.datatype.XMLGregorianCalendar.toGregorianCalendar() > - javax.xml.datatype.XMLGregorianCalendar.toGregorianCalendar(TimeZone, > Locale, XMLGregorianCalendar) > > XMLGregorianCalendar is tightly coupled with GregorianCalendar (not > unexpected considering the class name). But, since users are expected to > get instances of Duration and XMLGregorianCalendar only through the > DatatypeFactory which in turn should only be instantiated through its > static factory methods, this means that only JAXP implementors are expected > to be directly extending those classes and 99% of the use cases are ok. > > Further, these classes really deserved to be better bridged to java.time > classes. > > [FINISH] And, as far as I can tell, those are all the places which should > be changed. > > The following classes would be then be deprecated: java.sql.Date, > java.sql.Time, java.sql.Timestamp, java.text.DateFormat, > java.text.SimpleDateFormat, java.util.Date, java.util.Calendar, > java.util.GregorianCalendar, java.util.TimeZone, java.util.SimpleTimeZone. > > The package javax.security.cert removed (not to be confused with > java.security.cert). > > Also, even if you decide that java.util.Date, java.util.Calendar and > java.util.GregorianCalendar should not be deprecated, the refactorings > listed above seem to be very worth to perform anyway. Maybe deprecating > only some of them (like java.sql.Date, java.sql.Time and > java.sql.Timestamp) is a good start. > > Finally, I don't think that just because that are a few abstract methods in > the deep guts of the JDK which few programmers use directly and because the > best possible name method were taken over in roughly those same deep guts > classes that this is a sufficient justification to stop deprecating these > horrible classes. > > Em seg., 9 de mai. de 2022 ?s 18:39, Ethan McCue escreveu: > > > > code checkers, possibly built-in > > > > Maybe instead of tackling Date specifically lets ask "What would it look > > like for the JDK to have a built-in fully featured linter." > > > > The capabilities provided by javac's lints like -Xlint:deprecation are a > > subset of the capabilities of a more fully featured linter like SonarCube. > > There is no reason SonarCube's bottom line should be any of our concern, so > > there isn't any conceptual reason the JDK couldn't include something akin > > to clippy - "jlint"? - and have that be the place to really flesh out how > > tooling should communicate the nuance / "best practices" around older apis. > > > > > > > > On Mon, May 9, 2022 at 4:15 PM Peter Lawrey > > wrote: > > > >> Hi, > >> The only way forward is to have code checkers, possibly built-in, to > >> suggest alternatives. > >> Getting novices to use them is also a challenge. > >> > >> BTW This is an example of how hard it is to kill poor code. At one point, > >> I > >> edited a few hundred copies of this block of code on StackOverflow, but > >> below is an example from 2022. > >> I assume the original author used DataInputStream.readLine() before > >> realising he should use BufferedReader. I found an example from 2002, > >> possibly the original. > >> > >> A google search suggested there are about 3k copies of this code around. > >> https://www.google.com/search?q=%22Get+the+object+of+DataInputStream%22 > >> > >> FileInputStream fstream = new FileInputStream("D:adresse.txt"); > >> // Get the object of DataInputStream > >> DataInputStream in = new DataInputStream(fstream); > >> BufferedReader br = new BufferedReader(new InputStreamReader(in)); > >> > >> Regards, > >> Peter. > >> > >> On Mon, 9 May 2022 at 20:44, Brian Goetz wrote: > >> > >> > The problem with such a proposal is that applications are not the only > >> > user of Date. Libraries -- including the JDK -- have baked Date into > >> > their APIs. > >> > > >> > A simple example is java.security.Timestamp::getTimestamp, which returns > >> > a Date. This one is easier because it is a final class, and could > >> > acquire a getTimestampAsLocalDate method, and deprecate getTimestamp. > >> > But even this gives a hint of the pain users are in for; the good name > >> > is taken, and since we don't overload on return types, we'd have to pick > >> > a lesser name. And users would forever be confronted with the choice of > >> > the less desirable but better-named getTimestamp, and the more desirable > >> > but worse-named getTimestampAsLocalDate. > >> > > >> > A more difficult example is java.security.cert.X509Certificate, with: > >> > > >> > public abstract Date getNotAfter(); > >> > > >> > This is a public abstract method in a public abstract class. This means > >> > that remediating this use is even more difficult. We can add a default > >> > method that returns LocalDate that converts from Date, and then update > >> > existing implementations to swap what they view their canonical > >> > representation as, but there's still going to be an abstract method > >> > returning Date, that new implementations will be confronted with. So it > >> > will be pretty weird to have an abstract method in a public abstract > >> > class / interface that returns a deprecated type. > >> > > >> > And, after all this, I still don't see a path to removing it in the next > >> > 10 years. So this seems like a lot of contortion and rewriting and > >> > putting users in confusion positions for mostly symbolic benefit. > >> > > >> > > The negative impact is expected to be very small. Popular products > >> like > >> > > Spring and Jakarta either already moved on and provided java.time.* > >> > > alternatives to their APIs or could do that quickly and easily. Anyone > >> > who > >> > > is left behind, would only get some [deserved] deprecation warnings. > >> > > >> > As I hope you now see, you're ignoring a whole category of > >> > not-at-all-small impact. > >> > > >> > > >> > On 5/7/2022 10:36 PM, Victor Williams Stafusa da Silva wrote: > >> > > The java.time package was released in Java 8, far back in 2014, more > >> > than 8 > >> > > years ago. It has been a long time since then. Before that, we had the > >> > > dreadful infamous java.util.Date, java.util.Calendar, > >> > > java.text.DateFormat and their subclasses java.sql.Date, > >> java.sql.Time, > >> > > java.sql.Timestamp, java.util.GregorianCalendar, > >> > java.text.SimpleDateFormat > >> > > and a few other lesser-known obscure cases. > >> > > > >> > > There are plenty of reasons to avoid using Date, Calendar, DateFormat > >> and > >> > > their subclasses, otherwise there would be few to no reasons for > >> > java.time > >> > > to be conceived. > >> > > > >> > > Applications and libraries which used or relied on those legacy > >> classes > >> > > already had plenty of time to move on and provide java.time.* > >> > alternatives. > >> > > > >> > > No skilled java programmer uses the legacy classes in new applications > >> > > except when integrating with legacy APIs. > >> > > > >> > > Using those classes nowadays should be considered at least a bad > >> > > programming practice, if not something worse (source of bugs, security > >> > > issues, etc). > >> > > > >> > > Novices, unskilled, careless and lazy programmers who should know > >> better > >> > > still happily continue to use the legacy classes, pissing off those > >> who > >> > are > >> > > more enlightened. > >> > > > >> > > So, my proposal is pretty simple: It is time to put a @Deprecated in > >> all > >> > of > >> > > those (not for removal, though). > >> > > > >> > > First, let's deprecate all of them. Second, any method in the JDK > >> > returning > >> > > or receiving any of those as a parameter should be equally > >> deprecated. If > >> > > there is no replacement method using the relevant classes or > >> interfaces > >> > in > >> > > the java.time package, one should be created (which is something > >> probably > >> > > pretty straightforward). > >> > > > >> > > If any of those methods is abstract or is part of an interface, then > >> we > >> > > have a small problem, and it should be solved on a case-by-case > >> analysis, > >> > > preferentially by providing a default implementation. I'm sure that > >> some > >> > > cases should still exist, but I doubt that any of them would be a > >> > > showstopper. > >> > > > >> > > The negative impact is expected to be very small. Popular products > >> like > >> > > Spring and Jakarta either already moved on and provided java.time.* > >> > > alternatives to their APIs or could do that quickly and easily. Anyone > >> > who > >> > > is left behind, would only get some [deserved] deprecation warnings. > >> > > > >> > > On the positive impact side, more than just discouraging the usage of > >> the > >> > > ugly and annoying API of Date, Calendar and DateFormat for people who > >> > > should know better, those classes are a frequent source of bugs that > >> are > >> > > hard do track and to debug due to their mutability and thread > >> unsafety. > >> > > Thus, we are already way past the time to make the compiler give a > >> > warning > >> > > to anyone still using them. > >> > > > >> > > What do you think? > >> > > >> > > From stuart.marks at oracle.com Tue May 10 19:01:32 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 10 May 2022 12:01:32 -0700 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: References: Message-ID: <426fe814-13ff-b642-52fb-896dc7a33200@oracle.com> You're definitely on to something in that java.util.Date is obsolete, or obsolescent, and perhaps conceptually at least it should be deprecated. If I were reviewing some code that used Date I'd certainly flag the issue. The main difficulty is that its usage is entrenched in implementation code, but more importantly, in APIs. In another message you listed several dozen places in the JDK that use Date and related APIs. It would be certain amount of work to introduce replacements that use newer APIs and to suppress the warnings resulting from the existing APIs. This is a bunch of work, but it's not intractable. However, the benefits aren't very high, and so the priority is low. That's just the JDK. What also needs to be considered is the amount of code out there that *uses* these APIs. Most of the usages are in legacy code, which people are unlikely to want to spend a large effort on migrating. In addition, Date and friends are used in third party library *APIs*, which have their own users. There's a lot of this code. There are a few possible responses maintainers of this code can take when new deprecations appear. - Ignoring them. OK, if people ignore deprecation, then it doesn't really matter what we do. - Disable deprecation warnings. If people had warnings enabled, they presumably found value in having those warnings. Mostly this is useful for preventing new code from using deprecated APIs. If a lot of many not-very-useful warnings suddenly appear, people might disable warnings entirely, and thus miss the warnings they'd actually find useful. This defeats the purpose of having the warnings. - Migrate code to use other APIs. Some people will do this, if they're in a position to do so. Maintainers of legacy code generally are not able to do this. Library maintainers are also often not in a position to do this, as they have their own compatibility concerns. - Suppress warnings at the call sites using @SuppressWarnings. This is probably the most common alternative to code migration. This isn't a terrible option, but it's tedious, low-value work, and people don't like being forced to do work that isn't providing value to them. This last point may be more significant than you think. When I deprecated java.util.Observer/Observable in Java 9, there was very little usage of these classes; yet I received a bunch of complaints from people having to deal with the warnings. Date and related classes have several orders of magnitude more usage. The number of warnings generated will be huge, and the effort required to deal with them will be tremendous. By the way, all this also applies to other obsolescent but widely used classes such as Vector, Hashtable, LinkedList, URL, etc. So if warnings are a problem, then maybe we should do something about that? That's a possibility. Some better form of @SuppressWarnings might be helpful. More flexible control over what warnings javac emits might be useful too. (Somebody will inevitably suggest a different annotation that doesn't generate warnings. That would be incorrect, because the policy of how to handle usage of deprecated APIs, and whether warnings should be emitted, should be in the hands of the maintainers of the code that uses those APIs, not the API designers.) s'marks On 5/7/22 7:36 PM, Victor Williams Stafusa da Silva wrote: > The java.time package was released in Java 8, far back in 2014, more than 8 > years ago. It has been a long time since then. Before that, we had the > dreadful infamous java.util.Date, java.util.Calendar, > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat > and a few other lesser-known obscure cases. > > There are plenty of reasons to avoid using Date, Calendar, DateFormat and > their subclasses, otherwise there would be few to no reasons for java.time > to be conceived. > > Applications and libraries which used or relied on those legacy classes > already had plenty of time to move on and provide java.time.* alternatives. > > No skilled java programmer uses the legacy classes in new applications > except when integrating with legacy APIs. > > Using those classes nowadays should be considered at least a bad > programming practice, if not something worse (source of bugs, security > issues, etc). > > Novices, unskilled, careless and lazy programmers who should know better > still happily continue to use the legacy classes, pissing off those who are > more enlightened. > > So, my proposal is pretty simple: It is time to put a @Deprecated in all of > those (not for removal, though). > > First, let's deprecate all of them. Second, any method in the JDK returning > or receiving any of those as a parameter should be equally deprecated. If > there is no replacement method using the relevant classes or interfaces in > the java.time package, one should be created (which is something probably > pretty straightforward). > > If any of those methods is abstract or is part of an interface, then we > have a small problem, and it should be solved on a case-by-case analysis, > preferentially by providing a default implementation. I'm sure that some > cases should still exist, but I doubt that any of them would be a > showstopper. > > The negative impact is expected to be very small. Popular products like > Spring and Jakarta either already moved on and provided java.time.* > alternatives to their APIs or could do that quickly and easily. Anyone who > is left behind, would only get some [deserved] deprecation warnings. > > On the positive impact side, more than just discouraging the usage of the > ugly and annoying API of Date, Calendar and DateFormat for people who > should know better, those classes are a frequent source of bugs that are > hard do track and to debug due to their mutability and thread unsafety. > Thus, we are already way past the time to make the compiler give a warning > to anyone still using them. > > What do you think? > From victorwssilva at gmail.com Tue May 10 20:03:58 2022 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Tue, 10 May 2022 17:03:58 -0300 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: <426fe814-13ff-b642-52fb-896dc7a33200@oracle.com> References: <426fe814-13ff-b642-52fb-896dc7a33200@oracle.com> Message-ID: Well, getting up from what Stuart Marks and others said, there are some classes that are obsolescent, but can't be deprecated because this would force user to add @SuppressWarnings("deprecation") in a bunch of places or just ignore warnings. As Ron Pressler said, some other annotation could do the job. But how? Part of the problem is that @SuppressWarnings("deprecation") isn't selective about which deprecated things are allowed and which aren't. Other problem is that @Deprecated is taken very seriously and harshly. Every single usage of the deprecated class/method/whatever will be flagged in a different warning. First, we could add @Discouraged for classes and interfaces that are discouraged, but the compiler should not warn about them too harshly as it does about @Deprecated. Then, a class, method, constructor, package or module could then be annotated with @ExportsDiscouraged({Date.class, Calendar.class}) and @UsesDiscouraged({StringBuffer.class, Vector.class}) to tell the compiler that the usage of the discouraged classes in the annotated class, method, constructor, package or module is ok. If the compiler sees any usage of the discouraged element which was not declared in the @ExportsDiscouraged or @UsesDiscouraged annotation or any discouraged element declared in the public API that is not declared in the @ExportsDiscouraged, it prints a message only once. Not much different than the actual "Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output" message. Something like "Note: Some discouraged elements were used; recompile with -Xlint:discouraged to get full output". If it is recompiled with the "-Xlint:discouraged", it will show which discouraged classes or interfaces not allowed with @ExportsDiscouraged or @UsesDiscouraged were used. Since @ExportsDiscouraged or @UsesDiscouraged are annotations that take an array of class literals, there would be no mechanism for discouraging fields, methods, constructors, packages or modules. Only classes and interfaces could be discouraged. Further, @Discouraged would be silently ignored if the annotated element also features @Deprecated. Non-discouraged classes/interfaces used in the values of @ExportsDiscouraged or @UsesDiscouraged would be silently ignored. Finally, adding array classes or primitives to @ExportsDiscouraged or @UsesDiscouraged would be a compiler error, so nobody would do @ExportsDiscouraged({int.class, void.class, String[].class}) Em ter., 10 de mai. de 2022 ?s 16:01, Stuart Marks escreveu: > You're definitely on to something in that java.util.Date is obsolete, or > obsolescent, and perhaps conceptually at least it should be deprecated. If > I were > reviewing some code that used Date I'd certainly flag the issue. The main > difficulty > is that its usage is entrenched in implementation code, but more > importantly, in APIs. > > In another message you listed several dozen places in the JDK that use > Date and > related APIs. It would be certain amount of work to introduce replacements > that use > newer APIs and to suppress the warnings resulting from the existing APIs. > This is a > bunch of work, but it's not intractable. However, the benefits aren't very > high, and > so the priority is low. > > That's just the JDK. What also needs to be considered is the amount of > code out > there that *uses* these APIs. Most of the usages are in legacy code, which > people > are unlikely to want to spend a large effort on migrating. In addition, > Date and > friends are used in third party library *APIs*, which have their own > users. There's > a lot of this code. > > There are a few possible responses maintainers of this code can take when > new > deprecations appear. > > - Ignoring them. OK, if people ignore deprecation, then it doesn't > really matter > what we do. > > - Disable deprecation warnings. If people had warnings enabled, they > presumably > found value in having those warnings. Mostly this is useful for preventing > new code > from using deprecated APIs. If a lot of many not-very-useful warnings > suddenly > appear, people might disable warnings entirely, and thus miss the warnings > they'd > actually find useful. This defeats the purpose of having the warnings. > > - Migrate code to use other APIs. Some people will do this, if they're > in a > position to do so. Maintainers of legacy code generally are not able to do > this. > Library maintainers are also often not in a position to do this, as they > have their > own compatibility concerns. > > - Suppress warnings at the call sites using @SuppressWarnings. This is > probably > the most common alternative to code migration. This isn't a terrible > option, but > it's tedious, low-value work, and people don't like being forced to do > work that > isn't providing value to them. > > This last point may be more significant than you think. When I deprecated > java.util.Observer/Observable in Java 9, there was very little usage of > these > classes; yet I received a bunch of complaints from people having to deal > with the > warnings. Date and related classes have several orders of magnitude more > usage. The > number of warnings generated will be huge, and the effort required to deal > with them > will be tremendous. > > By the way, all this also applies to other obsolescent but widely used > classes such > as Vector, Hashtable, LinkedList, URL, etc. > > So if warnings are a problem, then maybe we should do something about > that? That's a > possibility. Some better form of @SuppressWarnings might be helpful. More > flexible > control over what warnings javac emits might be useful too. > > (Somebody will inevitably suggest a different annotation that doesn't > generate > warnings. That would be incorrect, because the policy of how to handle > usage of > deprecated APIs, and whether warnings should be emitted, should be in the > hands of > the maintainers of the code that uses those APIs, not the API designers.) > > s'marks > > > > On 5/7/22 7:36 PM, Victor Williams Stafusa da Silva wrote: > > The java.time package was released in Java 8, far back in 2014, more > than 8 > > years ago. It has been a long time since then. Before that, we had the > > dreadful infamous java.util.Date, java.util.Calendar, > > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > > java.sql.Timestamp, java.util.GregorianCalendar, > java.text.SimpleDateFormat > > and a few other lesser-known obscure cases. > > > > There are plenty of reasons to avoid using Date, Calendar, DateFormat and > > their subclasses, otherwise there would be few to no reasons for > java.time > > to be conceived. > > > > Applications and libraries which used or relied on those legacy classes > > already had plenty of time to move on and provide java.time.* > alternatives. > > > > No skilled java programmer uses the legacy classes in new applications > > except when integrating with legacy APIs. > > > > Using those classes nowadays should be considered at least a bad > > programming practice, if not something worse (source of bugs, security > > issues, etc). > > > > Novices, unskilled, careless and lazy programmers who should know better > > still happily continue to use the legacy classes, pissing off those who > are > > more enlightened. > > > > So, my proposal is pretty simple: It is time to put a @Deprecated in all > of > > those (not for removal, though). > > > > First, let's deprecate all of them. Second, any method in the JDK > returning > > or receiving any of those as a parameter should be equally deprecated. If > > there is no replacement method using the relevant classes or interfaces > in > > the java.time package, one should be created (which is something probably > > pretty straightforward). > > > > If any of those methods is abstract or is part of an interface, then we > > have a small problem, and it should be solved on a case-by-case analysis, > > preferentially by providing a default implementation. I'm sure that some > > cases should still exist, but I doubt that any of them would be a > > showstopper. > > > > The negative impact is expected to be very small. Popular products like > > Spring and Jakarta either already moved on and provided java.time.* > > alternatives to their APIs or could do that quickly and easily. Anyone > who > > is left behind, would only get some [deserved] deprecation warnings. > > > > On the positive impact side, more than just discouraging the usage of the > > ugly and annoying API of Date, Calendar and DateFormat for people who > > should know better, those classes are a frequent source of bugs that are > > hard do track and to debug due to their mutability and thread unsafety. > > Thus, we are already way past the time to make the compiler give a > warning > > to anyone still using them. > > > > What do you think? > > > From fgunbin at fastmail.fm Wed May 11 11:06:07 2022 From: fgunbin at fastmail.fm (Filipp Gunbin) Date: Wed, 11 May 2022 14:06:07 +0300 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: (Victor Williams Stafusa da Silva's message of "Sat, 7 May 2022 23:36:27 -0300") References: Message-ID: On 07/05/2022 23:36 -0300, Victor Williams Stafusa da Silva wrote: > On the positive impact side, more than just discouraging the usage of the > ugly and annoying API of Date, Calendar and DateFormat for people who > should know better, those classes are a frequent source of bugs that are > hard do track and to debug due to their mutability and thread unsafety. The old APIs are still useful when all you need is i) to have a timestamp, ii) to convert it to calendrical information. They are much more compact than java.time. If you know how to use them right (= read the javadocs), then they're fine. I don't mean that new programmers should not use java.time, of course they should. I'd just rather use less strong words about the elder ones (the APIs :-)... From mark.reinhold at oracle.com Thu May 12 15:18:10 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 May 2022 08:18:10 -0700 Subject: Proposal: openjdk.java.net =?utf-8?Q?=E2=9E=9C?= openjdk.org Message-ID: <20220512081810.778733553@eggemoggin.niobe.net> Since the dawn of time [1] the OpenJDK Community?s web, e-mail, wiki, issue tracking, and (Mercurial) source-code infrastructure has been hosted under the third-level domain name ?openjdk.java.net?. That name has served us well for fifteen years, but it has also been a constant source of confusion. The second-level domain name ?java.net? originally pointed to an unrelated source-code forge site [2], which was perplexing. That forge was shut down in 2017, so now the ?java.net? name is perplexing in a different way. Above and beyond that, however, since the OpenJDK Community was founded many other open-source communities have placed their infrastructure under the ?.org? top-level domain name. This makes for easy discoverability. It also serves as both a reminder and a promise that the operation of the community is not meant to be dominated by any single corporate entity. I therefore propose that we rename openjdk.java.net to openjdk.org and make corresponding changes to the names of all active subdomains (i.e., bugs, cr, db, git, hg, mail, and wiki). If we proceed with this then Oracle?s infrastructure team will ensure that the old names act as aliases for the new names, so as not to break existing URLs or e-mail addresses. Comments? - Mark [1] https://mail.openjdk.java.net/pipermail/announce/2007-May/000000.html [2] https://en.wikipedia.org/wiki/Java.net From magnus.ihse.bursie at oracle.com Thu May 12 17:31:17 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 May 2022 19:31:17 +0200 Subject: =?UTF-8?Q?Re=3a_Proposal=3a_openjdk=2ejava=2enet_=e2=9e=9c_openjdk?= =?UTF-8?Q?=2eorg?= In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: On 2022-05-12 17:18, mark.reinhold at oracle.com wrote: > I therefore propose that we rename openjdk.java.net to openjdk.org and > make corresponding changes to the names of all active subdomains (i.e., > bugs, cr, db, git, hg, mail, and wiki). > > [...] > > Comments? As we say in Sweden: ?ntligen! [1] :-) This is a great move to get a proper home for the OpenJDK community on the Internet. (This has been eagerly awaited by the Skara project, since the Git commits have from the start been recorded as @openjdk.org.) /Magnus [1] Meaning ? "finally" From aph at redhat.com Thu May 12 17:55:04 2022 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 May 2022 18:55:04 +0100 Subject: =?UTF-8?Q?Re=3a_Proposal=3a_openjdk=2ejava=2enet_=e2=9e=9c_openjdk?= =?UTF-8?Q?=2eorg?= In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: On 5/12/22 16:18, mark.reinhold at oracle.com wrote: > I therefore propose that we rename openjdk.java.net to openjdk.org and > make corresponding changes to the names of all active subdomains (i.e., > bugs, cr, db, git, hg, mail, and wiki). > > If we proceed with this then Oracle?s infrastructure team will ensure > that the old names act as aliases for the new names, so as not to break > existing URLs or e-mail addresses. > > Comments? I'd definitely support that. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jesper.wilhelmsson at oracle.com Thu May 12 19:05:47 2022 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2022 19:05:47 +0000 Subject: =?utf-8?B?UmU6IFByb3Bvc2FsOiBvcGVuamRrLmphdmEubmV0IOKenCBvcGVuamRrLm9y?= =?utf-8?Q?g?= In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: <34DEFF09-46E2-48BB-B9AB-73D0903B9C47@oracle.com> > On 12 May 2022, at 17:18, mark.reinhold at oracle.com wrote: > > Since the dawn of time [1] the OpenJDK Community?s web, e-mail, wiki, > issue tracking, and (Mercurial) source-code infrastructure has been > hosted under the third-level domain name ?openjdk.java.net?. > > That name has served us well for fifteen years, but it has also been a > constant source of confusion. The second-level domain name ?java.net? > originally pointed to an unrelated source-code forge site [2], which was > perplexing. That forge was shut down in 2017, so now the ?java.net? name > is perplexing in a different way. > > Above and beyond that, however, since the OpenJDK Community was founded > many other open-source communities have placed their infrastructure under > the ?.org? top-level domain name. This makes for easy discoverability. > It also serves as both a reminder and a promise that the operation of the > community is not meant to be dominated by any single corporate entity. > > I therefore propose that we rename openjdk.java.net to openjdk.org and > make corresponding changes to the names of all active subdomains (i.e., > bugs, cr, db, git, hg, mail, and wiki). > > If we proceed with this then Oracle?s infrastructure team will ensure > that the old names act as aliases for the new names, so as not to break > existing URLs or e-mail addresses. > > Comments? This is a very good change! Thank you! /Jesper > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/announce/2007-May/000000.html > [2] https://en.wikipedia.org/wiki/Java.net From vladimir.kozlov at oracle.com Thu May 12 19:57:35 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 May 2022 12:57:35 -0700 Subject: =?UTF-8?Q?Re=3a_Proposal=3a_openjdk=2ejava=2enet_=e2=9e=9c_openjdk?= =?UTF-8?Q?=2eorg?= In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: <7fabdbe5-8b6e-4e97-88a5-b9aa048f669e@oracle.com> I support it. What about "jdk.java.net"? Thanks, Vladimir K On 5/12/22 8:18 AM, mark.reinhold at oracle.com wrote: > Since the dawn of time [1] the OpenJDK Community?s web, e-mail, wiki, > issue tracking, and (Mercurial) source-code infrastructure has been > hosted under the third-level domain name ?openjdk.java.net?. > > That name has served us well for fifteen years, but it has also been a > constant source of confusion. The second-level domain name ?java.net? > originally pointed to an unrelated source-code forge site [2], which was > perplexing. That forge was shut down in 2017, so now the ?java.net? name > is perplexing in a different way. > > Above and beyond that, however, since the OpenJDK Community was founded > many other open-source communities have placed their infrastructure under > the ?.org? top-level domain name. This makes for easy discoverability. > It also serves as both a reminder and a promise that the operation of the > community is not meant to be dominated by any single corporate entity. > > I therefore propose that we rename openjdk.java.net to openjdk.org and > make corresponding changes to the names of all active subdomains (i.e., > bugs, cr, db, git, hg, mail, and wiki). > > If we proceed with this then Oracle?s infrastructure team will ensure > that the old names act as aliases for the new names, so as not to break > existing URLs or e-mail addresses. > > Comments? > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/announce/2007-May/000000.html > [2] https://en.wikipedia.org/wiki/Java.net From mark.reinhold at oracle.com Thu May 12 20:03:26 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 May 2022 13:03:26 -0700 Subject: Proposal: openjdk.java.net =?utf-8?Q?=E2=9E=9C?= openjdk.org In-Reply-To: <7fabdbe5-8b6e-4e97-88a5-b9aa048f669e@oracle.com> References: <20220512081810.778733553@eggemoggin.niobe.net> <7fabdbe5-8b6e-4e97-88a5-b9aa048f669e@oracle.com> Message-ID: <20220512130326.180942694@eggemoggin.niobe.net> 2022/5/12 12:57:35 -0700, vladimir.kozlov at oracle.com: > I support it. > > What about "jdk.java.net"? There are no plans, at this time, to move jdk.java.net. - Mark From neugens.limasoftware at gmail.com Thu May 12 20:08:23 2022 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 12 May 2022 22:08:23 +0200 Subject: Proposal: openjdk.java.net =?utf-8?Q?=E2=9E=9C_?=openjdk.org In-Reply-To: <20220512130326.180942694@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> <7fabdbe5-8b6e-4e97-88a5-b9aa048f669e@oracle.com> <20220512130326.180942694@eggemoggin.niobe.net> Message-ID: Yes! That is the best thing since the last best thing ;) Cheers, Mario ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ > On Thursday, May 12, 2022 at 22:03, wrote: > 2022/5/12 12:57:35 -0700, vladimir.kozlov at oracle.com: > > I support it. > > > > What about "jdk.java.net"? > > There are no plans, at this time, to move jdk.java.net. > > - Mark From christoph.langer at sap.com Thu May 12 22:20:52 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 May 2022 22:20:52 +0000 Subject: =?utf-8?B?UkU6IFByb3Bvc2FsOiBvcGVuamRrLmphdmEubmV0IOKenCBvcGVuamRrLm9y?= =?utf-8?Q?g?= In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: Sounds great! Will it then also be possible to relay mails to @openjdk.org to our mailboxes? Cheers Christoph > -----Original Message----- > From: discuss On Behalf Of > mark.reinhold at oracle.com > Sent: Donnerstag, 12. Mai 2022 17:18 > To: discuss at openjdk.java.net > Subject: Proposal: openjdk.java.net ? openjdk.org > > Since the dawn of time [1] the OpenJDK Community?s web, e-mail, wiki, issue > tracking, and (Mercurial) source-code infrastructure has been hosted under the > third-level domain name ?openjdk.java.net?. > > That name has served us well for fifteen years, but it has also been a constant > source of confusion. The second-level domain name ?java.net? > originally pointed to an unrelated source-code forge site [2], which was > perplexing. That forge was shut down in 2017, so now the ?java.net? name is > perplexing in a different way. > > Above and beyond that, however, since the OpenJDK Community was founded > many other open-source communities have placed their infrastructure under > the ?.org? top-level domain name. This makes for easy discoverability. > It also serves as both a reminder and a promise that the operation of the > community is not meant to be dominated by any single corporate entity. > > I therefore propose that we rename openjdk.java.net to openjdk.org and make > corresponding changes to the names of all active subdomains (i.e., bugs, cr, db, > git, hg, mail, and wiki). > > If we proceed with this then Oracle?s infrastructure team will ensure that the > old names act as aliases for the new names, so as not to break existing URLs or > e-mail addresses. > > Comments? > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/announce/2007-May/000000.html > [2] > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikip > edia.org%2Fwiki%2FJava.net&data=05%7C01%7Cchristoph.langer%40sap. > com%7C165ead2addd645ba9f8a08da342abfee%7C42f7676cf455423c82f6dc2 > d99791af7%7C0%7C0%7C637879655458964563%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D%7C3000%7C%7C%7C&sdata=hz6U%2B8mq5Lew2UB98Q%2BbdhKs > 7n6YaGBW9igUe%2FCQjGY%3D&reserved=0 From john.r.rose at oracle.com Thu May 12 23:03:10 2022 From: john.r.rose at oracle.com (John Rose) Date: Thu, 12 May 2022 16:03:10 -0700 Subject: Proposal: openjdk.java.net =?utf-8?q?=E2=9E=9C?= openjdk.org In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: <69B22289-F7B0-4AD4-9926-586F51094F28@oracle.com> Yes, please! From simon at webmink.com Thu May 12 23:18:15 2022 From: simon at webmink.com (Simon Phipps) Date: Fri, 13 May 2022 00:18:15 +0100 Subject: =?UTF-8?Q?Re=3A_Proposal=3A_openjdk=2Ejava=2Enet_=E2=9E=9C_openjdk=2Eorg?= In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: Speaking as a relic from the dawn of time, that's a great suggestion that I wish we'd opted for at the dawn of time :-) S. On Thu, May 12, 2022 at 4:19 PM wrote: > Since the dawn of time [1] the OpenJDK Community?s web, e-mail, wiki, > issue tracking, and (Mercurial) source-code infrastructure has been > hosted under the third-level domain name ?openjdk.java.net?. > > That name has served us well for fifteen years, but it has also been a > constant source of confusion. The second-level domain name ?java.net? > originally pointed to an unrelated source-code forge site [2], which was > perplexing. That forge was shut down in 2017, so now the ?java.net? name > is perplexing in a different way. > > Above and beyond that, however, since the OpenJDK Community was founded > many other open-source communities have placed their infrastructure under > the ?.org? top-level domain name. This makes for easy discoverability. > It also serves as both a reminder and a promise that the operation of the > community is not meant to be dominated by any single corporate entity. > > I therefore propose that we rename openjdk.java.net to openjdk.org and > make corresponding changes to the names of all active subdomains (i.e., > bugs, cr, db, git, hg, mail, and wiki). > > If we proceed with this then Oracle?s infrastructure team will ensure > that the old names act as aliases for the new names, so as not to break > existing URLs or e-mail addresses. > > Comments? > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/announce/2007-May/000000.html > [2] https://en.wikipedia.org/wiki/Java.net > -- *Simon Phipps* *Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027 *Signal/Mobile*: +44 774 776 2816 From ethan at mccue.dev Thu May 12 23:42:32 2022 From: ethan at mccue.dev (Ethan McCue) Date: Thu, 12 May 2022 19:42:32 -0400 Subject: =?UTF-8?Q?Re=3A_Proposal=3A_openjdk=2Ejava=2Enet_=E2=9E=9C_openjdk=2Eorg?= In-Reply-To: References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: ?? On Thu, May 12, 2022, 7:19 PM Simon Phipps wrote: > Speaking as a relic from the dawn of time, that's a great suggestion that I > wish we'd opted for at the dawn of time :-) > > S. > > > On Thu, May 12, 2022 at 4:19 PM wrote: > > > Since the dawn of time [1] the OpenJDK Community?s web, e-mail, wiki, > > issue tracking, and (Mercurial) source-code infrastructure has been > > hosted under the third-level domain name ?openjdk.java.net?. > > > > That name has served us well for fifteen years, but it has also been a > > constant source of confusion. The second-level domain name ?java.net? > > originally pointed to an unrelated source-code forge site [2], which was > > perplexing. That forge was shut down in 2017, so now the ?java.net? > name > > is perplexing in a different way. > > > > Above and beyond that, however, since the OpenJDK Community was founded > > many other open-source communities have placed their infrastructure under > > the ?.org? top-level domain name. This makes for easy discoverability. > > It also serves as both a reminder and a promise that the operation of the > > community is not meant to be dominated by any single corporate entity. > > > > I therefore propose that we rename openjdk.java.net to openjdk.org and > > make corresponding changes to the names of all active subdomains (i.e., > > bugs, cr, db, git, hg, mail, and wiki). > > > > If we proceed with this then Oracle?s infrastructure team will ensure > > that the old names act as aliases for the new names, so as not to break > > existing URLs or e-mail addresses. > > > > Comments? > > > > - Mark > > > > > > [1] > https://mail.openjdk.java.net/pipermail/announce/2007-May/000000.html > > [2] https://en.wikipedia.org/wiki/Java.net > > > > > -- > *Simon Phipps* > *Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027 > *Signal/Mobile*: +44 774 776 2816 > From andvasp at gmail.com Fri May 13 02:17:19 2022 From: andvasp at gmail.com (Anderson Vasconcelos Pires) Date: Thu, 12 May 2022 23:17:19 -0300 Subject: Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses In-Reply-To: <426fe814-13ff-b642-52fb-896dc7a33200@oracle.com> References: <426fe814-13ff-b642-52fb-896dc7a33200@oracle.com> Message-ID: Ok... Is not beneficial to deprecate these classes but I believe should be considered the points mentioned by Stephen Colebourne in his email, specially the point 1 shown below not just because of the better code design but for performance reasons. I guess! :) 1) there is no alternative in certain cases for those who wish to completely avoid the old classes". If we can use the java.time classes directly, it is better for performance reasons than creating an intermediate instance of the obsolete classes to get the desired class, right? Imagine the situation where we have to read a lot of data from the database and we need to use Instant class. I understand it would be pretty good to have the usage of it directly in the interface java.sql.ResultSet to avoid unnecessary instance creation of Timestamp class, right? Can/will the JIT optimize this task by passing the intermediate class instance creation? Thanks, Anderson. On Tue, May 10, 2022 at 4:02 PM Stuart Marks wrote: > You're definitely on to something in that java.util.Date is obsolete, or > obsolescent, and perhaps conceptually at least it should be deprecated. If > I were > reviewing some code that used Date I'd certainly flag the issue. The main > difficulty > is that its usage is entrenched in implementation code, but more > importantly, in APIs. > > In another message you listed several dozen places in the JDK that use > Date and > related APIs. It would be certain amount of work to introduce replacements > that use > newer APIs and to suppress the warnings resulting from the existing APIs. > This is a > bunch of work, but it's not intractable. However, the benefits aren't very > high, and > so the priority is low. > > That's just the JDK. What also needs to be considered is the amount of > code out > there that *uses* these APIs. Most of the usages are in legacy code, which > people > are unlikely to want to spend a large effort on migrating. In addition, > Date and > friends are used in third party library *APIs*, which have their own > users. There's > a lot of this code. > > There are a few possible responses maintainers of this code can take when > new > deprecations appear. > > - Ignoring them. OK, if people ignore deprecation, then it doesn't > really matter > what we do. > > - Disable deprecation warnings. If people had warnings enabled, they > presumably > found value in having those warnings. Mostly this is useful for preventing > new code > from using deprecated APIs. If a lot of many not-very-useful warnings > suddenly > appear, people might disable warnings entirely, and thus miss the warnings > they'd > actually find useful. This defeats the purpose of having the warnings. > > - Migrate code to use other APIs. Some people will do this, if they're > in a > position to do so. Maintainers of legacy code generally are not able to do > this. > Library maintainers are also often not in a position to do this, as they > have their > own compatibility concerns. > > - Suppress warnings at the call sites using @SuppressWarnings. This is > probably > the most common alternative to code migration. This isn't a terrible > option, but > it's tedious, low-value work, and people don't like being forced to do > work that > isn't providing value to them. > > This last point may be more significant than you think. When I deprecated > java.util.Observer/Observable in Java 9, there was very little usage of > these > classes; yet I received a bunch of complaints from people having to deal > with the > warnings. Date and related classes have several orders of magnitude more > usage. The > number of warnings generated will be huge, and the effort required to deal > with them > will be tremendous. > > By the way, all this also applies to other obsolescent but widely used > classes such > as Vector, Hashtable, LinkedList, URL, etc. > > So if warnings are a problem, then maybe we should do something about > that? That's a > possibility. Some better form of @SuppressWarnings might be helpful. More > flexible > control over what warnings javac emits might be useful too. > > (Somebody will inevitably suggest a different annotation that doesn't > generate > warnings. That would be incorrect, because the policy of how to handle > usage of > deprecated APIs, and whether warnings should be emitted, should be in the > hands of > the maintainers of the code that uses those APIs, not the API designers.) > > s'marks > > > > On 5/7/22 7:36 PM, Victor Williams Stafusa da Silva wrote: > > The java.time package was released in Java 8, far back in 2014, more > than 8 > > years ago. It has been a long time since then. Before that, we had the > > dreadful infamous java.util.Date, java.util.Calendar, > > java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, > > java.sql.Timestamp, java.util.GregorianCalendar, > java.text.SimpleDateFormat > > and a few other lesser-known obscure cases. > > > > There are plenty of reasons to avoid using Date, Calendar, DateFormat and > > their subclasses, otherwise there would be few to no reasons for > java.time > > to be conceived. > > > > Applications and libraries which used or relied on those legacy classes > > already had plenty of time to move on and provide java.time.* > alternatives. > > > > No skilled java programmer uses the legacy classes in new applications > > except when integrating with legacy APIs. > > > > Using those classes nowadays should be considered at least a bad > > programming practice, if not something worse (source of bugs, security > > issues, etc). > > > > Novices, unskilled, careless and lazy programmers who should know better > > still happily continue to use the legacy classes, pissing off those who > are > > more enlightened. > > > > So, my proposal is pretty simple: It is time to put a @Deprecated in all > of > > those (not for removal, though). > > > > First, let's deprecate all of them. Second, any method in the JDK > returning > > or receiving any of those as a parameter should be equally deprecated. If > > there is no replacement method using the relevant classes or interfaces > in > > the java.time package, one should be created (which is something probably > > pretty straightforward). > > > > If any of those methods is abstract or is part of an interface, then we > > have a small problem, and it should be solved on a case-by-case analysis, > > preferentially by providing a default implementation. I'm sure that some > > cases should still exist, but I doubt that any of them would be a > > showstopper. > > > > The negative impact is expected to be very small. Popular products like > > Spring and Jakarta either already moved on and provided java.time.* > > alternatives to their APIs or could do that quickly and easily. Anyone > who > > is left behind, would only get some [deserved] deprecation warnings. > > > > On the positive impact side, more than just discouraging the usage of the > > ugly and annoying API of Date, Calendar and DateFormat for people who > > should know better, those classes are a frequent source of bugs that are > > hard do track and to debug due to their mutability and thread unsafety. > > Thus, we are already way past the time to make the compiler give a > warning > > to anyone still using them. > > > > What do you think? > > > From sgehwolf at redhat.com Fri May 13 08:17:00 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 13 May 2022 10:17:00 +0200 Subject: Proposal: openjdk.java.net =?UTF-8?Q?=E2=9E=9C?= openjdk.org In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: On Thu, 2022-05-12 at 08:18 -0700, mark.reinhold at oracle.com wrote: > Since the dawn of time [1] the OpenJDK Community?s web, e-mail, wiki, > issue tracking, and (Mercurial) source-code infrastructure has been > hosted under the third-level domain name ?openjdk.java.net?. > > That name has served us well for fifteen years, but it has also been a > constant source of confusion.? The second-level domain name ?java.net? > originally pointed to an unrelated source-code forge site [2], which was > perplexing.? That forge was shut down in 2017, so now the ?java.net? name > is perplexing in a different way. > > Above and beyond that, however, since the OpenJDK Community was founded > many other open-source communities have placed their infrastructure under > the ?.org? top-level domain name.? This makes for easy discoverability. > It also serves as both a reminder and a promise that the operation of the > community is not meant to be dominated by any single corporate entity. > > I therefore propose that we rename openjdk.java.net to openjdk.org and > make corresponding changes to the names of all active subdomains (i.e., > bugs, cr, db, git, hg, mail, and wiki). > > If we proceed with this then Oracle?s infrastructure team will ensure > that the old names act as aliases for the new names, so as not to break > existing URLs or e-mail addresses. > > Comments? Horray! :) Thanks, Severin > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/announce/2007-May/000000.html > [2] https://en.wikipedia.org/wiki/Java.net > From volker.simonis at gmail.com Fri May 13 14:07:32 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 May 2022 16:07:32 +0200 Subject: =?UTF-8?Q?Re=3A_Proposal=3A_openjdk=2Ejava=2Enet_=E2=9E=9C_openjdk=2Eorg?= In-Reply-To: References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: On Thu, May 12, 2022 at 7:31 PM Magnus Ihse Bursie wrote: > > On 2022-05-12 17:18, mark.reinhold at oracle.com wrote: > > I therefore propose that we rename openjdk.java.net to openjdk.org and > > make corresponding changes to the names of all active subdomains (i.e., > > bugs, cr, db, git, hg, mail, and wiki). > > > > [...] > > > > Comments? > > As we say in Sweden: ?ntligen! [1] :-) As we say in Germany: Endlich! (same word, no umlauts :) > > This is a great move to get a proper home for the OpenJDK community on > the Internet. > > (This has been eagerly awaited by the Skara project, since the Git > commits have from the start been recorded as name>@openjdk.org.) > > /Magnus > > [1] Meaning ? "finally" From dalibor.topic at oracle.com Fri May 13 15:06:44 2022 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 13 May 2022 17:06:44 +0200 Subject: =?UTF-8?Q?Re=3a_Proposal=3a_openjdk=2ejava=2enet_=e2=9e=9c_openjdk?= =?UTF-8?Q?=2eorg?= In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: <8c106963-9aa3-8825-f140-53e4cff65493@oracle.com> On 12.05.2022 17:18, mark.reinhold at oracle.com wrote: > I therefore propose that we rename openjdk.java.net to openjdk.org and > make corresponding changes to the names of all active subdomains (i.e., > bugs, cr, db, git, hg, mail, and wiki). Yes, please. Thank you! cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From mark.reinhold at oracle.com Fri May 13 15:35:23 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 13 May 2022 08:35:23 -0700 Subject: Proposal: openjdk.java.net =?utf-8?Q?=E2=9E=9C?= openjdk.org In-Reply-To: References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: <20220513083523.683981776@eggemoggin.niobe.net> 2022/5/12 15:20:52 -0700, christoph.langer at sap.com: > Sounds great! > > Will it then also be possible to relay mails to name>@openjdk.org to our mailboxes? Yes -- in fact, that?s worked since shortly after we moved to GitHub and started using @openjdk.org addresses in commit messages. - Mark From christoph.langer at sap.com Fri May 13 15:37:02 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 May 2022 15:37:02 +0000 Subject: =?utf-8?B?UkU6IFByb3Bvc2FsOiBvcGVuamRrLmphdmEubmV0IOKenCBvcGVuamRrLm9y?= =?utf-8?Q?g?= In-Reply-To: <20220513083523.683981776@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> <20220513083523.683981776@eggemoggin.niobe.net> Message-ID: > > Will it then also be possible to relay mails to > name>@openjdk.org to our mailboxes? > > Yes -- in fact, that?s worked since shortly after we moved to GitHub and started > using @openjdk.org addresses in commit messages. Oh, I obviously didn't know that. What can I do to configure it? Is it a question for ops or skara-dev? Thanks Christoph From mark.reinhold at oracle.com Fri May 13 15:38:35 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 13 May 2022 08:38:35 -0700 Subject: Proposal: openjdk.java.net =?utf-8?Q?=E2=9E=9C?= openjdk.org In-Reply-To: References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: <20220513083835.202243256@eggemoggin.niobe.net> 2022/5/12 16:18:15 -0700, Simon Phipps : > Speaking as a relic from the dawn of time, that's a great suggestion > that I wish we'd opted for at the dawn of time :-) We did in fact push strongly for openjdk.org way back when, but then the edict came down from Sun?s C-suite that ?you can have any domain that you want, as long as it ends in ?java.net.?? So I parked openjdk.org myself in 2006 and transferred ownership to Oracle when the time was right. - Mark From mark.reinhold at oracle.com Fri May 13 15:46:48 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 13 May 2022 08:46:48 -0700 Subject: Proposal: openjdk.java.net =?utf-8?Q?=E2=9E=9C?= openjdk.org In-Reply-To: References: <20220512081810.778733553@eggemoggin.niobe.net> <20220513083523.683981776@eggemoggin.niobe.net> Message-ID: <20220513084648.489539280@eggemoggin.niobe.net> 2022/5/13 8:37:02 -0700, christoph.langer at sap.com: >> > Will it then also be possible to relay mails to > > name>@openjdk.org to our mailboxes? >> >> Yes -- in fact, that?s worked since shortly after we moved to GitHub >> and started using @openjdk.org addresses in commit messages. > > Oh, I obviously didn't know that. What can I do to configure it? Is it > a question for ops or skara-dev? E-mail registrar at openjdk.org. - Mark From magnus.ihse.bursie at oracle.com Fri May 13 16:57:18 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 13 May 2022 18:57:18 +0200 Subject: =?UTF-8?Q?Re=3a_Proposal=3a_openjdk=2ejava=2enet_=e2=9e=9c_openjdk?= =?UTF-8?Q?=2eorg?= In-Reply-To: References: <20220512081810.778733553@eggemoggin.niobe.net> <20220513083523.683981776@eggemoggin.niobe.net> Message-ID: <11d0e7f2-3056-2f13-9eb1-a2f959ab5996@oracle.com> On 2022-05-13 17:37, Langer, Christoph wrote: >>> Will it then also be possible to relay mails to >> name>@openjdk.org to our mailboxes? >> Yes -- in fact, that?s worked since shortly after we moved to GitHub and started >> using @openjdk.org addresses in commit messages. > Oh, I obviously didn't know that. What can I do to configure it? Is it a question for ops or skara-dev? Make sure Github knows about your address. Go to https://github.com/settings/emails and add `@openjdk.org` as a mail address. /Magnus > > Thanks > Christoph From christoph.langer at sap.com Fri May 13 17:43:33 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 May 2022 17:43:33 +0000 Subject: =?utf-8?B?UkU6IFByb3Bvc2FsOiBvcGVuamRrLmphdmEubmV0IOKenCBvcGVuamRrLm9y?= =?utf-8?Q?g?= In-Reply-To: <11d0e7f2-3056-2f13-9eb1-a2f959ab5996@oracle.com> References: <20220512081810.778733553@eggemoggin.niobe.net> <20220513083523.683981776@eggemoggin.niobe.net> <11d0e7f2-3056-2f13-9eb1-a2f959ab5996@oracle.com> Message-ID: > Make sure Github knows about your address. Go to > https://github.com/settings/emails and add ` id>@openjdk.org` as a mail address. I had that for a while already. Now it could even be verified... ?? Thanks Christoph From mark.reinhold at oracle.com Fri May 20 14:46:57 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 20 May 2022 07:46:57 -0700 (PDT) Subject: Project Leyden Message-ID: <20220520144657.4BBED537750@eggemoggin.niobe.net> FYI, work on Project Leyden is beginning: https://openjdk.java.net/projects/leyden https://openjdk.java.net/projects/leyden/notes/01-beginnings Please direct comments and questions to the leyden-dev list, to which you must subscribe before you post: https://mail.openjdk.java.net/mailman/listinfo/leyden-dev - Mark From tanksherman27 at gmail.com Sat May 21 14:10:47 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Sat, 21 May 2022 22:10:47 +0800 Subject: Project Leyden Message-ID: Hell yeah!! (Is the Leyden Group still open for joining?) best regards, Julian From mark.reinhold at oracle.com Tue May 24 16:15:16 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 May 2022 09:15:16 -0700 Subject: Proposal: openjdk.java.net =?utf-8?Q?=E2=9E=9C?= openjdk.org In-Reply-To: <20220512081810.778733553@eggemoggin.niobe.net> References: <20220512081810.778733553@eggemoggin.niobe.net> Message-ID: <20220524091516.435843007@eggemoggin.niobe.net> 2022/5/12 8:18:10 -0700, mark.reinhold at oracle.com: > ... > > I therefore propose that we rename openjdk.java.net to openjdk.org and > make corresponding changes to the names of all active subdomains (i.e., > bugs, cr, db, git, hg, mail, and wiki). Thanks, everyone, for the feedback. We?re going to proceed with this change. Stay tuned for details. - Mark From steffen.moser at uni-ulm.de Sun May 29 08:46:48 2022 From: steffen.moser at uni-ulm.de (Steffen Moser) Date: Sun, 29 May 2022 10:46:48 +0200 Subject: HTTP Error 500 when accessing hg.openjdk.java.net Message-ID: Hi all, when trying to clone a repository from http://hg.openjdk.java.net, there is a chance of about 20 % of getting a web server error 500, which looks as following: > > > ** Python 2.6.9: /oj/bin/python > Sun May 29 08:42:05 2022 > > A problem occurred in a Python script. Here is the sequence of > function calls leading up to the error, in the order they occurred. > > /oj/lib/python2.6/site-packages/flup-1.0.3.dev_20110405-py2.6.egg/flup/server/fcgi_base.py > in *run*(self=) > ??572 > ??573?????????try: > ??574?????????????protocolStatus,?appStatus?=?self.server.handler(self) > ??575?????????except: > ??576?????????????traceback.print_exc(file=self.stderr) > protocolStatus /undefined/, appStatus /undefined/, *self*?= > , self.*server*?= > , self.server.*handler*?= method WSGIServer.handler of > > So there seems to be something broken on (one of the?) Mercurial server(s). Does anybody know who I should inform about this? How to reproduce: Go, for example, to http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ebc6c83bfa9e and press "Reload" several times. Thank you very much in advance! Kind regards, Steffen -- ?----------------------------------------------------------------------- Dipl.-Inf. Steffen Moser Tel (Office): +49.731.50.32407 School of Advanced Professional Studies Fax (Office): +49.731.50.32409 Ulm University, Room: 02_11.4 Tel (Home): +49.731.36080158 Lise-Meitner-Stra?e 16, 89081 Ulm, Germanyhttp://saps.uni-ulm.de/ GDPR Statement:https://wissenschaftliche-weiterbildung.org/datenschutz/ From tim.bell at oracle.com Mon May 30 15:26:01 2022 From: tim.bell at oracle.com (tim.bell at oracle.com) Date: Mon, 30 May 2022 08:26:01 -0700 Subject: HTTP Error 500 when accessing hg.openjdk.java.net In-Reply-To: References: Message-ID: <0adee14c-7c9c-a68f-f9b2-e92117e7c3a9@oracle.com> Hello Steffen On 5/29/22 01:46, Steffen Moser wrote: > seems to be something broken on (one of the?) Mercurial server(s). > Does anybody know who I should inform about this? > > How to reproduce: Go, for example, to > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ebc6c83bfa9e and > press "Reload" several times. This is fixed on http://hg.openjdk.java.net. Please try it again. For future use, the list to notify regarding technical problems is ops at openjdk.java.net. As an additional note, all Mercurial repositories on hg.openjdk.java.net are read-only.? Active OpenJDK development migrated to github at https://github.com/openjdk For jdk11u specifically, look here: * https://github.com/openjdk/jdk11u * https://github.com/openjdk/jdk11u-dev Tim From qustacksm2123456 at gmail.com Mon May 30 21:14:52 2022 From: qustacksm2123456 at gmail.com (sam smith) Date: Mon, 30 May 2022 23:14:52 +0200 Subject: [Question] How to effectively convert a list of list of lists of string into an array of arrays of arrays of string in Java>8 Message-ID: Hello guys, Let's say i have a List>> that i want to convert into a String[][][]; how to do that effectively in Java versions greater that 8? Thanks. From forax at univ-mlv.fr Mon May 30 21:44:00 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 30 May 2022 23:44:00 +0200 (CEST) Subject: [Question] How to effectively convert a list of list of lists of string into an array of arrays of arrays of string in Java>8 In-Reply-To: References: Message-ID: <606700328.15129036.1653947040761.JavaMail.zimbra@u-pem.fr> Hi Sam, wrong list, openjdk.org is about people implementing the JDK, it's not a helping forum about how to do funny things in Java. Stackoverflow.com is a better web site for the kind of questions you are asking. reards, R?mi public static List>> wrap(String[][][] array) { return new AbstractList<>() { @Override public List> get(int index) { var item = array[index]; return new AbstractList<>() { @Override public List get(int index) { var item2 = item[index]; return new AbstractList<>() { @Override public String get(int index) { return item2[index]; } @Override public int size() { return item2.length; } }; } @Override public int size() { return item.length; } }; } @Override public int size() { return array.length; } }; } ----- Original Message ----- > From: "sam smith" > To: "discuss" > Sent: Monday, May 30, 2022 11:14:52 PM > Subject: [Question] How to effectively convert a list of list of lists of string into an array of arrays of arrays of > string in Java>8 > Hello guys, > > Let's say i have a List>> that i want to convert into a > String[][][]; how to do that effectively in Java versions greater that 8? > > Thanks. From ethan at mccue.dev Mon May 30 22:04:19 2022 From: ethan at mccue.dev (Ethan McCue) Date: Mon, 30 May 2022 18:04:19 -0400 Subject: [Question] How to effectively convert a list of list of lists of string into an array of arrays of arrays of string in Java>8 In-Reply-To: <606700328.15129036.1653947040761.JavaMail.zimbra@u-pem.fr> References: <606700328.15129036.1653947040761.JavaMail.zimbra@u-pem.fr> Message-ID: static String[][][] convert(List>> items) { return items.stream().map(__ -> __.stream().map(___ -> ___.toArray(String[]::new)).toArray(String[][]::new)).toArray(String[][][]::new); } On Mon, May 30, 2022 at 5:45 PM Remi Forax wrote: > Hi Sam, wrong list, > openjdk.org is about people implementing the JDK, it's not a helping > forum about how to do funny things in Java. > > Stackoverflow.com is a better web site for the kind of questions you are > asking. > > reards, > R?mi > > public static List>> wrap(String[][][] array) { > return new AbstractList<>() { > @Override > public List> get(int index) { > var item = array[index]; > return new AbstractList<>() { > @Override > public List get(int index) { > var item2 = item[index]; > return new AbstractList<>() { > @Override > public String get(int index) { > return item2[index]; > } > > @Override > public int size() { > return item2.length; > } > }; > } > > @Override > public int size() { > return item.length; > } > }; > } > > @Override > public int size() { > return array.length; > } > }; > } > > > > ----- Original Message ----- > > From: "sam smith" > > To: "discuss" > > Sent: Monday, May 30, 2022 11:14:52 PM > > Subject: [Question] How to effectively convert a list of list of lists > of string into an array of arrays of arrays of > > string in Java>8 > > > Hello guys, > > > > Let's say i have a List>> that i want to convert into a > > String[][][]; how to do that effectively in Java versions greater that 8? > > > > Thanks. >