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
