Re: RFR: JDK-8228744: file associations broken on linux.

Looks good. - Alexey On 7/29/2019 3:19 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8228744 [2] http://cr.openjdk.java.net/~

Issue with SSL handshake implementation

Hi, There may be some issue with the SSL handshake implementation. In sun.security.x509.X500Name.java, there's a static hashmap field named *internedOIDs*, used for caching X.500 attributes. Each time a new oid is encountered, jdk will cache them into the static hashmap. With a purposely

Re: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works

Hi Mandy, 380 * {@link java.lang.invoke.MethodHandles.Lookup#unreflectSpecial lookup.unreflectSpecial(aMethod,this.class)} 381 * {@code T m(A*);}{@code (T) aMethod.invoke(this, arg*);} Is this exactly true? I mean - if `this` is an instance of a subclass of `aMethod.getDe

RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year

Hi, Request your review of this simple change. JBS:https://bugs.openjdk.java.net/browse/JDK-8160225 (java.time.format.DateTimeFormatter issues for month-of-year) Description:It is a simple documentation change. The DateTimeFormatter expects the month format to be represented by "L" for

RFR: 8228778: JDK 13 L10n resource files update - msg drop 20

Hi, Please help to review the update of L10n resource files in JDK13 msg drop 20. Bug: https://bugs.openjdk.java.net/browse/JDK-8228778 Webrev: http://cr.openjdk.java.net/~ljiang/8228778/webrev/read/ Thanks, Leo

Re: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works

Think about aMethod is a protected method inherited from its superclass T.  To invoke aMethod, the receiver must be an instance of T or a subclass of T. Mandy On 7/30/19 3:22 AM, Daniel Fuchs wrote: Hi Mandy,  380  * {@link java.lang.invoke.MethodHandles.Lookup#unreflectSpecial

Re: RFR: 8224974: Implement JEP 352

JEP 352 has now been targeted for inclusion in JDK14. The latest webrev for the implementation JIRA has been rebased to apply to the current tree. Is it now ok to push this change set? JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974 webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev

Re: RFR: 8228778: JDK 13 L10n resource files update - msg drop 20

Looks good to me. Naoto On 7/30/19 6:55 AM, li.ji...@oracle.com wrote: Hi, Please help to review the update of L10n resource files in JDK13 msg drop 20. Bug: https://bugs.openjdk.java.net/browse/JDK-8228778 Webrev: http://cr.openjdk.java.net/~ljiang/8228778/webrev/read/ Thanks, Leo

Re: RFR: 8224974: Implement JEP 352

On 7/30/19 5:04 PM, Andrew Dinn wrote: > JEP 352 has now been targeted for inclusion in JDK14. The latest webrev > for the implementation JIRA has been rebased to apply to the current > tree. Is it now ok to push this change set? > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974 > webre

Re: RFR: 8228778: JDK 13 L10n resource files update - msg drop 20

This is not a review to this change. The super long lines in translated properties files are really unreadable. Is it possible to reformat them like the English version? i.e. break the line at every non-terminal \n? Thanks, Max > On Jul 30, 2019, at 9:55 PM, li.ji...@oracle.com wrote: > > Hi,

jdk.serial filter is not working for restricting depth of treemap in java

Hi All, I'm mailing here for the first time and I am unaware of any rules for mailing here. If there is any mistake please let me know. Below is my question JEP 290 solves the problem of deserialization vulnerabilities except some collection classes which inclu

Re: RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year

Hi Thejasvi, M/L does not designate textual nor numeric. Thus I don't think that the suggested documentation fix is correct. Furthermore, although the exception in JDK8 looks like a bug, the test result with JDK9 looks correct to me. The month displayed as "04" is the result of ZonedDateTime.

RE: RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year

Hi Naoto, Thank you for the response. You are correct. I ran the reproducer against JDK13 and JDK9, and they appear not to differentiate between L and M as long as the input is consistent. I will update the bug and revise the effort accordingly. Thanks!! -Original Message- From: Naot