hg: jdk8/tl/jdk: 6950237: Test java/nio/file/Path/CopyAndMove.java does not work correctly when test dir in on VFAT
Changeset: b8e08f5d255a Author:dxu Date: 2012-09-28 11:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8e08f5d255a 6950237: Test java/nio/file/Path/CopyAndMove.java does not work correctly when test dir in on VFAT Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! test/java/nio/file/Files/CopyAndMove.java
Re: RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent
Please review the changes described below. Again, at http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward/ http://cr.openjdk.java.net/%7Ejgish/Bug6206780-sb-append-forward/ Thanks, Jim On 09/26/2012 01:22 PM, Jim Gish wrote: On 09/26/2012 06:12 AM, Chris Hegarty wrote: Hi Jim, This is a nice cleanup, and certainly makes builder and buffer more consistent. Some specific comments: - StringBuilder Why the change to the public doc for append(StringBuffer)? It looks wrong to me. It is now taking about the wrong given type. \ accident - fixed. - Trivially, the year in the header of the tests is incorrect Fixed - StringBuffer I don't see that any of the new synchronized blocks are necessary. If ASB is doing exactly the same as the previous buffer code, then it will invoke the overridden subclass methods that are already synchronized. Good catch. I verified this, and you're absolutely right. Fixed. Thanks. I'll re-spin the patch and send it your way for pushing, if you would be so kind, please. Cheers, Jim -Chris. On 25/09/2012 23:03, Jim Gish wrote: Please review the change at http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward Overview -- * introduced consistent forwarding to AbstractStringBuilder from StringBuffer and StringBuilder for append and other methods per the bug report. * Added missing @Override annotations. * Got rid of knowledge of the sub-classes from ASB (smelled too bad to leave in). * Retained all methods to maintain compatibility (even though some like append(StringBuffer) could go away because append(CharSequence) would do). * To further maintain compatibility, used sychronized(this) in place of adding synchronized methods to those methods in StringBuffer that now need it (because of type-based dispatch being done in super rather than in /both/ StringBuffer and StringBuilder with CharSequence args). * Ensured that StringBuffer.append(StringBuilder) and StringBuilder.append(StringBuffer) are both handled properly. Thanks, Jim -- 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/langtools: 7199925: Separate compilation breaks check that elements have a default for the containing annotation
Changeset: 73312ec2cf7c Author:jfranck Date: 2012-09-28 11:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/73312ec2cf7c 7199925: Separate compilation breaks check that elements have a default for the containing annotation Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
Re: RFR: 7159567 - inconsistent configuration of MemoryHandler
I've re-spun the change with additional usage notes in the spec to reflect the long-standing actual behavior. Note that it doesn't change the spec per se, as it was already stated in LogManager. This change simply replicates that language with an example in each *Handler class to make it easier to find. The webrev, as posted at http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-logging-MemoryHandler/ Thanks, Jim On 09/27/2012 10:05 AM, Jim Gish wrote: I agree. I reached the same conclusion, but wanted to see how others reacted. Can we handle the spec change separate from the bug fix? If so, I'll file another spec bug, and proceed with this fix. The key part of the current language that leaves this open and undefined as it is is By default eachttMemoryHandler/tt is initialized using the following LogManager configuration properties. and then refers to java.util.logging.foo properties. Thanks, Jim On 09/26/2012 10:44 PM, Mandy Chung wrote: Hi Jim, On 9/26/2012 2:19 PM, Jim Gish wrote: Please review http://cr.openjdk.java.net/~jgish/Bug7159567-set-MemoryHandler-target/ http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-MemoryHandler-target/ Overview - currently you can sub-class java.util.logging.MemoryHandler and specify its configuration in a logging.properties file via the classname. For example, if com.foo.MyMemoryHandler extends MemoryHandler, you can have: logging.properties: com.foo.MyMemoryHandler.push=WARNING com.foo.MyMemoryHandler.level=FINEST The current implementation does use thehandler-classname.* properties. However I couldn't find it from the j.u.logging specification. Did I miss any javadoc that mentions this? Per the j.u.l.MemoryHandler specification, it only reads java.util.logging.MemoryHandler.* properties but not the properties with the subclass name. *bConfiguration:/b * By default eachttMemoryHandler/tt is initialized using the following * LogManager configuration properties. If properties are not defined * (or have invalid values) then the specified default values are used. * If no default value is defined then a RuntimeException is thrown. *ul *lijava.util.logging.MemoryHandler.level *specifies the level for thettHandler/tt *(defaults tottLevel.ALL/tt). *lijava.util.logging.MemoryHandler.filter *specifies the name of attFilter/tt class to use *(defaults to nottFilter/tt). *lijava.util.logging.MemoryHandler.size *defines the buffer size (defaults to 1000). *lijava.util.logging.MemoryHandler.push *defines thettpushLevel/tt (defaults tottlevel.SEVERE/tt). *lijava.util.logging.MemoryHandler.target *specifies the name of the targetttHandler/tt class. *(no default). */ul I looked at the change history and found that the change to read property using the classname as the prefix (rather than j.u.l.MemoryHandler) was done in JDK 5 in the fix for 4635817. This isn't related to the bug you're fixing but I think this deserves to investigate whether this was an intended spec change at that time; if so, a spec update to clarify this behavior would be good. Thanks Mandy -- 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
Re: RFR: 7159567 - inconsistent configuration of MemoryHandler
On 9/28/2012 12:13 PM, Jim Gish wrote:
I've re-spun the change with additional usage notes in the spec to
reflect the long-standing actual behavior. Note that it doesn't
change the spec per se, as it was already stated in LogManager. This
change simply replicates that language with an example in each
*Handler class to make it easier to find.
Thanks for looking into it. This statement in LogManager does
specify the properties for handlers:
The properties for loggers and Handlers will have names starting
with the dot-separated name for the handler or logger.
Replicating that statement with an example is one way to do it.
Would it be clearer if the prefix of the properties referenced
in the bullet list is replaced from java.util.logging to
some kind of prefix - something like this:
*bConfiguration:/b
* By default eachttConsoleHandler/tt is initialized using the following
*ttLogManager/tt configuration properties. If properties are not defined
* (or have invalid values) then the specified default values are used.
*ul
*lihandler's classname.level
*specifies the default level for thettHandler/tt
*(defaults tottLevel.INFO/tt).
...snip
*/ul
*
* For example, the properties for {@code ConsoleHandler} would be:
* java.util.logging.ConsoleHandler.level=INFO
*
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
*
* For a custom handler, e.g. com.foo.MyHandler, the properties would be:
* com.foo.MyHandler.level=INFO
* com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter
This might add some clarity to the spec.
This is a spec bug fix that I would suggest to file a CCC to
track for compatibility. I would also suggest running the JCK
tests to find out if there is any regression due to this fix.
The webrev, as posted at
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
See my comment above w.r.t. the spec change.
test/java/util/logging/MemoryHandler.java
L27: via via typo
L28: @run tag specifies the test name
So it should be @run main/othervm MemoryHandler
L43: jtreg runs the test in a different working directory
other than the test source. So the test has to read
the system property (test.src) to determine the location
of the properties file. Typically, we will do this:
String src = System.getProperty(test.src, .);
File fname = new File(src, LM_PROP_FNAME);
You don't need L44. You can reference LoggingDeadlock3.java test.
L51: this catch block to throw a RuntimeException doesn't seem
necessary. If NPE is thrown, the test will fail anyway.
One suggestion to the test is to test both cases (one with
the specified target handler and one without). You can
define a custom target handler so that the test can verify
if the expected one is used. A simple handler to count
the number of log messages will do the work.
test/java/util/logging/MemoryHandlerTest.props
I suggest to take out the comments and just keep the
properties the test needs to make it easier to tell
what's configured.
Perhaps you should also specify
java.util.logging.MemoryHandler.target to make sure
that the custom handler with no target handler specified
will not use j.u.l.MemoryHandler.target as the default.
Mandy
hg: jdk8/tl/jaxp: 3 new changesets
Changeset: 2eafc339f7e1 Author:ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2eafc339f7e1 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/Makefile Changeset: 7c9475c7618c Author:katleman Date: 2012-09-19 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7c9475c7618c Merge Changeset: 1cb19abb3f7b Author:katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1cb19abb3f7b Added tag jdk8-b57 for changeset 7c9475c7618c ! .hgtags
hg: jdk8/tl/corba: 3 new changesets
Changeset: 5c4f045fbd5f Author:ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5c4f045fbd5f 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/Makefile Changeset: f3ab4163ae01 Author:katleman Date: 2012-09-19 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/f3ab4163ae01 Merge Changeset: 18462a19f7bd Author:katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/18462a19f7bd Added tag jdk8-b57 for changeset f3ab4163ae01 ! .hgtags
hg: jdk8/tl/langtools: 5 new changesets
Changeset: 463fea75b618 Author:ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/463fea75b618 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/Makefile Changeset: 86d5740b9fdc Author:katleman Date: 2012-09-19 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/86d5740b9fdc Merge Changeset: bc42f20bfe48 Author:katleman Date: 2012-09-20 13:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc42f20bfe48 Added tag jdk8-b57 for changeset 86d5740b9fdc ! .hgtags Changeset: 804a3fbc86e2 Author:lana Date: 2012-09-24 21:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/804a3fbc86e2 Merge Changeset: e77841f2c74b Author:lana Date: 2012-09-28 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e77841f2c74b Merge
hg: jdk8/tl/jaxws: 3 new changesets
Changeset: bbcbebb9bc74 Author:ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bbcbebb9bc74 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/Makefile Changeset: b51b611209f1 Author:katleman Date: 2012-09-19 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b51b611209f1 Merge Changeset: cac4c3937063 Author:katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/cac4c3937063 Added tag jdk8-b57 for changeset b51b611209f1 ! .hgtags
