hg: jdk8/tl/jdk: 7158090: (launcher) newly added ToolsOpts.java fails on openjdk builds

[kumar . x . srinivasan]

Changeset: 00572399d39d
Author:ksrini
Date:  2012-03-30 17:22 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00572399d39d

7158090: (launcher) newly added ToolsOpts.java fails on openjdk builds
Reviewed-by: darcy

! test/tools/launcher/ToolsOpts.java

Re: 7127687: MethodType leaks memory due to interning

[John Rose]

On Mar 28, 2012, at 5:42 PM, Vitaly Davidovich wrote:
> I think you can use diamond generic inference when declaring the weak intern 
> set
> 
Done; thanks.
> Also any reason you didn't use WeakHashMap directly with dummy value to 
> simulate the set? Or wrap the WeakHashMap and synchronize the accessors to it
> 
That's been answered already on this thread.

Building collection-like types from reusable components in Java is not a 
fully-solved problem, and the symptom is lots of code copying.  Last time I 
checked, there wasn't even a reusable Map.Entry abstract class.

— John

Re: 7127687: MethodType leaks memory due to interning

[John Rose]

On Mar 28, 2012, at 7:50 PM, David Holmes wrote:

> One query I have is whether, given its intended usage, this change might add 
> pressure to the reference processing subsystem?

Not undue pressure, I hope.  JSR 292 applications tend to converge rapidly on 
the number of distinct MethodTypes they use.  After this the MethodType intern 
table will be stable and its entries will not need reference queue processing.

The main exception to this generalization (which the current patch addresses) 
is that some applications load wads of code via class loaders and then throw 
the class loaders away.  This will cause various kinds of churn in the JVM 
internals, leading to whole classes (etc.) being garbage collected.  In that 
case, the MethodType table needs to "keep up" with the rest of the churn, and 
not cause a storage leak.  I don't see how it can add a significant new 
overhead.  The reclamation of the classes themselves is a far bigger job.

Thanks,
— John

hg: jdk8/tl/jdk: 7142172: Custom TrustManagers that return null for getAcceptedIssuers will NPE

[bradford . wetmore]

Changeset: 7a7dcbbd610f
Author:wetmore
Date:  2012-03-30 15:43 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a7dcbbd610f

7142172: Custom TrustManagers that return null for getAcceptedIssuers will NPE
Reviewed-by: xuelei

! src/share/classes/sun/security/ssl/SSLContextImpl.java
+ 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NullGetAcceptedIssuers.java

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

[Ulf Zibis]

Oops, yes, there is a bug in my code:
FIXED_SIZE can't be reused for multiple instances of TestCollection, so it must 
not be static.
Correction:

public class TestCollection extends AbstractCollection {

private final E[] elements;
private final int[] fixedSize;
private int[] sizes;
private int nextSize;

public TestCollection(E[] elements) {
this.elements = elements;
setSizeSequence(fixedSize = new int[]{elements.length});
}

void setSizeSequence(int... sizes) {
this.sizes = sizes != null ? sizes : fixedSize;
nextSize = 0;
}

   ...

-Ulf


Am 30.03.2012 09:45, schrieb Sean Chou:

Hi Ulf,

While try the ToArray.java testcase, I got the following output with 
jdk1.7.0_01:

java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1342)
at InfraStructure.fail(InfraStructure.java:9)
at InfraStructure.check(InfraStructure.java:12)
at ToArray.test(ToArray.java:39)
at InfraStructure.run(InfraStructure.java:20)
at ToArray.main(ToArray.java:114)
java.lang.ArrayIndexOutOfBoundsException: 2
at ToArray.test(ToArray.java:40)
at InfraStructure.run(InfraStructure.java:20)
at ToArray.main(ToArray.java:114)


   The ArrayIndexOutOfBoundsException is easy to figure out, will you please have a look at the 
first one?



On Thu, Mar 29, 2012 at 2:48 AM, Ulf Zibis mailto:ulf.zi...@gmx.de>> wrote:

Hi David, Sean,

I have made little changes to make understanding little easier, see 
attachment...

-Ulf



Am 28.03.2012 07:29, schrieb David Holmes:

Hi Ulf,


I understand your point about ensuring we test 
AbstractCollection.toArray but I find this
revised test much harder to understand.

Also in the name setPseudoConcurrentSizeCourse the word "Course" 
doesn't fit. I'm not sure
what you were meaning here? Perhaps just modifySize or 
emulateConcurrentSizeChange ?

Thanks,
David




--
Best Regards,
Sean Chou

Re: jtreg, junit, and testng (was Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec)

[Ulf Zibis]

Am 30.03.2012 19:38, schrieb Brian Goetz:

Similarly class Infrastructure could be reused over all JDK's tests. But
personnally I would prefer to more and more use the JUnit framework. Is
there already an existing example?


There's good news on this front.  We are in the process of making TestNG a supported test 
framework for writing unit and regression tests in OpenJDK.  TestNG inherits a lot of ideas from 
JUnit, so JUnit users should find it easy to use, and there are plugins for all the big IDEs.


The goal you state -- making it easier to reuse test infrastructure -- is one of the reasons why 
we want to do this.  Another is that many people are already familiar / comfortable with this 
style of testing, and therefore are more likely to contribute good tests.


I don't have a schedule for when this will be supported within the OpenJDK build and test process, 
but we're working on it.


It seems, jtreg to JUnit bridge is already existing:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2009-October/002003.html

I also have found an example:
http://cr.openjdk.java.net/~jrose/6891770/webrev.00/test/java/dyn/MethodHandlesTest.java.html

-Ulf

hg: jdk8/tl/langtools: 2 new changesets

[maurizio . cimadamore]

Changeset: 379bc17d9a26
Author:mcimadamore
Date:  2012-03-30 19:19 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/379bc17d9a26

7157688: Regression: common compiler diagnostic features swapped required/found 
types
Summary: bug in resource key in compiler.properties
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/resources/compiler.properties

Changeset: c94c09f34701
Author:mcimadamore
Date:  2012-03-30 19:19 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c94c09f34701

7157165: Regression: code with disjunctive type crashes javac
Summary: Bad recovery logic in parser code that checks for generic cast
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/7157165/T7157165.java
+ test/tools/javac/parser/7157165/T7157165.out

Re: jtreg, junit, and testng (was Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec)

[Rémi Forax]

On 03/30/2012 07:38 PM, Brian Goetz wrote:

Similarly class Infrastructure could be reused over all JDK's tests. But
personnally I would prefer to more and more use the JUnit framework. Is
there already an existing example?


There's good news on this front.  We are in the process of making 
TestNG a supported test framework for writing unit and regression 
tests in OpenJDK.  TestNG inherits a lot of ideas from JUnit, so JUnit 
users should find it easy to use, and there are plugins for all the 
big IDEs.


The goal you state -- making it easier to reuse test infrastructure -- 
is one of the reasons why we want to do this.  Another is that many 
people are already familiar / comfortable with this style of testing, 
and therefore are more likely to contribute good tests.


I don't have a schedule for when this will be supported within the 
OpenJDK build and test process, but we're working on it.




just pedantically, TestNG was written after JUnit3 but before JUnit4, 
i.e before JUnit uses annotations,

so JUnit4 inherits from a lot of ideas of TestNG too.

Rémi

jtreg, junit, and testng (was Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec)

[Brian Goetz]

Similarly class Infrastructure could be reused over all JDK's tests. But
personnally I would prefer to more and more use the JUnit framework. Is
there already an existing example?


There's good news on this front.  We are in the process of making TestNG 
a supported test framework for writing unit and regression tests in 
OpenJDK.  TestNG inherits a lot of ideas from JUnit, so JUnit users 
should find it easy to use, and there are plugins for all the big IDEs.


The goal you state -- making it easier to reuse test infrastructure -- 
is one of the reasons why we want to do this.  Another is that many 
people are already familiar / comfortable with this style of testing, 
and therefore are more likely to contribute good tests.


I don't have a schedule for when this will be supported within the 
OpenJDK build and test process, but we're working on it.

Re: RFR 7151484 : NullPointerException caused by a bug in XMLDocumentFragmentScannerImpl

[Joe Wang]

Thanks!

On 3/30/2012 5:41 AM, Lance Andersen - Oracle wrote:

Hi Joe,

Looks fine

-lance
On Mar 30, 2012, at 3:24 AM, Joe Wang wrote:


Hi,

This is a one line fix: adding a return statement as suggested in the 
bug report to guard against null value of the name parameter.


webrev: http://cr.openjdk.java.net/~joehw/7u6/cr7151484/webrev/ 



Please review.

Thanks,
Joe



Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: Please review simple fix : 7158090: (launcher) newly added test ToolsOpts.java fails on openjdk builds

[Joe Darcy]

Approved,

-Joe

On 3/30/2012 9:59 AM, Kumar Srinivasan wrote:

Hi,

Please review this simple fix, the check for "openjdk version" was missed
for openjdk builds, here is the correction:

http://cr.openjdk.java.net/~ksrini/7158090/


Thanks
Kumar

Please review simple fix : 7158090: (launcher) newly added test ToolsOpts.java fails on openjdk builds

[Kumar Srinivasan]

Hi,

Please review this simple fix, the check for "openjdk version" was missed
for openjdk builds, here is the correction:

http://cr.openjdk.java.net/~ksrini/7158090/


Thanks
Kumar

hg: jdk8/tl/jdk: 7156976: improve java tools testing

[kumar . x . srinivasan]

Changeset: 45177d830325
Author:ksrini
Date:  2012-03-29 17:49 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/45177d830325

7156976: improve java tools testing
Reviewed-by: darcy
Contributed-by: steve.si...@oracle.com

! test/tools/launcher/TestHelper.java
+ test/tools/launcher/ToolsOpts.java
! test/tools/launcher/VersionCheck.java

Re: RFR 7151484 : NullPointerException caused by a bug in XMLDocumentFragmentScannerImpl

[Lance Andersen - Oracle]

Hi Joe,

Looks fine

-lance
On Mar 30, 2012, at 3:24 AM, Joe Wang wrote:

> Hi,
> 
> This is a one line fix: adding a return statement as suggested in the bug 
> report to guard against null value of the name parameter.
> 
> webrev: http://cr.openjdk.java.net/~joehw/7u6/cr7151484/webrev/
> 
> Please review.
> 
> Thanks,
> Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently

[Chris Hegarty]

Sorry guys, I think I found the actual cause for this failure. Though I 
think the increased defensive timeouts are still a good idea.


There is a race in the test itself. The "One thread interrupted" test 
tries to interrupt a thread blocked in awaitAdvanceInterruptibly, but 
how do we know the thread has actually made it to this point before we 
interrupt? The usual situation with these kind of tests!


The solution is to retry the interrupt if we know the target thread 
hasn't thrown anything.


http://cr.openjdk.java.net/~chegar/6963841/webrev.01/webrev/

-Chris.


On 27/03/2012 11:58, Doug Lea wrote:

On 03/26/12 23:04, Chris Hegarty wrote:

David, Doug,

This test has been failing intermittently on jdk7u-dev and jdk8 for a
while now.
It only appears to fail when run in our internal build/test system
(JPRT).

I believe the cause of the failure to be simply that the machines the
test is
run on are too slow, or very busy, and the defensive timeout in the
test are not
large enough to handle this. The solution is to increase these timeout
(similar
to other tests in the concurrency area that we increased the timeouts
for too).



OK. I synced with our version. As always, it is too bad that there is no
way to operationalize the notion of "for some timeout value appropriate
for the platform, no TimeoutExceptions occur".

-Doug

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

[Sean Chou]

Hi Ulf,

While try the ToArray.java testcase, I got the following output with
jdk1.7.0_01:

java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1342)
at InfraStructure.fail(InfraStructure.java:9)
at InfraStructure.check(InfraStructure.java:12)
at ToArray.test(ToArray.java:39)
at InfraStructure.run(InfraStructure.java:20)
at ToArray.main(ToArray.java:114)
java.lang.ArrayIndexOutOfBoundsException: 2
at ToArray.test(ToArray.java:40)
at InfraStructure.run(InfraStructure.java:20)
at ToArray.main(ToArray.java:114)


   The ArrayIndexOutOfBoundsException is easy to figure out, will you
please have a look at the first one?


On Thu, Mar 29, 2012 at 2:48 AM, Ulf Zibis  wrote:

> Hi David, Sean,
>
> I have made little changes to make understanding little easier, see
> attachment...
>
> -Ulf
>
>
>
> Am 28.03.2012 07:29, schrieb David Holmes:
>
>> Hi Ulf,
>>
>>
>> I understand your point about ensuring we test AbstractCollection.toArray
>> but I find this revised test much harder to understand.
>>
>> Also in the name setPseudoConcurrentSizeCourse the word "Course" doesn't
>> fit. I'm not sure what you were meaning here? Perhaps just modifySize or
>> emulateConcurrentSizeChange ?
>>
>> Thanks,
>> David
>>
>>


-- 
Best Regards,
Sean Chou

RFR 7151484 : NullPointerException caused by a bug in XMLDocumentFragmentScannerImpl

[Joe Wang]

Hi,

This is a one line fix: adding a return statement as suggested in the 
bug report to guard against null value of the name parameter.


webrev: http://cr.openjdk.java.net/~joehw/7u6/cr7151484/webrev/

Please review.

Thanks,
Joe

Re: Code Review Request: 7157893: Warnings Cleanup in java.util.*

[Rémi Forax]

Hi Kurchi,

I've re-reviewed the file you merged, it's Ok for me.

Rémi

On 03/30/2012 02:15 AM, Kurchi Hazra wrote:

Hi,

  These changes cleanup warnings in java.util.* and were contributed 
by Remi Forax (fo...@univ-mlv.fr).


  Specifically the files that I merged/had conflicts are:
src/share/classes/java/util/Currency.java
src/share/classes/java/util/EnumMap.java
src/share/classes/java/util/PropertyPermission.java
src/share/classes/java/util/ResourceBundle.java
src/share/classes/java/util/TimeZone.java


Bug : http://monaco.us.oracle.com/detail.jsf?cr=7157893
Webrev: http://cr.openjdk.java.net/~khazra/7157893/webrev.00/

Some related discussion that I could find in the core-libs-dev archives:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-December/008601.html 

http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-December/008602.html 




Also, I am going to commit the reviewed patch using the following 
comment. Please let me know if someone else should be listed in 
Contributed-by or Reviewed-by:


Contributed-by: forax
Reviewed-by: mduigou, naoto, smarks


Thanks,
Kurchi