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 https://cr.openjdk.java.net/~cof

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

https://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:[email protected]>> wrote: Hi, I'd like to re

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:[email protected]>> wrote: Thanks Lance. I've updated the patch with some

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

"Event\\.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:

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

ibutes detected. 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 def

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: ht

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 ZipFil

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 : @r

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

eijun 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: 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 then

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://

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 added

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: [email protected]

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

x On Aug 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

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/ Tes

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:[email protected]>> 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,

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

the code. 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.

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 fil

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 pa

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 po

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

ful approach given that it's the 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

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

arens for the if statement. - Line 232-242: "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 t

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

#x27; || *p == '\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: Tha

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: 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 co

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: 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

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: 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

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()

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

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. https://bugs.openjdk.java.net/browse/JDK-82180

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

hat question and 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 +, Seán Coffey wrote: Hi, Looking to introduce some JDK private functionality which will help preserve internal zip f

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: htt

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

r file specs and jar and jarsigner 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 wonde

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, Sean

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 1

Re: RFR: 8223260: NamingManager should cache InitialContextFactory

ight for your 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

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

ng into that now. Also - 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:

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 whe

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

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.openj

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

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

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 S

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

Code review request for 7049774

7049774 : UID construction appears to hang if time changed backwards I'm looking for code review of above reported issue. If system clock goes backwards on rmi server with active clients and 64k UID boundary is hit, the server will wait until system time progresses past the time at which UID cl

Re: Code review request for 7049774

ith the same time. This would allow a much larger number of UID's to be created before encountering the issue you are seeing? I'm guess that this change is actually targeted to jdk8, rather than the 'compare against' gate shown in the webrev. -Chris. On 06/ 9/11 04:26 PM,

Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use

http://bugs.sun.com/view_bug.do?bug_id=7082769 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8/ Bug fix where we ensure that the fd object is not disposed of until all streams are closed out. Testcase is a bulked up version of CR 6322678 (which wasn't committed at t

Re: Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use

I might have to intermix try with resources and some try/finally blocks. regards, Sean. On 09/09/11 12:25, Alan Bateman wrote: Seán Coffey wrote: http://bugs.sun.com/view_bug.do?bug_id=7082769 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8/ Bug fix where we ensure that t

Re: Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use

easier to read with old style. Regards, Sean. On 09/09/2011 14:08, Seán Coffey wrote: Good points Alan. Coding styles probably differ from merging two testcases together. I'll clean up on the issues mentioned and send out the new webrev shortly. I thought about try with resources in a

Code review request: 7101658 : Backout 7082769 changes

bug ID : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7101658 (bug report not visible yet) changes for 7082769 fix have led to behavioral changes which can lead to native file descriptor exhaustion. Basically - file descriptors are not released until all streams referencing them are clos

code review request : 7099658 : Properties.loadFromXML fails with ClassCastException

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7099658 Simple fix where loadFromXML method should call into the standard API and use the getDocumentElement() call to obtain the properties Element. http://cr.openjdk.java.net/~coffeys/webrev.7099658/ regards, Sean.

code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

This is a second stab at cleaning up the close() and finalize() methods for FileInputStream / FileOutputStream / RandomAccessFile classes so that all parents/referents sharing the same native FileDescriptor are closed out correctly. With Alan's assistance, we have a better implementation in p

Re: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

On 30/10/2011 16:33, Alan Bateman wrote: On 28/10/2011 19:13, Seán Coffey wrote: This is a second stab at cleaning up the close() and finalize() methods for FileInputStream / FileOutputStream / RandomAccessFile classes so that all parents/referents sharing the same native FileDescriptor

Re: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

Lee wrote: On 10/29/2011 02:13 AM, Seán Coffey wrote: This is a second stab at cleaning up the close() and finalize() methods for FileInputStream / FileOutputStream / RandomAccessFile classes so that all parents/referents sharing the same native FileDescriptor are closed out correctly. With

Re: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

The fd count was only used if it was the finalizer thread. Any explicit close() call not from finalizer meant that the FD got closed. /* * If FileDescriptor is still in use by another stream, the finalizer * will not close it. */ if ((useCount <= 0) |

Re: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

On 02/11/2011 06:35, Alan Bateman wrote: On 01/11/2011 09:47, Seán Coffey wrote: : Are you referring to the parent.close() call ? If otherParents is null, then we only have one reference to this FileDesriptor - i.e the Stream that has called close(). It's parent.close() that I'm

Re: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

a comments added to FileDescriptor to help read code I'll leave the javadoc changes for another bugID/CCC request. regards, Sean. On 02/11/11 06:35, Alan Bateman wrote: On 01/11/2011 09:47, Seán Coffey wrote: : Are you referring to the parent.close() call ? If otherParents is null, then w

code review request : 7091388:Regular unexplained npe's from corba libs after system has been running for days

currently not live on bugs.sun.com but hope to get it up there shortly : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7091388 I'm porting fix for 7091388 forward to JDK8 (and then 7u) This is a fix in the CDRInputStream_1_0.close()/ CDROutputStream_1_0.close() methods where shared buffer

code review request : JDK 8 : RegistryImpl clean up (7102369)

Some clean up of the RMI RegistryImpl class is necessary after late changes made in the last set of update releases. This is a webrev to bring the code into sync with 6uX, 7uX. The java.rmi.server.codebase property no longer needs to be parsed by the registryImpl. webrev : http://cr.openjdk.java

Code review request for 7058133 : Javah should use the freshly built classes instead of those from the BOOTDIR jdk

Valerie, I'm porting this fix to the JDK 7u repo. It's been fixed in JDK 6 & JDK 8 repos already. full builds have been made with no issues seen. Bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058133 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7058133.jdk7u/ The fix

RFR: 7133138 Improve io performance around timezone lookups

I've worked with Masayoshi on this issue. Hoping to push to JDK8 and backport to 7u and a jdk6 once baked for a while. Some windows boxes were showing performance issues when attempting to iterate through all available timezones available in the JRE. Changes made here should reduce the amount

RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List)

Bug recently reported. We enter infinite recursion on a boundary case for Collections.synchronizedList.remove(..) Fix is a simple equals check in class method before delegating the call. bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144488 webrev : http://cr.openjdk.java.net/~coffey

Re: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List)

Yes, I stumbled across another few issues in the Collections class while looking to expand the testcase for this one. Below are other such cases. Various hashCode methods lead to recursive calls and this has been discussed in the past. It's also mentioned in the javadocs (albeit somewhat vague

Re: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List)

ok, I've updated the changes (and bug synopsis) based on comments. equals method tweaked for : Collections.SynchronizedList Collections.SynchronizedSet Collections.SynchronizedMap Collections.UnmodifiableEntry Testcase updated also. JCK java_util tests run also. http://cr.openjdk.java.net/~cof

Re: Please review fix for: 7148499

Can do Kumar. Should get these in before the week is out. regards, Sean. On 29/02/12 16:16, Kumar Srinivasan wrote: Hi, Please review fix for launcher tests, the JVM requires a higher stack size for 64bit systems, this fixes increases the stack size and removes the test from the problem list

RFR: 7105952 Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

Alan, as discussed, this is the proposed backport of 7105952 to jdk7u6. It's baked in Jdk 8 for some time now without issue. The patch is slightly different given that the JDK 7 repo had CR 7101658 to backout the round 1 fix. Resulting code should be identical though. I thought I'd create a

RFR : 7148584 Jar tools fails to generate manifest correctly when boundary condition hit

Issue seen when the inner Manifest.FastInputStream.peek() method is called just as we hit EOF of main buffer being parsed (the manifest input file) Simple fix involves getting peek() to return -1 if a fill() request fails to read anything. webrev : http://cr.openjdk.java.net/~coffeys/webrev.71

RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

Issue seen on somewhat irregular linux system configuration where /etc/localtime is a symbolic link to a directory outside of /usr/share/zoneinfo. In past, when a symbolic link was seen, the end target file was assumed to be under /usr/share/zoneinfo and a string comparison match was attempted.

Re: RFR : 7148584 Jar tools fails to generate manifest correctly when boundary condition hit

x27;s cleaner. http://cr.openjdk.java.net/~coffeys/webrev.7148584.jdk8.2/ regards, Sean. On 09/03/2012 16:18, Alan Bateman wrote: On 09/03/2012 15:52, Seán Coffey wrote: Issue seen when the inner Manifest.FastInputStream.peek() method is called just as we hit EOF of main buffer being parsed (the

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

Ok - good point on the stat change Alan. I think this is what you're after : http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.2/ regards, Sean. On 12/03/12 11:04, Alan Bateman wrote: On 09/03/2012 16:00, Seán Coffey wrote: Issue seen on somewhat irregular linux system configur

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

Yes - good catch. I hadn't tested the sym link being a relative path. We should always open whatever is pointed to from DEFAULT_ZONEINFO_FILE. This simplifies the code. Tested and looks good. regards, Sean. On 12/03/12 14:34, Alan Bateman wrote: On 12/03/2012 14:31, Seán Coffey wrot

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

15:11, Seán Coffey wrote: Yes - good catch. I hadn't tested the sym link being a relative path. We should always open whatever is pointed to from DEFAULT_ZONEINFO_FILE. This simplifies the code. Tested and looks good. I assume this is the latest: http://cr.openjdk.java.net/~coffeys/w

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

On 13/03/2012 09:38, Seán Coffey wrote: Update made. Hopefully the last iteration ;) http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/ Looks okay to me. For bonus points, open, fstat and read should be restarted if interrupted (EINTR). -Alan.

RFR : 7161925 : sjava files in corba don't have copyright string and legal notice

This is a copyright patch that [email protected] has asked to contribute. I'm pushing it to jdk8 for him. corba repo found to be lacking headers on 2 files. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161925 http://cr.openjdk.java.net/~coffeys/webrev.7161925.jdk8/ regards, Sean.

RFR : 7161925 : sjava files in corba don't have copyright string and legal notice

This is a copyright patch that [email protected] has asked to contribute. I'm pushing it to jdk8 for him. corba repo found to be lacking headers on 2 files. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161925 http://cr.openjdk.java.net/~coffeys/webrev.7161925.jdk8/ regards, Sean.

Request for review : 7181793 FileDescriptor keeps its own hard reference to Closeables causing a memory leak

7105952 fix introduced some improvements for finalization strategy around FileInputStream/FileOutputStream/RandomAccessFile. However a recently reported issue has highlighted an issue where memory heap can be consumed with SocketOutputStream objects as a result of clients repeatedly calling

Re: Request for review : 7181793 FileDescriptor keeps its own hard reference to Closeables causing a memory leak

uld prefer not to add the test in its current state. -Chris. On 10/07/2012 17:37, Seán Coffey wrote: 7105952 fix introduced some improvements for finalization strategy around FileInputStream/FileOutputStream/RandomAccessFile. However a recently reported issue has highlighted an issue where me

Re: Request for review : 7181793 FileDescriptor keeps its own hard reference to Closeables causing a memory leak

e Alan. CR 7183209 : Backout 7105952 changes for jdk7u Regards, Sean. On 11/07/12 11:43, Alan Bateman wrote: On 10/07/2012 17:37, Seán Coffey wrote: 7105952 fix introduced some improvements for finalization strategy around FileInputStream/FileOutputStream/RandomAccessFile. However a recentl

RFR: 7056731: Race condition in CORBA code causes re-use of ABORTed connections

I'm looking to forward port this corba fix from 6u34 to jdk8 (and eventually port to 7u) [email protected] originally reported this issue and I'll be marking the fix as contributed by him. He's already signed the OCA. There's a good description in bug report. We have a race like condi

Re: [7u8] Request for approval: 7184287: (prefs) BackingStoreException when calling flush on root node[macosx]

Approved. regards, Sean. On 28/08/2012 01:32, Kurchi Hazra wrote: This is a request for approval to backport the fix for 7184287 rom 8 to 7u8. Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287 Webrev:http://cr.openjdk.java.net/~khazra/7184287/7u8/webrev.00/ This had been revie

RFR: 7195063 [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure.

bug report should be live shortly : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195063 The introduction of a new corba testcase in recent past is showing up as a random failure on our internal build/test harness (JPRT). === - com/sun/corba/

RFR : 7196086 : update copyright years for files in corba repository (JDK 8)

[email protected] has contributed the following patch which I'd like to push to jdk8 TL. It's the correction of copyright years in corba repo. Need a reviewer. webrev : http://cr.openjdk.java.net/~coffeys/webrev.7196086.jdk8/

Re: Please review -XshowSettings a java launcher option.

Kumar, Great to see this functionality being added. Another useful piece of data may be the tzdata version used by the JRE. I'll open up another thread on this with you. It should be possible to get some helper code added to parse tzdata version. This could always be added at a later date of cou

Re: RFR: 8098547: (tz) Support tzdata2015e

Looks fine. Regards, Sean. On 24/06/15 12:05, Aleksej Efimov wrote: Hello, Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 Testing shows no TZ related failures on all platforms. With Best Regards, Aleksej [1] https://bu

Re: RFR/RFA (8u-dev) 8080524: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profiles

Looks ok to me Ivan. Is this required for JDK 9 also ? If not, please add 9-na label. Approved. Regards, Sean. On 24/06/2015 19:11, Ivan Gerasimov wrote: Hello! This test fails when running on compact1 and compact2, since it tries to access all the jars from "sun.boot.class.path". The easie

Re: RFR: 8098547: (tz) Support tzdata2015e

That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. Where the 1969 date coming from ? Is there some rollover calculation happening ? Regards, Sean. On 25/06/2015 09:05, Attila Szege

Re: [8u-dev] Request for review and for approval to backport: 8080115: (fs) Crash in libgio when calling Files.probeContentType(path) from parallel threads

Looks fine. Approved. Regards, Sean. On 10/09/2015 14:54, Ivan Gerasimov wrote: Hello! Would you please approve the *almost* direct backport of the fix from jdk 9 to 8u? The patch didn't apply automatically due to renaming of a function. Bug: https://bugs.openjdk.java.net/browse/JDK-8080115

RFR (xs) : 8077874 : [TESTBUG] The test com/sun/corba/cachedSocket/7056731.sh should not be run on JRE

Test bug correction to allow the jdb command to be launched via compilejdk parameter where necessary. I've checked for similar usage across other corba tests and this one seems to be the only one. Also made a small edit to use the $JAVA variable where possible. (was already defined) bug repor

RFR: 6907252: ZipFileInputStream Not Thread-Safe

Looking to tighten up access between the java and native level zip library calls. This extra check should ensure that we don't hit SEGV on thread races. I've also taken the opportunity to make the ZStreamRef address variable volatile. I'm still getting reports of zip crashes in the deflate, d

RFR (xs) : 8038502: Deflater.needsInput() should use synchronization

bug report : https://bugs.openjdk.java.net/browse/JDK-8038502 The len instance variable should be read/written while holding the zsRef lock. needsInput() seems to be missing that. Simple change : diff --git a/src/java.base/share/classes/java/util/zip/Deflater.java b/src/java.base/share/class

Re: RFR: 8140344: add support for 3 digit update release numbers

Looks fine to me Rob. Assuming JPRT job builds & tests ok. Regards, Sean. On 24/11/15 12:40, Rob McKenna wrote: You would think, but this fix isn't in jdk_util.c in 6. The test isn't in 6 either though. -Rob On 24/11/15 04:39, David Holmes wrote: On 24/11/2015 12:24 AM, Rob McKenna wrot

Re: [8u-dev] Request for approval: 8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518

Looks fine Aleksej. Reviewed. Also approved for jdk8u-dev. Regards, Sean. On 04/12/15 00:25, Aleksej Efimov wrote: Hi, Please, help to review and approve JDK-8133924 backport to JDK8. The source fix is identical to JDK9 changes, but there was no test added for this issue in JDK9. The exis

Re: RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk

Hi Sherman, Nice work. It'll certainly help protect the VM from bad application code. I've no major issues with the new code. Some comments below. src/java.base/share/classes/java/util/zip/ZipFile.java unused import : import java.nio.file.Path; line 840 : This could be marked final private

Re: RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk

r to leave this to a separate rfe, if desired. http://cr.openjdk.java.net/~sherman/8142508/webrev Thanks, Sherman On 12/07/2015 08:51 AM, Seán Coffey wrote: Hi Sherman, Nice work. It'll certainly help protect the VM from bad application code. I've no major issues with the new code. Some c

Re: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8

Hi Alex, I'm dropping jdk7u-dev mailing list for the moment. core-libs-dev is the mailing list where this review should happen. This fix would be required in JDK 9 first as per process. I think Sherman would be best to review if possible. Once it's soaked in JDK 9 for a few weeks, we could c

Re: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2]

Sherman, Changes look fine. One suggestion in ZipFile around line 956. Would you be better off managing the RandomAccessFile via try-with-resources. That would clean up your exception handling. Regards, Sean. On 12/12/2015 18:43, Xueming Shen wrote: Hi, The changeset for JDK-8142508 had be

Re: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2]

Ah - of course. That comment would been lack of coffee syndrome on my behalf earlier this morning then ;) Regards, Sean. On 14/12/15 16:36, Xueming Shen wrote: On 12/14/15 1:13 AM, Seán Coffey wrote: Sherman, Changes look fine. One suggestion in ZipFile around line 956. Would you be better

  1   2   3   4   >