Just for the record: GitHub uses Azul Zulu -
https://github.com/actions/setup-java/blob/a8e7064d5b5073e11c2bb6107e0f4f2219da969b/lib/installer.js#L55

There is an open issue to use OpenJDK by default or at least add it as an
option: https://github.com/actions/setup-java/issues/13

On Mon, Aug 19, 2019 at 1:26 PM Martin Grigorov <[email protected]>
wrote:

> 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
>>
>

Reply via email to