Re: RFR: JDK-8173094 Error in API documentation for SwingWorker

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. Looks good otherwise. regards, Sean. On 10/02/17 10:51, Abhijit Roy wrote: Hi all, Please

Re: RFR: 8077395: org.omg.CORBA_2_3.portable.InputStream constructor should not specify JDK-specific property

1/19/2017 12:59 PM, Seán Coffey wrote: Changes made to the CORBA InputStream/OutputStream class back in 2013 contained javadoc comments which should have been marked as implementation specific. The minor edits here should correct that. webrev : http://cr.openjdk.java.net/~coffeys/webrev.80

RFR: 8077395: org.omg.CORBA_2_3.portable.InputStream constructor should not specify JDK-specific property

Changes made to the CORBA InputStream/OutputStream class back in 2013 contained javadoc comments which should have been marked as implementation specific. The minor edits here should correct that. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077395/webrev/ JBS :

Re: [8u-dev] Request for Approval: 8159058: SAXParseException when sending soap message

Backported changes look fine. Regards, Sean. On 11/01/17 13:56, David Buck wrote: approved for push to 8u-dev (contingent on successful code review) I have added the core libraries alias for what will hopefully be a trivial code review process. Cheers, -Buck On 2017/01/11 22:01, Aleks

Re: Does jvisualvm work in JDK 9?

I don't believe jvisualvm will ship bundled with JDK 9 and is due for removal. Probably best to download the latest visualvm binaries from the VisualVM project website. See https://blogs.oracle.com/java-platform-group/entry/visual_vm_in_jdk_9 regards, Sean. On 29/12/2016 02:39, Frank Yuan

Re: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

Looks fine Aleksej. Approved for jdk8u-dev. regards, Sean. On 19/12/2016 15:53, Aleks Efimov wrote: Hi, Can I, please, ask JDK8 reviewer to look through the backported changes? Thanks, Aleksej On 15/12/16 17:06, Aleks Efimov wrote: Hi, Can I, please, have an approval to backport

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/ Regards, Sean. On 01/06/16 16:00, Seán Coffey wrote: On 01/06/16 10:21, Alan Bateman wrote: On 31/05/2016 18:57, Seán Coffey wrote: new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v2/webrev/ Also

Re: [8u-dev] Request for Review and Approval to backport: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output

Looks fine Ivan. Reviewed. Approved for jdk8u-dev. Regards, Sean. On 09/09/16 16:43, Ivan Gerasimov wrote: Hello! I'd like to backport this fix to jdk8u. The unshuffled fix applies almost clearly: I only had to slightly modify the regression test. Bug:

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

Looks fine Ivan. Reviewed. Regards, Sean. On 19/08/16 15:59, Ivan Gerasimov wrote: On 19.08.2016 17:32, Stephen Colebourne wrote: I'm less comfortable with the compareTo change because it may make it slower and that may have knock on effects. I think a comment saying that both are bounded

Re: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

On 8/5/2016 10:05 AM, Seán Coffey wrote: Hoping to get a review on this issue that's been sitting on my plate for a long while. Pavel drew up the bulk of the edits for this one (Thanks) The fix basically delegates polling and timeout management to the BlockingQueue.poll(timeout.. ) method

RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hoping to get a review on this issue that's been sitting on my plate for a long while. Pavel drew up the bulk of the edits for this one (Thanks) The fix basically delegates polling and timeout management to the BlockingQueue.poll(timeout.. ) method. As a result it makes Connection readReply

Re: [8u] request for approval: "8152172: PPC64: Support AES intrinsics"

://openjdk.java.net/guide/changePlanning.html#noreg noreg-other seems fine. You might want to add a short comment to bug outlining your comment on existing AES tests. regards, Sean. Thanks, Volker On Tue, Aug 2, 2016 at 9:58 AM, Seán Coffey <sean.cof...@oracle.com> wrote: Volker, Have the jdk8u hotspot

Re: [8u] request for approval: "8152172: PPC64: Support AES intrinsics"

Volker, Have the jdk8u hotspot edits been reviewed ? Looks like they should be. Can you add a suitable noreg label to the master bug report also. Regards, Sean. On 29/07/2016 19:58, Volker Simonis wrote: Ping! Can I please have an approval for backporting this change to 8u-dev? Thanks,

Re: [8u-dev] RFR (JAXP) 8028363: XmlGregorianCalendarImpl.getTimeZone() bug when offset is less than 10 minutes

Looks fine to me also Svetlana. Regards, Sean. On 21/07/2016 13:13, Svetlana Nikandrova wrote: Little reminder. On 19.07.2016 19:29, Svetlana Nikandrova wrote: Hello, please review this fix for 8u-dev. For jdk9 problem has been addressed in JEP 255

Re: RFR: 8153044: Allow a property to control location of tzdb.dat file

etProperty("java.home"), "lib", "tzdb.dat"). Also, for the property access in the case of a security manager, use sun.security.actions.GetPropertyAction.privilegedGetProperty. Perhaps rename 'pathToRules' to 'pathToTzdb' Thanks, Roger On 7/7/2016 10:53 AM,

Re: RFR: 8153044: Allow a property to control location of tzdb.dat file

I'll (reluctantly) close this out then. I do think it was a convenient and low-maintenance feature that would allow end users the ability to bounce applications in an ordered fashion in order to pick up new tzdata rules. I'll investigate the upgradeable module approach. Regards, Sean. On

Re: RFR: JDK-8160240 - javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java failed with error "Address already in use: bind"

Mark, fixed port numbers are always going to be problematic in tests. Is there any way the port numbers can be assigned after the test starts up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be modified/accessed via reflection so that the initUsingIiopUrl can be re-called once

Re: [jdk9] RFR: 8159822: Non-synchronized access to shared members of com.sun.jndi.ldap.pool.Pool

Looks fine to me Ivan. If you have a stacktrace of an example ConcurrentModificationException issue, please paste it into the bug report so that it's documented for others to find. Regards, Sean. On 24/06/2016 15:56, Ivan Gerasimov wrote: Hi Aleksey! I've double-checked the Pool class and

Re: [jdk9] RFR: 8158802: com.sun.jndi.ldap.SimpleClientId produces wrong hash code

Looks fine to me Ivan. Nice find. Regards, Sean. On 09/06/2016 14:52, Ivan Gerasimov wrote: Could someone please help review this? The essential part of the fix is quite simple: i.e. replacing char/byte[].hashCode() with Arrays.hashCode(char/byte[]). The regression test confirms that the

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Hey Mark, Looks fine. A few comments. 2291 Class declaredFieldClass = declaredClassField.getType(); 2292 2293 if (declaredFieldClass == null) { 2294 continue; 2295 } I'm not sure if this check is

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

On 01/06/16 10:21, Alan Bateman wrote: On 31/05/2016 18:57, Seán Coffey wrote: new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v2/webrev/ Also in JprtPath.checkPath then I assume path.getClass() is enough as the toString is specified to return a useful string

Re: RFR: 8151876: (tz) Support tzdata2016d

(! zi.equalsTo(ziOLD)) { Regards, Ramanand. *From:*Seán Coffey *Sent:* Tuesday, May 31, 2016 3:05 PM *To:* Masayoshi Okutsu; Ramanand Patil; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.net *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d Masayoshi, I still think the test ad

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

messages Some other observations: *) ImageLocation: why the beginning quote? throw new InternalError("\"Missing jimage attribute data"); *) JrtFileSystem: extra space before colon "option class : " + option.getClass().getName()); Cheers, Paul On Tue, May 31, 2016 at

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

I've gone ahead with a trimmed down webrev as per Alan's request. new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v2/webrev/ Regards, Sean. On 16/05/2016 15:10, Alan Bateman wrote: On 16/05/2016 14:45, Seán Coffey wrote: On 16/05/16 13:51, Alan Bateman wrote: On 16/05

Re: RFR: 8151876: (tz) Support tzdata2016d

es where the entries are not present in the resources and the Short/Long display names fallback to the GMT±hh:mm format. Regards, Ramanand. *From:*Masayoshi Okutsu *Sent:* Saturday, May 28, 2016 10:58 AM *To:* Seán Coffey; Ramanand Patil; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.n

Re: RFR: 8151876: (tz) Support tzdata2016d

e "GMT±hh:mm" format is used for *new* zones with the "±hh" format. But this change removes *existing* zones which have changed to use the "±hh" format in tzdata. Can this cause any compatibility issues? And have we agreed to use the "GMT±hh:mm" format? Thanks,

Re: RFR: 8151876: (tz) Support tzdata2016d

Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. Regards, Sean. On 26/05/16 14:22, Ramanand Patil wrote: HI all, Please review the latest TZDATA integration

(@modules documentation)Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

Was our OpenJDK documentation ever updated to highlight the @modules change for JDK 9 ? Could we edit the developer's guide[1] to highlight the @modules tag [2]. The current doc states that an @bug tag should be supplied. It would help to document why/when an @modules tag would be required

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

On 16/05/16 13:51, Alan Bateman wrote: On 16/05/2016 13:44, Seán Coffey wrote: Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits. https://bugs.openjdk.java.net/browse/JDK-8151832 webrev : http://cr.openjdk.java.net

RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits. https://bugs.openjdk.java.net/browse/JDK-8151832 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html -- Regards, Sean.

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

Looks good Chris. Regards, Sean. On 18/04/2016 21:50, Chris Hegarty wrote: This change updates the code in the cobra module to use the new Thread constructor that suppresses inheritable-thread-local initial values. http://cr.openjdk.java.net/~chegar/8148863/

Re: RFR: 8154304: NullpointerException at LdapReferralException.getReferralContext

Thanks. Corrected copyright and pushed. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e2b04e57b51a Regards, Sean. On 15/04/2016 15:46, Xuelei Fan wrote: Looks nice to me. It would be nice to update the copyright date, too. Thanks, Xuelei On 4/15/2016 10:13 PM, Seán Coffey wrote: I need

RFR: 8154304: NullpointerException at LdapReferralException.getReferralContext

I need to correct another issue related to JDK-8149450. If a getReferralContext call is made on a ReferralContext that doesn't contain any referrals (URI fields) then a null scenario is possible. There's a question mark around how compliant the LDAP BER response is but I'd like the JDK to

Re: RFR: 8153262: javax/xml/bind/marshal/8134111/UnmarshalTest.java fails

Looks fine. Regards, Sean. On 01/04/16 14:01, Aleksej Efimov wrote: Hi, The push for JDK-8134111 missed one test file. Please, review and approve the addition of missing ObjectFactory.java file. Webrev with added file: http://cr.openjdk.java.net/~aefimov/8153262/00 Thanks, Aleksej

Re: [8u-dev] Request for Approval for Backport: 8151352 (8151574), jdk/test/sample fails with "effective library path is outside the test suite"

On 15/03/16 14:38, Felix Yang wrote: Hi Sean, thank you for the review. Could you sponsor this change? Pushed : http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/2e0399f66ddc regards, Sean. -Felix On 2016/3/15 16:03, Seán Coffey wrote: Please don't use backport IDs in email

Re: [8u-dev] RFR 8151535: java/lang/invoke/AccessControlTest.java should be modified to run with JTREG 4.1 b13

Approved. I'll push this for you. Regards, Sean. On 17/03/2016 07:07, Felix Yang wrote: Hi there, please, help to review the fix for test 'java/lang/invoke/AccessControlTest.java'. Bug: https://bugs.openjdk.java.net/browse/JDK-8151535 Webrev:

Re: [8u-dev] Request for Approval for Backport: 8151352 (8151574), jdk/test/sample fails with "effective library path is outside the test suite"

Please don't use backport IDs in email communication or approval requests. Use the master bug ID in your changeset commit comment. I've edited the subject line to include master bug ID (8151352). Approved. The jtreg upgrade disrupted test results for quite a few teams (again).

Re: [8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Approved for jdk8u-dev (BTW). Regards, Sean. On 03/03/2016 09:04, Seán Coffey wrote: Ivan, the JBS bug description is scare on detail. Can you fill it out a bit ? Some examples of the stack trace encountered and links to OpenJDK reviews/discussions will help people who encounter this issue

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

to have system library support - I'm just highlighting a possible risk. A fall back option solves that but there's no appetite for such a solution. Let's see how it goes. regards, Sean. Sherman On 02/10/2016 06:41 AM, Seán Coffey wrote: On 10/02/16 14:29, Alan Bateman wrote: On 10/02/2016

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 10/02/16 14:29, Alan Bateman wrote: On 10/02/2016 13:57, Seán Coffey wrote: I'm all for allowing one to introduce a new version of zlib to their JDK at runtime. I just don't think it's in the interests of enterprises and stability to introduce a dependency to the JDK on the underlying OS

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 08/02/16 09:55, Alan Bateman wrote: On 08/02/2016 10:42, Seán Coffey wrote: Is there an option to fall back to the older v.1.2.8 implementation if necessary ? It would certainly alleviate issues for any applications that might run into issues with the latest and greatest zlib libraries

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

Is there an option to fall back to the older v.1.2.8 implementation if necessary ? It would certainly alleviate issues for any applications that might run into issues with the latest and greatest zlib libraries. JDK-8133206 would be one such example. Regards, Sean. On 05/02/2016 18:55,

Re: RFR: JDK-8144144 - ORB destroy() leaks filedescriptors after unsuccessful connection

to manage this state flag. Either way, I don't think the synchronization around the closed variable is root cause of this issue and performance issues could be addressed in another change if necessary (playing safe) regards, Sean. regards Mark On 20/01/2016 18:17, Seán Coffey wrote: Hi Mark

Re: RFR [9] 8148220: Update TEST.groups to include jdk/internal/math and jdk/internal/misc

Looks fine to me Chris. Regards, Sean. On 26/01/2016 12:27, Chris Hegarty wrote: The test groups, that make up jdk_core, should be updated to include jdk/internal/math and jdk/internal/misc. These updates were overlooked when doing re-orgaziation and cleanup in preparation for JEP 260. diff

Re: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

The changes look fine to me also Chris. Regards, Sean. On 22/01/16 14:49, Chris Hegarty wrote: On 21/01/16 22:55, Felix Yang wrote: Hi Chris, your fix is cool. I will assign the bug to you:) a comment on this fix. The test changed system SecurityManager and it is not executed with

Re: RFR: JDK-8144144 - ORB destroy() leaks filedescriptors after unsuccessful connection

this state flag. Either way, I don't think the synchronization around the closed variable is root cause of this issue and performance issues could be addressed in another change if necessary (playing safe) regards, Sean. regards Mark On 20/01/2016 18:17, Seán Coffey wrote: Hi Mark

Re: RFR: JDK-8144144 - ORB destroy() leaks filedescriptors after unsuccessful connection

Hi Mark, SelectorImpl.java: line 125, could you use a 2 arg method call to dprint. It'll print the stacktrace instead : dprint(".close: selector.close: " + t); --> dprint(".close: selector.close", t); The "while (!isClosed()) " change introduces a new hot lock on closed variable.

Re: RFR: JDK-8144144 - ORB destroy() leaks filedescriptors after unsuccessful connection

Looks good to me Mark. Chris's point will help clean up the new clearDeferredRegistrations method. Is this close operation applicable only to the inboundConnectionCaches ? I guess that one creates the ServerSocket for the acceptor. Does any such socket get created/left behind for the

Re: Remove sun.misc.CompoundEnumeration

Looks good! Regards, Sean. On 22/12/2015 15:00, Chris Hegarty wrote: On 22 Dec 2015, at 14:58, Aleksey Shipilev wrote: On 12/22/2015 05:57 PM, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8146000/ Looks good. Thanks. Thanks, -Aleksey P.S. Nice

Re: Review request for JDK-8145545 : Typos in Javadoc of XmlAdapter

Looks fine. Regards, Sean. On 17/12/2015 08:55, Abhijit Roy wrote: Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8145545 Bug - Typos in Javadoc of XmlAdapter Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8145545/webrev.00/ I have just rectified and

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

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

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

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 comments below. src

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

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

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

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

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

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:

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

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]

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

Re: RFR: 7130985: Four helper classes missing in Sun JDK

Looks good to me too. Regards, Sean. On 08/06/15 13:30, Mark Sheppard wrote: Hi Rob, looks fine to me thanks for handling this issue regards Mark On 05/06/2015 15:41, Rob McKenna wrote: Added some cleanup code around the BufferedReaders the leftover test files:

Re: [8u60] approval request for JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded

Approved. Regards, Sean. On 05/06/15 11:30, Konstantin Shefov wrote: Please approve direct backport. bug: https://bugs.openjdk.java.net/browse/JDK-8068416 jdk9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/033998.html jdk8u-dev webrev:

Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded

I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise. Regards, Sean. On 03/06/2015 17:33, Konstantin Shefov wrote: Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is

Re: [8u60] Request for approval: 8073357: schema1.xsd has wrong content. Sequence of the enum values has been changed

Approved. Please get a peer review before pushing the changes. Regards, Sean. On 22/04/15 07:12, Aleksej Efimov wrote: Hello, Can I ask for approval of the JDK-8073357 [2] bug fix [1] to JDK8. The original fix contains only test modifications, but the jaxws part was introduced during JAXWS

Re: RFR (XXS) : 8050123: Incorrect property name documented in CORBA InputStream API

JDK-8077395 tracking this request now. Thanks for logging bug Alan. Regards, Sean. On 10/04/15 08:03, Alan Bateman wrote: This is JDK-specific and so shouldn't be in the constructor specification. Can it be moved to an @implNote?

RFR (XXS) : 8050123: Incorrect property name documented in CORBA InputStream API

https://bugs.openjdk.java.net/browse/JDK-8050123 diff --git a/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java b/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java --- a/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java +++

Re: stop using mmap for zip I/O

On 27/02/15 12:23, chris...@zoulas.com wrote: On Feb 27, 9:51am, sean.cof...@oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) wrote: -- Subject: Re: stop using mmap for zip I/O | The sun.zip.disableMemoryMapping=true property helps with ZipFile class | only. There are other related issues in

Re: stop using mmap for zip I/O

The sun.zip.disableMemoryMapping=true property helps with ZipFile class only. There are other related issues in the ZipInput/Output streams. Some code areas don't have synchronization and there are opportunities for the underlying native zip resources to be freed which Java code then tries to

Re: RFR | 8073779: StackOverflowError called StackOverflowException in javadoc

On 24/02/2015 17:08, Ivan Gerasimov wrote: Right. I shouldn't have pushed it that quick. Sigh Nothing important. Just thought it might be a useful step while you were there! It's something we can keep in mind for a later fix. regards, Sean. On 24.02.2015 19:53, Seán Coffey wrote: Nice

Re: RFR | 8073779: StackOverflowError called StackOverflowException in javadoc

Nice catch Ivan. You could also clean up the typo in various test cases relating to it also perhaps : langtools/test/tools/javac/generics/inference/8043725/T8043725.java jdk/test/java/util/Hashtable/SelfRef.java jdk/test/javax/swing/border/Test6461042.java

Re: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null) don't throw NPE as specified

Looks fine to me Claes. From a supportability point of view, could I suggest that the exception string be made more informative ? (for cases where the stack may not be present - logs etc.) i.e. lastModifiedTime, lastAccessTime, creationTime. Will you be porting this to jdk8u-dev also ?

Re: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null) don't throw NPE as specified

On 20/02/15 15:24, Claes Redestad wrote: On 2015-02-20 16:04, Seán Coffey wrote: Looks fine to me Claes. From a supportability point of view, could I suggest that the exception string be made more informative ? (for cases where the stack may not be present - logs etc.) i.e. lastModifiedTime

Re: [9] RFR: 8072042: (tz) Support tzdata2015a

Looks good to me. regards, Sean. On 03/02/2015 15:59, Aleksej Efimov wrote: Hi, Could I have a review the latest tzdata2015a integration fix to JDK9, please. The regression tests run and JPRT testing (jdk_other,jdk_util, jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.

Re: Useful message about NullPointerException

Adding hotspot-dev to this mail thread also as it's relevant to hotspot. (complete thread at http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031015.html) As one who often has to dig through application logs and JDK issues, I think this would certainly be a useful addition to

Re: [8u60] Request for approval: JDK-8067344: Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent changes in java.lang.invoke

Approved. Might be good to add noreg-self label to bug report also. regards, Sean. On 26/01/15 11:26, Konstantin Shefov wrote: Kindly reminder On 21.01.2015 18:29, Konstantin Shefov wrote: Hello, Please approve the direct backport of the test bug fix to 8u60 The webrev is slightly

Re: [8u-dev] Request for approval: JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

Konstantin, can you hold off pushing this fix to jdk8u for the moment ? It's a P4 and could have behavioural consequences (something we try and avoid in update releases). I see JDK-8071458 was logged to track IPv6 scope specifications. Let's see how this soaks into JDK 9 over coming days and

Re: [8u60] - Request for Approval : RFR 8069302 Deprecate Unsafe monitor methods in JDK 8u release

Paul, Approved for jdk8u-dev. Can you add a subcomponent to the bug, add the 9-na label and add a suitable noreg- label. regards, Sean. On 21/01/2015 19:43, John Rose wrote: +1; do it. On Jan 21, 2015, at 2:35 AM, Paul Sandoz paul.san...@oracle.com wrote: Hi, The Unsafe monitor methods

Re: RFR : 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible.

to set the copyright year to 2015. Best regards, -- daniel On 08/01/15 15:41, Seán Coffey wrote: I've taken suggested test code from Daniel and am looking to backport 8066612 to jdk7u-dev. The test differs slightly in that it used the non-lambda approach (ClassNameListBuilder) I've reduced

RFR : 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible.

I've taken suggested test code from Daniel and am looking to backport 8066612 to jdk7u-dev. The test differs slightly in that it used the non-lambda approach (ClassNameListBuilder) I've reduced the number of run counts also (one ovm run for secure and one for non-secure mode) - As a result

Re: Documentation of methods in java.lang.Number

Andreas, this didn't get attention in the past. You can now find your report at https://bugs.openjdk.java.net/browse/JDK-8067669 I'll leave it up to maths engineers to determine if the Number API needs improving. regards, Sean. On 16/12/2014 12:55, Andreas Lundblad wrote: I've noticed that

Re: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible.

, Daniel Fuchs wrote: On 04/12/14 14:02, Seán Coffey wrote: Thanks for driving efforts in this area Daniel. I think it's a very useful test and is bound to help test code coverage. If it's currently passing on all JPRT platforms, it's a good measure. It seems to :-) Eventually I think we can bulk up

Re: Should some JDK system properties be read only ?

Yes - that would be a nice API addition also. Not sure if we'd have to consider a way of working on system properties set via the command line option also. I'm tracking this via https://bugs.openjdk.java.net/browse/JDK-8066709 regards, Sean. On 05/12/2014 01:00, Wang Weijun wrote: A

Re: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible.

Thanks for driving efforts in this area Daniel. I think it's a very useful test and is bound to help test code coverage. If it's currently passing on all JPRT platforms, it's a good measure. Eventually I think we can bulk up the tests that can be run on the Iterable returned from your class

Re: Should some JDK system properties be read only ?

On 04/12/2014 16:00, David M. Lloyd wrote: On 12/04/2014 09:42 AM, Seán Coffey wrote: Apologies if this has been raised in past. I've run into issues in the past where bad user code (app server) has set the java.home system property to a value other than the default. This has consequences

Re: RFR - 8065552: setAccessible(true) on fields of Class may throw a SecurityException

Looks fine to me Daniel. Thanks for handling it. I can work on the 7u backport if necessary. on the test side would it be worth testing all public classes available (e.g in rt.jar ?) to ensure that Field.setAccessible works as expected and that we don't hit this issue again ? It might be some

Re: RFR - 8065552: setAccessible(true) on fields of Class may throw a SecurityException

On 01/12/2014 18:54, Daniel Fuchs wrote: on the test side would it be worth testing all public classes available (e.g in rt.jar ?) to ensure that Field.setAccessible works as expected and that we don't hit this issue again ? It might be some what of a heavy test for jtreg inclusion though. It

Re: [7u-dev] Request for Review + Request for Approval to Backport: 8064391: More thread safety problems in core reflection

Looks fine to me Ivan. Please get jdk7u reviewer to review. Approved. regards, Sean. On 28/11/2014 13:37, Ivan Gerasimov wrote: Hello! Would you please approve the backport from jdk 8u to 7u? The patch didn't apply cleanly due to generics in these two files:

Re: RFR: 8064914: tzdb.dat compilation failure when using tzdata2014j

Looks fine. Thanks for handling. regards, Sean. On 17/11/2014 00:11, Aleksej Efimov wrote: Hello, During the latest tzdata (2014j) integration the tzdb.dat build failure was observed - details can be found in JBS [1]. The proposed [2] fix resolves time zones double link problem and JDK

RFR : 8047340 - (process) Runtime.exec() fails in Turkish locale

This issue was addressed in JDK8u and later via JDK-8000975. I'm planning on fixing this in JDK 7u by itself. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8047340.7u/webrev/ bug report : https://bugs.openjdk.java.net/browse/JDK-8047340 regards, Sean.

Re: [8u40] Request for approval and review : 8058695: [TESTBUG] Reinvokers with arity 253 can't be cached

This was already approved Konstantin : http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-October/002118.html If it's a clean import (patch wise) then - there's no need for a separate review. If there was changes to the 8u patch (apart from modular path name changes) then please get a

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

: The problem was in line endings. The updated webrev for test: http://cr.openjdk.java.net/~mkos/8038966/jdk.04/ Thanks Miran On 19/09/14 17:42, Seán Coffey wrote: Miran, thanks for the update. Seems like you're working from an old JDK 9 forest. The webrev is using the pre-modular path layout

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

(classes instead of scratch + test path as prefix), so I changed the code to Path p = Paths.get(.., classes, javax, xml, ws, xsanymixed, org); Thanks Miran On 18/09/14 14:01, Seán Coffey wrote: jtreg should remove the work/scratch directory upon test completion but it's best practice

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

then. regards, Sean. Thanks Miran On 17/09/14 16:16, Seán Coffey wrote: Miran, the src change looks ok but I think there's a problem with the testcase. You've defined generated classes for wsimport to be output to the TESTSRC directory. This is often read only and won't work. TESTCLASSES

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

Miran On 18/09/14 11:49, Seán Coffey wrote: On 18/09/2014 10:12, Miroslav Kos wrote: Thanks, Sean, good catch ... I changed the destination for generated files: http://cr.openjdk.java.net/~mkos/8038966/jdk.02/ Regarding usage ProcessBuilder instead of shell script - the problem

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

Miran, the src change looks ok but I think there's a problem with the testcase. You've defined generated classes for wsimport to be output to the TESTSRC directory. This is often read only and won't work. TESTCLASSES is the variable you're probably looking for. In any case, I think it's

Re: RFR : 8044725 :Bug in zlib 1.2.5 prevents inflation of some gzipped files (zlib 1.2.8 port)

Thanks for review Sherman. I'll go ahead and push current changes. Not sure what to do with the zlib launcher reference. Most likely not needed but we can rip that code out under a new bug ID if necessary. regards, Sean. On 08/09/2014 18:34, Xueming Shen wrote: On 09/03/2014 03:05 AM, Seán

Re: [8u-dev] Request for approval: 6545422: TEST BUG: NativeErrors.java uses wrong path name in exec

Approved. regards, Sean. On 01/07/14 22:32, Ivan Gerasimov wrote: Corrected the subject line: I'm requesting an approval to push the fix into jdk8u-dev repo, not jdk8u20 On 02.07.2014 1:29, Ivan Gerasimov wrote: Hello! I'm rerequesting an approval to backport this test fix into jdk8u. To

<    1   2   3   4   >