Thank you for your answer, Dalibor!
Honestly this sounds very frightening to me!
With one vendor Java was quite stable in my experience, but now with many
vendors it seems we will have to add workarounds and checks like the old
days in JavaScript: if (isInternetExplorer6()) {...} else if
(isInternetExplorer7()) {...}
On Mon, Aug 19, 2019 at 12:09 PM Dalibor Topic <[email protected]>
wrote:
> Hi Martin,
>
> That's a slightly more complicated question than it may appear to be,
> since 11.0.2 was the last OpenJDK JDK 11 release led by Oracle, and I
> can't really say in such detail what third parties producing their own
> OpenJDK JDK 11 builds will chose to backport, and if they do so, when
> they would include a specific backport within their builds.
>
> The backports section in the bug report can provide some hints, but it's
> worth pointing out that third party builds might differ in what issues
> they focus on backporting, for example, due to different priorities,
> customers, or preferences, so at the end of the day, the observed
> behavior might still vary, when it comes to individual issues.
>
> cheers,
> dalibor topic
>
>
> On 19.08.2019 10:34, Martin Grigorov wrote:
> > Hello Rory & Muneer,
> >
> > Is the change UCT -> UTC time zone have been backported to Java 11 ? Or
> > it is only in Java 13 ?
> > We just tried GitHub Actions and the test has failed on their Java
> > 11.0.4 installation: https://github.com/apache/wicket/runs/196487121
> > Me and another Wicket developer tested with 11.0.4 on our Ubuntu
> > machines (installed with "apt install openjdk-11-jdk") but the test
> > passed locally.
> > I have the feeling that GitHub's installation of Java 11 is corrupted
> > somehow but it could also be the Ubuntu package that we have.
> >
> > Kind regards,
> > Martin
> >
> > On Tue, Jul 23, 2019 at 4:05 AM <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Yea Martin, don't need a ticket for this.
> >
> > It's an expected behavior from build 30 onwards.
> >
> > -Muneer
> >
> >
> > On 22/07/19 6:16 PM, Martin Grigorov wrote:
> >> Hi Muneer,
> >>
> >> Yes, this ticket explains the problem:
> >>
> >> Etc/UCT is now a backward-compatibility link to Etc/UTC, instead
> >> of being a separate zone that generates the abbreviation "UCT",
> >> which nowadays is typically a typo. (Problem reported by Isiah
> >> Meadows.)
> >>
> >> So it seems there is no need of a ticket.
> >>
> >> Otherwise the reproducer is :import java.time.ZonedDateTime;
> >> import java.time.format.DateTimeFormatter;
> >> import java.time.format.FormatStyle;
> >> import java.time.temporal.TemporalAccessor;
> >> import java.util.Locale;
> >>
> >> public class Java13Build30
> >> {
> >> public static void main(String[] args)
> >> {
> >> String toParse = "Jul 11, 2016, 1:02:03 AM Coordinated
> >> Universal Time";
> >> Locale locale = Locale.ENGLISH;
> >> DateTimeFormatter dateTimeFormatter =
> >> DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM,
> >> FormatStyle.FULL).withLocale(locale);
> >> final TemporalAccessor temporalAccessor =
> >> dateTimeFormatter.parse(toParse);
> >> final ZonedDateTime zonedDateTime =
> >> ZonedDateTime.from(temporalAccessor);
> >> System.err.println(zonedDateTime);
> >> }
> >> }
> >>
> >> Regards,
> >> Martin
> >>
> >> On Mon, Jul 22, 2019 at 3:40 PM <[email protected]
> >> <mailto:[email protected]>> wrote:
> >>
> >> Hi Martin,
> >>
> >> This enhancement task description may help you:
> >> https://bugs.openjdk.java.net/browse/JDK-8224560 .
> >>
> >> It is included in JDK 13 build 30.
> >>
> >> -Muneer
> >>
> >>
> >> On 22/07/19 6:00 PM, Rory O'Donnell wrote:
> >>>
> >>> Hi Martin,
> >>>
> >>> A reproducer would be great.
> >>>
> >>> Thanks,Rory
> >>>
> >>> On 22/07/2019 13:03, Martin Grigorov wrote:
> >>>> Hi,
> >>>>
> >>>> I won't have time now to extract a mini reproducer but if
> >>>> anyone else has time here are some details:
> >>>>
> >>>> the test tries to parse "Jul 11, 2016, 1:02:03 AM
> >>>> Coordinated Universal Time" with Locale.ENGLISH
> >>>> In earlier versions of Java it returns a
> >>>> ZonedDateTime.of(2016, 7, 11, 1, 2, 3, 0,
> ZoneId.of("Etc/UCT"))
> >>>> with Java 13 b30 the zone id is "Etc/UTC"
> >>>> I am not sure what UCT is and whether it is a valid zone,
> >>>> but it seems to be a valid one.
> >>>>
> >>>> On Mon, Jul 22, 2019 at 2:48 PM Martin Grigorov
> >>>> <[email protected] <mailto:[email protected]>> wrote:
> >>>>
> >>>> Hi Rory,
> >>>>
> >>>> There is a test failure with Java 13 build 30 in Apache
> >>>> Wicket:
> >>>>
> >>>> INFO] Results:
> >>>> [INFO]
> >>>> [ERROR] Failures:
> >>>> [ERROR] ZonedDateTimeConverterTest.convertToObject:46
> >>>> expected: <2016-07-11T01:02:03Z[Etc/UTC]> but was:
> >>>> <2016-07-11T01:02:03Z[Etc/UCT]>
> >>>>
> >>>> Java 13 returns UCT instead of UTC as a ZoneId.
> >>>> Is this expected ?
> >>>>
> >>>> Regards,
> >>>> Martin
> >>>>
> >>>>
> >>>> On Mon, Jul 22, 2019 at 1:18 PM Rory O'Donnell
> >>>> <[email protected]
> >>>> <mailto:[email protected]>> wrote:
> >>>>
> >>>> Hi Martin,
> >>>>
> >>>> Any issues to report on JDK 13 , would like to hear
> >>>> the status as we are
> >>>> now in rampdown phase 2 ?
> >>>>
> >>>> **OpenJDK builds *- JDK 13 Early Access build 30
> >>>> **is now available **at
> >>>> : - jdk.java.net/13/* <http://jdk.java.net/13/*>
> >>>>
> >>>> * Per the JDK 13 schedule [1], we are now in
> >>>> Rampdown Phase Two.
> >>>> o For more details , see Mark Reinhold's email
> >>>> to jdk-dev mailing
> >>>> list [2]
> >>>> o The overall feature set is frozen, no
> >>>> further JEPs will be
> >>>> targeted to this release.
> >>>> o Per the JDK Release Process [3] we now turn
> >>>> our focus to P1 and
> >>>> P2 bugs.
> >>>>
> >>>> * I want to draw your attention to some noteable
> >>>> changes in previous
> >>>> builds of JDK 13. These changes are important
> >>>> for those that
> >>>> develop/maintain their own socket implementation
> >>>> (java.net.SocketImpl) or use the
> >>>> setSocketImplFactory or
> >>>> setSocketFactory APIs to change the system-wide
> >>>> socket implementation:
> >>>>
> >>>> o
> >>>> http://jdk.java.net/13/release-notes#JDK-8224477 -
> >>>> delivered in
> >>>> build 23
> >>>> o
> >>>> http://jdk.java.net/13/release-notes#JDK-8216978 -
> >>>> delivered in
> >>>> build 20
> >>>> o
> >>>> http://jdk.java.net/13/release-notes#JDK-8220493 -
> >>>> delivered in
> >>>> build 13
> >>>>
> >>>> **OpenJDK builds *- JDK 14 Early Access build 6 is
> >>>> **now available **at
> >>>> : - jdk.java.net/14/* <http://jdk.java.net/14/*>
> >>>>
> >>>> * These early-access, open-source builds are
> >>>> provided under the
> >>>> o GNU General Public License, version 2, with
> >>>> the Classpath
> >>>> Exception
> >>>> <http://openjdk.java.net/legal/gplv2+ce.html>.
> >>>> * Changes of interest since last email
> >>>> o 8225239: Refactor NetworkInterface lookups
> >>>> o 8226409: Enable argument profiling for
> >>>> sun.misc.Unsafe.put*/get*
> >>>> * JEP targeted to JDK 14:
> >>>> o JEP352: Non-Volatile Mapped
> >>>> * Bug fixes reported by Open Source Projects :
> >>>> o JDK-8227080 - fixed in b5 -reported by
> >>>> Eclipse Jetty
> >>>>
> >>>> The Java Crypto Roadmap
> >>>> <https://www.java.com/en/jre-jdk-cryptoroadmap.html
> > has
> >>>> been updated :
> >>>>
> >>>> * Released - 16-July-2019 - Release Affected JDK
> >>>> 7u231 - Disabled
> >>>> Kerberos DES encryption by default
> >>>> * Targeted Date - 2020 - Targeted Release - JDK 8
> >>>> - Transport Layer
> >>>> Security (TLS) 1.3
> >>>>
> >>>> Rgds,Rory
> >>>>
> >>>> [1] http://openjdk.java.net/projects/jdk/13/#Schedule
> >>>> [2]
> >>>>
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003170.html
> >>>>
> >>>>
> >>>> --
> >>>> Rgds, Rory O'Donnell
> >>>> Quality Engineering Manager
> >>>> Oracle EMEA, Dublin, Ireland
> >>>>
> >>> --
> >>> Rgds, Rory O'Donnell
> >>> Quality Engineering Manager
> >>> Oracle EMEA, Dublin, Ireland
> >>
> >
>
> --
> <http://www.oracle.com>
> Dalibor Topic | Consulting Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961> | Video: [email protected]
> <sip:[email protected]>
>
> Oracle Global Services Germany GmbH
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRB 246209
> Geschäftsführer: Ralf Herrmann
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
>
