Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v2]

Hi Valerie, many thanks for the thorough review. I've taken all your feedback on board with the latest push. Some of the test anomalies were a result of previous iterations of test edits I had been making. Regarding the extra edits in "src/java.base/share/lib/security/default.policy", I had

Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads

Thank for the feedback Peter. Comments inline. On 22/06/2021 22:40, Peter Firmstone wrote: Was ever to run with SecurityManager? I found the issue while porting to jdk8u where Solaris uses a configuration file with the SunPKCS11 Provider by default - We have tests to register Providers while

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

. JavaUtilZipFileAccess.java #44: Change posixPerms to extraAttrs. ZipFile.java #661: Suggest to keep the comment and update it with the additional 4 bits for symlink. The rest of code changes and CSR look good. Thanks, Hai-May On Aug 28, 2020, at 7:17 AM, Seán Coffey <mailto:sean.cof...@oracle.

Re: RFR: 8249694 - [TestBug] java/lang/StringBuffer/HugeCapacity.java and j/l/StringBuilder/HugeCapacity.java tests shouldn't be @ignore-d

;= 6G) Regards, Fernando On 1 Sep 2020, at 17:25, Seán Coffey <mailto:sean.cof...@oracle.com>> wrote: Wouldn't you require the sun.arch.data.model == "64" jtreg config in these tests also ? regards, Sean. On 28/08/2020 19:13, Fernando Guallini wrote: Hi, May

Re: RFR: 8249694 - [TestBug] java/lang/StringBuffer/HugeCapacity.java and j/l/StringBuilder/HugeCapacity.java tests shouldn't be @ignore-d

Wouldn't you require the sun.arch.data.model == "64" jtreg config in these tests also ? regards, Sean. On 28/08/2020 19:13, Fernando Guallini wrote: Hi, May I please get reviews and a sponsor for this trivial change: webrev: http://cr.openjdk.java.net/~fguallini/8249694/webrev.00/

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

28, 2020, at 10:17 AM, Seán Coffey wrote: I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of inter

Re: RFR: JDK-8249699: java/io/ByteArrayOutputStream/MaxCapacity.java should use @requires instead of @ignore

Apologies. Meant to reply yesterday. Your edit looks fine to me. regards, Sean. On 27/08/2020 16:41, Fernando Guallini wrote: Thanks Sean, updated webrev here: http://cr.openjdk.java.net/~fguallini/8249699/webrev.01/ Regards, Fernando - Original Message - From: sean.cof...@oracle.com

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of interest in the signed zip file. New testcase

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. regards, Sean. No other comment. Thanks, Max On Aug 27, 2020, at 3:26 AM, Seán Coffey wrote: updated webrev: http://cr.op

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

updated webrev: http://cr.openjdk.java.net/~coffeys/webrev.8250968.v2/webrev/ regards, Sean. On 27/08/2020 07:42, Seán Coffey wrote: Hi Max, I looked at updating the warning string but figured that it might have been of no interest to end users. How about this edit

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

5, Weijun Wang wrote: Are you going to update the warning text or create a new one? Thanks, Max On Aug 26, 2020, at 2:26 PM, Seán Coffey wrote: This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should p

Re: RFR: JDK-8249699: java/io/ByteArrayOutputStream/MaxCapacity.java should use @requires instead of @ignore

test/jdk/java/util/Base64/TestEncodingDecodingLength.java is an example of another test using -Xmx8g. Do you want to push the os.maxMemory requirement up to 10g perhaps ? It might avoid border line resource failures. Also I think it might need a "sun.arch.data.model == "64" " requirement :

RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in

Re: RFR: JDK-8249691: jdk/lambda/vm/StrictfpDefault.java file can be removed

Looks fine to me Evan. regards, Sean. On 17/08/2020 16:25, Evan Whelan wrote: Hi all, This is a small fix that helps with some test cleanup. One redundant test file has been removed. Webrev found at: http://cr.openjdk.java.net/~kravikumar/8249691/webrev/ Link to JBS issue:

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

ected. These attributes are ignored when signing and are not protected by the signature." regards, Sean. On 02/07/2020 08:59, Alan Bateman wrote: On 30/06/2020 14:51, Seán Coffey wrote: : During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warn

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

t\\.report\\(.*,\"(.*?)\","); If you agree to add a whitespace in the calls in OSCP.java and DistributionFetcher.java, you might want to add a whitespace (or "\s*") here as well. Thanks, Max On Jun 30, 2020, at 9:51 PM, Seán Coffey wrote: Thanks Lance. During the

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

/ regards, Sean. On 22/06/2020 17:17, Lance Andersen wrote: HI Sean, Looks OK based on our exchanges.  Thank you for your time on this one! Best Lance On Jun 22, 2020, at 7:22 AM, Seán Coffey <mailto:sean.cof...@oracle.com>> wrote: Thanks Lance. I've updated the patch with some extr

Re: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/ regards, Sean. On 12/06/2020 17:05, Lance Andersen wrote: Hi Sean, I think your changes look fine so all good FMPOV. Best Lance On Jun 12, 2020, at 6:21 AM, Seán Coffey <mailto:sean.cof...@oracle.com>> wrote: Hi, I'd like to reboot this

RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

Hi, I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms https://bugs.openjdk.java.net/browse/JDK-8218021

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

I've also created JDK-8238688 to track the specification clarification request. I'll start an RFR for that shortly. Regards, Sean. On 07/02/20 14:23, Seán Coffey wrote: I've introduced such a class: FactoryInitializationError Also added a new simple testcase method check for case where

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

I've introduced such a class: FactoryInitializationError Also added a new simple testcase method check for case where this new exception would be exercised : testBadContextCall(Hashtable) http://cr.openjdk.java.net/~coffeys/webrev.8223260.v4/webrev/

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

On 6 February 2020 21:13:52 GMT, Peter Levart wrote: > > >On 2/6/20 6:54 PM, Seán Coffey wrote: >> the current proposal is still: >> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/ > >But wasn't this one already better: > >https://cr.openjdk.ja

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

the current proposal is still: http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/ I'd like to make the specification change in a follow on bug ID (if that works for people) Regards, Sean. On 06/02/20 17:49, Alan Bateman wrote: On 06/02/2020 15:32, Seán Coffey wrote

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

On 05/02/20 16:51, Daniel Fuchs wrote: On 05/02/2020 15:31, Peter Levart wrote: I think this is about allow the InitialContextFactory instance to be GC'ed when the thread is long lived. It might not be a concern for the LDAP or the other providers in the JDK. -Alan Ah, I see. You mean

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

lso - I'm hoping to port this to JDK 11u also so I might spin the specification changes into a different bug ID. regards, Sean. On 03/02/2020 09:05, Peter Levart wrote: Hi Seán, On 2/1/20 12:22 AM, Seán Coffey wrote: The following is also possible:     // 1st try find

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

Peter, thanks again for your review. comments inline.. On 31/01/2020 17:16, Peter Levart wrote: Hi Seán, On 1/31/20 2:16 PM, Seán Coffey wrote: Thanks for the review Peter. All good points! My latest patch contains adjustments based on feedback from you and others to date. * Incorporate

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

our purpose. Regards, Peter On 1/29/20 6:22 PM, Seán Coffey wrote: Thanks for the reviews. I found an issue with the new test also - it's loading the custom factory class via the non-serviceloader approach. I was hoping to exercise ServiceLoader here. I'll address this and the comments rai

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

Thanks for the reviews. I found an issue with the new test also - it's loading the custom factory class via the non-serviceloader approach. I was hoping to exercise ServiceLoader here. I'll address this and the comments raised and revert with a new patch shortly. Regards, Sean. On 29/01/20

RFR: 8223260: NamingManager should cache InitialContextFactory

Looks like we can improve performance in this area. I've put together a testcase which exercises the ServiceLoader and keeps track of whether we're able to cache or not. https://bugs.openjdk.java.net/browse/JDK-8223260 http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/ regards,

Re: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

tools docs accordingly. Let me have a think about this. A new flag in jarsigner may help. regards, Sean. Regards, Philipp On Fri, 2020-01-17 at 13:07 +, Seán Coffey wrote: Hi Philipp, On 17/01/2020 12:40, Philipp Kunz wrote: Hi Sean, Nice patch. I wonder why permissions should be preserv

Re: RFR: 8237508: Simplify JarFile.isInitializing

Looks good to me Claes - thanks for fixing. Regards, Sean. On 20/01/20 12:15, Claes Redestad wrote: Makes sense to keep even trivial logic out of the access bridge. Let's also clean up the placement of the static variable and the pre-existing use of the unconventional "final static" combo:

Re: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

d the test would not have to check that files with another name extension than zip don't preserve permissions. Philipp On Fri, 2020-01-17 at 10:59 +0000, Seán Coffey wrote: Hi, Looking to introduce some JDK private functionality which will help preserve internal zip file attribute permis

RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

Hi, Looking to introduce some JDK private functionality which will help preserve internal zip file attribute permissions when jarsigner is run on a zip file. Some of the logic is taken from the recent work carried out in this area for zipfs API.

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

Thanks Alan. Updates made and changes pushed. regards, Sean. On 13/01/2020 18:50, Alan Bateman wrote: On 13/01/2020 10:28, Seán Coffey wrote: some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure expectations are in place. http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/ Hope this

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

/webrev/ regards, Sean. On 16/12/2019 14:15, Seán Coffey wrote: The recent crypto event logging mechanism (JDK-8148188) has introduced a regression whereby the System Logger may be invoked too early in the bootstrap phase. This causes issue when JarFile objects are locked by JarFile verifier

RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

The recent crypto event logging mechanism (JDK-8148188) has introduced a regression whereby the System Logger may be invoked too early in the bootstrap phase. This causes issue when JarFile objects are locked by JarFile verifier initialization code. The logging work records an X509 Certificate

Re: RFR: 8232984: Upgrading Joni License version to 2.1.16

Looks fine to me. I can push this for you. Regards, Sean. On 04/11/19 10:04, Kiran Ravikumar wrote: Hi, Please review this patch to update the joni version to 2.1.16. JBS: https://bugs.openjdk.java.net/browse/JDK-8232984 License File: https://github.com/jruby/joni/blob/joni-2.1.16/LICENSE

Re: RFR of JDK-8134599: TEST_BUG: java/rmi/transport/closeServerSocket/CloseServerSocket.java fails intermittently with Address already in use

Quite a while since I touched this one! The nature of the test is a bit flaky given that we're assuming no other process will use the chosen port. I'm not sure if a concrete solution is possible. One other option is to have this test run in non-concurrent mode by editing test/jdk/TEST.ROOT -->

Re: RFR: JDK-8231770 - Test java/util/zip/FlaterTest.java fails with -Xcheck:jni

Looks good Kiran. I'll sponsor this for you. regards, Sean. On 08/10/2019 17:17, Kiran Ravikumar wrote: Hi Guys, I am a new hire with the Oracle Java Platform Group and will be working mainly on JDK Update releases. Below is my first contribution. Looking forward to contribute more to the

RFR: 8231124: Missing closedir call with JDK-8223490

A minor issue that was introduced via my recent JDK-8223490 fix. One which I noticed while backporting the edits.. https://bugs.openjdk.java.net/browse/JDK-8231124 proposed patch: diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c b/src/java.base/unix/native/libjava/TimeZone_md.c

Re: RFR: 8223490: Optimize search algorithm for determining default time zone

'\t') p++; #define RESTARTABLE(_cmd, _result) do { \ Regards, Sean. On 13/09/19 13:01, Roger Riggs wrote: Hi Sean, The declaration can be up in the _md.c file to satify the compiler about forward declarations. $.02, Roger On 9/13/19 4:34 AM, Seán Coffey wrote: Thanks for the review Roger.

Re: RFR: 8223490: Optimize search algorithm for determining default time zone

pathname" is an argument to this function, so freeing it inside the function seems odd. Also, no need to reset dbuf/fd since they are no longer reused in the loop. Naoto On 9/11/19 3:50 AM, Seán Coffey wrote: The current algorithm for determining the default timezone on (non-AIX) unix systems goe

Re: RFR: 8223490: Optimize search algorithm for determining default time zone

he last function to use 'pathname'. However, it's not in keeping with normal design I guess. I've reverted and now free pathname at other call sites instead. new webrev at http://cr.openjdk.java.net/~coffeys/webrev.8223490.v2/webrev/ regards, Sean. Naoto On 9/11/19 3:50 AM, Seán Coffey wrote:

RFR: 8223490: Optimize search algorithm for determining default time zone

The current algorithm for determining the default timezone on (non-AIX) unix systems goes something like : 1. If TZ environment variable is defined, use it 2. else if /etc/timezone exists, use the value contained within it 3. else if /etc/localtime exists and is a symbolic link, use the name

Re: [13u]: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b

Looks good Ramanand. regards, Sean. On 06/08/2019 06:57, Ramanand Patil wrote: 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

RFR: 8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1

Reports that this test is failing intermittently over past few months. It's a rare occurrence but I'd like to take steps to correct it. I've removed the dependence on randomness in the bug. I've fixed up the zip file creation logic to produce a real zip file I've renamed the file to a unique

Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710

Looks good. regards, Sean. On 21/02/2019 08:54, Deepak Kejriwal wrote: Hi Naoto, Corrected the exception message. Please find below updated version of webrev:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/ Thanks for review. Regards, Deepak

Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

Thanks. Looks good to me. regards, Sean. On 21/02/2019 09:10, Deepak Kejriwal wrote: Hi Sean, The webrev I shared was not correct. I have corrected the webrev.02 now. Please check now:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ Regards, Deepak *From:*Seán

Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

Deepak, this exception message in new test still needs correction: 166 "Character.isLetter(int) failed for codepoint " 167 + Integer.toHexString(cp)); As an aside, there's probably no need for such specific exception messages in a

Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710

Looks fine to me. some minor comments on formatting : space after "//" style comments in your new tests : e.g //List of new code points are not present in Unicode 6.2. 39 add(0x20BB); //NORDIC MARK SIGN 40

Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

Deepak, changes look fine to me. Some minor comments on formatting : make a space after all  "//" comments e.g. + //isJavaIdentifierStart strictly conforms to code points assigned + //in Unicode 10.0. Since code point {32FF} is not from Unicode 10.0, + //return false.

Re: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra

Thanks for the reviews. Here's the final webrev which I hope to sponsor for Deepak once I have the necessary approvals. http://cr.openjdk.java.net/~coffeys/webrev.8212941.jdk8u/webrev/ Regards, Sean. On 28/01/19 16:06, Naoto Sato wrote: +1 Naoto On 1/28/19 3:18 AM, Chris Hegarty wrote:

Re: RFR: 8182992 Typo in DatagramPacket constructor API doc

Looks fine to me. We can update the bug summary to make it more general to affected classes. I can help sponsor this change if required. regards, Sean. On 03/01/2019 16:51, Roger Calnan wrote: I was looking at the fix for: https://bugs.openjdk.java.net/browse/JDK-8182992 Typo in

Re: RFR: 8148188: Enhance the security libraries to record events of interest

/11/18 21:09, Seán Coffey wrote: Hi Sean, comments inline.. On 13/11/2018 18:53, Sean Mullan wrote: Looking good, a couple of comments/questions: * src/java.base/share/classes/java/security/Security.java The isJdkSecurityProperty method could return false positives, for example there may

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Thanks for the comments Weijun. As per other review thread, I'm now recording all properties set via Security.setProperty(String, String). regards, Sean. On 14/11/2018 01:11, Weijun Wang wrote: Confused. Aren't all Security properties security-related? This is not about normal system

Re: RFR: 8148188: Enhance the security libraries to record events of interest

/jdk/jdk/security/logging/TestTLSHandshakeLog.java --Sean On 11/6/18 3:46 AM, Seán Coffey wrote: With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk code. Some modifications also made based on off-thread suggestions : src/java.base/share/classes/java/security/Security.java

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Erik, comments inline.. On 08/11/18 15:12, Erik Gahlin wrote: Hi Sean, I think we could still call the event "jdk.SecurityPropertyModification", but add a @Description that explains that events are only emitted for the JDK due to security concerns. If we at a later stage want to include

Re: RFR: 8148188: Enhance the security libraries to record events of interest

/ Regards, Sean. On 17/10/18 11:25, Seán Coffey wrote: I'd like to re-boot this review. I've been working with Erik off thread who's been helping with code and test design. Some of the main changes worthy of highlighting : * Separate out the tests for JFR and Logger events * Rename some events

Re: RFR: 8148188: Enhance the security libraries to record events of interest

is dependent on the JDK-8203629 enhancement being integrated. Regards, Sean. On 10/07/18 13:50, Seán Coffey wrote: Erik, After some trial edits, I'm not so sure if moving the event & logger commit code into the class where it's used works too well after all. In the code you suggested, the

Re: How to detect that a VM was started with --enable-preview ?

would `jcmd VM.info | grep jvm_args:` help ? or `jcmd VM.command_line` regards, Sean. On 09/10/2018 16:20, Remi Forax wrote: Hi all, it seems that there is no simple way* to detect if a VM is started with --enable-preview or not ? Rémi * apart using JMX to sniff the VM command line with

Re: RFR[12] JDK-8211107: LDAPS communication failure with jdk 1.8.0_181

Correction looks good to me. regards, Sean. On 02/10/2018 02:09, Prasadrao Koppula wrote: Hi, Could you please review this patch. This patch fixes the regression caused by LDAP fixes in JDK11, JDK8u181, JDK7u191 Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/

Re: RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents of empty JAR file

This RFR should be removed from core-libs-dev. nio-dev is the correct mailing list. The test needs to be fixed before that happens (and possibly the code also) regards, Sean. On 25/09/2018 06:53, Deepak Kejriwal wrote: Hi, Gentle reminder for review below fix. Regards, Deepak

Re: RFR: 8148188: Enhance the security libraries to record events of interest

ould handle Logger via its own framework/API in a future JDK release. I've removed the variable names using underscore. Also optimized some variable assignments in X509Impl.commitEvent(..) http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ regards, Sean. On 09/07/2018 18:01, Seán Co

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Erik, Thanks for reviewing. Comments inline.. On 09/07/18 17:21, Erik Gahlin wrote: Thanks Sean. Some feedback on the code in the security libraries. - We should use camel case naming convention for variables (not underscore). Sure. I see two offending variable names which I'll fix up. -

Re: RFR: 8148188: Enhance the security libraries to record events of interest

and modifications carried out to clean up the code up further. http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ This enhancement has a dependency on JDK-8203629 Regards, Sean. On 02/07/18 09:49, Erik Gahlin wrote: On 29 Jun 2018, at 17:34, Seán Coffey wrote: I've introduced a new

Re: RFR: 8148188: Enhance the security libraries to record events of interest

t;KiB" - not the normal when examining key lengths used in X509Certificates. i.e a 2048 bit key gets displayed as "2 KiB" - I'd prefer to keep the 2048 display version. new webrev at: http://cr.openjdk.java.net/~coffeys/webrev.8148188.v4/webrev/ Regards, Sean. On 28/06/18 17:5

Re: RFR: 8148188: Enhance the security libraries to record events of interest

for the update Erik. By default I'm proposing that the new JFR Events and Logger be disabled. As a result the event class shouldn't escape. If performance metrics highlight an issue, we should revisit. regards, Sean. On 27/06/2018 20:57, Erik Gahlin wrote: On 2018-06-27 21:1

Re: RFR: 8148188: Enhance the security libraries to record events of interest

new to record events.  I did not get the point to use both. I was initially hoping to concentrate on just JFR events but I got strong feedback to also consider use of Logger (esp. in cases where the jdk.jfr module is not available) regards, Sean. Thanks, Xuelei On 6/26/2018 3:18 PM, Seán Coffey

Re: RFR: 8148188: Enhance the security libraries to record events of interest

the above code will create a new instance.  Is the return value of cce.isEnabled() dynamically changed or static? Is there a need to support both logging and JFR?  I'm new to record events.  I did not get the point to use both. Thanks, Xuelei On 6/26/2018 3:18 PM, Seán Coffey wrote: Erik

Re: RFR: 8148188: Enhance the security libraries to record events of interest

/26/2018 3:18 PM, Seán Coffey wrote: Erik, I rebased the patch with TLS v1.3 integration today. I hadn't realized how much the handshaker code had changed. Hopefully, I'll get a review from security dev team on that front. Regards the JFR semantics, I believe the edits should match majority of

Re: RFR: 8148188: Enhance the security libraries to record events of interest

log/record functionality. I might catch up with you tomorrow to see what the best arrangement would be. http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ regards, Sean. On 25/06/2018 21:22, Seán Coffey wrote: Many thanks for the review comments Erik. Replies inline. On 24/06

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Many thanks for the review comments Erik. Replies inline. On 24/06/2018 14:21, Erik Gahlin wrote: Hi Sean, Some of the changes in the webrev belongs to JDK-8203629 and should be removed for clarity. Some initial comments: default.jfc, profile.jfr: The events should not have

RFR: 8148188: Enhance the security libraries to record events of interest

Following on from the recent JDK-8203629 code review, I'd like to propose enhancements on how we can record events in security libs. The introduction of the JFR libraries can give us much better ways of examining JDK actions. For the initial phase, I'm looking to enhance some key security

Re: RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr

Thanks for implementing this enhancement Erik. I think it'll prove to be popular given the functionality available in JFR recordings. I'd agree with Alan's comment that the Event class could be documented better to indicate its purpose. I'm already using this enhancement to implement some new

Re: [RFR] 8204539: improve error messages in matchJavaTZ [windows]

Looks good. Thanks for adding this improvement. Regards, Sean. On 08/06/18 12:28, Baesken, Matthias wrote: Hi Goetz/Christoph, thanks for the reviews . However of course Sean is absolutely correct about the null character message output. Updated the null character related message output

Re: [RFR] 8204539: improve error messages in matchJavaTZ [windows]

Not sure if this has been tested. Don't you need to escape the printing of the \0 character ? errorMessage = "illegal character \0 found"; regards, Sean. On 08/06/2018 08:14, Langer, Christoph wrote: Hi Matthias, this looks good. Reviewed from my end. Best regards Christoph

Re: [RFR] 8204539: improve error messages in matchJavaTZ [windows]

On 07/06/2018 13:03, Baesken, Matthias wrote: Hi Christoph you are correct I compiled it on the wrong platforms , stupid mistake ! Will send an updated web rev . * Also, mapFileName can't be used at this place, because it has already been free'ed there. Yes, makes sense. Will move

Re: [8u-dev] Request for Review and Approval to Backport 8203368: ObjectInputStream filterCheck method throws NullPointerException

Looks fine. Approved for jdk8u-dev. regards, Sean. On 31/05/2018 02:40, Ivan Gerasimov wrote: Hello! I'd like to backport the fix to JDK 8u-dev. Both source patch and the regression test had to be adjusted slightly due to the code divergence, thus the review request. Bug:

Re: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution

The Cipher tests were re-grouped via https://bugs.openjdk.java.net/browse/JDK-8132855 NIO re-grouped via https://bugs.openjdk.java.net/browse/JDK-8132854 All appears connected with exercising hotspot intrinsics in tier1 testing. regards, Sean. On 17/04/2018 08:10, Alan Bateman wrote: On

RFR : 8196854 :TestFlushableGZIPOutputStream failing with IndexOutOfBoundsException

A jdk8u (and earlier) issue where some new/recent test code meant that IndexOutOfBoundsException could be thrown. https://bugs.openjdk.java.net/browse/JDK-8196854 http://cr.openjdk.java.net/~coffeys/webrev.8196854/webrev/ The buf array was never required and I've verified that the original

Re: JDK-8166339,Code conversion working behavior was changed for x-IBM834

Looks fine to me Sherman. regards, Sean. On 30/01/2018 22:59, Xueming Shen wrote: Hi, Please help review the change for JDK-8166339. issue: https://bugs.openjdk.java.net/browse/JDK-8166339 webrev: http://cr.openjdk.java.net/~sherman/8166339/webrev This is a regression triggered by issue:

Re: RFR[JDK10]: 8195837: (tz) Support tzdata2018c

The changes look fine to me Ramanand. The europe file contains some interesting comments about the rolled back changes that have been made for 2018c. A plan on how to resolve these pending changes can be followed up via JDK-8195595 Regards, Sean. On 29/01/18 08:49, Ramanand Patil wrote: Hi

Re: Oracle Java 8u161 regression in XML Schema Factory

)         at com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:125)         ... 15 more Resource bundle loading issue...could that be related to this XML issue here? Thanks, Kris On Thu, Jan 25, 2018 at 8:41 AM, Seán Coffey <sean.cof...@oracle.com <mailto:sean.cof...@oracle.com&g

Re: Oracle Java 8u161 regression in XML Schema Factory

On 25/01/2018 11:58, Bernd wrote: Hello, some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and u162) but work with 8u152. I cant reproduce the fault in a stand-alone program so it seems to be related to classloader/reflection magic of those tools, sorry. Is this a

Re: Adding SocketChannel toString to connection exception messages

As someone who works with alot of log files, I'd like to chime in and support Steven's end goal. Looking at a "Connection refused" error in the middle of a log file that possibly extends to millions of lines is near useless. In the era of cloud compute, diagnosing network issues is sure to

Re: RFR: JDK8u Backport of 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit

Looks fine to me. regards, Sean. On 18/12/2017 11:41, Ramanand Patil wrote: Hi all, Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8153955 Backport Bug: https://bugs.openjdk.java.net/browse/JDK-8161266 Webrev:

Re: RFR JDK-8191918: tomcat gzip-compressed response bodies appear to be broken in update 151

Looks good to me. Regards, Sean. On 02/12/17 01:04, Xueming Shen wrote: On 12/1/17, 3:40 PM, Paul Sandoz wrote: On 30 Nov 2017, at 14:46, Xueming Shen wrote: Hi, Please help review the change for JDK-8191918: issue:

Re: RFR: JDK8U Backport of 8154017: Shutdown hooks are racing against shutdown sequence, if System.exit()-calling thread is interrupted

Looks fine. Regards, Sean. On 27/11/17 08:17, Muneer Kolarkunnu wrote: Hi All, Please review this webrev for jdk8u backport. Webrev: http://cr.openjdk.java.net/~akolarkunnu/8191289/webrev.00/ Main Bug: https://bugs.openjdk.java.net/browse/JDK-8154017 JDK10 review thread:

Re: 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151

rom the main zlib repo for that change [1] regards, Sean. [1] https://github.com/madler/zlib/issues/275 Thanks, Paul On 11/22/17, 2:00 AM, "core-libs-dev on behalf of Seán Coffey" <core-libs-dev-boun...@openjdk.java.net on behalf of sean.cof...@oracle.com> wrote: Look

RFR: 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151

Looking to fix a recent regression that appeared in 8u151. Thanks goes to Sherman for the src patch. Paul Hohensee has also helped by provided some test code. I've been able to modify an existing test to mimic the behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x.

Re: Incorrect validation of DST in java.util.SimpleTimeZone

I think the OpenJDK mailing lists accept attachments if in patch format. If it's a simple short patch, it's acceptable to paste it into email body. Easiest solution is to use webrev[1]. If you can't upload this to cr.openjdk.java.net - then one of your colleagues may be able to help. [1]

Re: [8u-dev][JAXB] Request for review and approval: 8159240: XSOM parser incorrectly processes type names with whitespaces

This looks fine Aleksei.  Approved for jdk8u-dev. The JDK-8159240 record is currently closed as a duplicate. I'd suggest you reopen that master record for your 8u-dev port and mark it 9-na. regards, Sean. On 27/09/2017 22:28, Aleks Efimov wrote: Hi, Can I, please, ask for review and

Re: RFR: JDK8U Backport of 8185346: Relax RMI Registry Serial Filter to allow arrays of any type

Looks good. Regards, Sean. On 17/08/17 20:06, Ramanand Patil wrote: Hi All, Please review this webrev for jdk8u backport. Webrev: http://cr.openjdk.java.net/~rpatil/8185346/jdk8u-dev/webrev.00/ Main Bug: https://bugs.openjdk.java.net/browse/JDK-8185346 JDK10 review thread:

Re: RFR 8185346 : Relax RMI Registry Serial Filter to allow arrays of any type

Looks fine to me Roger. Thanks for handling. Should the testcase get an @bug tag ? regards, Sean. On 03/08/2017 15:25, Roger Riggs wrote: Please review a relaxation of the serial filter checks on the RMI Registry. Arrays of any type are serializable and do not pose a risk except based on

Re: 8179527:(8182743?) Ineffective use of volatile hurts performance of Charset.atBugLevel()

Ogata, minor comments from me. * The bug ID referenced in mail/webrev links is wrong. It should be 8182743 ? * The copyright change in Charset-X-Coder.java.template is the wrong format. You can simply replace 2013 with 2017. Regards, Sean. On 29/06/17 19:49, Kazunori Ogata wrote: Hi

Re: Bug in File.getLastModified()

Hi Brian, I think it's worth fixing unless there are objections. I see Stuart's comment about compatibility and wonder if we've any examples of such applications. I just put together a patch [1] for this. I'm still figuring out how nanoseconds get recorded for macosx.

Re: Bug in File.getLastModified()

Ricardo, I see that JDK-8177809[1] has been logged. The newer NIO APIs can report back with higher time precision and it's probably best to use those. JDK-6939260 is related to your issue also. Returning a ms value not equal to the ms value used in the setLastModified call does seem

Re: [8u-dev] (XS) RFR 8169056: StringIndexOutOfBoundsException in Pattern.compile with CANON_EQ flag

Looks good. regards, Sean. On 23/03/2017 00:26, Ivan Gerasimov wrote: Hello! This is an 8u-dev only fix. (In 9 the bug was fixed with a massive update [1]). The fix is essentially one-liner: just check that the index remains within the bounds after update. Regression test was updated to

Re: RFR: JDK-8173094, 8173751, 8173752, 8173755, 8173802

roy/8173094/webrev.01/> Thanks, Abhijit On 2/10/2017 10:37 PM, Seán Coffey wrote: Hi Abhijit, you'll need to correct the Copyright year format in your edits. It needs to be "Copyright (c) , , Oracle..." format. For the ZipFile change, you need to use lower case 's' in @since. Look

  1   2   3   4   >