Re: Time to retire System.runFinalizersOnExit?

On 29/01/2015 5:06 PM, Peter Levart wrote: On 01/29/2015 04:43 AM, Mandy Chung wrote: On 1/28/2015 5:36 PM, Stuart Marks wrote: On 1/28/15 7:07 AM, Alan Bateman wrote: On 27/01/2015 04:37, Mandy Chung wrote: System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2) and this metho

Re: Time to retire System.runFinalizersOnExit?

On 01/29/2015 04:43 AM, Mandy Chung wrote: On 1/28/2015 5:36 PM, Stuart Marks wrote: On 1/28/15 7:07 AM, Alan Bateman wrote: On 27/01/2015 04:37, Mandy Chung wrote: System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2) and this method is inherently unsafe. I am thinking to pr

Re: Review request for JDK-8051547: Convert JAXP function tests: javax.xml.validation.* to jtreg (testng) tests

I see, it's all good then. Joe On 1/28/2015 6:17 PM, Frank Yuan wrote: Actually, Schema01 is commented out from TestValidation.java although Schema01.java exists in sqe repo. Best Regards Frank *From:*huizhe wang [mailto:[email protected]] *Sent:* Thursday, January 29, 2015 7:34 AM *

Re: Time to retire System.runFinalizersOnExit?

On 1/28/2015 5:36 PM, Stuart Marks wrote: On 1/28/15 7:07 AM, Alan Bateman wrote: On 27/01/2015 04:37, Mandy Chung wrote: System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2) and this method is inherently unsafe. I am thinking to propose this method in JDK 9 to throw Unsupp

Re: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in jdk.rmic module

I updated the webrev, suppress deprecation warnings for jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered. Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/ Thanks, Amy On 1/19/15 2:31 PM, Amy Lu wrote: Please review these changes to address a few stray deprecat

Re: [9] RFR (XS): 8071787: Don't block inlining when DONT_INLINE_THRESHOLD=0

Good. Consider fixing the typo in 'makeBlockInlningWrapper'. — John On Jan 28, 2015, at 9:12 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8071787 > > For testing & performance measurements, sometimes it's us

Re: [9] RFR (XXS): 8071788: CountingWrapper.asType() is broken

Good. On Jan 28, 2015, at 9:22 AM, Vladimir Ivanov wrote: > > The fix is to use adapted MethodHandle to construct LambdaForm.

Re: Time to retire System.runFinalizersOnExit?

On 1/28/15 7:07 AM, Alan Bateman wrote: On 27/01/2015 04:37, Mandy Chung wrote: System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2) and this method is inherently unsafe. I am thinking to propose this method in JDK 9 to throw UnsupportedOperationException. I believe it's rare

Re: Review request for JDK-8051547: Convert JAXP function tests: javax.xml.validation.* to jtreg (testng) tests

Hi Frank, I noticed that the test "Schema01" is not in the webrev. Did you remove it? It's not a problem since what the two test cases did were covered by the Validator/ValidatorHandler tests. So, just wanted to make sure. Thanks, Joe On 1/28/2015 2:57 AM, Frank Yuan wrote: Thank you! The

Re: Java cmdline encoding challenges on Windows

Roger, There is an existing Enhancement request for this: https://bugs.openjdk.java.net/browse/JDK-8029584 Kumar On 1/28/2015 10:30 AM, Roger Riggs wrote: Hi Martin, Excellent, command line parsing of non-ascii has been a issuefor a while. Is the patch small enough to include in email? Sorr

Re: Review request for JDK-8052401: JAXP function gap tests conversion

Hi Frank, The tests look fine. > Thank you, Joe. > > I have moved gatest to test.gatest, would you like to check again? > http://cr.openjdk.java.net/~fyuan/8052401/webrev.01/ > > If the code has no problem, would you like to be the sponsor? > > Best Regards > Frank > > -Original Messa

Re: Review request for JDK-8051710: Convert JAXP function tests: javax.xml.jaxp14.* to jtreg (testng) tests

Hi Frank, Overall they look fine. Minor comments that you can address when you have time but should not stop you pushing your changes/additions TransformTest - just have setup throw Exception as you really don't need the granularity because your are not doing anything with it XPathFactoryTes

Re: Review request for JDK-8051709: Convert JAXP function tests: javax.xml.datatype to jtreg (testng) tests

Hi Frank Overall, it is fine, a couple minor nits: I thinking some of the comments in both class should be clearer as the comments can be confusing as to what the test should return --- 332 333 /** 334 * Test XMLGregorianCalendar#toString() Bug # 5049528: 335 * XML

Re: Java cmdline encoding challenges on Windows

Hi Martin, This was vaguely on my TODO list 10 years ago. It makes sense for Microsoft to be funding this sort of improvement. I'm your cheerleader (but not your reviewer). See also incomplete work here: http://bugs.java.com/view_bug.do?bug_id=4519026 http://mail.openjdk.java.net/pipermail/core-l

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

On Jan 28, 2015, at 1:00 AM, Vladimir Ivanov wrote: > I polished the change a little according to your comments (diff against v03): > http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03-04/hotspot > +1 Glad to see the AndI

Re: RFR 8050819: Please add java.util.Stream.ofNullable(T object)

On 28 January 2015 at 17:09, Paul Sandoz wrote: >> I guess having a method like this makes it easier for people to deal with >> their possibly-null-producing code in a new streams world. Such >> null-producing code already exists. I guess you could say that providing >> this method encourages p

Re: Java cmdline encoding challenges on Windows

Hi Martin, Excellent, command line parsing of non-ascii has been a issuefor a while. Is the patch small enough to include in email? Sorry, but links to non-OpenJDK servers are not covered by the OpenJDK agreements. And the openjdk mailer strips off attachments as a defense mechanism. Is ther

Re: Q: 8071326: ThreadPoolExecutor in endless thread creation loop if workQueue.take() throws RuntimeException

It's hard for me to think of something we could add to the javadoc that would actually help future users enough to offset the confusion of adding subtleties of rarely encountered behavior. I also don't see an easy way to improve the pool's reaction to exceptions coming from the queue. Right now t

[9] RFR (XXS): 8071788: CountingWrapper.asType() is broken

http://cr.openjdk.java.net/~vlivanov/8071788/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8071788 There's a type mismatch between MethodHandle and LambdaForm in CountingWrapper.asTypeUncached(). Sometimes, it leads to a VM crash. The fix is to use adapted MethodHandle to construct Lambd

Re: RFR 8050819: Please add java.util.Stream.ofNullable(T object)

On Jan 27, 2015, at 11:49 PM, Stuart Marks wrote: > > On 1/26/15 2:15 PM, Remi Forax wrote: >> >> On 01/26/2015 07:42 PM, Alan Bateman wrote: >>> On 26/01/2015 18:32, Paul Sandoz wrote: On Jan 20, 2015, at 7:05 PM, Paul Sandoz wrote: > Hi, > > http://cr.openjdk.java.net/~psa

Re: Review request 8057645: Deprivilege JAX-WS, JAXB, JAF to extension class loader

On 26/01/15 20:23, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8057645/webrev.00/ This patch proposes to move java.xml.ws, java.xml.bind, java.activation out of the boot loader and be loaded by the extension class loader. We grant java.xml.ws and java.xml.bind the mini

[9] RFR (XS): 8071787: Don't block inlining when DONT_INLINE_THRESHOLD=0

http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8071787 For testing & performance measurements, sometimes it's useful to replace block inlining wrappers with trivial reinvokers. This change extends DONT_INLINE_THRESHOLD in the following manner:

Re: Time to retire System.runFinalizersOnExit?

On Jan 28, 2015, at 4:28 PM, Volker Simonis wrote: > I understand that the benefits of calling System.runFinalizersOnExit() > may be questionable and I don’t have any objections to remove it in > Java 9. But I'm strongly against changing it to throw an > UnsupportedOperationException and downpor

Re: Useful message about NullPointerException

On 01/28/2015 03:30 AM, David Holmes wrote: If you have access to sources, then perhaps an easier solution would be for stack traces to include column number in addition to line number of location in source that resulted in bytecodes that include the one that triggered the NPE. There is already

Re: Time to retire System.runFinalizersOnExit?

I understand that the benefits of calling System.runFinalizersOnExit() may be questionable and I don’t have any objections to remove it in Java 9. But I'm strongly against changing it to throw an UnsupportedOperationException and downport that change to Java 8. In my eyes that’s really a no-go. I'

Re: Time to retire System.runFinalizersOnExit?

On 27/01/2015 04:37, Mandy Chung wrote: System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2) and this method is inherently unsafe. I am thinking to propose this method in JDK 9 to throw UnsupportedOperationException. I believe it's rare for existing applications using System

Re: Time to retire System.runFinalizersOnExit?

On Jan 27, 2015, at 5:37 AM, Mandy Chung wrote: > System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2) > and this method is inherently unsafe. I am thinking to propose this method > in JDK 9 to throw UnsupportedOperationException. > > I believe it's rare for existing applicati

Re: Q: 8071326: ThreadPoolExecutor in endless thread creation loop if workQueue.take() throws RuntimeException

Thanks Doug, David, Martin, especially Martin. Is it worth to update javadoc of ThreadPoolExecutor#Queuing section with this caveat ? The original confusion in custom queue implementation raise up from javadoc, because BlockingQueue.take() interface specification does not prohibit explicitly

RE: Review request for JDK-8051710: Convert JAXP function tests: javax.xml.jaxp14.* to jtreg (testng) tests

Hi Joe I have moved the jaxp14 tests to the corresponding packages, would you like to have a check? http://cr.openjdk.java.net/~fyuan/8051710/webrev.01/ There is an issue, SchemaFactoryTest is merged to validation.SchemaFactoryTest, but the validation package(Lance reviewed it) is waiting to push

RE: Review request for JDK-8052401: JAXP function gap tests conversion

Thank you, Joe. I have moved gatest to test.gatest, would you like to check again? http://cr.openjdk.java.net/~fyuan/8052401/webrev.01/ If the code has no problem, would you like to be the sponsor? Best Regards Frank -Original Message- From: huizhe wang [mailto:[email protected]]

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

Looking very good, thanks. Ship it! Thanks, John! Actually, can you insert a comment why the injected counts are not scaled? (Or perhaps they should be??) Sure! I intentionally don't scale the counts because I don't see any reason to do so. Profiling is done on per-MethodHandle basis, so th