Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi Sherman, Thanks for your quick response :) I aimed to implement the "traditional" at this proposal by the below reasons. * We want to prepare API for encrypted zip files at first. * Many people use the "traditional" in problem-free scope like a temporary file. * We do not know which impl

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

On 3/12/2015 12:56 AM, Doug Lea wrote: Bringing Martin's JEP comment (https://bugs.openjdk.java.net/browse/JDK-8046936) to the lists: Approximately 100% of the cases of StackOverflowError (SOE) we hear about lately on concurrency-interest are due to long chains of CompletableFutures that exist

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

(I'm not a reviewer) Just a minor question. jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and BASE64Decoder, but is not included in this fix. Missed? or justbecause this test will be totally removed soon in a separate bugid? Thanks, Amy On 12/2/15 11:03 PM, Chris He

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi Yuji, I will take a look at your PoC. Might need some time and even bring in the security guy to evaluate the proposal. It seems like you are only interested in the "traditional PKWare decryption", which is, based on the wiki, "known to be seriously flawed, and in particular is vulnerable

[PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi all, We need reviewer(s) for this PoC. Could you please review this proposal and PoC ? Thanks, Yuji 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : > Hi all, > > * Sorry for my mistake. I re-post this mail because I sent before get > a response of subscription confirmation of core-libs-dev. > > Our

Re: RFR: jsr166 jdk9 integration wave 2

We're stuck. Peter wants to make Throwables cloneable, I want to reverse the order of throwables and add the past Throwable as a suppressed exception to the exception of a dependent action, and Doug wants the current webrev behavior of adding the dependent action as a suppressed exception of the s

Re: Unexpected BindException in Endpoint.publish

Hi Miroslav, 2015-12-02 22:39 GMT+09:00 Miroslav Kos : > thanks for the patch - it fixes the issue and looks ok to me. I'll integrate > it to standalone JAX-WS repo and it will be integrated into openjdk during > next syncup. Thanks for your quick response and push! I will get 2nd "Contributed-by

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

> On Dec 2, 2015, at 2:36 PM, Paul Sandoz wrote: > > >> On 2 Dec 2015, at 22:24, Mandy Chung wrote: >> >> >>> On Nov 26, 2015, at 1:55 AM, Paul Sandoz wrote: >>> >>> Hi, >>> >>> This is a request for an optimistic review to fork the sun.misc.Unsafe and >>> jdk.internal.misc.Unsafe native

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: > > Please review the java.lang.ref.Cleaner and tests following the > recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Javadoc: > htt

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

Hi Stefan, > On 2 Dec 2015, at 17:20, Stefan Särne wrote: > > > Hi Paul, > > The reason we stick on standard jtreg tests is because it is simpler. > For us, a java test is not a unit test, it is an application. :) > I tend to think of that as an artificial distinction since such java test

Re: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

Hi Stuart, On 12/2/15 11:49 PM, Stuart Marks wrote: Hi Daniel, I'm ok with setMillis() remaining deprecated, but there should be an explanation of why it's deprecated. What's there now says To set event time with nanosecond resolution, use {@link #setInstant(java.time.Instant)}. A b

Re: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

BTW Daniel, if you're ok with my suggestions, go ahead and push them. I don't need to see another webrev. Thanks, s'marks On 12/2/15 2:49 PM, Stuart Marks wrote: Hi Daniel, I'm ok with setMillis() remaining deprecated, but there should be an explanation of why it's deprecated. What's there n

Re: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

Hi Daniel, I'm ok with setMillis() remaining deprecated, but there should be an explanation of why it's deprecated. What's there now says To set event time with nanosecond resolution, use {@link #setInstant(java.time.Instant)}. A better explanation might be along the lines of: Lo

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

> On 2 Dec 2015, at 22:24, Mandy Chung wrote: > > >> On Nov 26, 2015, at 1:55 AM, Paul Sandoz wrote: >> >> Hi, >> >> This is a request for an optimistic review to fork the sun.misc.Unsafe and >> jdk.internal.misc.Unsafe native method tables so that we can evolve the >> latter e.g. for VarH

RE: RFR: 8144533: VersionCheck.java failing after Verona changes in dev

Hi, Kumar. Looks good. iris -Original Message- From: Kumar Srinivasan Sent: Wednesday, December 02, 2015 2:16 PM To: Joe Darcy; IRIS,CLARK Cc: core-libs-dev Subject: RFR: 8144533: VersionCheck.java failing after Verona changes in dev Please review fix: diff --git a/test/tools/launcher/

Re: RFR: 8144533: VersionCheck.java failing after Verona changes in dev

Look good Kumar; thanks, -Joe On 12/2/2015 2:16 PM, Kumar Srinivasan wrote: Please review fix: diff --git a/test/tools/launcher/VersionCheck.java b/test/tools/launcher/VersionCheck.java --- a/test/tools/launcher/VersionCheck.java +++ b/test/tools/launcher/VersionCheck.java @@ -187,7 +187,7 @@

RFR: 8144533: VersionCheck.java failing after Verona changes in dev

Please review fix: diff --git a/test/tools/launcher/VersionCheck.java b/test/tools/launcher/VersionCheck.java --- a/test/tools/launcher/VersionCheck.java +++ b/test/tools/launcher/VersionCheck.java @@ -187,7 +187,7 @@ static boolean compareInternalStrings() { int failcount = 0; -

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Lance, Cleaner class level javadoc defines the behavior: "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." Roger On 12/02/2015 04:09 PM, Lance Andersen wrote: Hi Roger,

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

> On Nov 26, 2015, at 1:55 AM, Paul Sandoz wrote: > > Hi, > > This is a request for an optimistic review to fork the sun.misc.Unsafe and > jdk.internal.misc.Unsafe native method tables so that we can evolve the > latter e.g. for VarHandles unsafe work > > http://cr.openjdk.java.net/~psandoz

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, Should the javadocs in the Cleaner methods include NPE given they use Objects.requireNonNull? Best Lance On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: > Please review the java.lang.ref.Cleaner and tests following the > recommendation to simplify the public > interface to support on

Re: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

+1 From: Daniel Fuchs Sent: Wednesday, December 2, 2015 2:10 PM To: core-libs-dev Cc: Stuart Marks; Jason Mehrens Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated Hi, Please find below a fix for

Re: RFE Pre-review: Support for cloning exceptions

Hello, On 12/2/2015 10:39 AM, Martin Buchholz wrote: On Wed, Dec 2, 2015 at 1:32 AM, Peter Levart wrote: In short, I think exceptions are a special hierarchy with special use pattern in which clone() would not present a practical problem that generally arises in other objects that are meant t

Re: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

+1 On Dec 2, 2015, at 3:10 PM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for > 8144262: LogRecord.getMillis() method is a convenience API that > should not have been deprecated > https://bugs.openjdk.java.net/browse/JDK-8144262 > > > webrev: > http://cr.openjdk.java.net/~df

Re: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

Looks good, Roger On 12/02/2015 03:10 PM, Daniel Fuchs wrote: Hi, Please find below a fix for 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated https://bugs.openjdk.java.net/browse/JDK-8144262 webrev: http://cr.openjdk.java.net/~dfuchs/

RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Please review the java.lang.ref.Cleaner and tests following the recommendation to simplify the public interface to support only phantom cleanup. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ Javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Thanks, Ro

RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

Hi, Please find below a fix for 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated https://bugs.openjdk.java.net/browse/JDK-8144262 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 specdiff: http://cr.openjdk.java.net/~df

Re: Deprecation of LogRecord.getMillis in JDK9

On 02/12/15 02:13, Stuart Marks wrote: I'd recommend making setInstant() be more explicit about the range of Instant values that are allowed, namely those created from Instant.ofEpochMilli(long), which allows ± 292 million years from the epoch. Otherwise the reader is forced to try to understand

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

Kim, Thanks for sending this out. I like the 1-line fix in hotspot - simple and sweet. Mandy > On Dec 2, 2015, at 10:37 AM, Kim Barrett wrote: > > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This ch

Re: RFE Pre-review: Support for cloning exceptions

On Wed, Dec 2, 2015 at 1:32 AM, Peter Levart wrote: > > In short, I think exceptions are a special hierarchy with special use > pattern in which clone() would not present a practical problem that > generally arises in other objects that are meant to change state > independently from their creatio

RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

Please review this change to PhantomReference processing, changing the GC-based notification to automatically clear the referent. This change provides performance benefits by eliminating the work involved in keeping the otherwise inaccessible referent objects alive, as required by the existing spe

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

On 12/1/15 9:21 AM, Frederic Parain wrote: Hi Dan, Thank you for your detailed review. My answers are in-lined below. New webrev: http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ Re-reviewed by comparing 8046936.0[12].hotspot.patch in jfilemerge... Just a couple of nits: src

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

> On 2 Dec 2015, at 17:16, Peter Levart wrote: > > Hi Paul, > > Just a nit more: > > 120 int valuesPerWidth = LOG2_ARRAY_LONG_INDEX_SCALE - > log2ArrayIndexScale; > > Would it be more correct to call that variable log2ValuesPerWidth? > Yes, good point. Updated. I also used the con

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

On 02/12/2015 15:26, Chris Hegarty wrote: Thanks Max, I'm ok with this version, if you are. I'll include it in the final push. This version looks okay to me too. -Alan.

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

Hi Paul, The reason we stick on standard jtreg tests is because it is simpler. For us, a java test is not a unit test, it is an application. :) I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE. But debugging

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

Hi Paul, Just a nit more: 120 int valuesPerWidth = LOG2_ARRAY_LONG_INDEX_SCALE - log2ArrayIndexScale; Would it be more correct to call that variable log2ValuesPerWidth? Regards, Peter On 11/30/2015 04:21 PM, Paul Sandoz wrote: On 25 Nov 2015, at 10:53, Paul Sandoz wrote: Hi, An

Re: [9] RFR of 8032027: Add BigInteger square root methods

Hi Joe, On Dec 1, 2015, at 7:25 PM, Joseph D. Darcy wrote: > Current version looks okay. One more request, before pushing please add > explicit test cases for the for the largest number having 63 bits and the > smallest number having 64 bits. No need for another round of webrevs for that. OK,

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

Thank you, Paul. This looks good. Vladimir On 12/2/15 1:10 AM, Paul Sandoz wrote: On 2 Dec 2015, at 02:55, Vladimir Kozlov wrote: I reviewed 8143355 today and my main question is where are range checks? In this case the range checks are performed by the methods in Arrays, which call non

Re: Deprecation of LogRecord.getMillis in JDK9

My original thinking was that it not so much that 3rd party code doesn't care about nanoseconds it just that the code was built before the concept of nano time was added to LogRecords. The use cases for LogRecord.getMillis are: 1.g - Formatters for rendering the event time. 2.g - Filters for thr

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

> On Dec 2, 2015, at 11:26 PM, Chris Hegarty wrote: > > Thanks Max, > > I'm ok with this version, if you are. I'll include it in the final push. Please. --Max > > -Chris. > > On 02/12/15 15:13, Wang Weijun wrote: >> >>> On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: >>> >>> My fault to

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

Thanks Max, I'm ok with this version, if you are. I'll include it in the final push. -Chris. On 02/12/15 15:13, Wang Weijun wrote: On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll se

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

> On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: > > My fault to use an internal class. I should have simply used the hex > encoding. Please wait a while and I'll send you a fix. > > Thanks > Max

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

On 12/02/2015 02:56 PM, Doug Lea wrote: > On 32bit systems the 1MB limit is completely defensible. But expanding > to say 64MB on 64bit systems would reduce practical encounters with > SOE in these kinds of constructions by a factor of 64 or so. > Is there any reason not to do this? Some cloud VM

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

Updated to remove all use of reflection. If someone really wants to run S11N on an older JDK, then it is a simple edit to uncomment/comment 3 lines. http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/ -Chris. On 02/12/15 14:15, Chris Hegarty wrote: On 02/12/15 14:03, Alan Bateman

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Bringing Martin's JEP comment (https://bugs.openjdk.java.net/browse/JDK-8046936) to the lists: Approximately 100% of the cases of StackOverflowError (SOE) we hear about lately on concurrency-interest are due to long chains of CompletableFutures that exist because of the lack of tail-recursion lo

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. Thanks Max > On Dec 2, 2015, at 10:15 PM, Chris Hegarty wrote: > > On 02/12/15 14:03, Alan Bateman wrote: >> >> On 02/12/2015 12:08, Chris Hegarty wrote: >>> The regress

RFR(S): 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest

Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8143343 Webrev: http://cr.openjdk.java.net/~mhaupt/8143343/webrev.00 The change adds the JEP 274 Javadoc tests to JavaDocExamplesTest and fixes three glitches in the pertaining Javadoc. Thanks, Michael --

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

On 02/12/15 14:03, Alan Bateman wrote: On 02/12/2015 12:08, Chris Hegarty wrote: The regression tests in the jdk should be updated, where possible, to use java.util.Base64. http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ Should S11N be updated to serialize with JDK 8 so that th

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

On 02/12/2015 12:08, Chris Hegarty wrote: The regression tests in the jdk should be updated, where possible, to use java.util.Base64. http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ Should S11N be updated to serialize with JDK 8 so that the core reflection code isn't needed?

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

> On 2 Dec 2015, at 13:08, Chris Hegarty wrote: > > The regression tests in the jdk should be updated, where possible, to use > java.util.Base64. > > http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ > +1 Paul.

Re: Unexpected BindException in Endpoint.publish

Hi Yuji, thanks for the patch - it fixes the issue and looks ok to me. I'll integrate it to standalone JAX-WS repo and it will be integrated into openjdk during next syncup. Thanks Miran On 01/12/15 11:11, KUBOTA Yuji wrote: Hi Miroslav and all, Could you please review the below issue and

Re: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character

On 2015-11-18 23:26, Aleksey Shipilev wrote: By the way, I see there is a cleaner way to implement emitIconstInsn, see java.lang.invoke.TypeConvertingMethodAdapter.iconst: void iconst(final int cst) { if (cst >= -1 && cst <= 5) { mv.visitInsn(Opcodes.ICONST_0 + cst);

RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

The regression tests in the jdk should be updated, where possible, to use java.util.Base64. http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ -Chris.

Re: RFR(XS): 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping

Looks good. Best regards, Vladimir Ivanov On 12/2/15 12:34 PM, Michael Haupt wrote: Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8076596 Webrev: http://cr.openjdk.java.net/~mhaupt/8076596/webrev.00/ The bug was actually fixed by the fix to https://bugs.o

Re: RFR: 8143131: Remove unused code from java.lang.invoke

FTR IBG.localTypes was used for LambdaForm inlining [1] during MethodHandle customization prototype I did while working on LambdaForm caching. Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/lfc/enhancements/lf.inline On 12/1/15 7:06 PM, Claes Redestad wrote: Hi, plea

Re: RFR: 8143131: Remove unused code from java.lang.invoke

Reviewed. Best regards, Vladimir Ivanov On 12/1/15 7:06 PM, Claes Redestad wrote: Hi, please review this patch to cleanup various things in and around java.lang.invoke: Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/ /Clae

Re: RFR(XS): 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping

+1 -Sundar On 12/2/2015 3:04 PM, Michael Haupt wrote: Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8076596 Webrev: http://cr.openjdk.java.net/~mhaupt/8076596/webrev.00/ The bug was actually fixed by the fix to https://bugs.openjdk.java.net/browse/JDK-813

RFR(XS): 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8076596 Webrev: http://cr.openjdk.java.net/~mhaupt/8076596/webrev.00/ The bug was actually fixed by the fix to https://bugs.openjdk.java.net/browse/JDK-8136893; the proposed change adds a test for the original bu

Re: RFE Pre-review: Support for cloning exceptions

Hi Martin, On 12/02/2015 06:48 AM, Martin Buchholz wrote: I very much want object copying to be simple and easy, but Cloneable has been under a cloud for a very long time and Effective Java Item 11 advises to stay away from it. I'm aware of potential problems with clone() method in general.

Re: RFR 6856817: Poor performance of Writer#append with CharBuffer

Hi Vyom, Looks good to me too. If you don't get more comments from reviewers, send me the exported changeset and I'll push it for you. best regards, -- daniel On 11/25/15 3:29 PM, vyom wrote: Hi All, Please review my changes for below bug. Bug:JDK-6856817 : Poor performance of Writ

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

> On 2 Dec 2015, at 02:55, Vladimir Kozlov wrote: > > I reviewed 8143355 today and my main question is where are range checks? > In this case the range checks are performed by the methods in Arrays, which call non-checking type-specific methods in ArraysSupport that in turn call vectorizedMi

Re: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service

Hi Hamlin, This looks good to me. I can sponsor this change. best regards, -- daniel On 12/2/15 8:14 AM, Hamlin Li wrote: Hi Daniel, Thanks for the review, I follow you suggestion to create a new RFE https://bugs.openjdk.java.net/browse/JDK-8144460 to track the pushing for this new test.

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

Hi Christian, > On 1 Dec 2015, at 20:19, Christian Tornqvist > wrote: > > Hi Paul, > > Tests in hotspot/test/runtime needs to be jtreg tests. They are jtreg tests. They are require to be run (re: “launched") with jtreg see: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-