Re: XS RFR: 7198815 Add the minimal VM as known in jvm.cfg
On 01/11/2012 05:24, David Holmes wrote: http://cr.openjdk.java.net/~dholmes/7198815/webrev/ The minimal VM has just reached jdk8/jdk8/hotspot. This change makes it easy for anyone building the minimal VM to actually select it at runtime. Only 32-bit linux platforms are targeted. This will be pushed via the TL repo. This looks okay to me. -Alan
Re: Review Request: CR#8001634 : Initial set of lambda functional interfaces
On 31/10/2012 20:16, Mike Duigou wrote: There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories. We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow. : http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/ This mail concerns some side issues that are nothing to do with the functional interfaces themselves, so file this separately to the feedback on the API. jdk8 still builds with the old build system and I don't think there is a transition date yet. Even after the transition then I expect that the old build system will need to be kept on life support for a few weeks. I just mention this as I don't see any updates to make/java/java/* in the webrev. As the functions are in their own package and are pure java then they just need to be compiled. I think this should do it (no need to list specific classes): --- a/make/java/java/Makefile +++ b/make/java/java/Makefile @@ -62,6 +62,8 @@ include FILES_c.gmk include FILES_c.gmk include FILES_java.gmk include Exportedfiles.gmk + +AUTO_FILES_JAVA_DIRS = java/util/functions ifeq ($(PLATFORM),windows) FILES_java += java/io/WinNTFileSystem.java \ The other minor thing is the copyright headers, a few of the interfaces (such as Block and Mapper) have three dates in the header. There are scripts around that check the format, might be worth running those to avoid noise during the reviews. -Alan
hg: jdk8/tl/jdk: 8002101: break out auxiliary classes that will prevent multi-core compilation of the JDK
Changeset: 8b944ebef8a7 Author:ohrstrom Date: 2012-11-01 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b944ebef8a7 8002101: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, sla + src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java + src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java
Re: Review Request: CR#8001634 : Initial set of lambda functional interfaces
Hi Mike,
A few small comments:
BinaryOperator:
Typo: the the
---
Block:
* @param t an input object
- the input object
---
typeBinaryOperator
* Combines two {@code type} operands of the same type
As opposed to two type operands of different type? :)
typeMapper explicitly says it is the type specialization of Mapper, but
typeBinaryOperator doesn't say the same thing about BinaryOperator.
Ditto for UnaryOperator. We need a consistent approach here.
---
DoubleUnaryOperator
IntUnaryOperator:
@param operand The operand value.
The - the
General consistency note: sometimes the @param descriptive text starts
with a capital and sometimes not.
Mapper:
A mapper may variously provide a mapping between types, object
instances or keys and values or any other form of transformation upon
the input.
I can't parse this sentence and I'm not sure it is adding value beyond
what is already said in the first sentence.
---
UnaryOperator:
* @param T the type of input objects to {@code operate} and of the
result.
objects - object
and perhaps the type of ^the^ input object ...
---
package-info.java
* emFunctional interfaces/em provide typing for lambda methods.
lambda methods? Do you mean lambda expressions?
non-defaulted is a horrible term. Isn't it simply abstract? Seems to
me that abstract default should not be permitted and that default
wipes out any implicit abstract. That way a default method is not an
abstract method, while an abstract method is what it always has been: a
method signature with no implementation.
+ * pAll functional interface implementations are expected to:
The above lead in does not read correctly with the subsequent bullet points
Cheers,
David
On 1/11/2012 6:16 AM, Mike Duigou wrote:
There's a large set of library changes that will be coming with Lambda. We're
getting near the end of the runway and there's lots left to do so we want to
start the process of getting some of the more stable pieces put back to the
JDK8 repositories. We've spent a some time slicing things into manageable
chunks. This is the first bunch. We'd like to time-box this review at one week,
since there are many more pieces to follow.
The first chunk is the basic set of functional interface types. While this set
is not complete, it is enough to be able to proceed on some other pieces. This
set contains no extension methods (we'll do those separately) and does not
contain all the specializations we may eventually need.
The specification is limited; most of the interesting restrictions (side-effect-freedom,
idempotency, stability) would really be imposed not by the SAM itself by by how the SAM
is used in a calculation. However, some common doc for how to write good SAMs
that we can stick in the package doc would be helpful. Suggestions welcome.
Elements of this naming scheme include:
- Each SAM type has a unique (arity, method name) pair. This allows SAMs to
implement other SAMs without collision.
- The argument lists are structured so that specializations act on the first argument(s), so
IntMapperT is a specialization of MapperR,T, and IntBinaryOperator is a
specialization of BinaryOperatorT.
In order to get the most useful feedback out of this review, we'd like to ask
you follow the following guidelines for the review:
- We are time-boxed at one week. (until Nov. 7th)
- Please review the whole bunch in a single message if possible, rather than in
bits and pieces. It is far easier to extract useful feedback from one complete
review than from a dozen partial ones.
- Please wait a few days before replying to other people's reviews! We want to
keep the discussion on-topic to maximize the useful review content. It is far
too easy for the discussion to spiral off into minutia and lose sight of the
goal -- which is to provide useful feedback on the API we're asking for
feedback on.
http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/
hg: jdk8/tl/langtools: 7153951: Add new lint option -Xlint:auxiliaryclass
Changeset: bf54daa9dcd8 Author:ohrstrom Date: 2012-11-01 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf54daa9dcd8 7153951: Add new lint option -Xlint:auxiliaryclass Reviewed-by: jjg, mcimadamore, forax ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassUsingAuxiliary.java + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out + test/tools/javac/warnings/AuxiliaryClass/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/NotAClassName.java + test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
Re: Review Request: CR#8001634 : Initial set of lambda functional interfaces
On 11/01/2012 10:43 AM, David Holmes wrote: [...] package-info.java * emFunctional interfaces/em provide typing for lambda methods. lambda methods? Do you mean lambda expressions? non-defaulted is a horrible term. Isn't it simply abstract? Seems to me that abstract default should not be permitted and that default wipes out any implicit abstract. That way a default method is not an abstract method, while an abstract method is what it always has been: a method signature with no implementation. I agree that a single abstract method is a better term here. Nitpicking, Java 8 allows static methods in interface so non-default doesn't mean abstract but abstract or static methods. Cheers, David Cheers, Rémi On 1/11/2012 6:16 AM, Mike Duigou wrote: There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories. We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow. The first chunk is the basic set of functional interface types. While this set is not complete, it is enough to be able to proceed on some other pieces. This set contains no extension methods (we'll do those separately) and does not contain all the specializations we may eventually need. The specification is limited; most of the interesting restrictions (side-effect-freedom, idempotency, stability) would really be imposed not by the SAM itself by by how the SAM is used in a calculation. However, some common doc for how to write good SAMs that we can stick in the package doc would be helpful. Suggestions welcome. Elements of this naming scheme include: - Each SAM type has a unique (arity, method name) pair. This allows SAMs to implement other SAMs without collision. - The argument lists are structured so that specializations act on the first argument(s), so IntMapperT is a specialization of MapperR,T, and IntBinaryOperator is a specialization of BinaryOperatorT. In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review: - We are time-boxed at one week. (until Nov. 7th) - Please review the whole bunch in a single message if possible, rather than in bits and pieces. It is far easier to extract useful feedback from one complete review than from a dozen partial ones. - Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content. It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on. http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/
Re: XS RFR: 7198815 Add the minimal VM as known in jvm.cfg
On 11/01/2012 08:34 AM, Alan Bateman wrote: On 01/11/2012 05:24, David Holmes wrote: http://cr.openjdk.java.net/~dholmes/7198815/webrev/ The minimal VM has just reached jdk8/jdk8/hotspot. This change makes it easy for anyone building the minimal VM to actually select it at runtime. Only 32-bit linux platforms are targeted. This will be pushed via the TL repo. This looks okay to me. -Alan Okay, to me too. Rémi
Re: RFR: 7050936: (pack200) Support version 52.0 class files
Hi David, Hi Kumar, On 1/11/2012 4:15 AM, Kumar Srinivasan wrote: Please review change which allows pack200 to recognize the class file v52.0. Looks fine, but I'm curious - if constants.h was never updated for 51.0 are those values even being used? You are absolutely right, class file version is not used by the unpacker (constant.h), I thought I will update this for the sake of completeness. Thanks for the review! Kumar David Bug is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7050936 Webrev is here: http://cr.openjdk.java.net/~ksrini/7050936/webrev.0/ Thanks Kumar
Re: Review Request: CR#8001634 : Initial set of lambda functional interfaces
Hi Mike,
Just a few minor javadoc suggestions. Otherwise, the meat looks good.
Thanks,
Jim
---
Copyrights -
- why do some of the copyrights say 2010, 2011, 2012 ? Is this the
correct format? DoubleBinaryOperater.java (and others) just have 2012
java/util/BinaryOperator.java
- why is extends CombinerT,T,T commented out on the interface
decl? Is this part of the phase-in of these changes?
- for the javadoc for operate(T,T), I'd say Returns the result of
some /binary /operation upon the operands.
java/util/DoubleBinaryOperator.java
- for the javadoc for operate(double,double), I'd say Returns the
result of some /binary /operation upon the operands.
java/util/DoubleMapper.java
- javadoc - simply insert comma between Given an input object and
maps to an appropriate {@code double) value
java/util/DoubleUnaryOperator.java
- Returns a {@code double} value computed from the double
operand. Should the second double also be {@code double}?
java/util/functions/Factory.java
- Returns an object. The returned object may be an existing object
or a newly created object. This might be better: Returns an object
which may have been created previously or is newly created.
- for make() - Returns an object -- Creates and returns an
object or returns one previously created
java/util/functions/IntBinaryOperator.java
- Combines two {@code int} operands of the same type producing an
{@code int} result -- I'd insert a comma between type and producing
- some operation - some /binary/ operation
java/util/IntMapper.java
- javadoc - simply insert comma between Given an input object and
maps to an appropriate {@code int) value
java/util/functions/LongBinaryOperator.java
- some operation - some /binary/ operation
java/util/LongMapper.java
- javadoc - simply insert comma between Given an input object and
maps to an appropriate {@code long) value
java/util/Mapper.java
- javadoc - simply insert comma between Given an input object and
maps to an appropriate output object
java.util/functions/Predicate.java
- I think condition might be better than criteria
java/util/functions/UnaryOperator.java
- @param T the type of input objects to {@code operate} and of
the result is hard to parse. Perhaps this would be better: @param
T the operand and result type of the {@code operate} method
- why is extends MapT,T commented out?
java/util/functions/package-info.html
- this seems a little awkward:
35 * pAll functional interface implementations are expected to:
36 * ul
37 * liWhen used for aggregate operations upon many elements it should not
be
38 * assumed that the operation will be called upon elements in any specific
order.
39 * /li
40 * /ul
It appears you were/are expecting additional things to be added to the
list of expectations. Maybe it would be best to reserve the list
structure of the comment for the time where additional conditions are
added. Until then a simpler sentence would be cleaner:
When used for aggregate operations upon many elements, no functional
interface implementation should assume that the operation will be called
upon elements in any specific order.
As Porky would say, That's all folks! :-)
On 10/31/2012 04:16 PM, Mike Duigou wrote:
There's a large set of library changes that will be coming with Lambda. We're
getting near the end of the runway and there's lots left to do so we want to
start the process of getting some of the more stable pieces put back to the
JDK8 repositories. We've spent a some time slicing things into manageable
chunks. This is the first bunch. We'd like to time-box this review at one week,
since there are many more pieces to follow.
The first chunk is the basic set of functional interface types. While this set
is not complete, it is enough to be able to proceed on some other pieces. This
set contains no extension methods (we'll do those separately) and does not
contain all the specializations we may eventually need.
The specification is limited; most of the interesting restrictions (side-effect-freedom,
idempotency, stability) would really be imposed not by the SAM itself by by how the SAM
is used in a calculation. However, some common doc for how to write good SAMs
that we can stick in the package doc would be helpful. Suggestions welcome.
Elements of this naming scheme include:
- Each SAM type has a unique (arity, method name) pair. This allows SAMs to
implement other SAMs without collision.
- The argument lists are structured so that specializations act on the first argument(s), so
IntMapperT is a specialization of MapperR,T, and IntBinaryOperator is a
specialization of BinaryOperatorT.
In order to get the most useful feedback out of this review, we'd like to ask
you follow the following guidelines for the review:
- We are time-boxed at one
Re: XS RFR: 7198815 Add the minimal VM as known in jvm.cfg
Looks good to me. Mandy On 10/31/2012 10:24 PM, David Holmes wrote: http://cr.openjdk.java.net/~dholmes/7198815/webrev/ The minimal VM has just reached jdk8/jdk8/hotspot. This change makes it easy for anyone building the minimal VM to actually select it at runtime. Only 32-bit linux platforms are targeted. This will be pushed via the TL repo. Thanks, David
Re: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK
If someone is doing a partial build (without langtools) the import jdk is used for javac compilation, not the boot jdk javac. This has not changed. The boot jdk javac is only used to build langtools and the hotspot serviceability agent. -kto On Oct 31, 2012, at 7:22 PM, David Holmes wrote: Hi Jon, On 1/11/2012 12:09 PM, Jonathan Gibbons wrote: David, For a long time now, the JDK 8 langtools repo has accepted -source 8 and -target 8, so this should not affect which version of langtools you need to use. Of course, you do need to make sure that these options are not used with the bootstrap javac, which will typically be from JDK 7. That wasn't quite my query/concern - I wasn't very clear. If someone is doing a partial build, ie JDK repo only, they will now have to use a JDK8 boot JDK (or point to suitable langtools import?) - correct? (Where a full build would use the current langtools to build the rest of the JDK.) Just trying to understand if there may be places (JPRT?) where we've so far been able to use a JDK7 boot JDK but will no longer be able to. Thanks, David -- Jon On 10/31/2012 06:38 PM, David Holmes wrote: Hi Kumar, So after this jdk8 builds will have to use current langtools javac in order to work? The corresponding changes to the new build system will be needed as well. David On 1/11/2012 3:43 AM, Kumar Srinivasan wrote: Hello, Please review changes to rev up the default -source and -target for jdk compilation, thus producing v52.0 class files. Bug is here: https://jbs.oracle.com/bugs/browse/JDK-8001191 Webrev is here: http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/ Note: this webrev is generated against the master repository but changes will be pushed via tl after the tl-master sync is completed. Thanks Kumar
Re: Review request for 8001536 updated
On 31/10/2012 15:08, Lance Andersen - Oracle wrote:
Here is revised webrev taking into account Remi's suggestions
http://cr.openjdk.java.net/~lancea/8001536/webrev.01/
I skimmed over the updated webrev and the changes mostly look okay to me.
One comment on the clone method is that The internal {@code Blob} field
will be set to null doesn't seem right. Shouldn't this say that the
resulting object doesn't have an underlying Blob?
I don't know if you want formatting/type comments but a couple of nits:
- In both classes then it looks like the javadoc comment on equals has
been shunted right by space
- In equals then if( seems to be missing a space between if and (.
There's another one in readObject.
- The spacing around + in hashCode is a bit odd, it doesn't matter of
course but would be good to be consistent
- the first line of both readObject has also been shunted right by one
space.
-Alan.
Re: about JavaOne2012 Finding and Solving Java Deadlocks
I've pinged Heinz - M On 31 October 2012 20:08, Jim Gish jim.g...@oracle.com wrote: I'd be very interested in this too, and would also like to see the slides. Thanks, Jim On 10/15/2012 05:50 PM, Mike Duigou wrote: The session was a hands on lab so was not recorded that I can tell. Here's the official session page: https://oracleus.activeevents.**com/connect/search.ww?event=** javaone#loadSearch-event=**javaonesearchPhrase=** searchType=sessiontc=0**sortBy=p=i%2811424%29=18653** i%2810050%29=i%2810090%29=i%**2810092%29=i%2811842%29=i%**2810086%29=https://oracleus.activeevents.com/connect/search.ww?event=javaone#loadSearch-event=javaonesearchPhrase=searchType=sessiontc=0sortBy=p=i%2811424%29=18653i%2810050%29=i%2810090%29=i%2810092%29=i%2811842%29=i%2810086%29= Some of the presenters are subscribers to this list. If they don't respond with the slides perhaps you can contact them. Mike On Oct 13 2012, at 03:44 , fuyou wrote: hi all I am very interested in session of HOL6500 - Finding and Solving Java Deadlocks(JavaOne 2012) .how can i watch video or download slides. Thanks! -- ==**=== fuyou001 Best Regards -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
hg: jdk8/tl/jdk: 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format()
Changeset: 6420fcd61c10 Author:naoto Date: 2012-11-01 13:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6420fcd61c10 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format() Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormatSymbols.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh
Re: about JavaOne2012 Finding and Solving Java Deadlocks
You can download the lab with the slides from here: https://github.com/henri-tremblay/DeadlockLabJavaOne2012 If you have any comments or questions, please email me directly to he...@javaspecialists.eu. Even though I am on this list, I don't read every message that comes past. I did see your one, but I forgot to reply and without Martijn's prompting it would have escaped into the mists of time. Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of The Java(tm) Specialists' Newsletter Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz On 10/31/12 9:08 PM, Jim Gish wrote: I'd be very interested in this too, and would also like to see the slides. Thanks, Jim On 10/15/2012 05:50 PM, Mike Duigou wrote: The session was a hands on lab so was not recorded that I can tell. Here's the official session page: https://oracleus.activeevents.com/connect/search.ww?event=javaone#loadSearch-event=javaonesearchPhrase=searchType=sessiontc=0sortBy=p=i%2811424%29=18653i%2810050%29=i%2810090%29=i%2810092%29=i%2811842%29=i%2810086%29= Some of the presenters are subscribers to this list. If they don't respond with the slides perhaps you can contact them. Mike On Oct 13 2012, at 03:44 , fuyou wrote: hi all I am very interested in session of HOL6500 - Finding and Solving Java Deadlocks(JavaOne 2012) .how can i watch video or download slides. Thanks! -- = fuyou001 Best Regards
8002120: ProblemList.txt updates (11/2012)
I need a reviewer to remove 5 tests from the exclude list. 4 of the tests were excluded temporarily during the perm gen removal work. The other one was a compiler2 bug that is long fixed. While I was there I updated TEST.ROOT to add the top-level directories for the client area to othervm.dirs. This ensures that the tests for those areas is run in jtreg othervm mode even if samevm or agentvm mode is specified to jtreg. If the tests in those areas are updated so that each test doesn't require its own VM then they can be removed from the othervm.dirs list. The patch is trivial and inlined below. -Alan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -136,12 +136,6 @@ java/lang/management/MemoryMXBean/ResetP # 7196801 java/lang/management/MemoryMXBean/LowMemoryTest2.shgeneric-all - -# Exclude until the fix for 7195557 propagates widely. -java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh generic-all -java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh generic-all -java/lang/management/MemoryMXBean/MemoryTest.java generic-all -java/lang/management/MemoryMXBean/MemoryTestAllGC.sh generic-all # Exclude until hotspot/jdk repos are sync'd w.r.t. JAVA_MAX_SUPPORTED_VERSION # Needed when hotspot fix 7054345 is present. Remove when the JDK source is @@ -334,9 +328,6 @@ sun/security/krb5/auto/MaxRetries.java # jdk_text -# 7196199 -java/text/Bidi/Bug6665028.java generic-all - # jdk_tools diff --git a/test/TEST.ROOT b/test/TEST.ROOT --- a/test/TEST.ROOT +++ b/test/TEST.ROOT @@ -6,7 +6,7 @@ keys=2d dnd i18n keys=2d dnd i18n # Tests that must run in othervm mode -othervm.dirs=java/rmi sun/rmi javax/management +othervm.dirs=java/awt java/beans java/rmi javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces sun/rmi # Tests that cannot run concurrently exclusiveAccess.dirs=java/rmi/Naming sun/management/jmxremote sun/tools/jstatd
Re: 8002120: ProblemList.txt updates (11/2012)
looks fine On Nov 1, 2012, at 5:12 PM, Alan Bateman wrote: I need a reviewer to remove 5 tests from the exclude list. 4 of the tests were excluded temporarily during the perm gen removal work. The other one was a compiler2 bug that is long fixed. While I was there I updated TEST.ROOT to add the top-level directories for the client area to othervm.dirs. This ensures that the tests for those areas is run in jtreg othervm mode even if samevm or agentvm mode is specified to jtreg. If the tests in those areas are updated so that each test doesn't require its own VM then they can be removed from the othervm.dirs list. The patch is trivial and inlined below. -Alan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -136,12 +136,6 @@ java/lang/management/MemoryMXBean/ResetP # 7196801 java/lang/management/MemoryMXBean/LowMemoryTest2.shgeneric-all - -# Exclude until the fix for 7195557 propagates widely. -java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh generic-all -java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh generic-all -java/lang/management/MemoryMXBean/MemoryTest.java generic-all -java/lang/management/MemoryMXBean/MemoryTestAllGC.sh generic-all # Exclude until hotspot/jdk repos are sync'd w.r.t. JAVA_MAX_SUPPORTED_VERSION # Needed when hotspot fix 7054345 is present. Remove when the JDK source is @@ -334,9 +328,6 @@ sun/security/krb5/auto/MaxRetries.java # jdk_text -# 7196199 -java/text/Bidi/Bug6665028.java generic-all - # jdk_tools diff --git a/test/TEST.ROOT b/test/TEST.ROOT --- a/test/TEST.ROOT +++ b/test/TEST.ROOT @@ -6,7 +6,7 @@ keys=2d dnd i18n keys=2d dnd i18n # Tests that must run in othervm mode -othervm.dirs=java/rmi sun/rmi javax/management +othervm.dirs=java/awt java/beans java/rmi javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces sun/rmi # Tests that cannot run concurrently exclusiveAccess.dirs=java/rmi/Naming sun/management/jmxremote sun/tools/jstatd 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: about JavaOne2012 Finding and Solving Java Deadlocks
Thank you -- it's much appreciated. Jim On 11/01/2012 04:26 PM, Dr Heinz M. Kabutz wrote: You can download the lab with the slides from here: https://github.com/henri-tremblay/DeadlockLabJavaOne2012 If you have any comments or questions, please email me directly to he...@javaspecialists.eu. Even though I am on this list, I don't read every message that comes past. I did see your one, but I forgot to reply and without Martijn's prompting it would have escaped into the mists of time. Regards Heinz -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
hg: jdk8/tl/jdk: 8001536: Added readObject, writeObject, clone, equals, hashcode to SerialXLob
Changeset: 8748331f63cf Author:lancea Date: 2012-11-01 17:35 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8748331f63cf 8001536: Added readObject,writeObject,clone, equals, hashcode to SerialXLob Reviewed-by: alanb, forax ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java
hg: jdk8/tl/jdk: 8002120: ProblemList.txt updates (11/2012)
Changeset: 79774104a1f4 Author:alanb Date: 2012-11-01 21:59 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79774104a1f4 8002120: ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT
hg: jdk8/tl/jdk: 7198815: Add the minimal VM as known in jvm.cfg
Changeset: 9b3867244eec Author:dholmes Date: 2012-11-01 18:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b3867244eec 7198815: Add the minimal VM as known in jvm.cfg Reviewed-by: alanb, forax, mchung ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg
