Hi all,
Please review the patch for jdk13u backport of tzdata2019b integration into jdk:
Webrev: http://cr.openjdk.java.net/~rpatil/8228469/13u/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8228469
The patch is not clean because: It uses "rearguard" format tzdata from IANA
(instead of
Thank you Martin and Naoto for your reviews.
Hi Martin,
Currently, we are evaluating the approach for update releases. But in my
opinion, it is better to migrate to vanguard format.
Regards,
Ramanand.
From: Martin Buchholz
Sent: Tuesday, August 6, 2019 1:57 AM
To: Ramanand Patil
Cc: core-li
One property of a lambda proxy class is to be in the same nest as the
caller class as it's logically part of the caller class (as it may
access its private member). VM anonymous class is an interim
implementation solution until we provide a way to define a dynamically
generated class as a nest
Thanks Rémi and Mandy.
I still don't get the full rationale on why lambda classes should be
treated so specially but at least I now understand the current behavior.
Greetings
Raffaello
On 05/08/2019 23.34, Remi Forax wrote:
It is intentional and the implementation details are planned to
Hi,
Please review Vladimir Yaroslavskiy's changes to DualPivotQuickSort
(seen earlier[1] on this alias). I will be sponsoring this change.
I have a webrev against jdk-jdk here:
http://cr.openjdk.java.net/~bchristi/8226297/webrev03-rfr/
(Note that I did a little re-ordering, and removed some
It is intentional and the implementation details are planned to change in the
future
(there are already some patches in the valhalla/nestmates branch).
The slash in the name is because you can create several classes from the same
bytecode by patching it at runtime,
the number after the slash is
This is intentional. The lambda proxy classes are defined as VM
anonymous classes through a JDK internal API
Unsafe::defineAnonymousClass. These generated classes are JDK
implementation details that are hidden for any class lookup and not
modifiable by JVM TI agent.
JDK-8171335 is the RFE t
Hello,
experiment suggests that classes generated by
java.lang.invoke.LambdaMetafactory are somewhat special:
(1) getName() on the class returns a string of the form
Xxx$$Lambda$nn/0xhhh
where Xxx is a fully qualified class name (with periods '.' as package
separators), nn is a decimal in
Thanks for the update and redundancy removal. Looks good to me.
What is the recommendation for older releases? Migrate to vanguard format
by backporting recent changes or stay on rearguard forever?
On Mon, Aug 5, 2019 at 1:28 AM Ramanand Patil
wrote:
> Hi all,
> Please review the patch for tz
Hi Ramanand,
Looks good to me. Glad that the number of files to review has decreased
a lot :-)
Naoto
On 8/5/19 1:27 AM, Ramanand Patil wrote:
Hi all,
Please review the patch for tzdata2019b integration into jdk project(jdk-14).
Webrev: http://cr.openjdk.java.net/~rpatil/8228469/14/webrev.00/
Hi all,
Please review the patch for tzdata2019b integration into jdk project(jdk-14).
Webrev: http://cr.openjdk.java.net/~rpatil/8228469/14/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8228469
Summary:
- This patch uses "vanguard" format tzdata from IANA (instead of
rearguard
Hi,
the changeset for the zipfs POSIX permissions support seems to be ready now.
I've spent some iterations with Lance to finalize it, mainly some formal things
and additions/cleanups to the test. I've got reviews now from both, Alan and
Lance.
So, that's the last call for review/feedback/obje
12 matches
Mail list logo
