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

On 1/27/2015 7:06 PM, Frank Yuan wrote: Thank you, Joe. I will sort the tests as your suggestion, and have 3 questions to confirm with you: 1. Should I also sort the gap tests? 2. Should I put astro suite at side of auctionportal? Ah, in that case, you may put gap tests alongside the auctionp

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

Looks good. Joe On 1/27/2015 1:17 AM, Frank Yuan wrote: Hi, Joe, Lance and All We are working on moving internal jaxp functional tests to open jdk repo. This is the gaptest suite. Would you please review these test? Any comment will be appreciated. bug: https://bugs.openjdk.java.net/browse/J

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

On 28/01/2015 7:03 AM, Lev Priima wrote: Yes. And if we have BlockingQueue w/ some amount of tasks which fail with exceptions, same amount of threads(not limited by neither maximumPoolSize/corePoolSize) will hang under TPE which takes tasks from this queue. It may cause problems if queue has a b

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

Thank you, Joe. I will sort the tests as your suggestion, and have 3 questions to confirm with you: 1. Should I also sort the gap tests? 2. Should I put astro suite at side of auctionportal? 3. If a package has very few test, e.g. I may put XMLEventFactoryTest and something else in javax.xml.strea

Re: Time to retire System.runFinalizersOnExit?

On 1/27/2015 1:49 AM, Aleksey Shipilev wrote: On 27.01.2015 07: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'

Re: Useful message about NullPointerException

Adding back in hotspot-dev to this reply There have been previous RFEs for this dating back to 2006 - most closed as duplicates and the main one eventually closed as "will not fix" simply due to it being a low priority RFE for 8 years. Also see: https://bugs.openjdk.java.net/browse/JDK-67175

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

Hi Frank, Nice refactoring the original tests, esp. the TransformerTest! jaxp14 is legacy in the jaxp standalone world. While we are at this, you may want to move these tests to their relevant packages since in the JDK world, jaxp14 is no longer relevant (jaxp 1.4 was integrated into JDK 6).

Re: java.util.DualPivotQuickSort does not guarantee NlogN time

An ugly but non-intrusive workaround, that would not add much overhead for usual cases,taking advantage of quadraticness blowing up in stack overflow before long: public class ParanoidSort {    public static void sort(Object[] a) {     try {     Arrays.sort(a);     } catch (Stac

Re: java.util.DualPivotQuickSort does not guarantee NlogN time

On 1/27/2015 12:15 PM, Doug Lea wrote: On 01/27/2015 08:44 AM, Buis, Paul wrote: The slowdown would be passing a single extra integer parameter, decrementing it and comparing it to zero at the beginning of the function. Right. The question is whether even a small slowdown is warranted. Does

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

On 01/27/2015 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/~psandoz/jdk9/JDK-8050819-Stream-ofNullable

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

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/~psandoz/jdk9/JDK-8050819-Stream-ofNullable/webrev/ Stream.ofNullable can make it easier

Re: Time to retire System.runFinalizersOnExit?

I was referring to http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java which I occasionally advertise here. (but it's intended to be used for testing...) On Tue, Jan 27, 2015 at 2:00 PM, Peter Levart wrote: > > On 01/27/2015 09:5

Re: Time to retire System.runFinalizersOnExit?

On 01/27/2015 09:55 PM, Martin Buchholz wrote: If you want to ensure something is run before VM exit, add a shutdown hook. If you really want to run all the finalizers, you can always run a variant of GcFinalization in your shutdown hook, although as always running during shutdown increases

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

Looking very good, thanks. Ship it! Actually, can you insert a comment why the injected counts are not scaled? (Or perhaps they should be??) Also, we may need a followup bug for the code with this comment: // Look for the following shape: AndI (ProfileBoolean) (ConI 1)) Since profileBoolean

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

Yes. And if we have BlockingQueue w/ some amount of tasks which fail with exceptions, same amount of threads(not limited by neither maximumPoolSize/corePoolSize) will hang under TPE which takes tasks from this queue. It may cause problems if queue has a big percentage of exception-fail tasks

Re: Time to retire System.runFinalizersOnExit?

If you want to ensure something is run before VM exit, add a shutdown hook. If you really want to run all the finalizers, you can always run a variant of GcFinalization in your shutdown hook, although as always running during shutdown increases the risk greatly. On Tue, Jan 27, 2015 at 6:48 AM, P

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

On Tue, Jan 27, 2015 at 7:43 AM, Lev Priima wrote: > And these thread will be cleaned only when whole TPE finished. > > Is this really true? Each thread should be replaced while running and so the total number of threads retained by the TPE at any one time should be no more than core pool size.

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

[Oops. I dropped core-libs-dev CC on reply. Resending...) On 01/27/2015 10:43 AM, Lev Priima wrote: Using TPE w/ custom BlockingQueue and if RuntimeException happens in blocking BlockingQueue.take() method then this code new ThreadPoolExecutor(1, 1, 0, TimeUnit.NANOSECONDS, new ArrayBlock

Re: java.util.DualPivotQuickSort does not guarantee NlogN time

On 01/27/2015 08:44 AM, Buis, Paul wrote: The slowdown would be passing a single extra integer parameter, decrementing it and comparing it to zero at the beginning of the function. Right. The question is whether even a small slowdown is warranted. Does quadratic behavior arise more that once

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

Hi Frank, On Jan 27, 2015, at 4:40 AM, Frank Yuan wrote: > Thank you, Lance! > > I applied some experience from your previous comments:) I a glad they were useful :-) > > I have a question for your comment, could you check it below in line? See below > > Best Regards > Frank > > From:

Java cmdline encoding challenges on Windows

Hello, We're proposing an improvement to the OpenJDK intended to fix the currently existing problem with handling Unicode parameters on the command line in Windows (via cmd.exe), which prevents users for example in China from properly passing text strings in their own language via the java.exe c

Re: [9] RFR of 6880737: (fs) FileLock constructors don't throw NPE if the channel argument is null

On Jan 27, 2015, at 4:19 AM, Alan Bateman wrote: > On 27/01/2015 01:40, Brian Burkhalter wrote: >> >> Here’s another updated patch: >> >> http://cr.openjdk.java.net/~bpb/6880737/webrev.02/ > Thanks for the update and moving the test to the right place. I think this is > okay for now. This do

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

Thanks for the feedback, John! Updated webrev: http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03/jdk http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03/hotspot Changes: - renamed MHI::profileBranch to MHI::profileBoolean, and ProfileBranchNode to ProfileBooleanNode; - restructured

Re: Useful message about NullPointerException

On 01/27/2015 03:34 PM, kedar mhaswade wrote: When the JVM executes instructions like getfield , getstatic, invokevirtual etc. with *objref* on the operand stack and if *objref* is null, an NPE is thrown. It appears

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

Using TPE w/ custom BlockingQueue and if RuntimeException happens in blocking BlockingQueue.take() method then this code new ThreadPoolExecutor(1, 1, 0, TimeUnit.NANOSECONDS, new ArrayBlockingQueue(1) { public Runnable take() throws InterruptedException { throw new Runtim

Re: Useful message about NullPointerException

On 01/27/2015 03:57 PM, Seán Coffey wrote: > 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

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: Useful message about NullPointerException

kedar mhaswade wrote > When the JVM executes instructions like getfield > ;, > getstatic, invokevirtual etc. with *objref* on the operand stack and if > *objref* is null, an NPE is thrown. It appears that the JVM could

Re: Time to retire System.runFinalizersOnExit?

On 01/27/2015 01:54 PM, Peter Levart wrote: A poor-man's escape hatch is a shutdown hook that calls System.runFinalization(). Which might interfere with other shutdown hooks that run concurrently (runFinalizersOnExit runs finalizers after all shutdown hooks are finished). Not really. This on

Re: Useful message about NullPointerException

When the JVM executes instructions like getfield , getstatic, invokevirtual etc. with *objref* on the operand stack and if *objref* is null, an NPE is thrown. It appears that the JVM could tell us more about which *obj

Re: java.util.DualPivotQuickSort does not guarantee NlogN time

The slowdown would be passing a single extra integer parameter, decrementing it and comparing it to zero at the beginning of the function. With an initial value of 4*logN, heapsort would hardly ever be called in practice, only after a long series of unfortundate pivot choices that indicate the

Re: Useful message about NullPointerException

On 01/21/2015 01:45 PM, pike wrote: > We frequently see NullPointerException in our logs. It's really a big > headache when we see a NullPointerException and it is encapsulated in > another exception as we don't know which object is null and it is throwing > an Exception. Is there any way we can ge

Re: Useful message about NullPointerException

Chris Newland wrote > Hi, > > If the contract for a method allows a null return you should really handle > it defensively. Null checks are cheap in terms of performance. > > If you *have* to chain method calls like that then you could drop each > call onto a new source line and the stack trace wi

Re: Useful message about NullPointerException

Hi, If the contract for a method allows a null return you should really handle it defensively. Null checks are cheap in terms of performance. If you *have* to chain method calls like that then you could drop each call onto a new source line and the stack trace will show you which call was on the

Re: Time to retire System.runFinalizersOnExit?

On 01/27/2015 10:49 AM, Aleksey Shipilev wrote: On 27.01.2015 07: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

Re: [9] RFR of 6880737: (fs) FileLock constructors don't throw NPE if the channel argument is null

On 27/01/2015 01:40, Brian Burkhalter wrote: Here’s another updated patch: http://cr.openjdk.java.net/~bpb/6880737/webrev.02/ Thanks for the update and moving the test to the right place. I think this is okay for now. -Alan

Re: No generic version of DualPivotQuickSort

On 01/26/2015 03:54 PM, Buis, Paul wrote: The java.util.DualPivotQuicksort class implements sort() methods for the primitive types, has no methods that deal with generic arrays with methods like static > void sort(T[] array, int iStart, int iEnd) Similarly, it contains no methods for Comparator

Re: Review Request 8068937: jdeps shows "not found" if target class has no reference other than its own package

On 27/01/2015 05:14, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8068937/webrev.00/ This simple patch fixes a couple jdeps issues. It makes sure a parsed class is added to the class list even if there is no reference other than its own package which is filtered by defau

Re: Useful message about NullPointerException

kedar mhaswade wrote > On Mon, Jan 26, 2015 at 11:20 AM, Bernd Eckenfels < > ecki@ > > > wrote: > >> Am Wed, 21 Jan 2015 05:45:08 -0700 (MST) >> schrieb pike < > pike630@ > >: >> >> > We frequently see NullPointerException in our logs. It's really a big >> > headache when we see a NullPointerE

Re: java.util.DualPivotQuickSort does not guarantee NlogN time

On 01/26/2015 03:05 PM, Buis, Paul wrote: DualPivotQuickSort is used by Arrays.sort() and provides NlogN average performance, but does not guarantee NlogN worst case performance. It would be relatively easy to incorporate the basic idea of IntroSort (see http://en.wikipedia.org/wiki/Introsort) to

Re: Useful message about NullPointerException

Bernd Eckenfels-4 wrote > Am Wed, 21 Jan 2015 05:45:08 -0700 (MST) > schrieb pike < > pike630@ > >: > >> We frequently see NullPointerException in our logs. It's really a big >> headache when we see a NullPointerException and it is encapsulated in >> another exception as we don't know which obje

Re: Time to retire System.runFinalizersOnExit?

On 27.01.2015 07: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 >

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

Hi, Joe, Lance and All We are working on moving internal jaxp functional tests to open jdk repo. This is the gaptest suite. Would you please review these test? Any comment will be appreciated. bug: https://bugs.openjdk.java.net/browse/JDK-8052401 webrev: http://cr.openjdk.java.net/~fyuan/8052401

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

Hi, Joe, Lance and All We are working on moving internal jaxp functional tests to open jdk repo. This is the jaxp14 suite. Would you please review these test? Any comment will be appreciated. bug: https://bugs.openjdk.java.net/browse/JDK-8051710 webrev: http://cr.openjdk.java.net/~fyuan/8051710/

Re: [9] RFR of 8069269: (spec) Defect in the System.nanoTime spec

On 27 Jan 2015, at 00:49, Brian Burkhalter wrote: > Thanks, I think that reads better than the somewhat obscure verbiage we were > discussing. > > It is formalized here: > > http://cr.openjdk.java.net/~bpb/8069269/webrev.01/ This looks good to me Brian. -Chris. > On Jan 24, 2015, at 9:55 AM