test

Construct	Matches	Construct	Matches


Character classes
`[abc]`	`a`, `b`, or `c` (simple class)
`[^abc]`	Any character except `a`, `b`, or `c` (negation)
`[a-zA-Z]`	`a` through `z` - * or `A` through `Z`, inclusive (range)
`[a-d[m-p]]`	`a` through `d`, - * or `m` through `p`: `[a-dm-p]` (union)
`[a-z&&[def]]`	`d`, `e`, or `f` (intersection)
`[a-z&&[^bc]]`	`a` through `z`, - * except for `b` and `c`: `[ad-z]` (subtraction)
`[a-z&&[^m-p]]`	`a` through `z`, - * and not `m` through `p`: `[a-lq-z]`(subtraction)
{@code [abc]}	{@code a}, {@code b}, or {@code c} (simple class)
{@code [^abc]}	Any character except {@code a}, {@code b}, or {@code c} (negation)
{@code [a-zA-Z]}	{@code a} through {@code z} + * or {@code A} through {@code Z}, inclusive (range)
{@code [a-d[m-p]]}	{@code a} through {@code d}, + * or {@code m} through {@code p}: {@code [a-dm-p]} (union)
{@code [a-z&&[def]]}	{@code d}, {@code e}, or {@code f} (intersection)
{@code [a-z&&[^bc]]}	{@code a} through {@code z}, + * except for {@code b} and {@code c}: {@code [ad-z]} (subtraction)
{@code [a-z&&[^m-p]]}	{@code a} through {@code z}, + * and not {@code m} through {@code p}: {@code [a-lq-z]}(subtraction)

Predefined character classes
`\W`	A non-word character: `[^\w]`

POSIX character classes (US-ASCII only)
POSIX character classes (US-ASCII only)
`\p{Lower}`	A lower-case alphabetic character: `[a-z]`
`\p{Upper}`	An upper-case alphabetic character:`[A-Z]`
`\p{ASCII}`	All ASCII:`[\x00-\x7F]`
`\p{Alpha}`	An alphabetic character:`[\p{Lower}\p{Upper}]`
`\p{Digit}`	A decimal digit: `[0-9]`
`\p{Alnum}`	An alphanumeric character:`[\p{Alpha}\p{Digit}]`
`\p{Punct}`	Punctuation: One of !"#$%&'()*+,-./:;<=>?@[\]^_`{\|}~
`\p{Graph}`	A visible character: `[\p{Alnum}\p{Punct}]`
`\p{Print}`	A printable character: `[\p{Graph}\x20]`
`\p{Blank}`	A space or a tab: `[ \t]`
`\p{Cntrl}`	A control character: `[\x00-\x1F\x7F]`
`\p{XDigit}`	A hexadecimal digit: `[0-9a-fA-F]`
`\p{Space}`	A whitespace character: `[ \t\n\x0B\f\r]`
{@code \p{Lower}}	A lower-case alphabetic character: {@code [a-z]}
{@code \p{Upper}}	An upper-case alphabetic character:{@code [A-Z]}
{@code \p{ASCII}}	All ASCII:{@code [\x00-\x7F]}
{@code \p{Alpha}}	An alphabetic character:{@code [\p{Lower}\p{Upper}]}
{@code \p{Digit}}	A decimal digit: {@code [0-9]}
{@code \p{Alnum}}	An alphanumeric character:{@code [\p{Alpha}\p{Digit}]}
{@code \p{Punct}}	Punctuation: One of {@code !"#$%&'()*+,-./:;<=>?@[\]^_`{\|}~}
{@code \p{Graph}}	A visible character: {@code [\p{Alnum}\p{Punct}]}
{@code \p{Print}}	A printable character: {@code [\p{Graph}\x20]}
{@code \p{Blank}}	A space or a tab: {@code [ \t]}
{@code \p{Cntrl}}	A control character: {@code [\x00-\x1F\x7F]}
{@code \p{XDigit}}	A hexadecimal digit: {@code [0-9a-fA-F]}
{@code \p{Space}}	A whitespace character: {@code [ \t\n\x0B\f\r]}

java.lang.Character classes (simple java character type)

Classes for Unicode scripts, blocks, categories and binary properties
`\p{IsLatin}`
{@code \p{IsLatin}}	A Latin script character (script)
`\p{InGreek}`
{@code \p{InGreek}}	A character in the Greek block (block)
`\p{Lu}`
{@code \p{Lu}}	An uppercase letter (category)
`\p{IsAlphabetic}`
{@code \p{IsAlphabetic}}	An alphabetic character (binary property)
`\p{Sc}`
{@code \p{Sc}}	A currency symbol
`\P{InGreek}`
{@code \P{InGreek}}	Any character except one in the Greek block (negation)
`[\p{L}&&[^\p{Lu}]]`
{@code [\p{L}&&[^\p{Lu}]]}	Any letter except an uppercase letter (subtraction)

`[a-e][i-u]`
5	Intersection	`[a-z&&[aeiou]]`
{@code [a-z&&[aeiou]]}

Classes	Matches	Classes	Matches
`\p{Lower}`	A lowercase character:`\p{IsLowercase}`
`\p{Graph}`	A visible character: `[^\p{IsWhite_Space}\p{gc=Cc}\p{gc=Cs}\p{gc=Cn}]`
`\p{Print}`	A printable character: `[\p{Graph}\p{Blank}&&[^\p{Cntrl}]]`
A printable character: {@code [\p{Graph}\p{Blank}&&[^\p{Cntrl}]]}
`\p{Blank}`	A space or a tab: `[\p{IsWhite_Space}&&[^\p{gc=Zl}\p{gc=Zp}\x0a\x0b\x0c\x0d\x85]]`
A space or a tab: {@code [\p{IsWhite_Space}&&[^\p{gc=Zl}\p{gc=Zp}\x0a\x0b\x0c\x0d\x85]]}
`\p{Cntrl}`	A control character: `\p{gc=Cc}`
`\p{XDigit}`	A non-word character: `[^\w]`

Regex	Limit	Result
Regex	Limit	Result
:	2	`{ "boo", "and:foo" }`

Regex	Result
Regex	Result
:	`{ "boo", "and", "foo" }`
o

Construct	Matches	Construct	Matches


Character classes
`[abc]`	`a`, `b`, or `c` (simple class)
`[^abc]`	Any character except `a`, `b`, or `c` (negation)
`[a-zA-Z]`	`a` through `z` > - * or `A` through `Z`, inclusive (range)
`[a-d[m-p]]`	`a` through `d`, > - * or `m` through `p`: `[a-dm-p]` (union)
`[a-z&&[def]]`	`d`, `e`, or `f` (intersection)
`[a-z&&[^bc]]`	`a` through `z`, > - * except for `b` and `c`: `[ad-z]` (subtraction)
`[a-z&&[^m-p]]`	`a` through `z`, > - * and not `m` through `p`: `[a-lq-z]`(subtraction)
{@code [abc]}	{@code a}, {@code b}, or {@code c} (simple class)
{@code [^abc]}	Any character except {@code a}, {@code b}, or {@code c} (negation)
{@code [a-zA-Z]}	{@code a} through {@code z} > + * or {@code A} through {@code Z}, inclusive (range)
{@code [a-d[m-p]]}	{@code a} through {@code d}, > + * or {@code m} through {@code p}: {@code [a-dm-p]} (union)
{@code [a-z&&[def]]}	{@code d}, {@code e}, or {@code f} (intersection)
{@code [a-z&&[^bc]]}	{@code a} through {@code z}, > + * except for {@code b} and {@code c}: {@code [ad-z]} (subtraction)
{@code [a-z&&[^m-p]]}	{@code a} through {@code z}, > + * and not {@code m} through {@code p}: {@code [a-lq-z]}(subtraction)

Predefined character classes
`\W`	A non-word character: `[^\w]`

POSIX character classes (US-ASCII only)
POSIX character classes (US-ASCII only)
`\p{Lower}`	A lower-case alphabetic character: `[a-z]`
`\p{Upper}`	An upper-case alphabetic character:`[A-Z]`
`\p{ASCII}`	All ASCII:`[\x00-\x7F]`
`\p{Alpha}`	An alphabetic character:`[\p{Lower}\p{Upper}]`
`\p{Digit}`	A decimal digit: `[0-9]`
`\p{Alnum}`	An alphanumeric character:`[\p{Alpha}\p{Digit}]`
`\p{Punct}`	Punctuation: One of !"#$%&'()*+,-./:;<=>?@[\]^_`{\|}~
`\p{Graph}`	A visible character: `[\p{Alnum}\p{Punct}]`
`\p{Print}`	A printable character: `[\p{Graph}\x20]`
`\p{Blank}`	A space or a tab: `[ \t]`
`\p{Cntrl}`	A control character: `[\x00-\x1F\x7F]`
`\p{XDigit}`	A hexadecimal digit: `[0-9a-fA-F]`
`\p{Space}`	A whitespace character: `[ \t\n\x0B\f\r]`
{@code \p{Lower}}	A lower-case alphabetic character: {@code [a-z]}
{@code \p{Upper}}	An upper-case alphabetic character:{@code [A-Z]}
{@code \p{ASCII}}	All ASCII:{@code [\x00-\x7F]}
{@code \p{Alpha}}	An alphabetic character:{@code [\p{Lower}\p{Upper}]}
{@code \p{Digit}}	A decimal digit: {@code [0-9]}
{@code \p{Alnum}}	An alphanumeric character:{@code [\p{Alpha}\p{Digit}]}
{@code \p{Punct}}	Punctuation: One of {@code !"#$%&'()*+,-./:;<=>?@[\]^_`{\|}~}
{@code \p{Graph}}	A visible character: {@code [\p{Alnum}\p{Punct}]}
{@code \p{Print}}	A printable character: {@code [\p{Graph}\x20]}
{@code \p{Blank}}	A space or a tab: {@code [ \t]}
{@code \p{Cntrl}}	A control character: {@code [\x00-\x1F\x7F]}
{@code \p{XDigit}}	A hexadecimal digit: {@code [0-9a-fA-F]}
{@code \p{Space}}	A whitespace character: {@code [ \t\n\x0B\f\r]}

java.lang.Character classes (simple java character type)

Classes for Unicode scripts, blocks, categories and binary properties
`\p{IsLatin}`
{@code \p{IsLatin}}	A Latin script character (script)
`\p{InGreek}`
{@code \p{InGreek}}	A character in the Greek block (block)
`\p{Lu}`
{@code \p{Lu}}	An uppercase letter (category)
`\p{IsAlphabetic}`
{@code \p{IsAlphabetic}}	An alphabetic character (binary property)
`\p{Sc}`
{@code \p{Sc}}	A currency symbol
`\P{InGreek}`
{@code \P{InGreek}}	Any character except one in the Greek block (negation)
`[\p{L}&&[^\p{Lu}]]`
{@code [\p{L}&&[^\p{Lu}]]}	Any letter except an uppercase letter (subtraction)

`[a-e][i-u]`
5	Intersection	`[a-z&&[aeiou]]`
{@code [a-z&&[aeiou]]}

Classes	Matches	Classes	Matches
`\p{Lower}`	A lowercase character:`\p{IsLowercase}`
`\p{Graph}`	A visible character: `[^\p{IsWhite_Space}\p{gc=Cc}\p{gc=Cs}\p{gc=Cn}]`
`\p{Print}`	A printable character: `[\p{Graph}\p{Blank}&&[^\p{Cntrl}]]`
A printable character: {@code [\p{Graph}\p{Blank}&&[^\p{Cntrl}]]}
`\p{Blank}`	A space or a tab: `[\p{IsWhite_Space}&&[^\p{gc=Zl}\p{gc=Zp}\x0a\x0b\x0c\x0d\x85]]`
A space or a tab: {@code [\p{IsWhite_Space}&&[^\p{gc=Zl}\p{gc=Zp}\x0a\x0b\x0c\x0d\x85]]}
`\p{Cntrl}`	A control character: `\p{gc=Cc}`
`\p{XDigit}`	A non-word character: `[^\w]`

Regex	Limit	Result
Regex	Limit	Result
:	2	`{ "boo", "and:foo" }`

Regex	Result
Regex	Result
:	`{ "boo", "and", "foo" }`
o

Attribute views	Description
Attribute views	Description
`{@link java.nio.file.attribute.AttributeView}`	Can read or update non-opaque values associated with objects in a file system
`{@link java.nio.file.attribute.FileAttributeView}`	Can read or update POSIX defined file attributes
`{@link java.nio.file.attribute.DosFileAttributeView}`	Can read or update FAT file attributes
`{@link java.nio.file.attribute.FileOwnerAttributeView}`
`{@link java.nio.file.attribute.FileOwnerAttributeView}`	Can read or update the owner of a file
`{@link java.nio.file.attribute.AclFileAttributeView}`	Can read or update Access Control Lists

Attribute views	align="left">Description
Attribute views	align="left">Description
`{@link > java.nio.file.attribute.AttributeView}`	Can read or update non-opaque values associated with > objects in a file system
`{@link > java.nio.file.attribute.FileAttributeView}`	Can read or update POSIX defined file attributes
valign=top> `{@link > java.nio.file.attribute.DosFileAttributeView}`	Can read or update FAT file attributes
`{@link > java.nio.file.attribute.FileOwnerAttributeView}`
`{@link > java.nio.file.attribute.FileOwnerAttributeView}`	Can read or update the owner of a file
`{@link > java.nio.file.attribute.AclFileAttributeView}`	Can read or update Access Control Lists

Attribute views	> align="left">Description
Attribute views	> align="left">Description
`{@link >> java.nio.file.attribute.AttributeView}`	Can read or update non-opaque values associated with >> objects in a file system
`{@link >> java.nio.file.attribute.FileAttributeView}`	Can read or update POSIX defined file attributes
> valign=top> `{@link >> java.nio.file.attribute.DosFileAttributeView}`	Can read or update FAT file attributes
`{@link >> java.nio.file.attribute.FileOwnerAttributeView}`
`{@link >> java.nio.file.attribute.FileOwnerAttributeView}`	Can read or update the owner of a file
`{@link >> java.nio.file.attribute.AclFileAttributeView}`	Can read or update Access Control Lists

Channels	Description
Channels	Description
`{@link java.nio.channels.Channel}`	A nexus for I/O operations
`{@link java.nio.channels.ReadableByteChannel}`

File channels	Description
File channels	Description
`{@link java.nio.channels.FileChannel}`	Reads, writes, maps, and manipulates files
`{@link java.nio.channels.FileLock}`

Multiplexed, non-blocking I/O	Description
Multiplexed, non-blocking I/O	Description
`{@link java.nio.channels.SelectableChannel}`	A channel that can be multiplexed
`{@link java.nio.channels.DatagramChannel}`

Asynchronous I/O	Description
Asynchronous I/O	Description
`{@link java.nio.channels.AsynchronousFileChannel}`	An asynchronous channel for reading, writing, and manipulating a file
`{@link java.nio.channels.AsynchronousSocketChannel}`

Charset	Description
Charset	Description
`US-ASCII`	Seven-bit ASCII, a.k.a. `ISO646-US`, * a.k.a. the Basic Latin block of the Unicode character set

Channels	Description
Channels	Description
`{@link java.nio.channels.Channel}`	A nexus for I/O operations
`{@link java.nio.channels.ReadableByteChannel}`

File channels	Description
File channels	Description
`{@link java.nio.channels.FileChannel}`	Reads, writes, maps, and manipulates files
`{@link java.nio.channels.FileLock}`

Multiplexed, non-blocking I/O	Description
Multiplexed, non-blocking I/O	Description
`{@link java.nio.channels.SelectableChannel}`	A channel that can be multiplexed
`{@link java.nio.channels.DatagramChannel}`

Asynchronous I/O	Description
Asynchronous I/O	Description
`{@link java.nio.channels.AsynchronousFileChannel}`	An asynchronous channel for reading, writing, and manipulating a file
`{@link java.nio.channels.AsynchronousSocketChannel}`

text outside div However
etc seems to be fine; they are elements with EMPTY content model, or "VOID element" in html 5 jargon. There are exactly 10 such elements in html 4 area base br col hr img input link meta param I agree with Nick that a mere warning is appropriate for these elements. Zhong Yu On Fri, Jul 26, 2013 at 10:46 AM, Nick Williams wrote: > > On Jul 26, 2013, at 10:27 AM, Stephen Colebourne wrote: > >> On 26 July 2013 14:49, David M. Lloyd wrote: >>> You took one step outside of logic, in my opinion. Yes, the spec is a >>> guide, in practice. But to use that to justify not even trying to conform >>> or not encouraging people to conform is crazy. Without the spec, the HTML >>> world would be even more insane than it is now, by orders of magnitude. >>> >>> It is very likely that browsers will accept spec-compliant HTML. It is also >>> very *unlikely* that your average user will be arsed to test their HTML on >>> every browser on the planet before they publish their JavaDoc. It is also >>> unlikely for your average Java developer to know or understand *any* of >>> these issues; you're giving them way too much credit IMO by assuming that >>> they're simply imposing some kind of rational style, rather than simply not >>> knowing how HTML works. >>> >>> In the end I think it does far less harm to bark at people who are not >>> writing spec-compliant HTML than it does to assume they know what they're >>> doing and what the implications are. If doclint doesn't enforce this kind >>> of strictness, then what will? >> >> Frankly, getting developers to write any Javadoc is a huge problem. >> Getting them to correctly use the basic tags is another huge step >> (generally enforced today via checkstyle). Asking them to write >> well-formed HTML seems unrealistic and likely to have the negative >> effect of causing less documentation, not more. >> >> In addition, Javadoc is frequently read as source code in IDEs (F3 >> through to the class and read the source code Javadoc, not the HTML >> Javadoc). In fact, I read source code Javadoc at least ten times more >> often than HTML Javadoc. Given that strict HTML tends to simply get in >> the way visually of reading the source code Javadoc, it becomes yet >> another negative of strictness. >> >> The original issue in the thread is whether
should be valid. I >> think it should because its hugely widely used and accepted by >> browsers, and forcing developers to change to
is net negative. >> >> Note that if doclint was off by default in the Javadoc tool, I >> probably wouldn't care. > > I would even say note that if
wasn't a process-stopping ERROR I probably wouldn't care. That's the biggest pain in the @$$ to me. That having
in a JavaDoc makes in impossible for me to generate JavaDoc. Sure, I can disable doclint, but THEN I miss out on all the other useful messages it provides. Just make
a warning (or all self-closing void tags in general) and I'm satisfied. From brent.christian at oracle.com Fri Jul 26 17:53:05 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 26 Jul 2013 10:53:05 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Message-ID: <51F2B781.1050104@oracle.com> Please review my fix for 8011194 : "Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X" http://bugs.sun.com/view_bug.do?bug_id=8011194 In most cases of launching a Java app on Mac (from the cmdline, or from a native .app bundle), reading and displaying UTF-8 characters beyond the standard ASCII range works fine. A notable exception is the launching of an app by double-clicking a .jar file. In this case, file.encoding defaults to US-ASCII, and characters outside of the ASCII range show up as garbage. (FWIW, this is not recommended by Apple as a method for deploying Java apps [1], though OS X does have a Jar Launcher.app to make it work.) It's worth mentioning that this is not something that has ever worked on MacOS X. (Apple's JRE defaulted to "MacRoman" for English and AFAIK most European locales. I believe this is a holdover from the pre-OS X days). Even so, the situation can be improved. When launching, if the standard encoding comes up as US-ASCII, but there are no hints from the environment (e.g. LANG/etc environment variables), it would be sane to instead use UTF-8 as the default encoding on MacOS X. An explicit file.encoding setting by the user is still honored (and can even be set back to US-ASCII). I believe this also fixes the related issue with webstart [2]. Webrev is here: http://cr.openjdk.java.net/~bchristi/8011194/webrev.00/ Thanks, -Brent [1] http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html [2] http://bugs.sun.com/view_bug.do?bug_id=8011195 From david.dehaven at oracle.com Fri Jul 26 21:34:11 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 26 Jul 2013 14:34:11 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51F2B781.1050104@oracle.com> References: <51F2B781.1050104@oracle.com> Message-ID: <23074B3D-B75B-4568-B32C-15481332FBB3@oracle.com> > Please review my fix for 8011194 : "Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X" > > http://bugs.sun.com/view_bug.do?bug_id=8011194 > > In most cases of launching a Java app on Mac (from the cmdline, or from a native .app bundle), reading and displaying UTF-8 characters beyond the standard ASCII range works fine. > > A notable exception is the launching of an app by double-clicking a .jar file. In this case, file.encoding defaults to US-ASCII, and characters outside of the ASCII range show up as garbage. > > (FWIW, this is not recommended by Apple as a method for deploying Java apps [1], though OS X does have a Jar Launcher.app to make it work.) > > It's worth mentioning that this is not something that has ever worked on MacOS X. (Apple's JRE defaulted to "MacRoman" for English and AFAIK most European locales. I believe this is a holdover from the pre-OS X days). > > Even so, the situation can be improved. When launching, if the standard encoding comes up as US-ASCII, but there are no hints from the environment (e.g. LANG/etc environment variables), it would be sane to instead use UTF-8 as the default encoding on MacOS X. An explicit file.encoding setting by the user is still honored (and can even be set back to US-ASCII). > > I believe this also fixes the related issue with webstart [2]. That'd be wonderful! :) I'm not a "Reviewer" but it looks fine to me. -DrD- From jason.uh at oracle.com Fri Jul 26 21:17:52 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Fri, 26 Jul 2013 21:17:52 +0000 Subject: hg: jdk8/tl/jdk: 8019544: Need to run ProviderTest.java in othervm mode. Message-ID: <20130726211833.668D6483EC@hg.openjdk.java.net> Changeset: 7ae061cfd4be Author: juh Date: 2013-07-26 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ae061cfd4be 8019544: Need to run ProviderTest.java in othervm mode. Reviewed-by: wetmore, xuelei, vinnie Contributed-by: rajan.halade at oracle.com ! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java From martinrb at google.com Fri Jul 26 21:54:56 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 26 Jul 2013 14:54:56 -0700 Subject: Still need a review for Java 8 RFR 8014319: Faster division of large integers In-Reply-To: <481BC79A-5015-456B-BC9B-FAFBBC9ED3A4@oracle.com> References: <481BC79A-5015-456B-BC9B-FAFBBC9ED3A4@oracle.com> Message-ID: Reluctant math reviewer here. Looks good, except for apparently overzealous s/size/SIZE/g, as in - * a lot of numbers that will find failure points, such as max sized + * a lot of numbers that will find failure points, such as max SIZEd On Thu, Jul 25, 2013 at 11:55 AM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > JDK 8 Reviewers: > > This patch is still pending approval by: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018922.html > > Thanks, > > Brian > From lana.steuck at oracle.com Fri Jul 26 22:18:33 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 26 Jul 2013 22:18:33 +0000 Subject: hg: jdk8/tl/hotspot: 15 new changesets Message-ID: <20130726221912.4DA9A483F6@hg.openjdk.java.net> Changeset: dc8afa03e5c9 Author: katleman Date: 2013-07-11 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc8afa03e5c9 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/runtime/8001071/Test8001071.sh Changeset: 1c474723a324 Author: katleman Date: 2013-07-11 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c474723a324 Merge Changeset: 81b6cb70717c Author: katleman Date: 2013-07-16 15:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81b6cb70717c Merge Changeset: bb416ee2a79b Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bb416ee2a79b Added tag jdk8-b99 for changeset 81b6cb70717c ! .hgtags Changeset: bd1dc81da579 Author: amurillo Date: 2013-07-12 17:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd1dc81da579 8020382: new hotspot build - hs25-b42 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f4311079200c Author: brutisso Date: 2013-07-11 11:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f4311079200c 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Summary: Take _last_young_gc into account when deciding on starting a concurrent mark. Also reviewed-by: per.liden at oracle.com. Reviewed-by: tschatzl, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: e7a47f226600 Author: tamao Date: 2013-07-15 15:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e7a47f226600 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: 980532a806a5 Author: goetz Date: 2013-06-20 15:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/980532a806a5 8016697: Use stubs to implement safefetch Summary: Implement Safefetch as stub routines. This reduces compiler and os dependencies. Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/bsd_x86_64.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/linux_x86_64.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: a74ec8831c7b Author: clucasius Date: 2013-07-15 12:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a74ec8831c7b Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 16b10327b00d Author: jprovino Date: 2013-07-16 10:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16b10327b00d 8011569: ARM -- avoid native stack walking Summary: ARM compilers do not emit FramePointer on each native frame by default Reviewed-by: dholmes, zgu ! make/linux/makefiles/vm.make ! src/share/vm/services/memTracker.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 90d6c221d4e5 Author: jprovino Date: 2013-07-16 12:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/90d6c221d4e5 Merge ! make/linux/makefiles/vm.make - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/services/memTracker.cpp - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9d18d92e54b5 Author: clucasius Date: 2013-07-18 00:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d18d92e54b5 Merge Changeset: 9f71e36a471a Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f71e36a471a Merge Changeset: 5787fac72e76 Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5787fac72e76 Added tag hs25-b42 for changeset 9f71e36a471a ! .hgtags Changeset: 9d7b55c8a0c4 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d7b55c8a0c4 Added tag jdk8-b100 for changeset 5787fac72e76 ! .hgtags From lana.steuck at oracle.com Fri Jul 26 22:18:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 26 Jul 2013 22:18:15 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130726221844.A957B483F5@hg.openjdk.java.net> Changeset: 6d85acab769e Author: mcimadamore Date: 2013-07-17 19:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6d85acab769e 8013638: Few policy tests are failing in Lambda nightly Summary: BridgeHarness test is leaving files open Reviewed-by: ksrini ! test/tools/javac/generics/bridges/BridgeHarness.java Changeset: e73f00139fb5 Author: cl Date: 2013-07-18 03:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e73f00139fb5 Added tag jdk8-b99 for changeset 6d85acab769e ! .hgtags Changeset: 82f68da70e47 Author: lana Date: 2013-07-22 17:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/82f68da70e47 Merge - test/tools/javac/generics/6723444/T6723444.out - test/tools/javac/generics/7015430/T7015430.out Changeset: 0324dbf07b0f Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0324dbf07b0f Added tag jdk8-b100 for changeset 82f68da70e47 ! .hgtags Changeset: 37048aa3ac19 Author: lana Date: 2013-07-26 14:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37048aa3ac19 Merge From lana.steuck at oracle.com Fri Jul 26 22:18:14 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 26 Jul 2013 22:18:14 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20130726221822.F3C45483F3@hg.openjdk.java.net> Changeset: 10503ced6cc2 Author: cl Date: 2013-07-18 03:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/10503ced6cc2 Added tag jdk8-b99 for changeset 10a1ab9e20a4 ! .hgtags Changeset: 598321c438b5 Author: lana Date: 2013-07-22 17:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/598321c438b5 Merge - src/jdk/nashorn/internal/ir/ExecuteNode.java - test/script/currently-failing/JDK-8006529.js Changeset: a302b05d0ee4 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a302b05d0ee4 Added tag jdk8-b100 for changeset 598321c438b5 ! .hgtags Changeset: d55856f82352 Author: lana Date: 2013-07-26 14:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d55856f82352 Merge From lana.steuck at oracle.com Fri Jul 26 22:18:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 26 Jul 2013 22:18:01 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130726221818.6CB78483F2@hg.openjdk.java.net> Changeset: 4fd722afae5c Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/4fd722afae5c Added tag jdk8-b99 for changeset 8ef83d4b23c9 ! .hgtags Changeset: 60b623a36164 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/60b623a36164 Added tag jdk8-b100 for changeset 4fd722afae5c ! .hgtags From lana.steuck at oracle.com Fri Jul 26 22:18:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 26 Jul 2013 22:18:01 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20130726221803.289C8483F0@hg.openjdk.java.net> Changeset: d2dcb110e9db Author: cl Date: 2013-07-18 03:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d2dcb110e9db Added tag jdk8-b99 for changeset 59dc9da81379 ! .hgtags Changeset: 9f74a220677d Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9f74a220677d Added tag jdk8-b100 for changeset d2dcb110e9db ! .hgtags From lana.steuck at oracle.com Fri Jul 26 22:18:02 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 26 Jul 2013 22:18:02 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130726221808.52A5D483F1@hg.openjdk.java.net> Changeset: 8d492f1dfd1b Author: cl Date: 2013-07-18 03:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8d492f1dfd1b Added tag jdk8-b99 for changeset 3f67804ab613 ! .hgtags Changeset: a013024b0747 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a013024b0747 Added tag jdk8-b100 for changeset 8d492f1dfd1b ! .hgtags From lana.steuck at oracle.com Fri Jul 26 22:18:06 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 26 Jul 2013 22:18:06 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20130726221828.4E289483F4@hg.openjdk.java.net> Changeset: 043da456d316 Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/043da456d316 Added tag jdk8-b99 for changeset adf49c3ef83c ! .hgtags Changeset: 5d1974c1d7b9 Author: lana Date: 2013-07-22 17:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5d1974c1d7b9 Merge Changeset: 0a7432f898e5 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0a7432f898e5 Added tag jdk8-b100 for changeset 5d1974c1d7b9 ! .hgtags Changeset: 467e1948612d Author: lana Date: 2013-07-26 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/467e1948612d Merge From lana.steuck at oracle.com Fri Jul 26 22:21:35 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 26 Jul 2013 22:21:35 +0000 Subject: hg: jdk8/tl/jdk: 26 new changesets Message-ID: <20130726223123.DF0AD483F8@hg.openjdk.java.net> Changeset: 56bc019a0525 Author: katleman Date: 2013-07-11 14:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56bc019a0525 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/sun/security/krb5/auto/NoneReplayCacheTest.java Changeset: 030d1ca7432f Author: katleman Date: 2013-07-11 14:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/030d1ca7432f Merge Changeset: 6a099a36589b Author: katleman Date: 2013-07-16 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a099a36589b Merge Changeset: 9b6070690e50 Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b6070690e50 Added tag jdk8-b99 for changeset 6a099a36589b ! .hgtags Changeset: cacfc77655c8 Author: serb Date: 2013-07-03 19:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cacfc77655c8 8004859: Graphics.getClipBounds/getClip return difference nonequivalent bounds, depending from transform Reviewed-by: prr, flar ! src/share/classes/sun/java2d/SunGraphics2D.java + test/java/awt/Graphics2D/Test8004859/Test8004859.java Changeset: 75844b444879 Author: jchen Date: 2013-07-03 10:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75844b444879 8014497: [parfait] Potential null pointer dereference in jdk/src/share/native/sun/java2d/cmm/lcms/cmsgamma.c Reviewed-by: bae, prr ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c Changeset: d32757b7060c Author: lana Date: 2013-07-05 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d32757b7060c Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: dead66347eca Author: jgodinez Date: 2013-07-10 11:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dead66347eca 8016737: After clicking on "Print UNCOLLATED" button, the print out come in order 'Page 1', 'Page 2', 'Page 1' Reviewed-by: jchen, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: fabcccc003d2 Author: lana Date: 2013-07-17 12:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fabcccc003d2 Merge Changeset: f41758d12409 Author: alitvinov Date: 2013-07-04 16:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f41758d12409 8015730: PIT: On Linux, OGL=true and fbobject=false leads to deadlock or infinite loop Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java ! src/solaris/native/sun/awt/awt_util.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c Changeset: 523815540788 Author: lana Date: 2013-07-05 11:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/523815540788 Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: b7cbad879d63 Author: leonidr Date: 2013-07-08 19:47 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7cbad879d63 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6 Reviewed-by: anthony ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 7e291fc61cad Author: malenkov Date: 2013-07-09 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e291fc61cad 6707231: Wrong read Method returned for boolen properties Reviewed-by: alexsch ! src/share/classes/java/beans/Introspector.java + test/java/beans/Introspector/Test6707231.java Changeset: e7ca6e259dc2 Author: serb Date: 2013-07-09 21:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7ca6e259dc2 8019587: [macosx] Possibility to set the same frame for the different screens Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/GraphicsDevice/IncorrectDisplayModeExitFullscreen.java Changeset: 46826d248616 Author: pchelko Date: 2013-07-11 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46826d248616 8020210: [macosx] JVM crashes in CWrapper$NSWindow.screen(long) Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/Window/MaximizeOffscreen/MaximizeOffscreenTest.java Changeset: c566daef4877 Author: leonidr Date: 2013-07-11 18:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c566daef4877 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread Reviewed-by: art, anthony ! src/macosx/classes/com/apple/eawt/FullScreenHandler.java ! src/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/macosx/classes/com/apple/eawt/event/GestureHandler.java ! src/macosx/classes/com/apple/laf/ScreenMenu.java ! src/macosx/classes/sun/lwawt/macosx/CCheckboxMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java Changeset: c3268a602a50 Author: raginip Date: 2013-07-12 14:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3268a602a50 8009168: accessibility.properties syntax issue Reviewed-by: ptbrunet, mfang, alexsch ! src/share/classes/com/sun/accessibility/internal/resources/accessibility.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/share/classes/javax/accessibility/AccessibleAction.java Changeset: f7ea38893138 Author: serb Date: 2013-07-12 21:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7ea38893138 8020298: [macosx] Incorrect merge in the lwawt code Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: d52fc9384765 Author: pchelko Date: 2013-07-15 12:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d52fc9384765 8020371: [macosx] applets with Drag and Drop fail with IllegalArgumentException Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 0967103c1b65 Author: malenkov Date: 2013-07-15 17:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0967103c1b65 8017492: Static field in HTML parser affects all applications Reviewed-by: art ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/Element.java + test/javax/swing/text/html/parser/Test8017492.java Changeset: 15ea601e707a Author: lana Date: 2013-07-17 12:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15ea601e707a Merge Changeset: f2558ef87d5a Author: lana Date: 2013-07-17 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2558ef87d5a Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 5be9c5bfcfe9 Author: lana Date: 2013-07-22 17:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5be9c5bfcfe9 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 690161232823 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/690161232823 Added tag jdk8-b100 for changeset 5be9c5bfcfe9 ! .hgtags Changeset: 25575c3c209d Author: lana Date: 2013-07-26 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25575c3c209d Merge Changeset: 9f9ffe6be557 Author: lana Date: 2013-07-26 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f9ffe6be557 Merge From mike.duigou at oracle.com Fri Jul 26 23:09:48 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 26 Jul 2013 16:09:48 -0700 Subject: RFR: 8021588 : (s) Remove explicit othervm execution from jdk/test/Makefile Message-ID: Hello all; I heard word from Alan Bateman that the jdk/test/TEST.ROOT includes accurate specification of which tests cannot be run by JTReg in agentvm mode. ie. they require othervm mode. I tested out removing the duplicate othervm specification from the jdk/test/Makefile and everything still seems to run. http://cr.openjdk.java.net/~mduigou/JDK-8021588/0/webrev/ Removes othervm specifications from the test/Makefile and other resulting simplifications. This lets us further simplify the jdk/test/Makefile and removes needless duplication. Great! I've been playing with another change inspired by work done by Tim Bell. When running tests concurrently it helps to specify -XX+UseSerialGC to avoid over creation of GC threads for what are mostly short lived tests. Testing jdk_utils on my 24 core / 32GB dev box using serial GC provides about 5%-10% speedup and appears to reduce memory usage by 20% or more. Unfortunately there are a few tests in java.lang.manangement which explicitly request incompatible GC options. I haven't figured out yet how to allow these tests to override the -XX+UseSerialGC vmoption in a sane way. (I can think of several rude ways to do it). So for now, this change is commented out. Mike From brian.burkhalter at oracle.com Fri Jul 26 23:21:19 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 26 Jul 2013 16:21:19 -0700 Subject: Still need a review for Java 8 RFR 8014319: Faster division of large integers In-Reply-To: References: <481BC79A-5015-456B-BC9B-FAFBBC9ED3A4@oracle.com> Message-ID: <3D730007-2CB8-458D-8AE6-E794F2282411@oracle.com> On Jul 26, 2013, at 2:54 PM, Martin Buchholz wrote: > Reluctant math reviewer here. > > Looks good, Thanks! > except for apparently overzealous s/size/SIZE/g, as in > > - * a lot of numbers that will find failure points, such as max sized > + * a lot of numbers that will find failure points, such as max SIZEd Similar verbiage to my own: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019035.html It will be fixed in the 8020641 patch as noted. Brian > On Thu, Jul 25, 2013 at 11:55 AM, Brian Burkhalter wrote: > JDK 8 Reviewers: > > This patch is still pending approval by: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018922.html > > Thanks, > > Brian > From mike.duigou at oracle.com Fri Jul 26 23:31:17 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 26 Jul 2013 16:31:17 -0700 Subject: RFR: 8021591 : (s) Additional explicit null checks Message-ID: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> Hello all; This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases. http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/ The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures. Mike From mike.duigou at oracle.com Sat Jul 27 00:06:54 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 26 Jul 2013 17:06:54 -0700 Subject: RFR: 8021601 : (xxs) Add unit test for PriorityQueue(Comparator) constructor Message-ID: <3DE346AE-1D1A-48C0-BA7A-4425ACDB947B@oracle.com> Hello all; JDK-6799426 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b) was pushed without a unit test. (Always recheck for unit tests when breathing life back into a stale old patch). A unit test is needed. This change adds an additional case to an existing test to exercise the new constructor. http://cr.openjdk.java.net/~mduigou/JDK-8021601/0/webrev/ I have also tweaked the constructor documentation per Paul Benedict's suggestion. Thanks, Mike From joe.darcy at oracle.com Sat Jul 27 00:15:49 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 26 Jul 2013 17:15:49 -0700 Subject: RFR: 8021601 : (xxs) Add unit test for PriorityQueue(Comparator) constructor In-Reply-To: <3DE346AE-1D1A-48C0-BA7A-4425ACDB947B@oracle.com> References: <3DE346AE-1D1A-48C0-BA7A-4425ACDB947B@oracle.com> Message-ID: <51F31135.2030704@oracle.com> Looks good Mike; cheers, -Joe On 7/26/2013 5:06 PM, Mike Duigou wrote: > Hello all; > > JDK-6799426 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b) was pushed without a unit test. (Always recheck for unit tests when breathing life back into a stale old patch). A unit test is needed. This change adds an additional case to an existing test to exercise the new constructor. > > http://cr.openjdk.java.net/~mduigou/JDK-8021601/0/webrev/ > > I have also tweaked the constructor documentation per Paul Benedict's suggestion. > > Thanks, > > Mike From Alan.Bateman at oracle.com Sat Jul 27 00:21:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Jul 2013 17:21:09 -0700 Subject: RFR: 8021601 : (xxs) Add unit test for PriorityQueue(Comparator) constructor In-Reply-To: <3DE346AE-1D1A-48C0-BA7A-4425ACDB947B@oracle.com> References: <3DE346AE-1D1A-48C0-BA7A-4425ACDB947B@oracle.com> Message-ID: <51F31275.8000605@oracle.com> On 26/07/2013 17:06, Mike Duigou wrote: > Hello all; > > JDK-6799426 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b) was pushed without a unit test. (Always recheck for unit tests when breathing life back into a stale old patch). A unit test is needed. This change adds an additional case to an existing test to exercise the new constructor. > > http://cr.openjdk.java.net/~mduigou/JDK-8021601/0/webrev/ > > I have also tweaked the constructor documentation per Paul Benedict's suggestion. > Thanks for expanding the test, it looks good to me too. -Alan From mike.duigou at oracle.com Sat Jul 27 03:36:58 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 27 Jul 2013 03:36:58 +0000 Subject: hg: jdk8/tl/jdk: 8021601: Add unit test for PriorityQueue(Comparator) constructor Message-ID: <20130727033742.27D2948411@hg.openjdk.java.net> Changeset: f056728871f8 Author: mduigou Date: 2013-07-26 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f056728871f8 8021601: Add unit test for PriorityQueue(Comparator) constructor Reviewed-by: darcy, alanb ! src/share/classes/java/util/PriorityQueue.java ! test/java/util/PriorityQueue/RemoveContains.java From joe.darcy at oracle.com Sat Jul 27 04:26:02 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 26 Jul 2013 21:26:02 -0700 Subject: RFR JDK 8 : fix doclint warnings in generated nio code Message-ID: <51F34BDA.9070803@oracle.com> Hello, The generated nio code has some doclint issues; the patch below fixes them. The majority of the changes are replacing {@link #Foo plain old foo

}

with

     {@linkplain #Foo foo}

Thanks,

-Joe


--- a/src/share/classes/java/nio/charset/Charset-X-Coder.java.template 
Thu Jul 25 20:03:20 2013 -0700
+++ b/src/share/classes/java/nio/charset/Charset-X-Coder.java.template 
Fri Jul 26 20:06:36 2013 -0700
@@ -41,7 +41,7 @@
   * An engine that can transform a sequence of $itypesPhrase$ into a 
sequence of
   * $otypesPhrase$.
   *
- * 
+ * 
   *
   *  The input $itype$ sequence is provided in a $itype$ buffer or a 
series
   * of such buffers.  The output $otype$ sequence is written to a 
$otype$ buffer
@@ -76,22 +76,22 @@
   * examine this object and fill the input buffer, flush the output 
buffer, or
   * attempt to recover from $a$ $coding$ error, as appropriate, and try 
again.
   *
- * 
+ * 
   *
   * 
 There are two general types of $coding$ errors.  If the input 
$itype$
   * sequence is $notLegal$ then the input is considered 
malformed.  If
   * the input $itype$ sequence is legal but cannot be mapped to a valid
   * $outSequence$ then an unmappable character has been encountered.
   *
- * 
+ * 
   *
   *

How $a$ $coding$ error is handled depends upon the action requested for * that type of error, which is described by an instance of the {@link - * CodingErrorAction} class. The possible error actions are to {@link - * CodingErrorAction#IGNOREignore} the erroneous input, {@link - * CodingErrorAction#REPORTreport} the error to the invoker via - * the returned {@link CoderResult} object, or {@link CodingErrorAction#REPLACE - *replace} the erroneous input with the current value of the + * CodingErrorAction} class. The possible error actions are to {@linkplain + * CodingErrorAction#IGNORE ignore} the erroneous input, {@linkplain + * CodingErrorAction#REPORT report} the error to the invoker via + * the returned {@link CoderResult} object, or {@linkplain CodingErrorAction#REPLACE + * replace} the erroneous input with the current value of the * replacement $replTypeName$. The replacement * #if[encoder] @@ -106,7 +106,7 @@ * replaceWith} method. * *

The default action for malformed-input and unmappable-character errors - * is to {@link CodingErrorAction#REPORTreport} them. The + * is to {@linkplain CodingErrorAction#REPORT report} them. The * malformed-input error action may be changed via the {@link * #onMalformedInput(CodingErrorAction) onMalformedInput} method; the * unmappable-character action may be changed via the {@link @@ -177,7 +177,7 @@ * @param replacement * The initial replacement; must not be null, must have * non-zero length, must not be longer than max$ItypesPerOtype$, - * and must be {@link #isLegalReplacementlegal} + * and must be {@linkplain #isLegalReplacement legal} * * @throws IllegalArgumentException * If the preconditions on the parameters do not hold @@ -276,7 +276,7 @@ * The new replacement; must not be null, must have * non-zero length, must not be longer than the value returned by * the {@link #max$ItypesPerOtype$() max$ItypesPerOtype$} method, and - * must be {@link #isLegalReplacementlegal} + * must be {@link #isLegalReplacement legal} #end[encoder] * * @return This $coder$ @@ -495,24 +495,24 @@ * typically done by draining any $code$d $otype$s from the output * buffer.


       *
-     *

A {@link CoderResult#malformedForLength - *malformed-input} result indicates that a malformed-input + *

A {@linkplain CoderResult#malformedForLength + * malformed-input} result indicates that a malformed-input * error has been detected. The malformed $itype$s begin at the input * buffer's (possibly incremented) position; the number of malformed * $itype$s may be determined by invoking the result object's {@link * CoderResult#length() length} method. This case applies only if the - * {@link #onMalformedInputmalformed action} of this $coder$ + * {@linkplain #onMalformedInput malformed action} of this $coder$ * is {@link CodingErrorAction#REPORT}; otherwise the malformed input * will be ignored or replaced, as requested.


       *
-     *

An {@link CoderResult#unmappableForLength - *unmappable-character} result indicates that an + *

An {@linkplain CoderResult#unmappableForLength + * unmappable-character} result indicates that an * unmappable-character error has been detected. The $itype$s that * $code$ the unmappable character begin at the input buffer's (possibly * incremented) position; the number of such $itype$s may be determined * by invoking the result object's {@link CoderResult#length() length} - * method. This case applies only if the {@link #onUnmappableCharacter - *unmappable action} of this $coder$ is {@link + * method. This case applies only if the {@linkplain #onUnmappableCharacter + * unmappable action} of this $coder$ is {@link * CodingErrorAction#REPORT}; otherwise the unmappable character will be * ignored or replaced, as requested.


       *



From Alan.Bateman at oracle.com  Sat Jul 27 05:46:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Jul 2013 22:46:27 -0700
Subject: RFR JDK 8 : fix doclint warnings in generated nio code
In-Reply-To: <51F34BDA.9070803@oracle.com>
References: <51F34BDA.9070803@oracle.com>
Message-ID: <51F35EB3.7080908@oracle.com>

On 26/07/2013 21:26, Joe Darcy wrote:
> Hello,
>
> The generated nio code has some doclint issues; the patch below fixes 
> them.
>
> The majority of the changes are replacing
>
>     {@link #Foo

plain old foo

}
>
> with
>
>     {@linkplain #Foo foo}
>
> Thanks,
>
> -Joe
Looks fine to me.

-Alan


From alan.bateman at oracle.com  Sat Jul 27 15:45:00 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 27 Jul 2013 15:45:00 +0000
Subject: hg: jdk8/tl/jdk: 8014319: Faster division of large integers
Message-ID: <20130727154550.747C748417@hg.openjdk.java.net>

Changeset: d4b2436892c8
Author:    bpb
Date:      2013-07-26 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4b2436892c8

8014319: Faster division of large integers
Summary: Implement Burnickel-Ziegler division algorithm in BigInteger
Reviewed-by: bpb, martin
Contributed-by: Tim Buktu 

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java



From alan.bateman at oracle.com  Sat Jul 27 15:47:44 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 27 Jul 2013 15:47:44 +0000
Subject: hg: jdk8/tl/jdk: 8020641: Clean up some code style in recent
	BigInteger contributions
Message-ID: <20130727154756.2893548418@hg.openjdk.java.net>

Changeset: a1c01457cf6c
Author:    bpb
Date:      2013-07-26 17:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1c01457cf6c

8020641: Clean up some code style in recent BigInteger contributions
Summary: Some minor cleanup to adhere better to Java coding conventions.
Reviewed-by: darcy
Contributed-by: Brian Burkhalter 

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java



From joe.darcy at oracle.com  Sat Jul 27 17:27:22 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Sat, 27 Jul 2013 17:27:22 +0000
Subject: hg: jdk8/tl/jdk: 8021609: Fix doclint issues in java.nio.charset
Message-ID: <20130727172747.319F64841B@hg.openjdk.java.net>

Changeset: eb1dc65162e8
Author:    darcy
Date:      2013-07-27 10:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb1dc65162e8

8021609: Fix doclint issues in java.nio.charset
Reviewed-by: alanb

! src/share/classes/java/nio/charset/Charset-X-Coder.java.template



From Alan.Bateman at oracle.com  Sat Jul 27 17:41:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Jul 2013 10:41:34 -0700
Subject: RFR: 8021588 : (s) Remove explicit othervm execution from
	jdk/test/Makefile
In-Reply-To: 
References: 
Message-ID: <51F4064E.6080201@oracle.com>

On 26/07/2013 16:09, Mike Duigou wrote:
> Hello all;
>
> I heard word from Alan Bateman that the jdk/test/TEST.ROOT includes accurate specification of which tests cannot be run by JTReg in agentvm mode. ie. they require othervm mode.
Yes although it's actually somewhat distributed because it can be 
overridden by specific tests (in the @run tag) and we also have a few 
TEST.properties in the tree that override it too. The main thing is that 
it's in the test suite so anyone can run jtreg -agentvm and the tests 
will run in right mode.


>   I tested out removing the duplicate othervm specification from the jdk/test/Makefile and everything still seems to run.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8021588/0/webrev/
>
> Removes othervm specifications from the test/Makefile and other resulting simplifications.
>
> This lets us further simplify the jdk/test/Makefile and removes needless duplication. Great!
>
> I've been playing with another change inspired by work done by Tim Bell. When running tests concurrently it helps to specify -XX+UseSerialGC to avoid over creation of GC threads for what are mostly short lived tests. Testing jdk_utils on my 24 core / 32GB dev box using serial GC provides about 5%-10% speedup and appears to reduce memory usage by 20% or more. Unfortunately there are a few tests in java.lang.manangement which explicitly request incompatible GC options. I haven't figured out yet how to allow these tests to override the -XX+UseSerialGC vmoption in a sane way. (I can think of several rude ways to do it). So for now, this change is commented out.
>
The changes in the webrev look good to me. It's good to finally remove 
some of the logic and I think a lot more can be removed over time too 
(in particularly the mapping of test targets to directories which really 
needs to be checked into the test suite as group definitions) and the 
exclude list handling as the ProblemList should be specified to jtreg 
via -exclude without any processing in the make file.

I think the issue of conflicting GC options has come up on the hotspot 
list a few times too. This may be a case where there needs to be a way 
to run a test in othervm mode in a way that doesn't pick up the vmoptions.

-Alan



From nicholas+openjdk at nicholaswilliams.net  Sat Jul 27 19:01:30 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sat, 27 Jul 2013 14:01:30 -0500
Subject: Classes on the stack trace (was: getElementClass/StackTraceElement,
	was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
Message-ID: 

All,

In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted to consolidate it all into this one discussion where I hope we can finalize on a solution and get it implemented for Java 8.

In a nut shell, here are the underlying needs that I have seen expressed through many, many messages:

- Some code needs to get the Class of the caller of the current method, skipping any reflection methods.
- Some code needs to get the Class of the caller /n/ stack frames before the current method, skipping any reflection methods.
- Some code needs to get the current stack trace, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
- Some code needs to get the stack trace from when a Throwable was created, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
- There needs to be a reflection way to achieve all of this since some libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and 8 (and thus can't use @CallerSensitive).

I believe the solutions to these needs are all related. Importantly, I think it is very important that action be taken in Java 8 due to the changes made to sun.reflect.Reflection#getCallerClass(...). While we all understand that relying on private sun.* APIs is not safe, the fact is that many people have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact that there is simply no other way to do this in the standard API. This includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will stop working correctly in Java 7 >= u25.

I would point out that this could all easily be solved simply by adding a getElementClass() method to StackTraceElement, but there was strong opposition to this, largely due to serialization issues. Since that is apparently not an option, I propose the following API, based on the various discussions in the last two months, StackTraceElement, and the API that .NET provides to achieve the same needs as listed above:

CallerSensitive.java:
package java.lang;

/** Previously private API, now public */
public @interface CallerSensitive {
    ...
}

StackTraceFrame.java:
package java.lang;

import java.util.Objects.

public final class StackTraceFrame {
    private final Class declaringClass;
    private final Executable executable;
    private final String fileName;
    private final int lineNumber;

    public StackTraceFrame(Class declaringClass, Executable executable, String fileName, int lineNumber) {
        this.declaringClass = Objects.requireNonNull(declaringClass, "Declaring class is null");
        this.executable = Objects.requireNonNull(executable, "Executable is null");
        this.fileName = fileName;
        this.lineNumber = lineNumber;
    }

    public Class getDeclaringClass() {
        return this.declaringClass;
    }

    public Executable getExecutable() {
        return this.executable;
    }

    public String getFileName() {
        return this.fileName;
    }

    public int getLineNumber() {
        return this.lineNumber;
    }

    public boolean isNative() {
        return this.lineNumber == -2;
    }

    public String toString() { /* Same as StackTraceElement */ }
    public boolean equals() { /* Ditto */ }
    public int hashCode() { /* Ditto */ }

    /** Uses @CallerSensitive */
    public static native StackTraceFrame getCallerFrame();

    /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() */
    public static native StackTraceFrame getCallerFrame(int skipFrames);

    public static native StackTraceFrame[] getCurrentStackTrace();
}

Throwable.java:
package java.lang;

...

public class Throwable {
    ...
    public synchronized Throwable fillInStackTraceFrames() { ... }

    private native Throwable fillInStackTraceFrames(int dummy);

    public StackTraceFrame[] getStackTraceFrames() {
        return this.getOurStackTraceFrames().clone();
    }

    private synchronized StackTraceFrame[] getOurStackTraceFrames() { ... }
    ...
}

Furthermore, I propose that we restore the behavior of sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the proposed above solution cannot be added to Java 7.

I would love if we could quickly coalesce around this solution or a derivative thereof so that it can be implemented before Feature Complete. The absence of any replacement or alternative for sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 that will cause hardships for many projects.

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
[3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html

From Alan.Bateman at oracle.com  Sat Jul 27 19:24:15 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Jul 2013 12:24:15 -0700
Subject: 8016036: RMI specification needs to be updated to allow Activation
	on remote hosts
In-Reply-To: <51DE3146.2000908@oracle.com>
References: <51DE3146.2000908@oracle.com>
Message-ID: <51F41E5F.6030407@oracle.com>

On 10/07/2013 21:15, Stephen Flores wrote:
> Bob, Sean,
>
> Please review this webrev
>
>   http://cr.openjdk.java.net/~sflores/8016036/webrev.00/
>
> for RFE/CCC: 8016036 RMI specification needs to be updated to allow 
> Activation on remote hosts
I didn't see any replies to this but I chatted briefly with Stuart Marks 
about this a few days ago as it's not clear (to me anyway) that this is 
the right thing to do. In particular it would be good to understand why 
the specification can't be changed to allow for environments that 
doesn't support multiple VM instances or where it's not possible to 
launch a new VM. This would amount to not supporting activation in such 
environments. Has this approach been explored? It could of course 
require being creative in the specifications but there are other 
examples of this type of thing.

-Alan


From mike.duigou at oracle.com  Sat Jul 27 21:24:24 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Sat, 27 Jul 2013 21:24:24 +0000
Subject: hg: jdk8/tl/jdk: 8021588: Remove explicit othervm execution from
	jdk/test/Makefile
Message-ID: <20130727212448.DF2464841E@hg.openjdk.java.net>

Changeset: 5d4a35823071
Author:    mduigou
Date:      2013-07-27 12:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d4a35823071

8021588: Remove explicit othervm execution from jdk/test/Makefile
Reviewed-by: alanb

! test/Makefile



From Alan.Bateman at oracle.com  Sun Jul 28 17:40:07 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 28 Jul 2013 10:40:07 -0700
Subject: Review request: JDK-8021245 (process) file leak in
	jdk/src/windows/native/java/lang/ProcessImpl_md.c
In-Reply-To: <51F296CF.2050902@oracle.com>
References: <51F296CF.2050902@oracle.com>
Message-ID: <51F55777.5050404@oracle.com>

On 26/07/2013 08:33, Alexey Utkin wrote:
> Bug description:
>     https://jbs.oracle.com/bugs/browse/JDK-8021245
>     http://bugs.sun.com/view_bug.do?bug_id=8021245
>
> Here is the suggested fix:
> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8021245/webrev.00/
>
> Summary:
> In accordance with MS spec [-1] is THE ONLY error signal from the 
> [_open] function call.
> http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx
> Any negative, except [-1], and zero are the valid handles that need to 
> be closed.
>
> The fix was tested in the debugger my manual switching to Win9x/WinMe 
> brunch of execution.
Checking if _open returns -1 and checking the return from _read and 
_lseek/_read looks okay to me. My only comment is that the "if (" on its 
own looks a bit odd, I just I would at least hoist the first part of the 
expression onto the same line.

-Alan.


From Alan.Bateman at oracle.com  Sun Jul 28 21:18:17 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 28 Jul 2013 14:18:17 -0700
Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, 
	on S10 to avoid swap exhaustion
In-Reply-To: <51F14F85.1010601@oracle.com>
References: <50AE98B1.2040200@oracle.com> <50B81A8D.2040403@oracle.com>
	<50B82C94.90109@oracle.com> <50D277BE.8060705@oracle.com>
	
	<50D65C3F.2040004@oracle.com> <51D2F496.6050400@oracle.com>
	<51D57B88.3050707@oracle.com> <51D674B5.7020100@oracle.com>
	<51F14F85.1010601@oracle.com>
Message-ID: <51F58A99.8050402@oracle.com>

On 25/07/2013 09:17, Rob McKenna wrote:
> Thanks a lot Erik,
>
> I've added the dependency to the makefile here:
>
> http://cr.openjdk.java.net/~robm/5049299/webrev.05/ 
> 
>
> Is it ok between the ifeq block?
>
> Alan,
>
> I've altered the launchMechanism code to use valueOf (and lower case 
> names) - much cleaner, thanks for that. I've also limited each 
> platform to supported mechanisms only. With the new layout I don't 
> believe a separate test is needed here. (the default is now 
> posix_spawn/vfork and Basic.java has been altered to run with fork too)
>
>     -Rob
Thanks Rob, I've taken another pass over the latest webrev and I think 
the finish line is close.

The launchMechanism determination is much cleaner now (thanks). For 
consistency the enum values should probably be in uppercase and so this 
means you'll need to uppercase the property value to use valueOf.

It would be nice if launchMechanism were final too (which you do by 
having the privileged action be of type LaunchMechanism rather than Void).

The comment in UNIXProcess.java.bsd references vfork/exec which I assume 
is copied from the Linux version and should be removed.

Did you consider having forkAndExec take the helper as a parameter? Just 
wonder if this would be cleaner than having to use JNI to grab the field 
value.

It's usually best to use sprintnf rather than sprintf (in spawnChild) to 
avoid any concerns (or static analysis tools) that wonder about buffer 
overflow.

Style nit in the C code is that many places have spurious space between 
the function name and the parentheses.

A pre-existing bug (only noticed because it has moved from 
UNIXProcess_md.c to childproc.c) is that close is not restartable.

The comment in in makefiles/CompileLauncher.gmk references the old 
build, is that needed?

So overall I don't see any issues, it would be really good to stress 
this to make sure that we aren't leaking file descriptors. I don't know 
if we have an existing test that would help with that.

One final comment is that the new files seems to have the pure GPL 
comment, I assume you will add the GPL+ Classpath Exception comment 
before you push this.

-Alan.



From ivan.gerasimov at oracle.com  Sun Jul 28 22:08:58 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 29 Jul 2013 02:08:58 +0400
Subject: RFR [8020669] java.nio.file.Files.readAllBytes() does not read
	any data when Files.size() is 0
In-Reply-To: <51F200F1.8010500@oracle.com>
References: <51E97416.20506@oracle.com> <51E98043.6030102@oracle.com>
	<51E9853E.8020409@redhat.com> <51E985AD.60401@redhat.com>
	<51EB0BFF.3030106@oracle.com> <51ED57D8.90001@oracle.com>
	<51EE55AC.5000902@oracle.com> <51EE8E9A.6040806@redhat.com>
	<51EF1B43.9030200@oracle.com>
	
	<51F06789.1050403@oracle.com> <51F12B3E.4010603@oracle.com>
	<51F1BB22.6040405@oracle.com> <51F200F1.8010500@oracle.com>
Message-ID: <51F5967A.6060705@oracle.com>

Hello Alan and everyone else

Thank you for review!

Here's another version of webrev:
http://cr.openjdk.java.net/~igerasim/8020669/5/webrev/ 


The comments are inline.

On 26.07.2013 8:54, Alan Bateman wrote:
> On 25/07/2013 16:56, Ivan Gerasimov wrote:
>>
>> Would you please help review an updated webrev?
>> http://cr.openjdk.java.net/~igerasim/8020669/4/webrev/
> Sorry for the late response to your mails on this, I was on vacation.
>
> As you have found, in the original implementation we allowed for 
> resizing (truncation or extending) while the file was open but when it 
> was optimized to avoid an unnecessary resize of the array then we lost 
> the ability to deal with extending case (which is the essentially the 
> same as when the size is reported is less than the actual size).
>
> Reverting to the original implementation and doing a single read to 
> double check for EOF seems reasonable.
>
> My only real comment on the latest webrev (4) is that the computation 
> of the new capacity is not obvious to the reader (and since this is 
> the uncommon case then it doesn't need to be super-optimized).  So I 
> think it would be a lot clearer if "newCapacity" were re-introduced 
> and then computed to a value that is a minimum of capacity+2, maximum 
> of capacity+BUFFER_SIZE (with OOME handling when newCapacity is 
> greater than MAX_BUFFER_SIZE). I think that would be clearer than 
> re-using the remaining count (rem).

OK. I simplified it once again.
Now the new capacity is set to one of {BUFFER_SIZE, 2 * old capacity, 
MAX_BUFFER_SIZE}, whatever is appropriate.
I think that doubling the capacity is better than increasing it by 
BUFFER_SIZE, since this will allow to allocate needed buffer in less 
number of iterations.

>
> A minor comment is that the input stream is named "fis" but probably 
> should be "in" as it is not a FileInputStream (I see David Llyod 
> suggested using a FileInputStream but the path may be to a file in a 
> custom file system so it can't be a FileInputStream).
>
Renamed.

> I see you've changed the javadoc from "Read" to "Reads" on several 
> methods. I don't know if you meant to include this in the webrev but 
> personally prefer "Read".
>
Files.java has mixed style. Most methods are documented with "Does" 
form, but some have "Do".
I left "Reads" on the methods I modify for consistency, but reverted 
changes from other places as I'm not going to change all the occurrences 
in this webrev.

> Thanks for moving the test to BytesAndLines as that is the test for 
> these methods. One suggestion is to move the new test for readAllBytes 
> into testReadAndWriteBytes and the new test for readAllLines into 
> testReadLines. It doesn't matter of course, it just keeps them together.
>
Sure, done.

Sincerely yours,
Ivan

> -Alan.



From Alan.Bateman at oracle.com  Sun Jul 28 22:32:58 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 28 Jul 2013 15:32:58 -0700
Subject: Review request: JDK-7147084 (process) appA hangs when read output
	stream of appB which starts appC that runs forever (v.1)
In-Reply-To: <51DE74D1.70607@oracle.com>
References: <518A88B1.3060105@oracle.com>
	
	<5190FC54.8050808@oracle.com> <5194B0D8.2040607@oracle.com>
	<51D685E1.1080606@oracle.com> <51D6D139.40508@oracle.com>
	<51DE74D1.70607@oracle.com>
Message-ID: <51F59C1A.4070602@oracle.com>

On 11/07/2013 02:03, Alexey Utkin wrote:
> :
>
> Bug description:
>      https://jbs.oracle.com/bugs/browse/JDK-7147084
>      http://bugs.sun.com/view_bug.do?bug_id=7147084
>
> Here is the suggested fix:
> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.01/
>
> Summary for  v1 changes:
>
> -- The set of handles that need to restore the inherit flag was extended
> by child process IOE handles. That was done to avoid "greedy sibling"
> problem for the file handles. The file handles are closed outside the
> synchronized block.
> -- "Greedy sibling" problem is covered by the
> [test/java/lang/ProcessBuilder/SiblingIOEHandle.java] test.
> -- The fact that the set of current process standard IOE handles and the
> set of child process IOE handles can intersect was taken into account.
> -- The [test/java/lang/ProcessBuilder/InheritIOEHandle.java] was changed
> in accordance with Martin's concern.
>
I've done a first pass over this. This is a long standing issue so a big 
thank you for taking this on. It's unfortunate that this requires 
serializing the exec but based on the various Microsoft articles that 
you cited when researching this one then it seems that this is what we 
have to do.

Overall I don't see any issues. It's nice to have the create function 
broken up into smaller functions. I do think the new code needs several 
comments, particularly initHolder and the constants.

One concern with the tests is that 10 seconds might not be sufficient on 
a slow/busy machine or a Windows machine that is being choked by AV 
software. Could this be changed so that it just getting timed by the 
test harness if the child does not terminate? I'm also wondering about 
waitAbit and whether this is useful.

-Alan.


From Alan.Bateman at oracle.com  Sun Jul 28 23:43:26 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 28 Jul 2013 16:43:26 -0700
Subject: RFR [8020669] java.nio.file.Files.readAllBytes() does not read
	any data when Files.size() is 0
In-Reply-To: <51F5967A.6060705@oracle.com>
References: <51E97416.20506@oracle.com> <51E98043.6030102@oracle.com>
	<51E9853E.8020409@redhat.com> <51E985AD.60401@redhat.com>
	<51EB0BFF.3030106@oracle.com> <51ED57D8.90001@oracle.com>
	<51EE55AC.5000902@oracle.com> <51EE8E9A.6040806@redhat.com>
	<51EF1B43.9030200@oracle.com>
	
	<51F06789.1050403@oracle.com> <51F12B3E.4010603@oracle.com>
	<51F1BB22.6040405@oracle.com> <51F200F1.8010500@oracle.com>
	<51F5967A.6060705@oracle.com>
Message-ID: <51F5AC9E.1010505@oracle.com>

On 28/07/2013 15:08, Ivan Gerasimov wrote:
> Hello Alan and everyone else
>
> Thank you for review!
>
> Here's another version of webrev:
> http://cr.openjdk.java.net/~igerasim/8020669/5/webrev/ 
> 
Thanks for the updated the webrev, the expansion of the capacity is much 
nicer now. As regards whether to double or increase by BUFFER_SIZE then 
it's probably a coin toss. One could come up with cases where someone is 
using this method on a file that is extended by another entity. It would 
depend on the extend rate as to which approach would be more efficient 
(clearly such cases are going to be problematic as file locking should 
be used to coordinate the access).

As regards the comment on "Reads" vs "Read", that was more just I've 
wasn't sure if you had intended to include this or not.

So I'm happy to sponsor this for you (assuming we are done).

-Alan.


From david.holmes at oracle.com  Mon Jul 29 02:18:06 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 Jul 2013 12:18:06 +1000
Subject: RFR: 8021588 : (s) Remove explicit othervm execution from
	jdk/test/Makefile
In-Reply-To: 
References: 
Message-ID: <51F5D0DE.9040503@oracle.com>

On 27/07/2013 9:09 AM, Mike Duigou wrote:
> Hello all;
>
> I heard word from Alan Bateman that the jdk/test/TEST.ROOT includes accurate specification of which tests cannot be run by JTReg in agentvm mode. ie. they require othervm mode. I tested out removing the duplicate othervm specification from the jdk/test/Makefile and everything still seems to run.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8021588/0/webrev/
>
> Removes othervm specifications from the test/Makefile and other resulting simplifications.
>
> This lets us further simplify the jdk/test/Makefile and removes needless duplication. Great!
>
> I've been playing with another change inspired by work done by Tim Bell. When running tests concurrently it helps to specify -XX+UseSerialGC to avoid over creation of GC threads for what are mostly short lived tests. Testing jdk_utils on my 24 core / 32GB dev box using serial GC provides about 5%-10% speedup and appears to reduce memory usage by 20% or more. Unfortunately there are a few tests in java.lang.manangement which explicitly request incompatible GC options. I haven't figured out yet how to allow these tests to override the -XX+UseSerialGC vmoption in a sane way. (I can think of several rude ways to do it). So for now, this change is commented out.

Not sure that forcing use of SerialGC is good for general 
testing/test-coverage.

The conflicting gc options is a known but as yet unresolved issue.

David

> Mike
>


From david.holmes at oracle.com  Mon Jul 29 05:13:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 Jul 2013 15:13:38 +1000
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: <51F2B781.1050104@oracle.com>
References: <51F2B781.1050104@oracle.com>
Message-ID: <51F5FA02.9020909@oracle.com>

On 27/07/2013 3:53 AM, Brent Christian wrote:
> Please review my fix for 8011194 : "Apps launched via double-clicked
> .jars have file.encoding value of US-ASCII on Mac OS X"
>
> http://bugs.sun.com/view_bug.do?bug_id=8011194
>
> In most cases of launching a Java app on Mac (from the cmdline, or from
> a native .app bundle), reading and displaying UTF-8 characters beyond
> the standard ASCII range works fine.
>
> A notable exception is the launching of an app by double-clicking a .jar
> file.  In this case, file.encoding defaults to US-ASCII, and characters
> outside of the ASCII range show up as garbage.

Why does this occur? What sets the encoding to US-ASCII?

David
-----

> (FWIW, this is not recommended by Apple as a method for deploying Java
> apps [1], though OS X does have a Jar Launcher.app to make it work.)
>
> It's worth mentioning that this is not something that has ever worked on
> MacOS X. (Apple's JRE defaulted to "MacRoman" for English and AFAIK most
> European locales.  I believe this is a holdover from the pre-OS X days).
>
> Even so, the situation can be improved.  When launching, if the standard
> encoding comes up as  US-ASCII, but there are no hints from the
> environment (e.g. LANG/etc environment variables), it would be sane to
> instead use UTF-8 as the default encoding on MacOS X.  An explicit
> file.encoding setting by the user is still honored (and can even be set
> back to US-ASCII).
>
> I believe this also fixes the related issue with webstart [2].
>
> Webrev is here:
> http://cr.openjdk.java.net/~bchristi/8011194/webrev.00/
>
> Thanks,
> -Brent
>
> [1]
> http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html
>
> [2] http://bugs.sun.com/view_bug.do?bug_id=8011195
>


From sundararajan.athijegannathan at oracle.com  Mon Jul 29 06:30:34 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 29 Jul 2013 06:30:34 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20130729063038.3ACD648438@hg.openjdk.java.net>

Changeset: f6588f168d79
Author:    hannesw
Date:      2013-07-26 13:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f6588f168d79

8020719: Run tests with reduced splitter threshold
Reviewed-by: lagergren, sundar, jlaskey

! make/build.xml
! make/project.properties
+ test/script/basic/NASHORN-592-dual.js
+ test/script/basic/NASHORN-592-dual.js.EXPECTED
+ test/script/basic/compile-octane-splitter.js
+ test/script/basic/compile-octane-splitter.js.EXPECTED
+ test/script/basic/splitter.js
+ test/script/basic/splitter.js.EXPECTED
- test/script/representations/NASHORN-592a.js
! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/TestConfig.java
! test/src/jdk/nashorn/internal/test/framework/TestFinder.java

Changeset: 17a947418e65
Author:    jlaskey
Date:      2013-07-26 09:17 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/17a947418e65

8021321: Two runsunspider tests fail after updating sunspider to 1.0
Reviewed-by: jlaskey, sundar
Contributed-by: michael.horowitz at oracle.com

! test/script/basic/runsunspider.js

Changeset: fbd21b00197b
Author:    sundar
Date:      2013-07-26 20:10 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fbd21b00197b

8021571: @fork tests should use VM options passed from project.properties
Reviewed-by: lagergren, hannesw, jlaskey

! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java
! make/project.properties
! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java
! src/jdk/nashorn/internal/objects/PrototypeObject.java
! src/jdk/nashorn/internal/runtime/AccessorProperty.java
! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk/nashorn/internal/runtime/Property.java
! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! src/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk/nashorn/internal/runtime/linker/AdaptationException.java
! src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java
! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java
! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java
! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/TestConfig.java

Changeset: 5fc6b7f11289
Author:    sundar
Date:      2013-07-29 10:28 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5fc6b7f11289

Merge

- test/script/representations/NASHORN-592a.js



From joe.darcy at oracle.com  Mon Jul 29 07:05:14 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 29 Jul 2013 00:05:14 -0700
Subject: Java 8 RFR 8020539: Clean up doclint problems in java.util
	package, part 2
In-Reply-To: <67232DB5-4077-4A4D-9729-B06C7FD911BF@oracle.com>
References: <50FE640E-DC42-47F2-9FAD-8472A013EB9B@oracle.com>
	
	
	<51E77802.8070001@oracle.com>
	<67232DB5-4077-4A4D-9729-B06C7FD911BF@oracle.com>
Message-ID: <51F6142A.2080201@oracle.com>

On 07/18/2013 02:19 PM, Brian Burkhalter wrote:
> On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
>
>> In Random.java, I would prefer if the  size manipulation of the exponent was removed instead of
>>
>> 373      * All 2²⁴ possible {@code float} values
>>
>> just
>>
>> 373      * All 2²⁴ possible {@code float} values.
> Done.
>
>> Also, I think the changes in Scanner would be better of the JLS-style grammar syntax was used, which is what is done in places like java.lang.*. From memory,
>>
>> NonTerminal:
>>     First Option of the production
>>     Second Options of the production
> Changes made but I'm not sure that they are exactly as expected:
>
> http://cr.openjdk.java.net/~bpb/Scanner.html

I recommend a few changes here:

* For readability, rename "NonASCIIDigit" as "NonAsciiDigit"

* Since Scanner is in the regex package, it may be more appropriate to 
stick more of a regex notation than an ebnf notation, but keeping the 
definition list structure tags.

>
>> Offhand, I wasn't aware Dequeue and Queue were maintained in Doug's CVS, but I agree changes to those files should flow through there first.
> Deque and Queue removed from the webrev:
>
> http://cr.openjdk.java.net/~bpb/8020539/
>

Otherwise, the changes look fine. If you like, the non-Scanner changes 
can be split out and pushed first.

Thanks,

-Joe



From sundararajan.athijegannathan at oracle.com  Mon Jul 29 08:03:55 2013
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 29 Jul 2013 13:33:55 +0530
Subject: Review request for 8021773: print function as defined by jrunscript's
	init.js script is incompatible with nashorn's definition
Message-ID: <51F621EB.1070401@oracle.com>

Bug: 8021773: print function as defined by jrunscript's init.js script 
is incompatible with nashorn's definition

Please review http://cr.openjdk.java.net/~sundar/8021773/

Thanks
-Sundar


From ivan.gerasimov at oracle.com  Mon Jul 29 08:48:54 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 29 Jul 2013 12:48:54 +0400
Subject: RFR [8020669] java.nio.file.Files.readAllBytes() does not read
	any data when Files.size() is 0
In-Reply-To: <51F5AC9E.1010505@oracle.com>
References: <51E97416.20506@oracle.com> <51E98043.6030102@oracle.com>
	<51E9853E.8020409@redhat.com> <51E985AD.60401@redhat.com>
	<51EB0BFF.3030106@oracle.com> <51ED57D8.90001@oracle.com>
	<51EE55AC.5000902@oracle.com> <51EE8E9A.6040806@redhat.com>
	<51EF1B43.9030200@oracle.com>
	
	<51F06789.1050403@oracle.com> <51F12B3E.4010603@oracle.com>
	<51F1BB22.6040405@oracle.com> <51F200F1.8010500@oracle.com>
	<51F5967A.6060705@oracle.com> <51F5AC9E.1010505@oracle.com>
Message-ID: <51F62C76.7030401@oracle.com>

Thank you, Alan. I really appreciate it.

Here's the mercurial export:
http://cr.openjdk.java.net/~igerasim/2commit/8020669-jdk8-readAllBytes.patch

Sincerely yours,
Ivan

On 29.07.2013 3:43, Alan Bateman wrote:
> On 28/07/2013 15:08, Ivan Gerasimov wrote:
>> Hello Alan and everyone else
>>
>> Thank you for review!
>>
>> Here's another version of webrev:
>> http://cr.openjdk.java.net/~igerasim/8020669/5/webrev/ 
>> 
> Thanks for the updated the webrev, the expansion of the capacity is 
> much nicer now. As regards whether to double or increase by 
> BUFFER_SIZE then it's probably a coin toss. One could come up with 
> cases where someone is using this method on a file that is extended by 
> another entity. It would depend on the extend rate as to which 
> approach would be more efficient (clearly such cases are going to be 
> problematic as file locking should be used to coordinate the access).
>
> As regards the comment on "Reads" vs "Read", that was more just I've 
> wasn't sure if you had intended to include this or not.
>
> So I'm happy to sponsor this for you (assuming we are done).
>
> -Alan.



From chris.hegarty at oracle.com  Mon Jul 29 09:43:35 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 29 Jul 2013 10:43:35 +0100
Subject: Java 8 RFR 8020539: Clean up doclint problems in java.util
	package, part 2
In-Reply-To: <51F6142A.2080201@oracle.com>
References: <50FE640E-DC42-47F2-9FAD-8472A013EB9B@oracle.com>
	
	
	<51E77802.8070001@oracle.com>
	<67232DB5-4077-4A4D-9729-B06C7FD911BF@oracle.com>
	<51F6142A.2080201@oracle.com>
Message-ID: <51F63947.9010908@oracle.com>


> .....
>> http://cr.openjdk.java.net/~bpb/8020539/

Brian,

Looks fine ( I did not go through the Scanner changes ).

Some minor comments:

1) List
    Trivially I wonder why you decided to go with '< '>', rather
    than {@code ... }, which I think is more readable.

2) Map
    Trivially, I would keep the @param's order the same as the actual
    method parameters order.

3) Optional
    Strangely, there doesn't appear to be a '@param' for the class level
    type T. doclint is not warning about this either.

-Chris.


From chris.hegarty at oracle.com  Mon Jul 29 10:27:45 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 29 Jul 2013 11:27:45 +0100
Subject: RFR [8020669] java.nio.file.Files.readAllBytes() does not read
	any data when Files.size() is 0
In-Reply-To: <51F5AC9E.1010505@oracle.com>
References: <51E97416.20506@oracle.com> <51E98043.6030102@oracle.com>
	<51E9853E.8020409@redhat.com> <51E985AD.60401@redhat.com>
	<51EB0BFF.3030106@oracle.com> <51ED57D8.90001@oracle.com>
	<51EE55AC.5000902@oracle.com> <51EE8E9A.6040806@redhat.com>
	<51EF1B43.9030200@oracle.com>
	
	<51F06789.1050403@oracle.com> <51F12B3E.4010603@oracle.com>
	<51F1BB22.6040405@oracle.com> <51F200F1.8010500@oracle.com>
	<51F5967A.6060705@oracle.com> <51F5AC9E.1010505@oracle.com>
Message-ID: <51F643A1.30404@oracle.com>

On 29/07/2013 00:43, Alan Bateman wrote:
> On 28/07/2013 15:08, Ivan Gerasimov wrote:
>> Hello Alan and everyone else
>>
>> Thank you for review!
>>
>> Here's another version of webrev:
>> http://cr.openjdk.java.net/~igerasim/8020669/5/webrev/
>> 

The change looks fine to me, but then again I was happy with previous 
version too ;-)

-Chris.


> Thanks for the updated the webrev, the expansion of the capacity is much
> nicer now. As regards whether to double or increase by BUFFER_SIZE then
> it's probably a coin toss. One could come up with cases where someone is
> using this method on a file that is extended by another entity. It would
> depend on the extend rate as to which approach would be more efficient
> (clearly such cases are going to be problematic as file locking should
> be used to coordinate the access).
>
> As regards the comment on "Reads" vs "Read", that was more just I've
> wasn't sure if you had intended to include this or not.
>
> So I'm happy to sponsor this for you (assuming we are done).
>
> -Alan.


From paul.sandoz at oracle.com  Mon Jul 29 11:20:03 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 29 Jul 2013 12:20:03 +0100
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
Message-ID: <97903415-01F4-4FE2-B5F8-AFBF54217D32@oracle.com>

Hi Mike,

V. quick review below.


On Jul 27, 2013, at 12:31 AM, Mike Duigou  wrote:

> Hello all;
> 
> This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases. 
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/
> 
> The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures.
> 

diff --git a/src/share/classes/java/util/Map.java b/src/share/classes/java/util/Map.java
--- a/src/share/classes/java/util/Map.java
+++ b/src/share/classes/java/util/Map.java
@@ -804,6 +804,10 @@
      *     return false;
      * }
      *
+     * @implNote The default implementation does not throw NullPointerException
+     * for maps that do not support null values if oldValue is null unless
+     * newValue is also null.


Is that really more a clarification of the default impl specification?


-     * @throws NullPointerException if a specified key or value is null,
+     * @throws NullPointerException if a specified key or newValue is null,
      *         and this map does not permit null keys or values
+     * @throws NullPointerException if oldValue is null and this map does not
+     *         permit null values
+     *         (optional)


More curious than anything else, is it fine to have two declarations of NPE here?


+++ b/src/share/classes/java/util/TreeMap.java
@@ -948,6 +948,27 @@
     }
 
     @Override
+    public synchronized boolean replace(K key, V oldValue, V newValue) {
+        Entry p = getEntry(key);
+        if (p!=null && Objects.equals(oldValue, p.value)) {
+            p.value = newValue;
+            return true;
+        }
+        return false;
+    }
+
+    @Override
+    public synchronized V replace(K key, V value) {

Remove the synchronized?


I might be missing something but i cannot see where ExtendsAbstractCollection is used.

Paul.

> Mike



From nicholas+openjdk at nicholaswilliams.net  Mon Jul 29 12:53:54 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 29 Jul 2013 07:53:54 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: 
References: 
Message-ID: <00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>

Just so that everyone understands how important this subject is, this change to getCallerClass(...) is being labeled a "disaster" for logging frameworks everywhere. Here's a benchmark for getting Classes from the following methods:

> 1,000,000 calls of all alternatives were measured as follows :
> Reflection: 10.195 ms.
> Current Thread StackTrace: 5886.964 ms.
> Throwable StackTrace: 4700.073 ms.
> SecurityManager: 1046.804 ms.

My goal here is to get the entire list engaged in coming up with the right solution. We (the community) can't afford for Java 8 not to have an equivalent replacement for getCallerClass().

Nick

On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:

> All,
> 
> In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted to consolidate it all into this one discussion where I hope we can finalize on a solution and get it implemented for Java 8.
> 
> In a nut shell, here are the underlying needs that I have seen expressed through many, many messages:
> 
> - Some code needs to get the Class of the caller of the current method, skipping any reflection methods.
> - Some code needs to get the Class of the caller /n/ stack frames before the current method, skipping any reflection methods.
> - Some code needs to get the current stack trace, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
> - Some code needs to get the stack trace from when a Throwable was created, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
> - There needs to be a reflection way to achieve all of this since some libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and 8 (and thus can't use @CallerSensitive).
> 
> I believe the solutions to these needs are all related. Importantly, I think it is very important that action be taken in Java 8 due to the changes made to sun.reflect.Reflection#getCallerClass(...). While we all understand that relying on private sun.* APIs is not safe, the fact is that many people have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact that there is simply no other way to do this in the standard API. This includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will stop working correctly in Java 7 >= u25.
> 
> I would point out that this could all easily be solved simply by adding a getElementClass() method to StackTraceElement, but there was strong opposition to this, largely due to serialization issues. Since that is apparently not an option, I propose the following API, based on the various discussions in the last two months, StackTraceElement, and the API that .NET provides to achieve the same needs as listed above:
> 
> CallerSensitive.java:
> package java.lang;
> 
> /** Previously private API, now public */
> public @interface CallerSensitive {
>     ...
> }
> 
> StackTraceFrame.java:
> package java.lang;
> 
> import java.util.Objects.
> 
> public final class StackTraceFrame {
>     private final Class declaringClass;
>     private final Executable executable;
>     private final String fileName;
>     private final int lineNumber;
> 
>     public StackTraceFrame(Class declaringClass, Executable executable, String fileName, int lineNumber) {
>         this.declaringClass = Objects.requireNonNull(declaringClass, "Declaring class is null");
>         this.executable = Objects.requireNonNull(executable, "Executable is null");
>         this.fileName = fileName;
>         this.lineNumber = lineNumber;
>     }
> 
>     public Class getDeclaringClass() {
>         return this.declaringClass;
>     }
> 
>     public Executable getExecutable() {
>         return this.executable;
>     }
> 
>     public String getFileName() {
>         return this.fileName;
>     }
> 
>     public int getLineNumber() {
>         return this.lineNumber;
>     }
> 
>     public boolean isNative() {
>         return this.lineNumber == -2;
>     }
> 
>     public String toString() { /* Same as StackTraceElement */ }
>     public boolean equals() { /* Ditto */ }
>     public int hashCode() { /* Ditto */ }
> 
>     /** Uses @CallerSensitive */
>     public static native StackTraceFrame getCallerFrame();
> 
>     /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() */
>     public static native StackTraceFrame getCallerFrame(int skipFrames);
> 
>     public static native StackTraceFrame[] getCurrentStackTrace();
> }
> 
> Throwable.java:
> package java.lang;
> 
> ...
> 
> public class Throwable {
>     ...
>     public synchronized Throwable fillInStackTraceFrames() { ... }
> 
>     private native Throwable fillInStackTraceFrames(int dummy);
> 
>     public StackTraceFrame[] getStackTraceFrames() {
>         return this.getOurStackTraceFrames().clone();
>     }
> 
>     private synchronized StackTraceFrame[] getOurStackTraceFrames() { ... }
>     ...
> }
> 
> Furthermore, I propose that we restore the behavior of sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the proposed above solution cannot be added to Java 7.
> 
> I would love if we could quickly coalesce around this solution or a derivative thereof so that it can be implemented before Feature Complete. The absence of any replacement or alternative for sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 that will cause hardships for many projects.
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html



From david.lloyd at redhat.com  Mon Jul 29 13:21:58 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 29 Jul 2013 08:21:58 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
Message-ID: <51F66C76.10209@redhat.com>

I find it very interesting that reflection is no less than two orders of 
magnitude faster than the security manager solution.  How big was the 
stack in these tests?  It makes me wonder if maybe the implementation of 
the security manager's getContext() method should be reevaluated a bit.

On 07/29/2013 07:53 AM, Nick Williams wrote:
> Just so that everyone understands how important this subject is, this change to getCallerClass(...) is being labeled a "disaster" for logging frameworks everywhere. Here's a benchmark for getting Classes from the following methods:
>
>> 1,000,000 calls of all alternatives were measured as follows :
>> Reflection: 10.195 ms.
>> Current Thread StackTrace: 5886.964 ms.
>> Throwable StackTrace: 4700.073 ms.
>> SecurityManager: 1046.804 ms.
>
> My goal here is to get the entire list engaged in coming up with the right solution. We (the community) can't afford for Java 8 not to have an equivalent replacement for getCallerClass().
>
> Nick
>
> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:
>
>> All,
>>
>> In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted to consolidate it all into this one discussion where I hope we can finalize on a solution and get it implemented for Java 8.
>>
>> In a nut shell, here are the underlying needs that I have seen expressed through many, many messages:
>>
>> - Some code needs to get the Class of the caller of the current method, skipping any reflection methods.
>> - Some code needs to get the Class of the caller /n/ stack frames before the current method, skipping any reflection methods.
>> - Some code needs to get the current stack trace, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
>> - Some code needs to get the stack trace from when a Throwable was created, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
>> - There needs to be a reflection way to achieve all of this since some libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and 8 (and thus can't use @CallerSensitive).
>>
>> I believe the solutions to these needs are all related. Importantly, I think it is very important that action be taken in Java 8 due to the changes made to sun.reflect.Reflection#getCallerClass(...). While we all understand that relying on private sun.* APIs is not safe, the fact is that many people have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact that there is simply no other way to do this in the standard API. This includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will stop working correctly in Java 7 >= u25.
>>
>> I would point out that this could all easily be solved simply by adding a getElementClass() method to StackTraceElement, but there was strong opposition to this, largely due to serialization issues. Since that is apparently not an option, I propose the following API, based on the various discussions in the last two months, StackTraceElement, and the API that .NET provides to achieve the same needs as listed above:
>>
>> CallerSensitive.java:
>> package java.lang;
>>
>> /** Previously private API, now public */
>> public @interface CallerSensitive {
>>      ...
>> }
>>
>> StackTraceFrame.java:
>> package java.lang;
>>
>> import java.util.Objects.
>>
>> public final class StackTraceFrame {
>>      private final Class declaringClass;
>>      private final Executable executable;
>>      private final String fileName;
>>      private final int lineNumber;
>>
>>      public StackTraceFrame(Class declaringClass, Executable executable, String fileName, int lineNumber) {
>>          this.declaringClass = Objects.requireNonNull(declaringClass, "Declaring class is null");
>>          this.executable = Objects.requireNonNull(executable, "Executable is null");
>>          this.fileName = fileName;
>>          this.lineNumber = lineNumber;
>>      }
>>
>>      public Class getDeclaringClass() {
>>          return this.declaringClass;
>>      }
>>
>>      public Executable getExecutable() {
>>          return this.executable;
>>      }
>>
>>      public String getFileName() {
>>          return this.fileName;
>>      }
>>
>>      public int getLineNumber() {
>>          return this.lineNumber;
>>      }
>>
>>      public boolean isNative() {
>>          return this.lineNumber == -2;
>>      }
>>
>>      public String toString() { /* Same as StackTraceElement */ }
>>      public boolean equals() { /* Ditto */ }
>>      public int hashCode() { /* Ditto */ }
>>
>>      /** Uses @CallerSensitive */
>>      public static native StackTraceFrame getCallerFrame();
>>
>>      /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() */
>>      public static native StackTraceFrame getCallerFrame(int skipFrames);
>>
>>      public static native StackTraceFrame[] getCurrentStackTrace();
>> }
>>
>> Throwable.java:
>> package java.lang;
>>
>> ...
>>
>> public class Throwable {
>>      ...
>>      public synchronized Throwable fillInStackTraceFrames() { ... }
>>
>>      private native Throwable fillInStackTraceFrames(int dummy);
>>
>>      public StackTraceFrame[] getStackTraceFrames() {
>>          return this.getOurStackTraceFrames().clone();
>>      }
>>
>>      private synchronized StackTraceFrame[] getOurStackTraceFrames() { ... }
>>      ...
>> }
>>
>> Furthermore, I propose that we restore the behavior of sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the proposed above solution cannot be added to Java 7.
>>
>> I would love if we could quickly coalesce around this solution or a derivative thereof so that it can be implemented before Feature Complete. The absence of any replacement or alternative for sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 that will cause hardships for many projects.
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>


-- 
- DML


From chris.hegarty at oracle.com  Mon Jul 29 13:46:48 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 29 Jul 2013 14:46:48 +0100
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: <97903415-01F4-4FE2-B5F8-AFBF54217D32@oracle.com>
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
	<97903415-01F4-4FE2-B5F8-AFBF54217D32@oracle.com>
Message-ID: <51F67248.60308@oracle.com>

On 29/07/2013 12:20, Paul Sandoz wrote:
> Hi Mike,
>
> V. quick review below.

The changes look ok to me. Some small comments below.

> On Jul 27, 2013, at 12:31 AM, Mike Duigou  wrote:
>
>> Hello all;
>>
>> This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/
>>
>> The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures.
>>
>
> diff --git a/src/share/classes/java/util/Map.java b/src/share/classes/java/util/Map.java
> --- a/src/share/classes/java/util/Map.java
> +++ b/src/share/classes/java/util/Map.java
> @@ -804,6 +804,10 @@
>        *     return false;
>        * }
>        *
> +     * @implNote The default implementation does not throw NullPointerException
> +     * for maps that do not support null values if oldValue is null unless
> +     * newValue is also null.
>
>
> Is that really more a clarification of the default impl specification?

I thought implNote was to be used for default implementations, but it 
appears that it is implSpec?

>
>
> -     * @throws NullPointerException if a specified key or value is null,
> +     * @throws NullPointerException if a specified key or newValue is null,
>        *         and this map does not permit null keys or values
> +     * @throws NullPointerException if oldValue is null and this map does not
> +     *         permit null values
> +     *         (optional)
>
>
> More curious than anything else, is it fine to have two declarations of NPE here?

Having two @throws looks a little strange to me. Putting it together???

  * @throws NullPointerException if a specified key or newValue is null,
  *         and this map does not permit null keys or values. If
  *         oldValue is null and this map does not permit null values
  *         (optional).

Is this even right? Should the implNote not be part of the NPE throws? 
Do you want replace to be used to put an initial value ( where 
previously unset (null) )?

-Chris.

>
>
> +++ b/src/share/classes/java/util/TreeMap.java
> @@ -948,6 +948,27 @@
>       }
>
>       @Override
> +    public synchronized boolean replace(K key, V oldValue, V newValue) {
> +        Entry  p = getEntry(key);
> +        if (p!=null&&  Objects.equals(oldValue, p.value)) {
> +            p.value = newValue;
> +            return true;
> +        }
> +        return false;
> +    }
> +
> +    @Override
> +    public synchronized V replace(K key, V value) {
>
> Remove the synchronized?
>
>
> I might be missing something but i cannot see where ExtendsAbstractCollection is used.
>
> Paul.
>
>> Mike
>


From pbenedict at apache.org  Mon Jul 29 13:50:07 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 29 Jul 2013 08:50:07 -0500
Subject: Classes on the stack trace (was: getElementClass/StackTraceElement,
	was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
Message-ID: 

If it is not possible in the remaining dev time for JDK8 to expose
Reflection.getCallerClass() functionality through some public API, why must
-Djdk.reflect.allowGetCallerClass be discontinued so soon? Why the hot
potato? I don't see how impacting the many (most? or all?) open source
logging libraries is a good idea.

With the argument of "you shouldn't be using private sun.* classes" aside,
it seriously needs to be evaulted rather causing such commotion is
worthwhile. I would like Oracle to reconsider dropping the System property
workaround until an API can be put in place.

-- 
Cheers,
Paul


From Bob.Vandette at oracle.com  Mon Jul 29 14:12:07 2013
From: Bob.Vandette at oracle.com (Bob Vandette)
Date: Mon, 29 Jul 2013 10:12:07 -0400
Subject: 8016036: RMI specification needs to be updated to allow
	Activation on remote hosts
In-Reply-To: <51F41E5F.6030407@oracle.com>
References: <51DE3146.2000908@oracle.com> <51F41E5F.6030407@oracle.com>
Message-ID: 

Alan,

Excuse me if I'm a bit frustrated by this issue ...

We keep going around and around on this issue.  We had a discussion with Stuart and the JCK
team and Stuart didn't want to change the specification.  Has he now changed his mind?

Security and configuration issues aside, I don't understand why it doesn't make sense to remote 
activate an Object in an API that is supposed implement "Remote Method Invocation" support.  
The fact that it only supports activation on a local host seems to be a bug to me.


Bob.


On Jul 27, 2013, at 3:24 PM, Alan Bateman wrote:

> On 10/07/2013 21:15, Stephen Flores wrote:
>> Bob, Sean,
>> 
>> Please review this webrev
>> 
>>  http://cr.openjdk.java.net/~sflores/8016036/webrev.00/
>> 
>> for RFE/CCC: 8016036 RMI specification needs to be updated to allow Activation on remote hosts
> I didn't see any replies to this but I chatted briefly with Stuart Marks about this a few days ago as it's not clear (to me anyway) that this is the right thing to do. In particular it would be good to understand why the specification can't be changed to allow for environments that doesn't support multiple VM instances or where it's not possible to launch a new VM. This would amount to not supporting activation in such environments. Has this approach been explored? It could of course require being creative in the specifications but there are other examples of this type of thing.
> 
> -Alan



From chris.hegarty at oracle.com  Mon Jul 29 14:28:36 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 29 Jul 2013 15:28:36 +0100
Subject: Remaining doclint issues in java.net
Message-ID: <51F67C14.5040804@oracle.com>


There are two remaining doclint warnings in the java.net package.

 >:javac -Xdoclint:all/protected 
src/share/classes/java/net/DatagramPacket.java
src/share/classes/java/net/DatagramPacket.java:142: warning: no @throws 
for java.net.SocketException
     public DatagramPacket(byte buf[], int offset, int length,
            ^
src/share/classes/java/net/DatagramPacket.java:178: warning: no @throws 
for java.net.SocketException
     public DatagramPacket(byte buf[], int length,
            ^

These are caused by no @throws SE declaration on the constructors.

As it happens 'throws SE' was incorrectly added to these constructors 
when introduced in 1.4. The original API specified that SE was thrown 
when the given SocketAddress was not supported. That was later changed 
to throw IAE, in 1.4.2. These constructor now can never throw SE.

Removing 'throws SE' from the method declaration is a binary compatible 
change, but not source compatible ( XXX  is never thrown in body of 
corresponding try statement ). I don't think breaking source 
compatibility for this kind of change is justified. If it is, then the 
solution is to simply remove 'throws SE'.

Back in the real world, I guess we need to come up with some wording for 
the '@throws SE' declaration. Something vague like "If an I/O Exception 
occurs", or can we put something stronger like "will never be thrown" ??

Thanks,
-Chris.



From ivan.gerasimov at oracle.com  Mon Jul 29 14:26:17 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 29 Jul 2013 18:26:17 +0400
Subject: RFR [8020669] java.nio.file.Files.readAllBytes() does not read
	any data when Files.size() is 0
In-Reply-To: <51F643A1.30404@oracle.com>
References: <51E97416.20506@oracle.com> <51E98043.6030102@oracle.com>
	<51E9853E.8020409@redhat.com> <51E985AD.60401@redhat.com>
	<51EB0BFF.3030106@oracle.com> <51ED57D8.90001@oracle.com>
	<51EE55AC.5000902@oracle.com> <51EE8E9A.6040806@redhat.com>
	<51EF1B43.9030200@oracle.com>
	
	<51F06789.1050403@oracle.com> <51F12B3E.4010603@oracle.com>
	<51F1BB22.6040405@oracle.com> <51F200F1.8010500@oracle.com>
	<51F5967A.6060705@oracle.com> <51F5AC9E.1010505@oracle.com>
	<51F643A1.30404@oracle.com>
Message-ID: <51F67B89.807@oracle.com>


On 29.07.2013 14:27, Chris Hegarty wrote:
> On 29/07/2013 00:43, Alan Bateman wrote:
>> On 28/07/2013 15:08, Ivan Gerasimov wrote:
>>> Hello Alan and everyone else
>>>
>>> Thank you for review!
>>>
>>> Here's another version of webrev:
>>> http://cr.openjdk.java.net/~igerasim/8020669/5/webrev/
>>> 
>
> The change looks fine to me, but then again I was happy with previous 
> version too ;-)
>
Thank you, Chris!

Ivan

> -Chris.
>
>
>> Thanks for the updated the webrev, the expansion of the capacity is much
>> nicer now. As regards whether to double or increase by BUFFER_SIZE then
>> it's probably a coin toss. One could come up with cases where someone is
>> using this method on a file that is extended by another entity. It would
>> depend on the extend rate as to which approach would be more efficient
>> (clearly such cases are going to be problematic as file locking should
>> be used to coordinate the access).
>>
>> As regards the comment on "Reads" vs "Read", that was more just I've
>> wasn't sure if you had intended to include this or not.
>>
>> So I'm happy to sponsor this for you (assuming we are done).
>>
>> -Alan.
>
>



From nicholas+openjdk at nicholaswilliams.net  Mon Jul 29 14:48:08 2013
From: nicholas+openjdk at nicholaswilliams.net (Nicholas Williams)
Date: Mon, 29 Jul 2013 09:48:08 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F66C76.10209@redhat.com>
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
Message-ID: 

I wasn't the one who ran the test, so I don't know for sure. My theory
was that getCallerClass() returns a single frame, but the
SecurityManager must allocate an array of appropriate size (which
involves some overhead) and then return all of the frames. I chalked
the difference up to that. My conclusion from the data was: If you
need a whole stack, SecurityManager is clearly the best option. If you
need a single frame, getCallerClass() is the only option that makes
any sense.

On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote:
> I find it very interesting that reflection is no less than two orders of
> magnitude faster than the security manager solution.  How big was the stack
> in these tests?  It makes me wonder if maybe the implementation of the
> security manager's getContext() method should be reevaluated a bit.
>
>
> On 07/29/2013 07:53 AM, Nick Williams wrote:
>>
>> Just so that everyone understands how important this subject is, this
>> change to getCallerClass(...) is being labeled a "disaster" for logging
>> frameworks everywhere. Here's a benchmark for getting Classes from the
>> following methods:
>>
>>> 1,000,000 calls of all alternatives were measured as follows :
>>> Reflection: 10.195 ms.
>>> Current Thread StackTrace: 5886.964 ms.
>>> Throwable StackTrace: 4700.073 ms.
>>> SecurityManager: 1046.804 ms.
>>
>>
>> My goal here is to get the entire list engaged in coming up with the right
>> solution. We (the community) can't afford for Java 8 not to have an
>> equivalent replacement for getCallerClass().
>>
>> Nick
>>
>> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:
>>
>>> All,
>>>
>>> In the last two months, there have been a number of discussions
>>> surrounding stack traces, Classes on the stack trace, and caller classes
>>> [1], [2], [3]. These are all related discussions and the solution to them is
>>> equally related, so I wanted to consolidate it all into this one discussion
>>> where I hope we can finalize on a solution and get it implemented for Java
>>> 8.
>>>
>>> In a nut shell, here are the underlying needs that I have seen expressed
>>> through many, many messages:
>>>
>>> - Some code needs to get the Class of the caller of the current method,
>>> skipping any reflection methods.
>>> - Some code needs to get the Class of the caller /n/ stack frames before
>>> the current method, skipping any reflection methods.
>>> - Some code needs to get the current stack trace, populated with Classes,
>>> Executables, file names, line numbers, and native flags instead of the
>>> String class names and String method names in StackTraceElement. This
>>> /should/ include any reflection methods, just like StackTraceElement[]s.
>>> - Some code needs to get the stack trace from when a Throwable was
>>> created, populated with Classes, Executables, file names, line numbers, and
>>> native flags instead of the String class names and String method names in
>>> StackTraceElement. This /should/ include any reflection methods, just like
>>> StackTraceElement[]s.
>>> - There needs to be a reflection way to achieve all of this since some
>>> libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and
>>> 8 (and thus can't use @CallerSensitive).
>>>
>>> I believe the solutions to these needs are all related. Importantly, I
>>> think it is very important that action be taken in Java 8 due to the changes
>>> made to sun.reflect.Reflection#getCallerClass(...). While we all understand
>>> that relying on private sun.* APIs is not safe, the fact is that many people
>>> have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact
>>> that there is simply no other way to do this in the standard API. This
>>> includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will
>>> stop working correctly in Java 7 >= u25.
>>>
>>> I would point out that this could all easily be solved simply by adding a
>>> getElementClass() method to StackTraceElement, but there was strong
>>> opposition to this, largely due to serialization issues. Since that is
>>> apparently not an option, I propose the following API, based on the various
>>> discussions in the last two months, StackTraceElement, and the API that .NET
>>> provides to achieve the same needs as listed above:
>>>
>>> CallerSensitive.java:
>>> package java.lang;
>>>
>>> /** Previously private API, now public */
>>> public @interface CallerSensitive {
>>>      ...
>>> }
>>>
>>> StackTraceFrame.java:
>>> package java.lang;
>>>
>>> import java.util.Objects.
>>>
>>> public final class StackTraceFrame {
>>>      private final Class declaringClass;
>>>      private final Executable executable;
>>>      private final String fileName;
>>>      private final int lineNumber;
>>>
>>>      public StackTraceFrame(Class declaringClass, Executable
>>> executable, String fileName, int lineNumber) {
>>>          this.declaringClass = Objects.requireNonNull(declaringClass,
>>> "Declaring class is null");
>>>          this.executable = Objects.requireNonNull(executable, "Executable
>>> is null");
>>>          this.fileName = fileName;
>>>          this.lineNumber = lineNumber;
>>>      }
>>>
>>>      public Class getDeclaringClass() {
>>>          return this.declaringClass;
>>>      }
>>>
>>>      public Executable getExecutable() {
>>>          return this.executable;
>>>      }
>>>
>>>      public String getFileName() {
>>>          return this.fileName;
>>>      }
>>>
>>>      public int getLineNumber() {
>>>          return this.lineNumber;
>>>      }
>>>
>>>      public boolean isNative() {
>>>          return this.lineNumber == -2;
>>>      }
>>>
>>>      public String toString() { /* Same as StackTraceElement */ }
>>>      public boolean equals() { /* Ditto */ }
>>>      public int hashCode() { /* Ditto */ }
>>>
>>>      /** Uses @CallerSensitive */
>>>      public static native StackTraceFrame getCallerFrame();
>>>
>>>      /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass()
>>> */
>>>      public static native StackTraceFrame getCallerFrame(int skipFrames);
>>>
>>>      public static native StackTraceFrame[] getCurrentStackTrace();
>>> }
>>>
>>> Throwable.java:
>>> package java.lang;
>>>
>>> ...
>>>
>>> public class Throwable {
>>>      ...
>>>      public synchronized Throwable fillInStackTraceFrames() { ... }
>>>
>>>      private native Throwable fillInStackTraceFrames(int dummy);
>>>
>>>      public StackTraceFrame[] getStackTraceFrames() {
>>>          return this.getOurStackTraceFrames().clone();
>>>      }
>>>
>>>      private synchronized StackTraceFrame[] getOurStackTraceFrames() {
>>> ... }
>>>      ...
>>> }
>>>
>>> Furthermore, I propose that we restore the behavior of
>>> sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the
>>> proposed above solution cannot be added to Java 7.
>>>
>>> I would love if we could quickly coalesce around this solution or a
>>> derivative thereof so that it can be implemented before Feature Complete.
>>> The absence of any replacement or alternative for
>>> sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8
>>> that will cause hardships for many projects.
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>>> [3]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>>
>>
>
>
> --
> - DML


From Alan.Bateman at oracle.com  Mon Jul 29 14:48:31 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Jul 2013 07:48:31 -0700
Subject: 8016036: RMI specification needs to be updated to allow Activation
	on remote hosts
In-Reply-To: 
References: <51DE3146.2000908@oracle.com> <51F41E5F.6030407@oracle.com>
	
Message-ID: <51F680BF.5060804@oracle.com>

On 29/07/2013 07:12, Bob Vandette wrote:
> Alan,
>
> Excuse me if I'm a bit frustrated by this issue ...
>
> We keep going around and around on this issue.  We had a discussion with Stuart and the JCK
> team and Stuart didn't want to change the specification.  Has he now changed his mind?
>
> Security and configuration issues aside, I don't understand why it doesn't make sense to remote
> activate an Object in an API that is supposed implement "Remote Method Invocation" support.
> The fact that it only supports activation on a local host seems to be a bug to me.
>
>
> Bob.
I understand that this is a bit frustrating but I think we should at 
least explore relaxing the specification (if it hasn't been explored 
already). I'm not an export on RMI but I'm just concerned that the 
currently "agreed" solution to do the activation on another system feels 
more like a solution to get tests to pass. Stuart told me that he would 
look into it and see if relaxing the specification is feasible or not. 
Stuart - do you have anything to add?

-Alan.



From jhuxhorn at googlemail.com  Mon Jul 29 15:47:18 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Mon, 29 Jul 2013 17:47:18 +0200
Subject: =?UTF-8?Q?Re=3A_Classes_on_the_stack_trace_(was=3A_getElementClass/StackTraceElement=2C_was=3A_=40CallerSensitive_public_API=2C_was=3A_sun.reflect.Reflection.getCallerClass)?=
In-Reply-To: 
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
	
Message-ID: 

The numbers are from this link:?http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection

Even if this benchmark suffers from micro-benchmark issues:
a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.

I'd suggest to at least postpone the UnsupportedOperationException change until we find a suitable replacement. This change will also break existing Groovy scripts. See?http://jira.codehaus.org/browse/GROOVY-6279?- but there are other issues as well.

Cheers,
J?rn.

On 29. Juli 2013 at 16:49:02, Nicholas Williams (nicholas+openjdk at nicholaswilliams.net) wrote:

I wasn't the one who ran the test, so I don't know for sure. My theory  
was that getCallerClass() returns a single frame, but the  
SecurityManager must allocate an array of appropriate size (which  
involves some overhead) and then return all of the frames. I chalked  
the difference up to that. My conclusion from the data was: If you  
need a whole stack, SecurityManager is clearly the best option. If you  
need a single frame, getCallerClass() is the only option that makes  
any sense.  

On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote:  
> I find it very interesting that reflection is no less than two orders of  
> magnitude faster than the security manager solution. How big was the stack  
> in these tests? It makes me wonder if maybe the implementation of the  
> security manager's getContext() method should be reevaluated a bit.  
>  
>  
> On 07/29/2013 07:53 AM, Nick Williams wrote:  
>>  
>> Just so that everyone understands how important this subject is, this  
>> change to getCallerClass(...) is being labeled a "disaster" for logging  
>> frameworks everywhere. Here's a benchmark for getting Classes from the  
>> following methods:  
>>  
>>> 1,000,000 calls of all alternatives were measured as follows :  
>>> Reflection: 10.195 ms.  
>>> Current Thread StackTrace: 5886.964 ms.  
>>> Throwable StackTrace: 4700.073 ms.  
>>> SecurityManager: 1046.804 ms.  
>>  
>>  
>> My goal here is to get the entire list engaged in coming up with the right  
>> solution. We (the community) can't afford for Java 8 not to have an  
>> equivalent replacement for getCallerClass().  
>>  
>> Nick  
>>  
>> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:  
>>  
>>> All,  
>>>  
>>> In the last two months, there have been a number of discussions  
>>> surrounding stack traces, Classes on the stack trace, and caller classes  
>>> [1], [2], [3]. These are all related discussions and the solution to them is  
>>> equally related, so I wanted to consolidate it all into this one discussion  
>>> where I hope we can finalize on a solution and get it implemented for Java  
>>> 8.  
>>>  
>>> In a nut shell, here are the underlying needs that I have seen expressed  
>>> through many, many messages:  
>>>  
>>> - Some code needs to get the Class of the caller of the current method,  
>>> skipping any reflection methods.  
>>> - Some code needs to get the Class of the caller /n/ stack frames before  
>>> the current method, skipping any reflection methods.  
>>> - Some code needs to get the current stack trace, populated with Classes,  
>>> Executables, file names, line numbers, and native flags instead of the  
>>> String class names and String method names in StackTraceElement. This  
>>> /should/ include any reflection methods, just like StackTraceElement[]s.  
>>> - Some code needs to get the stack trace from when a Throwable was  
>>> created, populated with Classes, Executables, file names, line numbers, and  
>>> native flags instead of the String class names and String method names in  
>>> StackTraceElement. This /should/ include any reflection methods, just like  
>>> StackTraceElement[]s.  
>>> - There needs to be a reflection way to achieve all of this since some  
>>> libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and  
>>> 8 (and thus can't use @CallerSensitive).  
>>>  
>>> I believe the solutions to these needs are all related. Importantly, I  
>>> think it is very important that action be taken in Java 8 due to the changes  
>>> made to sun.reflect.Reflection#getCallerClass(...). While we all understand  
>>> that relying on private sun.* APIs is not safe, the fact is that many people  
>>> have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact  
>>> that there is simply no other way to do this in the standard API. This  
>>> includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will  
>>> stop working correctly in Java 7 >= u25.  
>>>  
>>> I would point out that this could all easily be solved simply by adding a  
>>> getElementClass() method to StackTraceElement, but there was strong  
>>> opposition to this, largely due to serialization issues. Since that is  
>>> apparently not an option, I propose the following API, based on the various  
>>> discussions in the last two months, StackTraceElement, and the API that .NET  
>>> provides to achieve the same needs as listed above:  
>>>  
>>> CallerSensitive.java:  
>>> package java.lang;  
>>>  
>>> /** Previously private API, now public */  
>>> public @interface CallerSensitive {  
>>> ...  
>>> }  
>>>  
>>> StackTraceFrame.java:  
>>> package java.lang;  
>>>  
>>> import java.util.Objects.  
>>>  
>>> public final class StackTraceFrame {  
>>> private final Class declaringClass;  
>>> private final Executable executable;  
>>> private final String fileName;  
>>> private final int lineNumber;  
>>>  
>>> public StackTraceFrame(Class declaringClass, Executable  
>>> executable, String fileName, int lineNumber) {  
>>> this.declaringClass = Objects.requireNonNull(declaringClass,  
>>> "Declaring class is null");  
>>> this.executable = Objects.requireNonNull(executable, "Executable  
>>> is null");  
>>> this.fileName = fileName;  
>>> this.lineNumber = lineNumber;  
>>> }  
>>>  
>>> public Class getDeclaringClass() {  
>>> return this.declaringClass;  
>>> }  
>>>  
>>> public Executable getExecutable() {  
>>> return this.executable;  
>>> }  
>>>  
>>> public String getFileName() {  
>>> return this.fileName;  
>>> }  
>>>  
>>> public int getLineNumber() {  
>>> return this.lineNumber;  
>>> }  
>>>  
>>> public boolean isNative() {  
>>> return this.lineNumber == -2;  
>>> }  
>>>  
>>> public String toString() { /* Same as StackTraceElement */ }  
>>> public boolean equals() { /* Ditto */ }  
>>> public int hashCode() { /* Ditto */ }  
>>>  
>>> /** Uses @CallerSensitive */  
>>> public static native StackTraceFrame getCallerFrame();  
>>>  
>>> /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass()  
>>> */  
>>> public static native StackTraceFrame getCallerFrame(int skipFrames);  
>>>  
>>> public static native StackTraceFrame[] getCurrentStackTrace();  
>>> }  
>>>  
>>> Throwable.java:  
>>> package java.lang;  
>>>  
>>> ...  
>>>  
>>> public class Throwable {  
>>> ...  
>>> public synchronized Throwable fillInStackTraceFrames() { ... }  
>>>  
>>> private native Throwable fillInStackTraceFrames(int dummy);  
>>>  
>>> public StackTraceFrame[] getStackTraceFrames() {  
>>> return this.getOurStackTraceFrames().clone();  
>>> }  
>>>  
>>> private synchronized StackTraceFrame[] getOurStackTraceFrames() {  
>>> ... }  
>>> ...  
>>> }  
>>>  
>>> Furthermore, I propose that we restore the behavior of  
>>> sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the  
>>> proposed above solution cannot be added to Java 7.  
>>>  
>>> I would love if we could quickly coalesce around this solution or a  
>>> derivative thereof so that it can be implemented before Feature Complete.  
>>> The absence of any replacement or alternative for  
>>> sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8  
>>> that will cause hardships for many projects.  
>>>  
>>> [1]  
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html  
>>> [2]  
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,  
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html  
>>> [3]  
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html  
>>  
>>  
>  
>  
> --  
> - DML


From jhuxhorn at googlemail.com  Mon Jul 29 15:53:48 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Mon, 29 Jul 2013 17:53:48 +0200
Subject: =?UTF-8?Q?Re=3A_Classes_on_the_stack_trace_(was=3A_getElementClass/StackTraceElement=2C_was=3A_=40CallerSensitive_public_API=2C_was=3A_sun.reflect.Reflection.getCallerClass)?=
In-Reply-To: 
References: 
Message-ID: 

+1

On 29. Juli 2013 at 15:50:36, Paul Benedict (pbenedict at apache.org) wrote:

If it is not possible in the remaining dev time for JDK8 to expose  
Reflection.getCallerClass() functionality through some public API, why must  
-Djdk.reflect.allowGetCallerClass be discontinued so soon? Why the hot  
potato? I don't see how impacting the many (most? or all?) open source  
logging libraries is a good idea.  

With the argument of "you shouldn't be using private sun.* classes" aside,  
it seriously needs to be evaulted rather causing such commotion is  
worthwhile. I would like Oracle to reconsider dropping the System property  
workaround until an API can be put in place.  

--  
Cheers,  
Paul


From sundararajan.athijegannathan at oracle.com  Mon Jul 29 16:10:35 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 29 Jul 2013 16:10:35 +0000
Subject: hg: jdk8/tl/jdk: 8021773: print function as defined by jrunscript's
	init.js script is incompatible with nashorn's definition
Message-ID: <20130729161123.A3A2548445@hg.openjdk.java.net>

Changeset: 24bda55fca48
Author:    sundar
Date:      2013-07-29 21:39 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24bda55fca48

8021773: print function as defined by jrunscript's init.js script is incompatible with nashorn's definition
Reviewed-by: hannesw, lagergren

! src/share/classes/com/sun/tools/script/shell/init.js



From maurizio.cimadamore at oracle.com  Mon Jul 29 16:21:18 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 29 Jul 2013 16:21:18 +0000
Subject: hg: jdk8/tl/langtools: 8021338: Diamond finder may mark a required
	type argument as unnecessary
Message-ID: <20130729162121.693DA48448@hg.openjdk.java.net>

Changeset: cd9e8cea1b3c
Author:    jlahoda
Date:      2013-07-28 10:17 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cd9e8cea1b3c

8021338: Diamond finder may mark a required type argument as unnecessary
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! test/tools/javac/generics/diamond/6939780/T6939780.java



From maurizio.cimadamore at oracle.com  Mon Jul 29 16:17:43 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 29 Jul 2013 16:17:43 +0000
Subject: hg: jdk8/tl/langtools: 8020689: Missing LineNumberTable entries in
	compiled class files
Message-ID: <20130729161746.5CB0548446@hg.openjdk.java.net>

Changeset: 8c4b2987edac
Author:    jlahoda
Date:      2013-07-28 10:17 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8c4b2987edac

8020689: Missing LineNumberTable entries in compiled class files
Reviewed-by: ksrini, mcimadamore

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/jvm/T8020689.java



From alexey.utkin at oracle.com  Mon Jul 29 17:06:27 2013
From: alexey.utkin at oracle.com (Alexey Utkin)
Date: Mon, 29 Jul 2013 21:06:27 +0400
Subject: Review request: JDK-8021245 (process) file leak in
	jdk/src/windows/native/java/lang/ProcessImpl_md.c
In-Reply-To: <51F55777.5050404@oracle.com>
References: <51F296CF.2050902@oracle.com> <51F55777.5050404@oracle.com>
Message-ID: <51F6A113.3090700@oracle.com>

Thanks, Alan

I did "if" reformatting and small refactoring for the code in function 
in accordance with
     https://jbs.oracle.com/bugs/browse/JDK-5008166
recommendations. I am sure that the presence of path separator has no 
dependence from search direction.

Here is the webrev:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8021245/webrev.01/

The fix was tested in the debugger.

Regards,
-uta

On 7/28/2013 9:40 PM, Alan Bateman wrote:
> On 26/07/2013 08:33, Alexey Utkin wrote:
>> Bug description:
>>     https://jbs.oracle.com/bugs/browse/JDK-8021245
>>     http://bugs.sun.com/view_bug.do?bug_id=8021245
>>
>> Here is the suggested fix:
>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8021245/webrev.00/
>>
>> Summary:
>> In accordance with MS spec [-1] is THE ONLY error signal from the 
>> [_open] function call.
>> http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx
>> Any negative, except [-1], and zero are the valid handles that need 
>> to be closed.
>>
>> The fix was tested in the debugger my manual switching to Win9x/WinMe 
>> brunch of execution.
> Checking if _open returns -1 and checking the return from _read and 
> _lseek/_read looks okay to me. My only comment is that the "if (" on 
> its own looks a bit odd, I just I would at least hoist the first part 
> of the expression onto the same line.
>
> -Alan.
>



From sundararajan.athijegannathan at oracle.com  Mon Jul 29 17:55:23 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 29 Jul 2013 17:55:23 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130729175526.51ED448454@hg.openjdk.java.net>

Changeset: 0532397d0732
Author:    sundar
Date:      2013-07-29 18:07 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0532397d0732

8012792: print function defined in engine.js does not handle multiple arguments
Reviewed-by: hannesw

! src/jdk/nashorn/api/scripting/resources/engine.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 7d5d24bdb671
Author:    sundar
Date:      2013-07-29 21:56 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7d5d24bdb671

Merge




From paul.sandoz at oracle.com  Mon Jul 29 18:12:59 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 29 Jul 2013 19:12:59 +0100
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: <51F67248.60308@oracle.com>
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
	<97903415-01F4-4FE2-B5F8-AFBF54217D32@oracle.com>
	<51F67248.60308@oracle.com>
Message-ID: <269E2F2E-82A6-4B20-A0ED-A605708A8FF5@oracle.com>

On Jul 29, 2013, at 2:46 PM, Chris Hegarty  wrote:
>> diff --git a/src/share/classes/java/util/Map.java b/src/share/classes/java/util/Map.java
>> --- a/src/share/classes/java/util/Map.java
>> +++ b/src/share/classes/java/util/Map.java
>> @@ -804,6 +804,10 @@
>>       *     return false;
>>       * }
>>       *
>> +     * @implNote The default implementation does not throw NullPointerException
>> +     * for maps that do not support null values if oldValue is null unless
>> +     * newValue is also null.
>> 
>> 
>> Is that really more a clarification of the default impl specification?
> 
> I thought implNote was to be used for default implementations, but it appears that it is implSpec?
> 

Correct, @implNote can be used for an implementation of anything not just a default implementation; it signals some non-normative stuff. Whereas @implSpec defines the behaviour for a particular implementation whose actual code could be implemented differently by another JDK implementation, it could equally apply to methods on classes too e.g. those abstract collection classes


>> 
>> 
>> -     * @throws NullPointerException if a specified key or value is null,
>> +     * @throws NullPointerException if a specified key or newValue is null,
>>       *         and this map does not permit null keys or values
>> +     * @throws NullPointerException if oldValue is null and this map does not
>> +     *         permit null values
>> +     *         (optional)
>> 
>> 
>> More curious than anything else, is it fine to have two declarations of NPE here?
> 
> Having two @throws looks a little strange to me. Putting it together???
> 
> * @throws NullPointerException if a specified key or newValue is null,
> *         and this map does not permit null keys or values. If
> *         oldValue is null and this map does not permit null values
> *         (optional).
> 
> Is this even right? Should the implNote not be part of the NPE throws?

It seems fine to state:

     * @throws NullPointerException if the specified key, newValue or oldValue is null,
     *         and this map does not permit null values (...)

And let the @implSpec refine things for the default implementation.


> Do you want replace to be used to put an initial value ( where previously unset (null) )?
> 

Not according to what is currently defined:

     * Replaces the entry for the specified key only if currently
     * mapped to the specified value.

Paul.



From peter.levart at gmail.com  Mon Jul 29 18:29:18 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 29 Jul 2013 20:29:18 +0200
Subject: class SplittableRandom
In-Reply-To: <480BCC80-2A9C-4321-B81B-47487E90C0D7@oracle.com>
References: <51DDB26D.8050506@cs.oswego.edu> <51DE6069.2060308@gmail.com>
	<51DEA230.2060504@cs.oswego.edu> <51DEA3D5.5000509@oracle.com>
	<51E1549D.4060403@cs.oswego.edu>
	
	<51E414C6.9070400@cs.oswego.edu>
	
	
	<6099D28A-0B95-42A4-A59B-5E1C465EDCA9@oracle.com>
	
	<480BCC80-2A9C-4321-B81B-47487E90C0D7@oracle.com>
Message-ID: <51F6B47E.1040102@gmail.com>


On 07/16/2013 06:01 PM, Guy Steele wrote:
> On Jul 16, 2013, at 3:07 AM, Martin Buchholz  wrote:
>> Read Appleby and Stafford ...
>>
>> Hmmm.... mix32 has almost the same job as mix64 - have all the bits in the seed affect all the bits in the output, so the obvious implementation is
>>
>> mix32() { return (int) mix64(); }
>> or more conservatively
>> mix32() { m = mix64(); return (int)m ^ (int)(m >>> 32); }
>> although it would be slightly distressing to have nextInt be more expensive than nextLong.
> Yes---at first I used exactly
>     mix32() { return (int) mix64(); }
> but was worried about the time it took, which is why I searched for a cheaper mixing function.
>
>> There might be some clever way of doing murmurhash-style mixing when the input is 64-bit and the output is 32-bit that can do better, but I don't think the current mix32 is it.
> Again, I was astonished that so simply a mixing function seemed to do the job as far as Dieharder is concerned.  I agree that it does appear to perform poorly for sparse gamma values.  So now the question is: do such sparse gamma values arise in practice?
>
> As Doug has pointed out, we carefully made the two-argument constructor private so that the user cannot specify gamma values.  The gamma values are derived only from the gamma-seed 0, using the gamma value GAMMA_GAMMA, and always running the seed through mix64.
>
> I wrote a little test (code and output below) to generate the first 16 billion (well, 2^34+1) gamma values actually generated and gather certain statistics:
> (1) the number of 1-bits in the gamma value (output of Long.bitCount)
> (2) the "width" of the gamma value (64 - Long.numberOfLeadingBits(gamma) - Long.numberOfTrailingBits(gamma))
> Then it histograms the bit counts, and for each possible bit count tracks the minimum width for gammas having that same bit count.
> Whenever the number of of gammas examined is one more than a power of 2, it prints a report consisting of those two tables and the min over the minwidth table.
>
> Here's a brief summary:
>
> For the first 65 gamma values, no gamma value has fewer than 21 1-bits or more than 41 1-bits.  The minimum width is 57.  So I predict there will be no weird mixing problems at all when using SplittableRandom to do a balanced split of a stream of generated randoms.
>
> For the first 2^16+1 = 65537 gamma values, the minimum bit count is 15, the maximum bit count is 50 and the minimum width is 45.
>
> For the first 2^24+1 gamma values, the minimum bit count is 12, the maximum bit count is 52 and the minimum width is 35.
>
> For the first 2^32+1 gamma values, the minimum bit count is 9, the maximum bit count is 55 and the minimum width is 28.
>
> For the first 2^34+1 gamma values, the minimum bit count is 8, the maximum bit count is 56 and the minimum width is 28.
>
> So I think we will not hit any really bad gamma values in practice.
>
> --Guy
>

Hi,

Would it be possible to skip gammas with less than 12 or more than 52 bits?

I did some playing with dieharder a week ago, testing SR.nextInt() 
(mix32) and indeed for sparse gamma values, all dieharder tests show 
failure. In particular test id=1 (diehard_operm5) is the least 
forgiving, requiring minimum gamma bit count being about 11 and maximum 
about 54 in order for such "random" gamma to produce nextInt() bit 
streams that pass the diehard_operm5 test. Here's a sample of the first 
3 dieharder tests (0,1 and 2) for differently sparsed "random" gammas:

https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextInt_results_0to2.txt

The alternative:

     public int nextIntAlt1() {
         return (int) mix64(nextSeed());
     }

... does not exhibit this weakness. It seems to be satisfied with gammas 
having as few as 1 or as many as 63 bits set to pass dieharder tests:

https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextIntAlt1_results_0to2.txt

But such nextInt is slower, approximately as fast as 
ThreadLocalRandom.nextInt() by my measurements.

Random streams created by SplittableRandom.nextLong() (mix64) also don't 
exhibit weaknesses with sparse gammas, so I thought why not using 
mix64() to produce 64 bits of randomness that is then returned by two 
consecutive calls to nextInt, like that:

     private int nextInt;
     private boolean nextIntZero;

     public int nextIntAlt2() {
         if (nextInt != 0) {
             int result = nextInt;
             nextInt = 0;
             return result;
         } else if (nextIntZero) {
             nextIntZero = false;
             return 0;
         } else {
             long nextLong = mix64(nextSeed());
             nextInt = (int)(nextLong >>> 32);
             if (nextInt == 0) nextIntZero = true;
             return (int)(nextLong & 0xFFFFFFFFL);
         }
     }

The (little-Indian) bitstream produced by nextIntAlt2() is exactly the 
same as that produced by nextLong() and 1st 3 dieharder tests pass with 
sparse gammas too:

https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextIntAlt2_results_0to2.txt

  the measurements produced by micro benchmark show performance 
somewhere between nextInt() and nextIntAlt1():

Benchmark                      Thr    Cnt  Sec         Mean Mean 
error          Var    Units
s.g.t.JmhTest.SR_nextInt         1      8    5 477779.670     1151.048   
865504.410 ops/msec
s.g.t.JmhTest.SR_nextIntAlt1     1      8    5 385630.764      513.779   
172439.034 ops/msec
s.g.t.JmhTest.SR_nextIntAlt2     1      8    5 432071.940      572.221   
213899.640 ops/msec
s.g.t.JmhTest.TLR_nextInt        1      8    5 382334.416       
28.907      545.871 ops/msec


Here's the JMH micro benchmark I used:

https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/sr/JmhTest.java


Here's the code I used to produce dieharder reports:

https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/sr/Test.java

which uses the following utility class to interface dieharder tool:

https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/si/pele/dieharder/DieharderTest.java


Regards, Peter



From paul.sandoz at oracle.com  Mon Jul 29 18:52:40 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 29 Jul 2013 18:52:40 +0000
Subject: hg: jdk8/tl/jdk: 8020156: TreeMap.values().spliterator() does not
	report ORDERED; ...
Message-ID: <20130729185304.6C75748456@hg.openjdk.java.net>

Changeset: e83fc6d9cf03
Author:    psandoz
Date:      2013-07-29 19:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e83fc6d9cf03

8020156: TreeMap.values().spliterator() does not report ORDERED
8020009: TreeMap.entrySet().spliterator() reports SORTED + null comparator but the elements are not Comparable
Reviewed-by: mduigou

! src/share/classes/java/util/TreeMap.java
+ test/java/util/Spliterator/SpliteratorCharacteristics.java



From nicholas+openjdk at nicholaswilliams.net  Mon Jul 29 19:03:08 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 29 Jul 2013 14:03:08 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: 
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
	
	
Message-ID: <4E98395F-FCBA-43CC-A479-90603FA3BBB0@nicholaswilliams.net>

Some interesting things to note:

1) Someone has been asking for a public API replacement for getCallerClass() since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I /would/ have been asking for this for that long, except I haven't needed it until recently and assumed it already existed. .NET has had an API similar to what I proposed below since .NET 1.1.

2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925 discusses the change to getCallerClass(int) and says it will be completely removed (with no system property to re-enable) as early as 7u55. The bug then talks about how feedback needs to be solicited on how the community is using it so that a public API, if needed, can be created. This is that feedback, and the answer appears to be a resounding YES, a public API needs to replace it because this change is disastrous for many projects. As Paul says, at the very least getCallerClass(int) should keep working like it does in <7u25 (with or without a system property) through the rest of Java 7 and Java 8 if a replacement public API is not adopted.

3) The performance test numbers below don't reflect the fact that some use cases (like Log4j) have to use Thread/Throwable#getStackTrace() AND Reflection/SecurityManager. These use cases need the method name/line number AND the Class instance. If Reflection#getCallerClass() is taken away from us and SecurityManager#getClassContext() is unavailable (possible if an existing SecurityManager prohibits instantiating the SecurityManager class), these use cases have to call getStackTrace() and THEN Class#forName() for each StackTraceElement. I'm sure you can see where performance becomes a serious issue at that point. The proposed API below was designed to solve all of the uses cases that have been discussed in a well-performing way.

Nick

On Jul 29, 2013, at 10:47 AM, J?rn Huxhorn wrote:

> The numbers are from this link: http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection
> 
> Even if this benchmark suffers from micro-benchmark issues:
> a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.
> 
> I'd suggest to at least postpone the UnsupportedOperationException change until we find a suitable replacement. This change will also break existing Groovy scripts. See http://jira.codehaus.org/browse/GROOVY-6279 - but there are other issues as well.
> 
> Cheers,
> J?rn.
> 
> On 29. Juli 2013 at 16:49:02, Nicholas Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
> 
> I wasn't the one who ran the test, so I don't know for sure. My theory  
> was that getCallerClass() returns a single frame, but the  
> SecurityManager must allocate an array of appropriate size (which  
> involves some overhead) and then return all of the frames. I chalked  
> the difference up to that. My conclusion from the data was: If you  
> need a whole stack, SecurityManager is clearly the best option. If you  
> need a single frame, getCallerClass() is the only option that makes  
> any sense.  
> 
> On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote:  
>> I find it very interesting that reflection is no less than two orders of  
>> magnitude faster than the security manager solution. How big was the stack  
>> in these tests? It makes me wonder if maybe the implementation of the  
>> security manager's getContext() method should be reevaluated a bit.  
>> 
>> 
>> On 07/29/2013 07:53 AM, Nick Williams wrote:  
>>> 
>>> Just so that everyone understands how important this subject is, this  
>>> change to getCallerClass(...) is being labeled a "disaster" for logging  
>>> frameworks everywhere. Here's a benchmark for getting Classes from the  
>>> following methods:  
>>> 
>>>> 1,000,000 calls of all alternatives were measured as follows :  
>>>> Reflection: 10.195 ms.  
>>>> Current Thread StackTrace: 5886.964 ms.  
>>>> Throwable StackTrace: 4700.073 ms.  
>>>> SecurityManager: 1046.804 ms.  
>>> 
>>> 
>>> My goal here is to get the entire list engaged in coming up with the right  
>>> solution. We (the community) can't afford for Java 8 not to have an  
>>> equivalent replacement for getCallerClass().  
>>> 
>>> Nick  
>>> 
>>> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:  
>>> 
>>>> All,  
>>>> 
>>>> In the last two months, there have been a number of discussions  
>>>> surrounding stack traces, Classes on the stack trace, and caller classes  
>>>> [1], [2], [3]. These are all related discussions and the solution to them is  
>>>> equally related, so I wanted to consolidate it all into this one discussion  
>>>> where I hope we can finalize on a solution and get it implemented for Java  
>>>> 8.  
>>>> 
>>>> In a nut shell, here are the underlying needs that I have seen expressed  
>>>> through many, many messages:  
>>>> 
>>>> - Some code needs to get the Class of the caller of the current method,  
>>>> skipping any reflection methods.  
>>>> - Some code needs to get the Class of the caller /n/ stack frames before  
>>>> the current method, skipping any reflection methods.  
>>>> - Some code needs to get the current stack trace, populated with Classes,  
>>>> Executables, file names, line numbers, and native flags instead of the  
>>>> String class names and String method names in StackTraceElement. This  
>>>> /should/ include any reflection methods, just like StackTraceElement[]s.  
>>>> - Some code needs to get the stack trace from when a Throwable was  
>>>> created, populated with Classes, Executables, file names, line numbers, and  
>>>> native flags instead of the String class names and String method names in  
>>>> StackTraceElement. This /should/ include any reflection methods, just like  
>>>> StackTraceElement[]s.  
>>>> - There needs to be a reflection way to achieve all of this since some  
>>>> libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and  
>>>> 8 (and thus can't use @CallerSensitive).  
>>>> 
>>>> I believe the solutions to these needs are all related. Importantly, I  
>>>> think it is very important that action be taken in Java 8 due to the changes  
>>>> made to sun.reflect.Reflection#getCallerClass(...). While we all understand  
>>>> that relying on private sun.* APIs is not safe, the fact is that many people  
>>>> have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact  
>>>> that there is simply no other way to do this in the standard API. This  
>>>> includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will  
>>>> stop working correctly in Java 7 >= u25.  
>>>> 
>>>> I would point out that this could all easily be solved simply by adding a  
>>>> getElementClass() method to StackTraceElement, but there was strong  
>>>> opposition to this, largely due to serialization issues. Since that is  
>>>> apparently not an option, I propose the following API, based on the various  
>>>> discussions in the last two months, StackTraceElement, and the API that .NET  
>>>> provides to achieve the same needs as listed above:  
>>>> 
>>>> CallerSensitive.java:  
>>>> package java.lang;  
>>>> 
>>>> /** Previously private API, now public */  
>>>> public @interface CallerSensitive {  
>>>> ...  
>>>> }  
>>>> 
>>>> StackTraceFrame.java:  
>>>> package java.lang;  
>>>> 
>>>> import java.util.Objects.  
>>>> 
>>>> public final class StackTraceFrame {  
>>>> private final Class declaringClass;  
>>>> private final Executable executable;  
>>>> private final String fileName;  
>>>> private final int lineNumber;  
>>>> 
>>>> public StackTraceFrame(Class declaringClass, Executable  
>>>> executable, String fileName, int lineNumber) {  
>>>> this.declaringClass = Objects.requireNonNull(declaringClass,  
>>>> "Declaring class is null");  
>>>> this.executable = Objects.requireNonNull(executable, "Executable  
>>>> is null");  
>>>> this.fileName = fileName;  
>>>> this.lineNumber = lineNumber;  
>>>> }  
>>>> 
>>>> public Class getDeclaringClass() {  
>>>> return this.declaringClass;  
>>>> }  
>>>> 
>>>> public Executable getExecutable() {  
>>>> return this.executable;  
>>>> }  
>>>> 
>>>> public String getFileName() {  
>>>> return this.fileName;  
>>>> }  
>>>> 
>>>> public int getLineNumber() {  
>>>> return this.lineNumber;  
>>>> }  
>>>> 
>>>> public boolean isNative() {  
>>>> return this.lineNumber == -2;  
>>>> }  
>>>> 
>>>> public String toString() { /* Same as StackTraceElement */ }  
>>>> public boolean equals() { /* Ditto */ }  
>>>> public int hashCode() { /* Ditto */ }  
>>>> 
>>>> /** Uses @CallerSensitive */  
>>>> public static native StackTraceFrame getCallerFrame();  
>>>> 
>>>> /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass()  
>>>> */  
>>>> public static native StackTraceFrame getCallerFrame(int skipFrames);  
>>>> 
>>>> public static native StackTraceFrame[] getCurrentStackTrace();  
>>>> }  
>>>> 
>>>> Throwable.java:  
>>>> package java.lang;  
>>>> 
>>>> ...  
>>>> 
>>>> public class Throwable {  
>>>> ...  
>>>> public synchronized Throwable fillInStackTraceFrames() { ... }  
>>>> 
>>>> private native Throwable fillInStackTraceFrames(int dummy);  
>>>> 
>>>> public StackTraceFrame[] getStackTraceFrames() {  
>>>> return this.getOurStackTraceFrames().clone();  
>>>> }  
>>>> 
>>>> private synchronized StackTraceFrame[] getOurStackTraceFrames() {  
>>>> ... }  
>>>> ...  
>>>> }  
>>>> 
>>>> Furthermore, I propose that we restore the behavior of  
>>>> sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the  
>>>> proposed above solution cannot be added to Java 7.  
>>>> 
>>>> I would love if we could quickly coalesce around this solution or a  
>>>> derivative thereof so that it can be implemented before Feature Complete.  
>>>> The absence of any replacement or alternative for  
>>>> sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8  
>>>> that will cause hardships for many projects.  
>>>> 
>>>> [1]  
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html  
>>>> [2]  
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,  
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html  
>>>> [3]  
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html  
>>> 
>>> 
>> 
>> 
>> --  
>> - DML



From brent.christian at oracle.com  Mon Jul 29 19:54:08 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 29 Jul 2013 12:54:08 -0700
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: <51F5FA02.9020909@oracle.com>
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
Message-ID: <51F6C860.4020000@oracle.com>

On 7/28/13 10:13 PM, David Holmes wrote:
> On 27/07/2013 3:53 AM, Brent Christian wrote:
>> Please review my fix for 8011194 : "Apps launched via double-clicked
>> .jars have file.encoding value of US-ASCII on Mac OS X"
>>
>> http://bugs.sun.com/view_bug.do?bug_id=8011194
>>
>> In most cases of launching a Java app on Mac (from the cmdline, or from
>> a native .app bundle), reading and displaying UTF-8 characters beyond
>> the standard ASCII range works fine.
>>
>> A notable exception is the launching of an app by double-clicking a .jar
>> file.  In this case, file.encoding defaults to US-ASCII, and characters
>> outside of the ASCII range show up as garbage.
>
> Why does this occur? What sets the encoding to US-ASCII?

"US-ASCII" is the answer we get from nl_langinfo(CODESET) because no 
values for LANG/LC* are set in the environment when double-clicking a .jar.

We get "UTF-8" when launching from the command line because the default 
Terminal.app setup on Mac will setup LANG for you (to "en_US.UTF-8" in 
the US).

-Brent


From brian.burkhalter at oracle.com  Mon Jul 29 20:06:47 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 29 Jul 2013 13:06:47 -0700
Subject: Java 8 RFR 8020539: Clean up doclint problems in java.util
	package, part 2
In-Reply-To: <51F6142A.2080201@oracle.com>
References: <50FE640E-DC42-47F2-9FAD-8472A013EB9B@oracle.com>
	
	
	<51E77802.8070001@oracle.com>
	<67232DB5-4077-4A4D-9729-B06C7FD911BF@oracle.com>
	<51F6142A.2080201@oracle.com>
Message-ID: 

Joe / Chris:

The updated webrev is in the same place, http://cr.openjdk.java.net/~bpb/8020539/

If this looks good I will need an approval.

On Jul 29, 2013, at 12:05 AM, Joe Darcy wrote:

> I recommend a few changes here:
> 
> * For readability, rename "NonASCIIDigit" as "NonAsciiDigit"

Changed.

> * Since Scanner is in the regex package, it may be more appropriate to stick more of a regex notation than an ebnf notation, but keeping the definition list structure tags.

Changed back to regex notation.

>> 
>>> Offhand, I wasn't aware Dequeue and Queue were maintained in Doug's CVS, but I agree changes to those files should flow through there first.
>> Deque and Queue removed from the webrev:
>> 
>> http://cr.openjdk.java.net/~bpb/8020539/
>> 
> 
> Otherwise, the changes look fine. If you like, the non-Scanner changes can be split out and pushed first.


I've left it as one changeset.

On Jul 29, 2013, at 2:43 AM, Chris Hegarty wrote:

> Looks fine ( I did not go through the Scanner changes ).
> 
> Some minor comments:
> 
> 1) List
>   Trivially I wonder why you decided to go with '< '>', rather
>   than {@code ... }, which I think is more readable.

Changed.

> 2) Map
>   Trivially, I would keep the @param's order the same as the actual
>   method parameters order.

Changed.

> 3) Optional
>   Strangely, there doesn't appear to be a '@param' for the class level
>   type T. doclint is not warning about this either.


Not changed.

Thanks,

Brian

From jhuxhorn at googlemail.com  Mon Jul 29 20:57:31 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Mon, 29 Jul 2013 22:57:31 +0200
Subject: =?UTF-8?Q?Re=3A_Classes_on_the_stack_trace_(was=3A_getElementClass/StackTraceElement=2C_was=3A_=40CallerSensitive_public_API=2C_was=3A_sun.reflect.Reflection.getCallerClass)?=
In-Reply-To: <4E98395F-FCBA-43CC-A479-90603FA3BBB0@nicholaswilliams.net>
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
	
	
	<4E98395F-FCBA-43CC-A479-90603FA3BBB0@nicholaswilliams.net>
Message-ID: 

I second all of that.

It was my understanding that the whole purpose of EA and DP was pinpointing problems like these before they hit consumers. What's the point of them if feedback can't cause the reverting of a breaking change?

If this is not rectified then the old "Java is slow"-mantra will once again be quite true.
That, and lots of applications will break since not everyone updating to j7u40 will also update all libraries that currently depend on that method - if a timely fix will exist at all at that point. Throwing UnsupportedOperationException all of a sudden isn't exactly the most subtle way of handling this.

And please don't argue that everyone should just add that runtime property. This isn't realistic.
On 29. Juli 2013 at 21:03:10, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:

Some interesting things to note:

1) Someone has been asking for a public API replacement for getCallerClass() since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I /would/ have been asking for this for that long, except I haven't needed it until recently and assumed it already existed. .NET has had an API similar to what I proposed below since .NET 1.1.

2)?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925?discusses the change to getCallerClass(int) and says it will be completely removed (with no system property to re-enable) as early as 7u55. The bug then talks about how feedback needs to be solicited on how the community is using it so that a public API, if needed, can be created. This is that feedback, and the answer appears to be a resounding YES, a public API needs to replace it because this change is disastrous for many projects. As Paul says, at the very least getCallerClass(int) should keep working like it does in <7u25 (with or without a system property) through the rest of Java 7 and Java 8 if a replacement public API is not adopted.

3) The performance test numbers below don't reflect the fact that some use cases (like Log4j) have to use Thread/Throwable#getStackTrace() AND Reflection/SecurityManager. These use cases need the method name/line number AND the Class instance. If Reflection#getCallerClass() is taken away from us and SecurityManager#getClassContext() is unavailable (possible if an existing SecurityManager prohibits instantiating the SecurityManager class), these use cases have to call getStackTrace() and THEN Class#forName() for each StackTraceElement. I'm sure you can see where performance becomes a serious issue at that point. The proposed API below was designed to solve all of the uses cases that have been discussed in a well-performing way.

Nick

On Jul 29, 2013, at 10:47 AM, J?rn Huxhorn wrote:

The numbers are from this link:?http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection

Even if this benchmark suffers from micro-benchmark issues:
a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.

I'd suggest to at least postpone the UnsupportedOperationException change until we find a suitable replacement. This change will also break existing Groovy scripts. See?http://jira.codehaus.org/browse/GROOVY-6279?- but there are other issues as well.

Cheers,
J?rn.

On 29. Juli 2013 at 16:49:02, Nicholas Williams (nicholas+openjdk at nicholaswilliams.net) wrote:

I wasn't the one who ran the test, so I don't know for sure. My theory ?
was that getCallerClass() returns a single frame, but the ?
SecurityManager must allocate an array of appropriate size (which ?
involves some overhead) and then return all of the frames. I chalked ?
the difference up to that. My conclusion from the data was: If you ?
need a whole stack, SecurityManager is clearly the best option. If you ?
need a single frame, getCallerClass() is the only option that makes ?
any sense. ?

On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote: ?
I find it very interesting that reflection is no less than two orders of ?
magnitude faster than the security manager solution. How big was the stack ?
in these tests? It makes me wonder if maybe the implementation of the ?
security manager's getContext() method should be reevaluated a bit. ?


On 07/29/2013 07:53 AM, Nick Williams wrote: ?

Just so that everyone understands how important this subject is, this ?
change to getCallerClass(...) is being labeled a "disaster" for logging ?
frameworks everywhere. Here's a benchmark for getting Classes from the ?
following methods: ?

1,000,000 calls of all alternatives were measured as follows : ?
Reflection: 10.195 ms. ?
Current Thread StackTrace: 5886.964 ms. ?
Throwable StackTrace: 4700.073 ms. ?
SecurityManager: 1046.804 ms. ?


My goal here is to get the entire list engaged in coming up with the right ?
solution. We (the community) can't afford for Java 8 not to have an ?
equivalent replacement for getCallerClass(). ?

Nick ?

On Jul 27, 2013, at 2:01 PM, Nick Williams wrote: ?

All, ?

In the last two months, there have been a number of discussions ?
surrounding stack traces, Classes on the stack trace, and caller classes ?
[1], [2], [3]. These are all related discussions and the solution to them is ?
equally related, so I wanted to consolidate it all into this one discussion ?
where I hope we can finalize on a solution and get it implemented for Java ?
8. ?

In a nut shell, here are the underlying needs that I have seen expressed ?
through many, many messages: ?

- Some code needs to get the Class of the caller of the current method, ?
skipping any reflection methods. ?
- Some code needs to get the Class of the caller /n/ stack frames before ?
the current method, skipping any reflection methods. ?
- Some code needs to get the current stack trace, populated with Classes, ?
Executables, file names, line numbers, and native flags instead of the ?
String class names and String method names in StackTraceElement. This ?
/should/ include any reflection methods, just like StackTraceElement[]s. ?
- Some code needs to get the stack trace from when a Throwable was ?
created, populated with Classes, Executables, file names, line numbers, and ?
native flags instead of the String class names and String method names in ?
StackTraceElement. This /should/ include any reflection methods, just like ?
StackTraceElement[]s. ?
- There needs to be a reflection way to achieve all of this since some ?
libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and ?
8 (and thus can't use @CallerSensitive). ?

I believe the solutions to these needs are all related. Importantly, I ?
think it is very important that action be taken in Java 8 due to the changes ?
made to sun.reflect.Reflection#getCallerClass(...). While we all understand ?
that relying on private sun.* APIs is not safe, the fact is that many people ?
have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact ?
that there is simply no other way to do this in the standard API. This ?
includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will ?
stop working correctly in Java 7 >= u25. ?

I would point out that this could all easily be solved simply by adding a ?
getElementClass() method to StackTraceElement, but there was strong ?
opposition to this, largely due to serialization issues. Since that is ?
apparently not an option, I propose the following API, based on the various ?
discussions in the last two months, StackTraceElement, and the API that .NET ?
provides to achieve the same needs as listed above: ?

CallerSensitive.java: ?
package java.lang; ?

/** Previously private API, now public */ ?
public @interface CallerSensitive { ?
... ?
} ?

StackTraceFrame.java: ?
package java.lang; ?

import java.util.Objects. ?

public final class StackTraceFrame { ?
private final Class declaringClass; ?
private final Executable executable; ?
private final String fileName; ?
private final int lineNumber; ?

public StackTraceFrame(Class declaringClass, Executable ?
executable, String fileName, int lineNumber) { ?
this.declaringClass = Objects.requireNonNull(declaringClass, ?
"Declaring class is null"); ?
this.executable = Objects.requireNonNull(executable, "Executable ?
is null"); ?
this.fileName = fileName; ?
this.lineNumber = lineNumber; ?
} ?

public Class getDeclaringClass() { ?
return this.declaringClass; ?
} ?

public Executable getExecutable() { ?
return this.executable; ?
} ?

public String getFileName() { ?
return this.fileName; ?
} ?

public int getLineNumber() { ?
return this.lineNumber; ?
} ?

public boolean isNative() { ?
return this.lineNumber == -2; ?
} ?

public String toString() { /* Same as StackTraceElement */ } ?
public boolean equals() { /* Ditto */ } ?
public int hashCode() { /* Ditto */ } ?

/** Uses @CallerSensitive */ ?
public static native StackTraceFrame getCallerFrame(); ?

/** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() ?
*/ ?
public static native StackTraceFrame getCallerFrame(int skipFrames); ?

public static native StackTraceFrame[] getCurrentStackTrace(); ?
} ?

Throwable.java: ?
package java.lang; ?

... ?

public class Throwable { ?
... ?
public synchronized Throwable fillInStackTraceFrames() { ... } ?

private native Throwable fillInStackTraceFrames(int dummy); ?

public StackTraceFrame[] getStackTraceFrames() { ?
return this.getOurStackTraceFrames().clone(); ?
} ?

private synchronized StackTraceFrame[] getOurStackTraceFrames() { ?
... } ?
... ?
} ?

Furthermore, I propose that we restore the behavior of ?
sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the ?
proposed above solution cannot be added to Java 7. ?

I would love if we could quickly coalesce around this solution or a ?
derivative thereof so that it can be implemented before Feature Complete. ?
The absence of any replacement or alternative for ?
sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 ?
that will cause hardships for many projects. ?

[1] ?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html ?
[2] ?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, ?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html ?
[3] ?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html ?




-- ?
- DML


From jason.uh at oracle.com  Mon Jul 29 21:31:49 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Mon, 29 Jul 2013 21:31:49 +0000
Subject: hg: jdk8/tl/jdk: 8012971: PKCS11Test hiding exception failures
Message-ID: <20130729213215.976924845E@hg.openjdk.java.net>

Changeset: c042fd498f79
Author:    ascarpino
Date:      2013-07-19 11:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c042fd498f79

8012971: PKCS11Test hiding exception failures
Reviewed-by: vinnie, valeriep

! test/ProblemList.txt
! test/sun/security/pkcs11/PKCS11Test.java
! test/sun/security/pkcs11/SecmodTest.java



From jason.uh at oracle.com  Mon Jul 29 21:33:20 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Mon, 29 Jul 2013 21:33:20 +0000
Subject: hg: jdk8/tl/jdk: 8020424: The NSS version should be detected before
	running crypto tests
Message-ID: <20130729213332.186E64845F@hg.openjdk.java.net>

Changeset: e47569593fa0
Author:    ascarpino
Date:      2013-07-29 13:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e47569593fa0

8020424: The NSS version should be detected before running crypto tests
Reviewed-by: valeriep

! test/ProblemList.txt
! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java
! test/sun/security/pkcs11/PKCS11Test.java
+ test/sun/security/pkcs11/README
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/TestCurves.java
! test/sun/security/pkcs11/ec/TestECDH.java
! test/sun/security/pkcs11/ec/TestECDH2.java
! test/sun/security/pkcs11/ec/TestECDSA.java
! test/sun/security/pkcs11/ec/TestECDSA2.java
! test/sun/security/pkcs11/ec/TestECGenSpec.java
! test/sun/security/pkcs11/ec/TestKeyFactory.java



From david.lloyd at redhat.com  Mon Jul 29 21:59:09 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 29 Jul 2013 16:59:09 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: 
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
	
	
	<4E98395F-FCBA-43CC-A479-90603FA3BBB0@nicholaswilliams.net>
	
Message-ID: <51F6E5AD.6030802@redhat.com>

I expect that at this stage, patches speak louder than words :)

On 07/29/2013 03:57 PM, J?rn Huxhorn wrote:
> I second all of that.
>
> It was my understanding that the whole purpose of EA and DP was pinpointing problems like these before they hit consumers. What's the point of them if feedback can't cause the reverting of a breaking change?
>
> If this is not rectified then the old "Java is slow"-mantra will once again be quite true.
> That, and lots of applications will break since not everyone updating to j7u40 will also update all libraries that currently depend on that method - if a timely fix will exist at all at that point. Throwing UnsupportedOperationException all of a sudden isn't exactly the most subtle way of handling this.
>
> And please don't argue that everyone should just add that runtime property. This isn't realistic.
> On 29. Juli 2013 at 21:03:10, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>
> Some interesting things to note:
>
> 1) Someone has been asking for a public API replacement for getCallerClass() since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I /would/ have been asking for this for that long, except I haven't needed it until recently and assumed it already existed. .NET has had an API similar to what I proposed below since .NET 1.1.
>
> 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925 discusses the change to getCallerClass(int) and says it will be completely removed (with no system property to re-enable) as early as 7u55. The bug then talks about how feedback needs to be solicited on how the community is using it so that a public API, if needed, can be created. This is that feedback, and the answer appears to be a resounding YES, a public API needs to replace it because this change is disastrous for many projects. As Paul says, at the very least getCallerClass(int) should keep working like it does in <7u25 (with or without a system property) through the rest of Java 7 and Java 8 if a replacement public API is not adopted.
>
> 3) The performance test numbers below don't reflect the fact that some use cases (like Log4j) have to use Thread/Throwable#getStackTrace() AND Reflection/SecurityManager. These use cases need the method name/line number AND the Class instance. If Reflection#getCallerClass() is taken away from us and SecurityManager#getClassContext() is unavailable (possible if an existing SecurityManager prohibits instantiating the SecurityManager class), these use cases have to call getStackTrace() and THEN Class#forName() for each StackTraceElement. I'm sure you can see where performance becomes a serious issue at that point. The proposed API below was designed to solve all of the uses cases that have been discussed in a well-performing way.
>
> Nick
>
> On Jul 29, 2013, at 10:47 AM, J?rn Huxhorn wrote:
>
> The numbers are from this link: http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection
>
> Even if this benchmark suffers from micro-benchmark issues:
> a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.
>
> I'd suggest to at least postpone the UnsupportedOperationException change until we find a suitable replacement. This change will also break existing Groovy scripts. See http://jira.codehaus.org/browse/GROOVY-6279 - but there are other issues as well.
>
> Cheers,
> J?rn.
>
> On 29. Juli 2013 at 16:49:02, Nicholas Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>
> I wasn't the one who ran the test, so I don't know for sure. My theory
> was that getCallerClass() returns a single frame, but the
> SecurityManager must allocate an array of appropriate size (which
> involves some overhead) and then return all of the frames. I chalked
> the difference up to that. My conclusion from the data was: If you
> need a whole stack, SecurityManager is clearly the best option. If you
> need a single frame, getCallerClass() is the only option that makes
> any sense.
>
> On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote:
> I find it very interesting that reflection is no less than two orders of
> magnitude faster than the security manager solution. How big was the stack
> in these tests? It makes me wonder if maybe the implementation of the
> security manager's getContext() method should be reevaluated a bit.
>
>
> On 07/29/2013 07:53 AM, Nick Williams wrote:
>
> Just so that everyone understands how important this subject is, this
> change to getCallerClass(...) is being labeled a "disaster" for logging
> frameworks everywhere. Here's a benchmark for getting Classes from the
> following methods:
>
> 1,000,000 calls of all alternatives were measured as follows :
> Reflection: 10.195 ms.
> Current Thread StackTrace: 5886.964 ms.
> Throwable StackTrace: 4700.073 ms.
> SecurityManager: 1046.804 ms.
>
>
> My goal here is to get the entire list engaged in coming up with the right
> solution. We (the community) can't afford for Java 8 not to have an
> equivalent replacement for getCallerClass().
>
> Nick
>
> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:
>
> All,
>
> In the last two months, there have been a number of discussions
> surrounding stack traces, Classes on the stack trace, and caller classes
> [1], [2], [3]. These are all related discussions and the solution to them is
> equally related, so I wanted to consolidate it all into this one discussion
> where I hope we can finalize on a solution and get it implemented for Java
> 8.
>
> In a nut shell, here are the underlying needs that I have seen expressed
> through many, many messages:
>
> - Some code needs to get the Class of the caller of the current method,
> skipping any reflection methods.
> - Some code needs to get the Class of the caller /n/ stack frames before
> the current method, skipping any reflection methods.
> - Some code needs to get the current stack trace, populated with Classes,
> Executables, file names, line numbers, and native flags instead of the
> String class names and String method names in StackTraceElement. This
> /should/ include any reflection methods, just like StackTraceElement[]s.
> - Some code needs to get the stack trace from when a Throwable was
> created, populated with Classes, Executables, file names, line numbers, and
> native flags instead of the String class names and String method names in
> StackTraceElement. This /should/ include any reflection methods, just like
> StackTraceElement[]s.
> - There needs to be a reflection way to achieve all of this since some
> libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and
> 8 (and thus can't use @CallerSensitive).
>
> I believe the solutions to these needs are all related. Importantly, I
> think it is very important that action be taken in Java 8 due to the changes
> made to sun.reflect.Reflection#getCallerClass(...). While we all understand
> that relying on private sun.* APIs is not safe, the fact is that many people
> have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact
> that there is simply no other way to do this in the standard API. This
> includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will
> stop working correctly in Java 7 >= u25.
>
> I would point out that this could all easily be solved simply by adding a
> getElementClass() method to StackTraceElement, but there was strong
> opposition to this, largely due to serialization issues. Since that is
> apparently not an option, I propose the following API, based on the various
> discussions in the last two months, StackTraceElement, and the API that .NET
> provides to achieve the same needs as listed above:
>
> CallerSensitive.java:
> package java.lang;
>
> /** Previously private API, now public */
> public @interface CallerSensitive {
> ...
> }
>
> StackTraceFrame.java:
> package java.lang;
>
> import java.util.Objects.
>
> public final class StackTraceFrame {
> private final Class declaringClass;
> private final Executable executable;
> private final String fileName;
> private final int lineNumber;
>
> public StackTraceFrame(Class declaringClass, Executable
> executable, String fileName, int lineNumber) {
> this.declaringClass = Objects.requireNonNull(declaringClass,
> "Declaring class is null");
> this.executable = Objects.requireNonNull(executable, "Executable
> is null");
> this.fileName = fileName;
> this.lineNumber = lineNumber;
> }
>
> public Class getDeclaringClass() {
> return this.declaringClass;
> }
>
> public Executable getExecutable() {
> return this.executable;
> }
>
> public String getFileName() {
> return this.fileName;
> }
>
> public int getLineNumber() {
> return this.lineNumber;
> }
>
> public boolean isNative() {
> return this.lineNumber == -2;
> }
>
> public String toString() { /* Same as StackTraceElement */ }
> public boolean equals() { /* Ditto */ }
> public int hashCode() { /* Ditto */ }
>
> /** Uses @CallerSensitive */
> public static native StackTraceFrame getCallerFrame();
>
> /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass()
> */
> public static native StackTraceFrame getCallerFrame(int skipFrames);
>
> public static native StackTraceFrame[] getCurrentStackTrace();
> }
>
> Throwable.java:
> package java.lang;
>
> ...
>
> public class Throwable {
> ...
> public synchronized Throwable fillInStackTraceFrames() { ... }
>
> private native Throwable fillInStackTraceFrames(int dummy);
>
> public StackTraceFrame[] getStackTraceFrames() {
> return this.getOurStackTraceFrames().clone();
> }
>
> private synchronized StackTraceFrame[] getOurStackTraceFrames() {
> ... }
> ...
> }
>
> Furthermore, I propose that we restore the behavior of
> sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the
> proposed above solution cannot be added to Java 7.
>
> I would love if we could quickly coalesce around this solution or a
> derivative thereof so that it can be implemented before Feature Complete.
> The absence of any replacement or alternative for
> sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8
> that will cause hardships for many projects.
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
> [2]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
> [3]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>
>
>
>
> --
> - DML
>


-- 
- DML


From nicholas+openjdk at nicholaswilliams.net  Mon Jul 29 22:16:46 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 29 Jul 2013 17:16:46 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F6E5AD.6030802@redhat.com>
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
	
	
	<4E98395F-FCBA-43CC-A479-90603FA3BBB0@nicholaswilliams.net>
	
	<51F6E5AD.6030802@redhat.com>
Message-ID: <5C6626B4-347B-48BC-AC80-9D632FC9DC7B@nicholaswilliams.net>

I would happily contribute a patch if I were able to. However, I have almost no idea what I'm doing on the native side, and I spent three hours perusing the Mercurial repository and still can't figure out where anything is.

Even so, I would be willing to try. But I can't just blindly make up a patch. I need some kind of guidance as to what you're looking for. Is the API I propose below acceptable? If I propose a patch implementing that API /and it is generally accepted as correct/ is it going to be accepted? Or am I going to spend significant time trying to figure it out with the possibility that it might be rejected merely because of the API.

My goal in this email was to get the community to coalesce around an API. Once that happens, if nobody more qualified than I is willing or has time to implement it I will surely give it a try. But I don't want the start working on something that the community is going to reject, especially having not received any feedback on this API so far.

Nick

On Jul 29, 2013, at 4:59 PM, David M. Lloyd wrote:

> I expect that at this stage, patches speak louder than words :)
> 
> On 07/29/2013 03:57 PM, J?rn Huxhorn wrote:
>> I second all of that.
>> 
>> It was my understanding that the whole purpose of EA and DP was pinpointing problems like these before they hit consumers. What's the point of them if feedback can't cause the reverting of a breaking change?
>> 
>> If this is not rectified then the old "Java is slow"-mantra will once again be quite true.
>> That, and lots of applications will break since not everyone updating to j7u40 will also update all libraries that currently depend on that method - if a timely fix will exist at all at that point. Throwing UnsupportedOperationException all of a sudden isn't exactly the most subtle way of handling this.
>> 
>> And please don't argue that everyone should just add that runtime property. This isn't realistic.
>> On 29. Juli 2013 at 21:03:10, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>> 
>> Some interesting things to note:
>> 
>> 1) Someone has been asking for a public API replacement for getCallerClass() since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I /would/ have been asking for this for that long, except I haven't needed it until recently and assumed it already existed. .NET has had an API similar to what I proposed below since .NET 1.1.
>> 
>> 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925 discusses the change to getCallerClass(int) and says it will be completely removed (with no system property to re-enable) as early as 7u55. The bug then talks about how feedback needs to be solicited on how the community is using it so that a public API, if needed, can be created. This is that feedback, and the answer appears to be a resounding YES, a public API needs to replace it because this change is disastrous for many projects. As Paul says, at the very least getCallerClass(int) should keep working like it does in <7u25 (with or without a system property) through the rest of Java 7 and Java 8 if a replacement public API is not adopted.
>> 
>> 3) The performance test numbers below don't reflect the fact that some use cases (like Log4j) have to use Thread/Throwable#getStackTrace() AND Reflection/SecurityManager. These use cases need the method name/line number AND the Class instance. If Reflection#getCallerClass() is taken away from us and SecurityManager#getClassContext() is unavailable (possible if an existing SecurityManager prohibits instantiating the SecurityManager class), these use cases have to call getStackTrace() and THEN Class#forName() for each StackTraceElement. I'm sure you can see where performance becomes a serious issue at that point. The proposed API below was designed to solve all of the uses cases that have been discussed in a well-performing way.
>> 
>> Nick
>> 
>> On Jul 29, 2013, at 10:47 AM, J?rn Huxhorn wrote:
>> 
>> The numbers are from this link: http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection
>> 
>> Even if this benchmark suffers from micro-benchmark issues:
>> a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.
>> 
>> I'd suggest to at least postpone the UnsupportedOperationException change until we find a suitable replacement. This change will also break existing Groovy scripts. See http://jira.codehaus.org/browse/GROOVY-6279 - but there are other issues as well.
>> 
>> Cheers,
>> J?rn.
>> 
>> On 29. Juli 2013 at 16:49:02, Nicholas Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>> 
>> I wasn't the one who ran the test, so I don't know for sure. My theory
>> was that getCallerClass() returns a single frame, but the
>> SecurityManager must allocate an array of appropriate size (which
>> involves some overhead) and then return all of the frames. I chalked
>> the difference up to that. My conclusion from the data was: If you
>> need a whole stack, SecurityManager is clearly the best option. If you
>> need a single frame, getCallerClass() is the only option that makes
>> any sense.
>> 
>> On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote:
>> I find it very interesting that reflection is no less than two orders of
>> magnitude faster than the security manager solution. How big was the stack
>> in these tests? It makes me wonder if maybe the implementation of the
>> security manager's getContext() method should be reevaluated a bit.
>> 
>> 
>> On 07/29/2013 07:53 AM, Nick Williams wrote:
>> 
>> Just so that everyone understands how important this subject is, this
>> change to getCallerClass(...) is being labeled a "disaster" for logging
>> frameworks everywhere. Here's a benchmark for getting Classes from the
>> following methods:
>> 
>> 1,000,000 calls of all alternatives were measured as follows :
>> Reflection: 10.195 ms.
>> Current Thread StackTrace: 5886.964 ms.
>> Throwable StackTrace: 4700.073 ms.
>> SecurityManager: 1046.804 ms.
>> 
>> 
>> My goal here is to get the entire list engaged in coming up with the right
>> solution. We (the community) can't afford for Java 8 not to have an
>> equivalent replacement for getCallerClass().
>> 
>> Nick
>> 
>> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:
>> 
>> All,
>> 
>> In the last two months, there have been a number of discussions
>> surrounding stack traces, Classes on the stack trace, and caller classes
>> [1], [2], [3]. These are all related discussions and the solution to them is
>> equally related, so I wanted to consolidate it all into this one discussion
>> where I hope we can finalize on a solution and get it implemented for Java
>> 8.
>> 
>> In a nut shell, here are the underlying needs that I have seen expressed
>> through many, many messages:
>> 
>> - Some code needs to get the Class of the caller of the current method,
>> skipping any reflection methods.
>> - Some code needs to get the Class of the caller /n/ stack frames before
>> the current method, skipping any reflection methods.
>> - Some code needs to get the current stack trace, populated with Classes,
>> Executables, file names, line numbers, and native flags instead of the
>> String class names and String method names in StackTraceElement. This
>> /should/ include any reflection methods, just like StackTraceElement[]s.
>> - Some code needs to get the stack trace from when a Throwable was
>> created, populated with Classes, Executables, file names, line numbers, and
>> native flags instead of the String class names and String method names in
>> StackTraceElement. This /should/ include any reflection methods, just like
>> StackTraceElement[]s.
>> - There needs to be a reflection way to achieve all of this since some
>> libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and
>> 8 (and thus can't use @CallerSensitive).
>> 
>> I believe the solutions to these needs are all related. Importantly, I
>> think it is very important that action be taken in Java 8 due to the changes
>> made to sun.reflect.Reflection#getCallerClass(...). While we all understand
>> that relying on private sun.* APIs is not safe, the fact is that many people
>> have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact
>> that there is simply no other way to do this in the standard API. This
>> includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will
>> stop working correctly in Java 7 >= u25.
>> 
>> I would point out that this could all easily be solved simply by adding a
>> getElementClass() method to StackTraceElement, but there was strong
>> opposition to this, largely due to serialization issues. Since that is
>> apparently not an option, I propose the following API, based on the various
>> discussions in the last two months, StackTraceElement, and the API that .NET
>> provides to achieve the same needs as listed above:
>> 
>> CallerSensitive.java:
>> package java.lang;
>> 
>> /** Previously private API, now public */
>> public @interface CallerSensitive {
>> ...
>> }
>> 
>> StackTraceFrame.java:
>> package java.lang;
>> 
>> import java.util.Objects.
>> 
>> public final class StackTraceFrame {
>> private final Class declaringClass;
>> private final Executable executable;
>> private final String fileName;
>> private final int lineNumber;
>> 
>> public StackTraceFrame(Class declaringClass, Executable
>> executable, String fileName, int lineNumber) {
>> this.declaringClass = Objects.requireNonNull(declaringClass,
>> "Declaring class is null");
>> this.executable = Objects.requireNonNull(executable, "Executable
>> is null");
>> this.fileName = fileName;
>> this.lineNumber = lineNumber;
>> }
>> 
>> public Class getDeclaringClass() {
>> return this.declaringClass;
>> }
>> 
>> public Executable getExecutable() {
>> return this.executable;
>> }
>> 
>> public String getFileName() {
>> return this.fileName;
>> }
>> 
>> public int getLineNumber() {
>> return this.lineNumber;
>> }
>> 
>> public boolean isNative() {
>> return this.lineNumber == -2;
>> }
>> 
>> public String toString() { /* Same as StackTraceElement */ }
>> public boolean equals() { /* Ditto */ }
>> public int hashCode() { /* Ditto */ }
>> 
>> /** Uses @CallerSensitive */
>> public static native StackTraceFrame getCallerFrame();
>> 
>> /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass()
>> */
>> public static native StackTraceFrame getCallerFrame(int skipFrames);
>> 
>> public static native StackTraceFrame[] getCurrentStackTrace();
>> }
>> 
>> Throwable.java:
>> package java.lang;
>> 
>> ...
>> 
>> public class Throwable {
>> ...
>> public synchronized Throwable fillInStackTraceFrames() { ... }
>> 
>> private native Throwable fillInStackTraceFrames(int dummy);
>> 
>> public StackTraceFrame[] getStackTraceFrames() {
>> return this.getOurStackTraceFrames().clone();
>> }
>> 
>> private synchronized StackTraceFrame[] getOurStackTraceFrames() {
>> ... }
>> ...
>> }
>> 
>> Furthermore, I propose that we restore the behavior of
>> sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the
>> proposed above solution cannot be added to Java 7.
>> 
>> I would love if we could quickly coalesce around this solution or a
>> derivative thereof so that it can be implemented before Feature Complete.
>> The absence of any replacement or alternative for
>> sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8
>> that will cause hardships for many projects.
>> 
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>> [2]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>> [3]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>> 
>> 
>> 
>> 
>> --
>> - DML
>> 
> 
> 
> -- 
> - DML



From david.lloyd at redhat.com  Mon Jul 29 22:41:07 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 29 Jul 2013 17:41:07 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <5C6626B4-347B-48BC-AC80-9D632FC9DC7B@nicholaswilliams.net>
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
	
	
	<4E98395F-FCBA-43CC-A479-90603FA3BBB0@nicholaswilliams.net>
	
	<51F6E5AD.6030802@redhat.com>
	<5C6626B4-347B-48BC-AC80-9D632FC9DC7B@nicholaswilliams.net>
Message-ID: <51F6EF83.2080703@redhat.com>

I don't see how Throwables could be deserialized with the proposed 
changes to that class (Class.forName() only works when everything is 
visible from one class loader - a trivial case which is rarely true in 
practice, especially in an app server situation).  I think you'd have to 
leave that part off.

Other than that, I think StackTraceFrame would definitely be very 
useful; I think that adding a public getCallerClass(int) method is a lot 
more realistic though.  Unfortunately I'm not sure the Executable is 
actually physically available at runtime in hotspot - certainly not as 
an actual Executable in any case.

At the very least though, generalizing access to the classes on the call 
stack would have a lot of uses.  We know that it is possible to access 
the call stack, given that there are at least two places which do it, so 
maybe it makes sense to build from there.

On 07/29/2013 05:16 PM, Nick Williams wrote:
> I would happily contribute a patch if I were able to. However, I have almost no idea what I'm doing on the native side, and I spent three hours perusing the Mercurial repository and still can't figure out where anything is.
>
> Even so, I would be willing to try. But I can't just blindly make up a patch. I need some kind of guidance as to what you're looking for. Is the API I propose below acceptable? If I propose a patch implementing that API /and it is generally accepted as correct/ is it going to be accepted? Or am I going to spend significant time trying to figure it out with the possibility that it might be rejected merely because of the API.
>
> My goal in this email was to get the community to coalesce around an API. Once that happens, if nobody more qualified than I is willing or has time to implement it I will surely give it a try. But I don't want the start working on something that the community is going to reject, especially having not received any feedback on this API so far.
>
> Nick
>
> On Jul 29, 2013, at 4:59 PM, David M. Lloyd wrote:
>
>> I expect that at this stage, patches speak louder than words :)
>>
>> On 07/29/2013 03:57 PM, J?rn Huxhorn wrote:
>>> I second all of that.
>>>
>>> It was my understanding that the whole purpose of EA and DP was pinpointing problems like these before they hit consumers. What's the point of them if feedback can't cause the reverting of a breaking change?
>>>
>>> If this is not rectified then the old "Java is slow"-mantra will once again be quite true.
>>> That, and lots of applications will break since not everyone updating to j7u40 will also update all libraries that currently depend on that method - if a timely fix will exist at all at that point. Throwing UnsupportedOperationException all of a sudden isn't exactly the most subtle way of handling this.
>>>
>>> And please don't argue that everyone should just add that runtime property. This isn't realistic.
>>> On 29. Juli 2013 at 21:03:10, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>>>
>>> Some interesting things to note:
>>>
>>> 1) Someone has been asking for a public API replacement for getCallerClass() since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I /would/ have been asking for this for that long, except I haven't needed it until recently and assumed it already existed. .NET has had an API similar to what I proposed below since .NET 1.1.
>>>
>>> 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925 discusses the change to getCallerClass(int) and says it will be completely removed (with no system property to re-enable) as early as 7u55. The bug then talks about how feedback needs to be solicited on how the community is using it so that a public API, if needed, can be created. This is that feedback, and the answer appears to be a resounding YES, a public API needs to replace it because this change is disastrous for many projects. As Paul says, at the very least getCallerClass(int) should keep working like it does in <7u25 (with or without a system property) through the rest of Java 7 and Java 8 if a replacement public API is not adopted.
>>>
>>> 3) The performance test numbers below don't reflect the fact that some use cases (like Log4j) have to use Thread/Throwable#getStackTrace() AND Reflection/SecurityManager. These use cases need the method name/line number AND the Class instance. If Reflection#getCallerClass() is taken away from us and SecurityManager#getClassContext() is unavailable (possible if an existing SecurityManager prohibits instantiating the SecurityManager class), these use cases have to call getStackTrace() and THEN Class#forName() for each StackTraceElement. I'm sure you can see where performance becomes a serious issue at that point. The proposed API below was designed to solve all of the uses cases that have been discussed in a well-performing way.
>>>
>>> Nick
>>>
>>> On Jul 29, 2013, at 10:47 AM, J?rn Huxhorn wrote:
>>>
>>> The numbers are from this link: http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection
>>>
>>> Even if this benchmark suffers from micro-benchmark issues:
>>> a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.
>>>
>>> I'd suggest to at least postpone the UnsupportedOperationException change until we find a suitable replacement. This change will also break existing Groovy scripts. See http://jira.codehaus.org/browse/GROOVY-6279 - but there are other issues as well.
>>>
>>> Cheers,
>>> J?rn.
>>>
>>> On 29. Juli 2013 at 16:49:02, Nicholas Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>>>
>>> I wasn't the one who ran the test, so I don't know for sure. My theory
>>> was that getCallerClass() returns a single frame, but the
>>> SecurityManager must allocate an array of appropriate size (which
>>> involves some overhead) and then return all of the frames. I chalked
>>> the difference up to that. My conclusion from the data was: If you
>>> need a whole stack, SecurityManager is clearly the best option. If you
>>> need a single frame, getCallerClass() is the only option that makes
>>> any sense.
>>>
>>> On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote:
>>> I find it very interesting that reflection is no less than two orders of
>>> magnitude faster than the security manager solution. How big was the stack
>>> in these tests? It makes me wonder if maybe the implementation of the
>>> security manager's getContext() method should be reevaluated a bit.
>>>
>>>
>>> On 07/29/2013 07:53 AM, Nick Williams wrote:
>>>
>>> Just so that everyone understands how important this subject is, this
>>> change to getCallerClass(...) is being labeled a "disaster" for logging
>>> frameworks everywhere. Here's a benchmark for getting Classes from the
>>> following methods:
>>>
>>> 1,000,000 calls of all alternatives were measured as follows :
>>> Reflection: 10.195 ms.
>>> Current Thread StackTrace: 5886.964 ms.
>>> Throwable StackTrace: 4700.073 ms.
>>> SecurityManager: 1046.804 ms.
>>>
>>>
>>> My goal here is to get the entire list engaged in coming up with the right
>>> solution. We (the community) can't afford for Java 8 not to have an
>>> equivalent replacement for getCallerClass().
>>>
>>> Nick
>>>
>>> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:
>>>
>>> All,
>>>
>>> In the last two months, there have been a number of discussions
>>> surrounding stack traces, Classes on the stack trace, and caller classes
>>> [1], [2], [3]. These are all related discussions and the solution to them is
>>> equally related, so I wanted to consolidate it all into this one discussion
>>> where I hope we can finalize on a solution and get it implemented for Java
>>> 8.
>>>
>>> In a nut shell, here are the underlying needs that I have seen expressed
>>> through many, many messages:
>>>
>>> - Some code needs to get the Class of the caller of the current method,
>>> skipping any reflection methods.
>>> - Some code needs to get the Class of the caller /n/ stack frames before
>>> the current method, skipping any reflection methods.
>>> - Some code needs to get the current stack trace, populated with Classes,
>>> Executables, file names, line numbers, and native flags instead of the
>>> String class names and String method names in StackTraceElement. This
>>> /should/ include any reflection methods, just like StackTraceElement[]s.
>>> - Some code needs to get the stack trace from when a Throwable was
>>> created, populated with Classes, Executables, file names, line numbers, and
>>> native flags instead of the String class names and String method names in
>>> StackTraceElement. This /should/ include any reflection methods, just like
>>> StackTraceElement[]s.
>>> - There needs to be a reflection way to achieve all of this since some
>>> libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and
>>> 8 (and thus can't use @CallerSensitive).
>>>
>>> I believe the solutions to these needs are all related. Importantly, I
>>> think it is very important that action be taken in Java 8 due to the changes
>>> made to sun.reflect.Reflection#getCallerClass(...). While we all understand
>>> that relying on private sun.* APIs is not safe, the fact is that many people
>>> have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact
>>> that there is simply no other way to do this in the standard API. This
>>> includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will
>>> stop working correctly in Java 7 >= u25.
>>>
>>> I would point out that this could all easily be solved simply by adding a
>>> getElementClass() method to StackTraceElement, but there was strong
>>> opposition to this, largely due to serialization issues. Since that is
>>> apparently not an option, I propose the following API, based on the various
>>> discussions in the last two months, StackTraceElement, and the API that .NET
>>> provides to achieve the same needs as listed above:
>>>
>>> CallerSensitive.java:
>>> package java.lang;
>>>
>>> /** Previously private API, now public */
>>> public @interface CallerSensitive {
>>> ...
>>> }
>>>
>>> StackTraceFrame.java:
>>> package java.lang;
>>>
>>> import java.util.Objects.
>>>
>>> public final class StackTraceFrame {
>>> private final Class declaringClass;
>>> private final Executable executable;
>>> private final String fileName;
>>> private final int lineNumber;
>>>
>>> public StackTraceFrame(Class declaringClass, Executable
>>> executable, String fileName, int lineNumber) {
>>> this.declaringClass = Objects.requireNonNull(declaringClass,
>>> "Declaring class is null");
>>> this.executable = Objects.requireNonNull(executable, "Executable
>>> is null");
>>> this.fileName = fileName;
>>> this.lineNumber = lineNumber;
>>> }
>>>
>>> public Class getDeclaringClass() {
>>> return this.declaringClass;
>>> }
>>>
>>> public Executable getExecutable() {
>>> return this.executable;
>>> }
>>>
>>> public String getFileName() {
>>> return this.fileName;
>>> }
>>>
>>> public int getLineNumber() {
>>> return this.lineNumber;
>>> }
>>>
>>> public boolean isNative() {
>>> return this.lineNumber == -2;
>>> }
>>>
>>> public String toString() { /* Same as StackTraceElement */ }
>>> public boolean equals() { /* Ditto */ }
>>> public int hashCode() { /* Ditto */ }
>>>
>>> /** Uses @CallerSensitive */
>>> public static native StackTraceFrame getCallerFrame();
>>>
>>> /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass()
>>> */
>>> public static native StackTraceFrame getCallerFrame(int skipFrames);
>>>
>>> public static native StackTraceFrame[] getCurrentStackTrace();
>>> }
>>>
>>> Throwable.java:
>>> package java.lang;
>>>
>>> ...
>>>
>>> public class Throwable {
>>> ...
>>> public synchronized Throwable fillInStackTraceFrames() { ... }
>>>
>>> private native Throwable fillInStackTraceFrames(int dummy);
>>>
>>> public StackTraceFrame[] getStackTraceFrames() {
>>> return this.getOurStackTraceFrames().clone();
>>> }
>>>
>>> private synchronized StackTraceFrame[] getOurStackTraceFrames() {
>>> ... }
>>> ...
>>> }
>>>
>>> Furthermore, I propose that we restore the behavior of
>>> sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the
>>> proposed above solution cannot be added to Java 7.
>>>
>>> I would love if we could quickly coalesce around this solution or a
>>> derivative thereof so that it can be implemented before Feature Complete.
>>> The absence of any replacement or alternative for
>>> sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8
>>> that will cause hardships for many projects.
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>>> [3]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>>>
>>>
>>>
>>>
>>> --
>>> - DML
>>>
>>
>>
>> --
>> - DML
>


-- 
- DML


From pbenedict at apache.org  Mon Jul 29 22:48:06 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 29 Jul 2013 17:48:06 -0500
Subject: Classes on the stack trace (was: getElementClass/StackTraceElement,
	was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
Message-ID: 

+1 with Nick. There's no point in submitting a patch unless someone who is
in charge of Core Libs Dev is willing to first offer technical direction.
Where does Oracle want to go with the solution? There are no official
responses -- it's been quiet on their front for sometime. I don't know if
that means the proposal is being ignored, or there are offline discussions
happening, or people are enjoying summer vacations, or something else. I
just don't know.

Isn't this where someone usually speaks up to "sponsor" a commit?

-- 
Cheers,
Paul

> Nick Williams wrote:
>
> I would happily contribute a patch if I were able to. However, I have
> almost no idea what I'm doing on the native side, and I spent three
> hours perusing the Mercurial repository and still can't figure out
> where anything is.
>
> Even so, I would be willing to try. But I can't just blindly make up
> a patch. I need some kind of guidance as to what you're looking for.
> Is the API I propose below acceptable? If I propose a patch implementing
> that API /and it is generally accepted as correct/ is it going to be
> accepted? Or am I going to spend significant time trying to figure it
> out with the possibility that it might be rejected merely because of
> the API.
>
> My goal in this email was to get the community to coalesce around an
> API. Once that happens, if nobody more qualified than I is willing
> or has time to implement it I will surely give it a try. But I don't
> want the start working on something that the community is going to
> reject, especially having not received any feedback on this API
> so far.
>
> Nick


From nicholas+openjdk at nicholaswilliams.net  Mon Jul 29 23:21:23 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 29 Jul 2013 18:21:23 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F6EF83.2080703@redhat.com>
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
	
	
	<4E98395F-FCBA-43CC-A479-90603FA3BBB0@nicholaswilliams.net>
	
	<51F6E5AD.6030802@redhat.com>
	<5C6626B4-347B-48BC-AC80-9D632FC9DC7B@nicholaswilliams.net>
	<51F6EF83.2080703@redhat.com>
Message-ID: 

Okay. Some questions then:

1) Instead of Executable, StackTraceFrame could simply have the method name. Using Executable would be more future-proof (I anticipate someone wanting to know that someday), so if it turns out it's available I'd prefer to use it, but if it's not physically available there we'll have to do without and simply use the method name. Sound reasonable?

2) StackTraceElement is serializable, and Class is serializable, so in theory StackTraceFrame could be serializable and technically Throwable would be serializable. I would have to follow the same serialization rules that Throwable follows for its StackTraceElement[], but it's doable. The question is deserialization, which as you pointed out won't work if a class on the trace isn't available in the ClassLoader that deserialization is occurring in. I would be fine with, and even suggest, making the StackTraceFrame[] transient so that it wasn't serialized with the exception. I think that's better than omitting it from Throwable altogether. (However, I would point out that my original suggestion of adding the Class to StackTraceElement was shot down for serialization reasons, and when I suggested  making it transient that was also shot down.) Being able to obtain the Classes from the stack trace in an exception is one of the key features that Log4j needs, so leaving out any way to obtain this from a Throwable would be disappointing. I think making it transient is OK. I can't imagine still needing the Class from a deserialized Throwable. Thoughts?

3) What about getCallerFrame() and getCallerFrame(int) (as I suggested) AND getCallerClass() and getCallerClass(int) (as you mentioned)? That should create the best of both worlds.

4) What about @CallerSensitive? Part of my proposal was moving that to java.lang. There is a LOT of code that's currently using the private @CallerSensitive. How should I handle that?

5) What about Java 7? As has been widely reported, this change broke a lot of code running on Java 7. We're starting to get near-daily reports of problems now. The proposed idea is to forget about the system property in Java 7 and restore getCallerClass(int) to it's previous operation. How should I proceed on that?

6) Is there, as Paul Benedict suggested, someone willing to sponsor this commit if I create a patch?

7) Any suggestions on what to use and how to get started checking out and creating patches against JDK? I hadn't even heard of Mercurial until I started looking at this issue back in May, and I still don't understand how the project is laid out. Is everything I'm going to need to change within hg.openjdk.java.net/jdk8/jdk8/jdk/? Or are there files in other locations that I'll need to change?

Nick

On Jul 29, 2013, at 5:41 PM, David M. Lloyd wrote:

> I don't see how Throwables could be deserialized with the proposed changes to that class (Class.forName() only works when everything is visible from one class loader - a trivial case which is rarely true in practice, especially in an app server situation).  I think you'd have to leave that part off.
> 
> Other than that, I think StackTraceFrame would definitely be very useful; I think that adding a public getCallerClass(int) method is a lot more realistic though.  Unfortunately I'm not sure the Executable is actually physically available at runtime in hotspot - certainly not as an actual Executable in any case.
> 
> At the very least though, generalizing access to the classes on the call stack would have a lot of uses.  We know that it is possible to access the call stack, given that there are at least two places which do it, so maybe it makes sense to build from there.
> 
> On 07/29/2013 05:16 PM, Nick Williams wrote:
>> I would happily contribute a patch if I were able to. However, I have almost no idea what I'm doing on the native side, and I spent three hours perusing the Mercurial repository and still can't figure out where anything is.
>> 
>> Even so, I would be willing to try. But I can't just blindly make up a patch. I need some kind of guidance as to what you're looking for. Is the API I propose below acceptable? If I propose a patch implementing that API /and it is generally accepted as correct/ is it going to be accepted? Or am I going to spend significant time trying to figure it out with the possibility that it might be rejected merely because of the API.
>> 
>> My goal in this email was to get the community to coalesce around an API. Once that happens, if nobody more qualified than I is willing or has time to implement it I will surely give it a try. But I don't want the start working on something that the community is going to reject, especially having not received any feedback on this API so far.
>> 
>> Nick
>> 
>> On Jul 29, 2013, at 4:59 PM, David M. Lloyd wrote:
>> 
>>> I expect that at this stage, patches speak louder than words :)
>>> 
>>> On 07/29/2013 03:57 PM, J?rn Huxhorn wrote:
>>>> I second all of that.
>>>> 
>>>> It was my understanding that the whole purpose of EA and DP was pinpointing problems like these before they hit consumers. What's the point of them if feedback can't cause the reverting of a breaking change?
>>>> 
>>>> If this is not rectified then the old "Java is slow"-mantra will once again be quite true.
>>>> That, and lots of applications will break since not everyone updating to j7u40 will also update all libraries that currently depend on that method - if a timely fix will exist at all at that point. Throwing UnsupportedOperationException all of a sudden isn't exactly the most subtle way of handling this.
>>>> 
>>>> And please don't argue that everyone should just add that runtime property. This isn't realistic.
>>>> On 29. Juli 2013 at 21:03:10, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>>>> 
>>>> Some interesting things to note:
>>>> 
>>>> 1) Someone has been asking for a public API replacement for getCallerClass() since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I /would/ have been asking for this for that long, except I haven't needed it until recently and assumed it already existed. .NET has had an API similar to what I proposed below since .NET 1.1.
>>>> 
>>>> 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925 discusses the change to getCallerClass(int) and says it will be completely removed (with no system property to re-enable) as early as 7u55. The bug then talks about how feedback needs to be solicited on how the community is using it so that a public API, if needed, can be created. This is that feedback, and the answer appears to be a resounding YES, a public API needs to replace it because this change is disastrous for many projects. As Paul says, at the very least getCallerClass(int) should keep working like it does in <7u25 (with or without a system property) through the rest of Java 7 and Java 8 if a replacement public API is not adopted.
>>>> 
>>>> 3) The performance test numbers below don't reflect the fact that some use cases (like Log4j) have to use Thread/Throwable#getStackTrace() AND Reflection/SecurityManager. These use cases need the method name/line number AND the Class instance. If Reflection#getCallerClass() is taken away from us and SecurityManager#getClassContext() is unavailable (possible if an existing SecurityManager prohibits instantiating the SecurityManager class), these use cases have to call getStackTrace() and THEN Class#forName() for each StackTraceElement. I'm sure you can see where performance becomes a serious issue at that point. The proposed API below was designed to solve all of the uses cases that have been discussed in a well-performing way.
>>>> 
>>>> Nick
>>>> 
>>>> On Jul 29, 2013, at 10:47 AM, J?rn Huxhorn wrote:
>>>> 
>>>> The numbers are from this link: http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection
>>>> 
>>>> Even if this benchmark suffers from micro-benchmark issues:
>>>> a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.
>>>> 
>>>> I'd suggest to at least postpone the UnsupportedOperationException change until we find a suitable replacement. This change will also break existing Groovy scripts. See http://jira.codehaus.org/browse/GROOVY-6279 - but there are other issues as well.
>>>> 
>>>> Cheers,
>>>> J?rn.
>>>> 
>>>> On 29. Juli 2013 at 16:49:02, Nicholas Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>>>> 
>>>> I wasn't the one who ran the test, so I don't know for sure. My theory
>>>> was that getCallerClass() returns a single frame, but the
>>>> SecurityManager must allocate an array of appropriate size (which
>>>> involves some overhead) and then return all of the frames. I chalked
>>>> the difference up to that. My conclusion from the data was: If you
>>>> need a whole stack, SecurityManager is clearly the best option. If you
>>>> need a single frame, getCallerClass() is the only option that makes
>>>> any sense.
>>>> 
>>>> On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote:
>>>> I find it very interesting that reflection is no less than two orders of
>>>> magnitude faster than the security manager solution. How big was the stack
>>>> in these tests? It makes me wonder if maybe the implementation of the
>>>> security manager's getContext() method should be reevaluated a bit.
>>>> 
>>>> 
>>>> On 07/29/2013 07:53 AM, Nick Williams wrote:
>>>> 
>>>> Just so that everyone understands how important this subject is, this
>>>> change to getCallerClass(...) is being labeled a "disaster" for logging
>>>> frameworks everywhere. Here's a benchmark for getting Classes from the
>>>> following methods:
>>>> 
>>>> 1,000,000 calls of all alternatives were measured as follows :
>>>> Reflection: 10.195 ms.
>>>> Current Thread StackTrace: 5886.964 ms.
>>>> Throwable StackTrace: 4700.073 ms.
>>>> SecurityManager: 1046.804 ms.
>>>> 
>>>> 
>>>> My goal here is to get the entire list engaged in coming up with the right
>>>> solution. We (the community) can't afford for Java 8 not to have an
>>>> equivalent replacement for getCallerClass().
>>>> 
>>>> Nick
>>>> 
>>>> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:
>>>> 
>>>> All,
>>>> 
>>>> In the last two months, there have been a number of discussions
>>>> surrounding stack traces, Classes on the stack trace, and caller classes
>>>> [1], [2], [3]. These are all related discussions and the solution to them is
>>>> equally related, so I wanted to consolidate it all into this one discussion
>>>> where I hope we can finalize on a solution and get it implemented for Java
>>>> 8.
>>>> 
>>>> In a nut shell, here are the underlying needs that I have seen expressed
>>>> through many, many messages:
>>>> 
>>>> - Some code needs to get the Class of the caller of the current method,
>>>> skipping any reflection methods.
>>>> - Some code needs to get the Class of the caller /n/ stack frames before
>>>> the current method, skipping any reflection methods.
>>>> - Some code needs to get the current stack trace, populated with Classes,
>>>> Executables, file names, line numbers, and native flags instead of the
>>>> String class names and String method names in StackTraceElement. This
>>>> /should/ include any reflection methods, just like StackTraceElement[]s.
>>>> - Some code needs to get the stack trace from when a Throwable was
>>>> created, populated with Classes, Executables, file names, line numbers, and
>>>> native flags instead of the String class names and String method names in
>>>> StackTraceElement. This /should/ include any reflection methods, just like
>>>> StackTraceElement[]s.
>>>> - There needs to be a reflection way to achieve all of this since some
>>>> libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and
>>>> 8 (and thus can't use @CallerSensitive).
>>>> 
>>>> I believe the solutions to these needs are all related. Importantly, I
>>>> think it is very important that action be taken in Java 8 due to the changes
>>>> made to sun.reflect.Reflection#getCallerClass(...). While we all understand
>>>> that relying on private sun.* APIs is not safe, the fact is that many people
>>>> have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact
>>>> that there is simply no other way to do this in the standard API. This
>>>> includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will
>>>> stop working correctly in Java 7 >= u25.
>>>> 
>>>> I would point out that this could all easily be solved simply by adding a
>>>> getElementClass() method to StackTraceElement, but there was strong
>>>> opposition to this, largely due to serialization issues. Since that is
>>>> apparently not an option, I propose the following API, based on the various
>>>> discussions in the last two months, StackTraceElement, and the API that .NET
>>>> provides to achieve the same needs as listed above:
>>>> 
>>>> CallerSensitive.java:
>>>> package java.lang;
>>>> 
>>>> /** Previously private API, now public */
>>>> public @interface CallerSensitive {
>>>> ...
>>>> }
>>>> 
>>>> StackTraceFrame.java:
>>>> package java.lang;
>>>> 
>>>> import java.util.Objects.
>>>> 
>>>> public final class StackTraceFrame {
>>>> private final Class declaringClass;
>>>> private final Executable executable;
>>>> private final String fileName;
>>>> private final int lineNumber;
>>>> 
>>>> public StackTraceFrame(Class declaringClass, Executable
>>>> executable, String fileName, int lineNumber) {
>>>> this.declaringClass = Objects.requireNonNull(declaringClass,
>>>> "Declaring class is null");
>>>> this.executable = Objects.requireNonNull(executable, "Executable
>>>> is null");
>>>> this.fileName = fileName;
>>>> this.lineNumber = lineNumber;
>>>> }
>>>> 
>>>> public Class getDeclaringClass() {
>>>> return this.declaringClass;
>>>> }
>>>> 
>>>> public Executable getExecutable() {
>>>> return this.executable;
>>>> }
>>>> 
>>>> public String getFileName() {
>>>> return this.fileName;
>>>> }
>>>> 
>>>> public int getLineNumber() {
>>>> return this.lineNumber;
>>>> }
>>>> 
>>>> public boolean isNative() {
>>>> return this.lineNumber == -2;
>>>> }
>>>> 
>>>> public String toString() { /* Same as StackTraceElement */ }
>>>> public boolean equals() { /* Ditto */ }
>>>> public int hashCode() { /* Ditto */ }
>>>> 
>>>> /** Uses @CallerSensitive */
>>>> public static native StackTraceFrame getCallerFrame();
>>>> 
>>>> /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass()
>>>> */
>>>> public static native StackTraceFrame getCallerFrame(int skipFrames);
>>>> 
>>>> public static native StackTraceFrame[] getCurrentStackTrace();
>>>> }
>>>> 
>>>> Throwable.java:
>>>> package java.lang;
>>>> 
>>>> ...
>>>> 
>>>> public class Throwable {
>>>> ...
>>>> public synchronized Throwable fillInStackTraceFrames() { ... }
>>>> 
>>>> private native Throwable fillInStackTraceFrames(int dummy);
>>>> 
>>>> public StackTraceFrame[] getStackTraceFrames() {
>>>> return this.getOurStackTraceFrames().clone();
>>>> }
>>>> 
>>>> private synchronized StackTraceFrame[] getOurStackTraceFrames() {
>>>> ... }
>>>> ...
>>>> }
>>>> 
>>>> Furthermore, I propose that we restore the behavior of
>>>> sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the
>>>> proposed above solution cannot be added to Java 7.
>>>> 
>>>> I would love if we could quickly coalesce around this solution or a
>>>> derivative thereof so that it can be implemented before Feature Complete.
>>>> The absence of any replacement or alternative for
>>>> sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8
>>>> that will cause hardships for many projects.
>>>> 
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>>>> [2]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>>>> [3]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> - DML
>>>> 
>>> 
>>> 
>>> --
>>> - DML
>> 
> 
> 
> -- 
> - DML



From david.lloyd at redhat.com  Mon Jul 29 23:43:13 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 29 Jul 2013 18:43:13 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: 
References: 
	<00313922-A81A-49DE-9B4B-D56BC8A6D4BC@nicholaswilliams.net>
	<51F66C76.10209@redhat.com>
	
	
	<4E98395F-FCBA-43CC-A479-90603FA3BBB0@nicholaswilliams.net>
	
	<51F6E5AD.6030802@redhat.com>
	<5C6626B4-347B-48BC-AC80-9D632FC9DC7B@nicholaswilliams.net>
	<51F6EF83.2080703@redhat.com>
	
Message-ID: <51F6FE11.2090704@redhat.com>

Answers:

1) Seems reasonable enough.

2) I think this will be quite complicated in practice.  First, we don't 
want to obliterate performance, so we need some way to only assemble 
this information if necessary (assembling two stack traces is likely to 
be twice as expensive as assembling one, after all).  If you solve that 
issue, you still have to have a sane way to deal with the case where a 
deserialized exception will simply not have that information present.

3) Yes, that sounds good, but again to me the minimum acceptable 
functionality would be just the classes.

4) I don't know much about what that annotation actually entails, 
semantically, so I can't really comment.

5) I think we should continue to lobby Oracle to keep that method around 
at least until 8.  At worst, move it to an openjdk package, so code can 
detect the right one at runtime.

6) I'm sure if we came up with something reasonable and nobody from 
Oracle wanted to step up, I could find someone at Red Hat to do it.

7) Franky, HG is junk, and the way OpenJDK uses it is pure torture.  But 
until/unless I figure out a way to maintain a continuous Git mirror 
(something I kick around once every month or two), I guess we're at its 
mercy.  But the quick guide is, there are actually a bunch of 
repositories, and you have to check them all out (there's an outer one 
and several inner ones).  Once you implement your changes, you'll have 
to use "hg diff" to get them out.  I have no idea how to make a 
so-called "webrev", the final step in this insanely crusty stone-age 
process, but I know people who do.  So getting a diff or diffs is really 
the key step.

On 07/29/2013 06:21 PM, Nick Williams wrote:
> Okay. Some questions then:
>
> 1) Instead of Executable, StackTraceFrame could simply have the method name. Using Executable would be more future-proof (I anticipate someone wanting to know that someday), so if it turns out it's available I'd prefer to use it, but if it's not physically available there we'll have to do without and simply use the method name. Sound reasonable?
>
> 2) StackTraceElement is serializable, and Class is serializable, so in theory StackTraceFrame could be serializable and technically Throwable would be serializable. I would have to follow the same serialization rules that Throwable follows for its StackTraceElement[], but it's doable. The question is deserialization, which as you pointed out won't work if a class on the trace isn't available in the ClassLoader that deserialization is occurring in. I would be fine with, and even suggest, making the StackTraceFrame[] transient so that it wasn't serialized with the exception. I think that's better than omitting it from Throwable altogether. (However, I would point out that my original suggestion of adding the Class to StackTraceElement was shot down for serialization reasons, and when I suggested  making it transient that was also shot down.) Being able to obtain the Classes from the stack trace in an exception is one of the key features that Log4j needs, so leaving out any w!
 ay to obta
in this from a Throwable would be disappointing. I think making it transient is OK. I can't imagine still needing the Class from a deserialized Throwable. Thoughts?
>
> 3) What about getCallerFrame() and getCallerFrame(int) (as I suggested) AND getCallerClass() and getCallerClass(int) (as you mentioned)? That should create the best of both worlds.
>
> 4) What about @CallerSensitive? Part of my proposal was moving that to java.lang. There is a LOT of code that's currently using the private @CallerSensitive. How should I handle that?
>
> 5) What about Java 7? As has been widely reported, this change broke a lot of code running on Java 7. We're starting to get near-daily reports of problems now. The proposed idea is to forget about the system property in Java 7 and restore getCallerClass(int) to it's previous operation. How should I proceed on that?
>
> 6) Is there, as Paul Benedict suggested, someone willing to sponsor this commit if I create a patch?
>
> 7) Any suggestions on what to use and how to get started checking out and creating patches against JDK? I hadn't even heard of Mercurial until I started looking at this issue back in May, and I still don't understand how the project is laid out. Is everything I'm going to need to change within hg.openjdk.java.net/jdk8/jdk8/jdk/? Or are there files in other locations that I'll need to change?
>
> Nick
>
> On Jul 29, 2013, at 5:41 PM, David M. Lloyd wrote:
>
>> I don't see how Throwables could be deserialized with the proposed changes to that class (Class.forName() only works when everything is visible from one class loader - a trivial case which is rarely true in practice, especially in an app server situation).  I think you'd have to leave that part off.
>>
>> Other than that, I think StackTraceFrame would definitely be very useful; I think that adding a public getCallerClass(int) method is a lot more realistic though.  Unfortunately I'm not sure the Executable is actually physically available at runtime in hotspot - certainly not as an actual Executable in any case.
>>
>> At the very least though, generalizing access to the classes on the call stack would have a lot of uses.  We know that it is possible to access the call stack, given that there are at least two places which do it, so maybe it makes sense to build from there.
>>
>> On 07/29/2013 05:16 PM, Nick Williams wrote:
>>> I would happily contribute a patch if I were able to. However, I have almost no idea what I'm doing on the native side, and I spent three hours perusing the Mercurial repository and still can't figure out where anything is.
>>>
>>> Even so, I would be willing to try. But I can't just blindly make up a patch. I need some kind of guidance as to what you're looking for. Is the API I propose below acceptable? If I propose a patch implementing that API /and it is generally accepted as correct/ is it going to be accepted? Or am I going to spend significant time trying to figure it out with the possibility that it might be rejected merely because of the API.
>>>
>>> My goal in this email was to get the community to coalesce around an API. Once that happens, if nobody more qualified than I is willing or has time to implement it I will surely give it a try. But I don't want the start working on something that the community is going to reject, especially having not received any feedback on this API so far.
>>>
>>> Nick
>>>
>>> On Jul 29, 2013, at 4:59 PM, David M. Lloyd wrote:
>>>
>>>> I expect that at this stage, patches speak louder than words :)
>>>>
>>>> On 07/29/2013 03:57 PM, J?rn Huxhorn wrote:
>>>>> I second all of that.
>>>>>
>>>>> It was my understanding that the whole purpose of EA and DP was pinpointing problems like these before they hit consumers. What's the point of them if feedback can't cause the reverting of a breaking change?
>>>>>
>>>>> If this is not rectified then the old "Java is slow"-mantra will once again be quite true.
>>>>> That, and lots of applications will break since not everyone updating to j7u40 will also update all libraries that currently depend on that method - if a timely fix will exist at all at that point. Throwing UnsupportedOperationException all of a sudden isn't exactly the most subtle way of handling this.
>>>>>
>>>>> And please don't argue that everyone should just add that runtime property. This isn't realistic.
>>>>> On 29. Juli 2013 at 21:03:10, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>>>>>
>>>>> Some interesting things to note:
>>>>>
>>>>> 1) Someone has been asking for a public API replacement for getCallerClass() since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I /would/ have been asking for this for that long, except I haven't needed it until recently and assumed it already existed. .NET has had an API similar to what I proposed below since .NET 1.1.
>>>>>
>>>>> 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925 discusses the change to getCallerClass(int) and says it will be completely removed (with no system property to re-enable) as early as 7u55. The bug then talks about how feedback needs to be solicited on how the community is using it so that a public API, if needed, can be created. This is that feedback, and the answer appears to be a resounding YES, a public API needs to replace it because this change is disastrous for many projects. As Paul says, at the very least getCallerClass(int) should keep working like it does in <7u25 (with or without a system property) through the rest of Java 7 and Java 8 if a replacement public API is not adopted.
>>>>>
>>>>> 3) The performance test numbers below don't reflect the fact that some use cases (like Log4j) have to use Thread/Throwable#getStackTrace() AND Reflection/SecurityManager. These use cases need the method name/line number AND the Class instance. If Reflection#getCallerClass() is taken away from us and SecurityManager#getClassContext() is unavailable (possible if an existing SecurityManager prohibits instantiating the SecurityManager class), these use cases have to call getStackTrace() and THEN Class#forName() for each StackTraceElement. I'm sure you can see where performance becomes a serious issue at that point. The proposed API below was designed to solve all of the uses cases that have been discussed in a well-performing way.
>>>>>
>>>>> Nick
>>>>>
>>>>> On Jul 29, 2013, at 10:47 AM, J?rn Huxhorn wrote:
>>>>>
>>>>> The numbers are from this link: http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection
>>>>>
>>>>> Even if this benchmark suffers from micro-benchmark issues:
>>>>> a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.
>>>>>
>>>>> I'd suggest to at least postpone the UnsupportedOperationException change until we find a suitable replacement. This change will also break existing Groovy scripts. See http://jira.codehaus.org/browse/GROOVY-6279 - but there are other issues as well.
>>>>>
>>>>> Cheers,
>>>>> J?rn.
>>>>>
>>>>> On 29. Juli 2013 at 16:49:02, Nicholas Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
>>>>>
>>>>> I wasn't the one who ran the test, so I don't know for sure. My theory
>>>>> was that getCallerClass() returns a single frame, but the
>>>>> SecurityManager must allocate an array of appropriate size (which
>>>>> involves some overhead) and then return all of the frames. I chalked
>>>>> the difference up to that. My conclusion from the data was: If you
>>>>> need a whole stack, SecurityManager is clearly the best option. If you
>>>>> need a single frame, getCallerClass() is the only option that makes
>>>>> any sense.
>>>>>
>>>>> On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd  wrote:
>>>>> I find it very interesting that reflection is no less than two orders of
>>>>> magnitude faster than the security manager solution. How big was the stack
>>>>> in these tests? It makes me wonder if maybe the implementation of the
>>>>> security manager's getContext() method should be reevaluated a bit.
>>>>>
>>>>>
>>>>> On 07/29/2013 07:53 AM, Nick Williams wrote:
>>>>>
>>>>> Just so that everyone understands how important this subject is, this
>>>>> change to getCallerClass(...) is being labeled a "disaster" for logging
>>>>> frameworks everywhere. Here's a benchmark for getting Classes from the
>>>>> following methods:
>>>>>
>>>>> 1,000,000 calls of all alternatives were measured as follows :
>>>>> Reflection: 10.195 ms.
>>>>> Current Thread StackTrace: 5886.964 ms.
>>>>> Throwable StackTrace: 4700.073 ms.
>>>>> SecurityManager: 1046.804 ms.
>>>>>
>>>>>
>>>>> My goal here is to get the entire list engaged in coming up with the right
>>>>> solution. We (the community) can't afford for Java 8 not to have an
>>>>> equivalent replacement for getCallerClass().
>>>>>
>>>>> Nick
>>>>>
>>>>> On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:
>>>>>
>>>>> All,
>>>>>
>>>>> In the last two months, there have been a number of discussions
>>>>> surrounding stack traces, Classes on the stack trace, and caller classes
>>>>> [1], [2], [3]. These are all related discussions and the solution to them is
>>>>> equally related, so I wanted to consolidate it all into this one discussion
>>>>> where I hope we can finalize on a solution and get it implemented for Java
>>>>> 8.
>>>>>
>>>>> In a nut shell, here are the underlying needs that I have seen expressed
>>>>> through many, many messages:
>>>>>
>>>>> - Some code needs to get the Class of the caller of the current method,
>>>>> skipping any reflection methods.
>>>>> - Some code needs to get the Class of the caller /n/ stack frames before
>>>>> the current method, skipping any reflection methods.
>>>>> - Some code needs to get the current stack trace, populated with Classes,
>>>>> Executables, file names, line numbers, and native flags instead of the
>>>>> String class names and String method names in StackTraceElement. This
>>>>> /should/ include any reflection methods, just like StackTraceElement[]s.
>>>>> - Some code needs to get the stack trace from when a Throwable was
>>>>> created, populated with Classes, Executables, file names, line numbers, and
>>>>> native flags instead of the String class names and String method names in
>>>>> StackTraceElement. This /should/ include any reflection methods, just like
>>>>> StackTraceElement[]s.
>>>>> - There needs to be a reflection way to achieve all of this since some
>>>>> libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and
>>>>> 8 (and thus can't use @CallerSensitive).
>>>>>
>>>>> I believe the solutions to these needs are all related. Importantly, I
>>>>> think it is very important that action be taken in Java 8 due to the changes
>>>>> made to sun.reflect.Reflection#getCallerClass(...). While we all understand
>>>>> that relying on private sun.* APIs is not safe, the fact is that many people
>>>>> have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact
>>>>> that there is simply no other way to do this in the standard API. This
>>>>> includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will
>>>>> stop working correctly in Java 7 >= u25.
>>>>>
>>>>> I would point out that this could all easily be solved simply by adding a
>>>>> getElementClass() method to StackTraceElement, but there was strong
>>>>> opposition to this, largely due to serialization issues. Since that is
>>>>> apparently not an option, I propose the following API, based on the various
>>>>> discussions in the last two months, StackTraceElement, and the API that .NET
>>>>> provides to achieve the same needs as listed above:
>>>>>
>>>>> CallerSensitive.java:
>>>>> package java.lang;
>>>>>
>>>>> /** Previously private API, now public */
>>>>> public @interface CallerSensitive {
>>>>> ...
>>>>> }
>>>>>
>>>>> StackTraceFrame.java:
>>>>> package java.lang;
>>>>>
>>>>> import java.util.Objects.
>>>>>
>>>>> public final class StackTraceFrame {
>>>>> private final Class declaringClass;
>>>>> private final Executable executable;
>>>>> private final String fileName;
>>>>> private final int lineNumber;
>>>>>
>>>>> public StackTraceFrame(Class declaringClass, Executable
>>>>> executable, String fileName, int lineNumber) {
>>>>> this.declaringClass = Objects.requireNonNull(declaringClass,
>>>>> "Declaring class is null");
>>>>> this.executable = Objects.requireNonNull(executable, "Executable
>>>>> is null");
>>>>> this.fileName = fileName;
>>>>> this.lineNumber = lineNumber;
>>>>> }
>>>>>
>>>>> public Class getDeclaringClass() {
>>>>> return this.declaringClass;
>>>>> }
>>>>>
>>>>> public Executable getExecutable() {
>>>>> return this.executable;
>>>>> }
>>>>>
>>>>> public String getFileName() {
>>>>> return this.fileName;
>>>>> }
>>>>>
>>>>> public int getLineNumber() {
>>>>> return this.lineNumber;
>>>>> }
>>>>>
>>>>> public boolean isNative() {
>>>>> return this.lineNumber == -2;
>>>>> }
>>>>>
>>>>> public String toString() { /* Same as StackTraceElement */ }
>>>>> public boolean equals() { /* Ditto */ }
>>>>> public int hashCode() { /* Ditto */ }
>>>>>
>>>>> /** Uses @CallerSensitive */
>>>>> public static native StackTraceFrame getCallerFrame();
>>>>>
>>>>> /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass()
>>>>> */
>>>>> public static native StackTraceFrame getCallerFrame(int skipFrames);
>>>>>
>>>>> public static native StackTraceFrame[] getCurrentStackTrace();
>>>>> }
>>>>>
>>>>> Throwable.java:
>>>>> package java.lang;
>>>>>
>>>>> ...
>>>>>
>>>>> public class Throwable {
>>>>> ...
>>>>> public synchronized Throwable fillInStackTraceFrames() { ... }
>>>>>
>>>>> private native Throwable fillInStackTraceFrames(int dummy);
>>>>>
>>>>> public StackTraceFrame[] getStackTraceFrames() {
>>>>> return this.getOurStackTraceFrames().clone();
>>>>> }
>>>>>
>>>>> private synchronized StackTraceFrame[] getOurStackTraceFrames() {
>>>>> ... }
>>>>> ...
>>>>> }
>>>>>
>>>>> Furthermore, I propose that we restore the behavior of
>>>>> sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the
>>>>> proposed above solution cannot be added to Java 7.
>>>>>
>>>>> I would love if we could quickly coalesce around this solution or a
>>>>> derivative thereof so that it can be implemented before Feature Complete.
>>>>> The absence of any replacement or alternative for
>>>>> sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8
>>>>> that will cause hardships for many projects.
>>>>>
>>>>> [1]
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>>>>> [2]
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>>>>> [3]
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> - DML
>>>>>
>>>>
>>>>
>>>> --
>>>> - DML
>>>
>>
>>
>> --
>> - DML
>


-- 
- DML


From Alan.Bateman at oracle.com  Tue Jul 30 01:38:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Jul 2013 18:38:36 -0700
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: 
References: 
Message-ID: <51F7191C.9000909@oracle.com>

On 29/07/2013 15:48, Paul Benedict wrote:
> +1 with Nick. There's no point in submitting a patch unless someone who is
> in charge of Core Libs Dev is willing to first offer technical direction.
> Where does Oracle want to go with the solution? There are no official
> responses -- it's been quiet on their front for sometime. I don't know if
> that means the proposal is being ignored, or there are offline discussions
> happening, or people are enjoying summer vacations, or something else. I
> just don't know.
>

I think several people are on vacation, some people are at the JVM 
Language summit, others are probably just busy. I'm sure there will be 
further discussion over the next few weeks.

For JDK 8 then I think the use-cases need to be studied to see if it 
merits introducing new APIs or not (JDK 8 is past feature complete so it 
might be awkward/tight). The Groovy usage seems to be boil down to be 
able to distinguish frames associated with Groovy generated classes from 
other classes, Mandy has created a bug to look into that. Another one 
that has come up is loading resources on behalf of the caller, we 
already have a bug open to look at that for at least the purposes of 
logging resources.

On 7u40 then the method has not been removed and there is a workaround 
to allow existing code using the sun.reflect.Reflection directly to 
continue to work. I can't say whether this should be re-visited given 
the usages that have come out of the wood work. The timing on this is 
tighter given that 7u40 is supposed to be released mid-September.

-Alan




From david.lloyd at redhat.com  Tue Jul 30 02:17:00 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 29 Jul 2013 21:17:00 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7191C.9000909@oracle.com>
References: 
	<51F7191C.9000909@oracle.com>
Message-ID: <51F7221C.8080302@redhat.com>

On 07/29/2013 08:38 PM, Alan Bateman wrote:
> On 29/07/2013 15:48, Paul Benedict wrote:
>> +1 with Nick. There's no point in submitting a patch unless someone
>> who is
>> in charge of Core Libs Dev is willing to first offer technical direction.
>> Where does Oracle want to go with the solution? There are no official
>> responses -- it's been quiet on their front for sometime. I don't know if
>> that means the proposal is being ignored, or there are offline
>> discussions
>> happening, or people are enjoying summer vacations, or something else. I
>> just don't know.
>>
>
> I think several people are on vacation, some people are at the JVM
> Language summit, others are probably just busy. I'm sure there will be
> further discussion over the next few weeks.
>
> For JDK 8 then I think the use-cases need to be studied to see if it
> merits introducing new APIs or not (JDK 8 is past feature complete so it
> might be awkward/tight). The Groovy usage seems to be boil down to be
> able to distinguish frames associated with Groovy generated classes from
> other classes, Mandy has created a bug to look into that. Another one
> that has come up is loading resources on behalf of the caller, we
> already have a bug open to look at that for at least the purposes of
> logging resources.
>
> On 7u40 then the method has not been removed and there is a workaround
> to allow existing code using the sun.reflect.Reflection directly to
> continue to work. I can't say whether this should be re-visited given
> the usages that have come out of the wood work. The timing on this is
> tighter given that 7u40 is supposed to be released mid-September.

Your phrasing makes me think I missed something: is the 
Reflection.getCallerClass() method being removed due to some technical 
issue that it can only be somehow emulated as a workaround?  Or is it 
just a general cleanup effort?

-- 
- DML


From henry.jen at oracle.com  Tue Jul 30 02:30:10 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 29 Jul 2013 19:30:10 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
Message-ID: <51F72532.3010101@oracle.com>

Hi,

Please review a simple fix for 8020977.

The fix grab the length before initiate copying operation, so that the
'delimiter' added for this won't be included in copy.

For rest cases, the timing window changed a little, but that's fine as
simultaneous changes is not determined.

Cheers,
Henry


From henry.jen at oracle.com  Tue Jul 30 02:43:56 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 29 Jul 2013 19:43:56 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <51F72532.3010101@oracle.com>
References: <51F72532.3010101@oracle.com>
Message-ID: <51F7286C.9000508@oracle.com>

Sorry, the webrev is at

http://cr.openjdk.java.net/~henryjen/tl/8020977/0/webrev/

Cheers,
Henry

On 07/29/2013 07:30 PM, Henry Jen wrote:
> Hi,
> 
> Please review a simple fix for 8020977.
> 
> The fix grab the length before initiate copying operation, so that the
> 'delimiter' added for this won't be included in copy.
> 
> For rest cases, the timing window changed a little, but that's fine as
> simultaneous changes is not determined.
> 
> Cheers,
> Henry
> 



From Roger.Riggs at Oracle.com  Tue Jul 30 02:57:26 2013
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 29 Jul 2013 22:57:26 -0400
Subject: RFR: java.time test bug
Message-ID: <51F72B96.4050407@Oracle.com>

Please help review (and commit to jdk-tl or jdk) this java.time test bug

8021767 : 
test/java/time/tck/java/time/format/TCKFormatStyle.java failing
   Correct to use fixed locale; not locale of test environment

The test incorrectly uses the locale of the test environment and thus
fails in some environments.

Please review the webrev:
     http://cr.openjdk.java.net/~rriggs/webrev-8021767-fixedlocale/

Thanks, Roger



From xuelei.fan at oracle.com  Tue Jul 30 02:38:52 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 30 Jul 2013 02:38:52 +0000
Subject: hg: jdk8/tl/jdk: 8021841: Remove SSLEngineDeadlock.java from problem
	list
Message-ID: <20130730023918.2F77B48467@hg.openjdk.java.net>

Changeset: 613cc7beba64
Author:    xuelei
Date:      2013-07-29 19:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/613cc7beba64

8021841: Remove SSLEngineDeadlock.java from problem list
Reviewed-by: wetmore

! test/ProblemList.txt



From david.holmes at oracle.com  Tue Jul 30 03:10:37 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 30 Jul 2013 13:10:37 +1000
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: <51F6C860.4020000@oracle.com>
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com>
Message-ID: <51F72EAD.7040201@oracle.com>

On 30/07/2013 5:54 AM, Brent Christian wrote:
> On 7/28/13 10:13 PM, David Holmes wrote:
>> On 27/07/2013 3:53 AM, Brent Christian wrote:
>>> Please review my fix for 8011194 : "Apps launched via double-clicked
>>> .jars have file.encoding value of US-ASCII on Mac OS X"
>>>
>>> http://bugs.sun.com/view_bug.do?bug_id=8011194
>>>
>>> In most cases of launching a Java app on Mac (from the cmdline, or from
>>> a native .app bundle), reading and displaying UTF-8 characters beyond
>>> the standard ASCII range works fine.
>>>
>>> A notable exception is the launching of an app by double-clicking a .jar
>>> file.  In this case, file.encoding defaults to US-ASCII, and characters
>>> outside of the ASCII range show up as garbage.
>>
>> Why does this occur? What sets the encoding to US-ASCII?
>
> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
> values for LANG/LC* are set in the environment when double-clicking a .jar.
>
> We get "UTF-8" when launching from the command line because the default
> Terminal.app setup on Mac will setup LANG for you (to "en_US.UTF-8" in
> the US).

Sounds like a user environment error to me. This isn't my area but I'm 
not convinced we should be second guessing what we think the encoding 
should be. What if someone intends for it to be US-ASCII?

David
-----

> -Brent


From Alan.Bateman at oracle.com  Tue Jul 30 04:31:45 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Jul 2013 21:31:45 -0700
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7221C.8080302@redhat.com>
References: 
	<51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com>
Message-ID: <51F741B1.7020008@oracle.com>

On 29/07/2013 19:17, David M. Lloyd wrote:
>
> Your phrasing makes me think I missed something: is the 
> Reflection.getCallerClass() method being removed due to some technical 
> issue that it can only be somehow emulated as a workaround?  Or is it 
> just a general cleanup effort?
>
The sun.reflect.Reflection.getCallerClass(int) method was removed as 
part of JEP 176 [1].

-Alan.

[1] http://openjdk.java.net/jeps/176



From masayoshi.okutsu at oracle.com  Tue Jul 30 04:31:52 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 30 Jul 2013 13:31:52 +0900
Subject: RFR: java.time test bug
In-Reply-To: <51F72B96.4050407@Oracle.com>
References: <51F72B96.4050407@Oracle.com>
Message-ID: <51F741B8.9020903@oracle.com>

Looks good to me.

Masayoshi

On 7/30/2013 11:57 AM, Roger Riggs wrote:
> Please help review (and commit to jdk-tl or jdk) this java.time test bug
>
> 8021767 : 
> test/java/time/tck/java/time/format/TCKFormatStyle.java failing
>   Correct to use fixed locale; not locale of test environment
>
> The test incorrectly uses the locale of the test environment and thus
> fails in some environments.
>
> Please review the webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-8021767-fixedlocale/
>
> Thanks, Roger
>



From Alan.Bateman at oracle.com  Tue Jul 30 04:37:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Jul 2013 21:37:36 -0700
Subject: RFR: java.time test bug
In-Reply-To: <51F72B96.4050407@Oracle.com>
References: <51F72B96.4050407@Oracle.com>
Message-ID: <51F74310.10304@oracle.com>

On 29/07/2013 19:57, Roger Riggs wrote:
> Please help review (and commit to jdk-tl or jdk) this java.time test bug
>
> 8021767 : 
> test/java/time/tck/java/time/format/TCKFormatStyle.java failing
>   Correct to use fixed locale; not locale of test environment
>
> The test incorrectly uses the locale of the test environment and thus
> fails in some environments.
>
> Please review the webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-8021767-fixedlocale/
>
> Thanks, Roger
>
I've been running into this, the fix looks good to me.

-Alan.


From joe.darcy at oracle.com  Tue Jul 30 04:59:07 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Mon, 29 Jul 2013 21:59:07 -0700
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F741B1.7020008@oracle.com>
References: 
	<51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com>
	<51F741B1.7020008@oracle.com>
Message-ID: <51F7481B.1080903@oracle.com>


On 7/29/2013 9:31 PM, Alan Bateman wrote:
> On 29/07/2013 19:17, David M. Lloyd wrote:
>>
>> Your phrasing makes me think I missed something: is the 
>> Reflection.getCallerClass() method being removed due to some 
>> technical issue that it can only be somehow emulated as a 
>> workaround?  Or is it just a general cleanup effort?
>>
> The sun.reflect.Reflection.getCallerClass(int) method was removed as 
> part of JEP 176 [1].
>
> -Alan.
>
> [1] http://openjdk.java.net/jeps/176
>

And as a sun.* method, this was officially outside of the exported 
interface of the JDK and not something that should be expected to work 
if called from outside of the JDK:

http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html

-Joe


From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 04:58:47 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 29 Jul 2013 23:58:47 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7481B.1080903@oracle.com>
References: 
	<51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com>
	<51F741B1.7020008@oracle.com> <51F7481B.1080903@oracle.com>
Message-ID: <4C7F7BA9-F099-49BE-BC1D-C7ADD0F4850A@nicholaswilliams.net>


On Jul 29, 2013, at 11:59 PM, Joseph Darcy wrote:

> 
> On 7/29/2013 9:31 PM, Alan Bateman wrote:
>> On 29/07/2013 19:17, David M. Lloyd wrote:
>>> 
>>> Your phrasing makes me think I missed something: is the Reflection.getCallerClass() method being removed due to some technical issue that it can only be somehow emulated as a workaround?  Or is it just a general cleanup effort?
>>> 
>> The sun.reflect.Reflection.getCallerClass(int) method was removed as part of JEP 176 [1].
>> 
>> -Alan.
>> 
>> [1] http://openjdk.java.net/jeps/176
>> 
> 
> And as a sun.* method, this was officially outside of the exported interface of the JDK and not something that should be expected to work if called from outside of the JDK.

As has been said many, many times in the last few days, we are all well aware of this. It doesn't make the problem any less disastrous for the community. This needs to be replaced with a public API.

Nick

From paul.sandoz at oracle.com  Tue Jul 30 10:53:37 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Jul 2013 11:53:37 +0100
Subject: RFR 8021863: Stream.concat incorrectly calculates unsized state
Message-ID: <7E3DF7C4-32CD-4731-9C10-C38FAE0BB4B8@oracle.com>

Hi,

http://cr.openjdk.java.net/~psandoz/tl/JDK-8021863-concat-size/webrev/

This patch just tidies up calculating whether the concatenating spliterator is unsized or not before splitting. There was a typo when checking spliterator characteristics, but it turns out the characteristics do not need to be checked. Some tests are also added.

Paul.

From paul.sandoz at oracle.com  Tue Jul 30 11:02:23 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Jul 2013 12:02:23 +0100
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <51F7286C.9000508@oracle.com>
References: <51F72532.3010101@oracle.com> <51F7286C.9000508@oracle.com>
Message-ID: <9CF21EB7-5B38-467E-A8E4-A6E155D3DEA7@oracle.com>


On Jul 30, 2013, at 3:43 AM, Henry Jen  wrote:

> Sorry, the webrev is at
> 
> http://cr.openjdk.java.net/~henryjen/tl/8020977/0/webrev/
> 

Looks ok to me.

Paul.


From jhuxhorn at googlemail.com  Tue Jul 30 12:01:00 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Tue, 30 Jul 2013 14:01:00 +0200
Subject: =?UTF-8?Q?Re=3A_Classes_on_the_stack_trace_(was=3A_getElementClass/StackTraceElement=2C_was=3A_=40CallerSensitive_public_API=2C_was=3A_sun.reflect.Reflection.getCallerClass)?=
In-Reply-To: <4C7F7BA9-F099-49BE-BC1D-C7ADD0F4850A@nicholaswilliams.net>
References: 
	<51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com>
	<51F741B1.7020008@oracle.com> <51F7481B.1080903@oracle.com>
	<4C7F7BA9-F099-49BE-BC1D-C7ADD0F4850A@nicholaswilliams.net>
Message-ID: 

This whole issue started with the "fix" of http://bugs.sun.com/view_bug.do?bug_id=8016814 because, obviously, throwing an UnsupportedOperationException is a straightforward and reasonable way of fixing an off-by-one problem with the description "returns the wrong stack frame" (see http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html).
Bonus points for doing this instead of just applying the "1-line fix" in the comments of that bug report. I'm pretty sure that this exception wasn't the kind of fix the reporter of the bug was looking for. (Yes, I know. The 1-line fix was applied and is executing if the JVM parameter is set - but this is not my point.)

Ironically, the comment on the "fix" regarded a sudden, unexpected RuntimeException in an unknown amount of third-party code as "Low risk.".

This is justified by http://bugs.sun.com/view_bug.do?bug_id=8014925 (created on 2013-05-20 - which is just the blink of an eye in Java time. To put it into perspective: we missed the tenth birthday of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444 which requested this functionality in a proper public API) which contains the following paragraph:

> The following describes the transition plan to allow customers to migrate their applications away from this private API:
> 1. Disable sun.reflect.Reflection.getCallerClass(int) in 7u40 and provide a flag to re-enable it
> 2. Determine how this private API is being used and the use cases
> 3. Remove this private API if there is no valid use case or there is a proper replacement for it. Allow at least 2 CPU releases to allow customers to make appropriate change. ?So the earliest for the removal is 7u55. ?If there are valid use cases but no proper replacement, we may keep this private API in jdk7u for longer.

With regards to 3., I think we were able to give examples of "valid use cases" for this API.

If the only alternatives available are either slow and fragile (100x slower, achieved by extending SecurityManager for the sake of calling the protected getClassContext() method, will break if the RuntimePermission "createSecurityManager" is not granted by a possibly installed SecurityManager) or even slower (450x slower, using Throwable) then this is a showstopper, especially if the code is executed?literally?millions of times, as is the case with logging calls.

Yes. It sucks that a private API call is necessary. Yep, one should not depend on such a private API. But the RFE to rectify this has been idling for more than ten years and the performance impact of *not* using it is substantial.

The j7u40 change will result in lots of applications simply going BOOM or acting weird after updating which in turn will slow the adoption of Java updates. And that isn't a good idea at all with regards to security fixes. It will likely also prevent reasonable adoption rates for Java 8. Why should I choose a new Java version if it results in a significantly slower overall speed of my applications? If all third-party libraries using the API have been updated so that the application will work at all.

There's really only one rational way to handle this situation:
- Remove the UnsupportedOperationException from j7u40 und higher Java 7 versions.
- Restore sun.reflect.Reflection in Java 8.
- Define a proper public API (TBD) with similar performance to the private API, as requested ten years ago, for Java 9. This functionality is available in .NET since 1.1, as previously mentioned.

Anything else will simply hurt the Java platform as a whole and reaffirm the "Java is slow" mantra. If keeping the "but this wasn't part of the public API so we did nothing wrong" stance is worth all of this then feel free to just ignore our objections.

Seriously, I fail to understand how something like this could have passed the QA. See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough estimate about the impact of this change. This is probably one of the most used private Java API calls, ever.

Cheers,
J?rn.

On 30. Juli 2013 at 06:59:53, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:


On Jul 29, 2013, at 11:59 PM, Joseph Darcy wrote:  

>  
> On 7/29/2013 9:31 PM, Alan Bateman wrote:  
>> On 29/07/2013 19:17, David M. Lloyd wrote:  
>>>  
>>> Your phrasing makes me think I missed something: is the Reflection.getCallerClass() method being removed due to some technical issue that it can only be somehow emulated as a workaround? Or is it just a general cleanup effort?  
>>>  
>> The sun.reflect.Reflection.getCallerClass(int) method was removed as part of JEP 176 [1].  
>>  
>> -Alan.  
>>  
>> [1] http://openjdk.java.net/jeps/176  
>>  
>  
> And as a sun.* method, this was officially outside of the exported interface of the JDK and not something that should be expected to work if called from outside of the JDK.  

As has been said many, many times in the last few days, we are all well aware of this. It doesn't make the problem any less disastrous for the community. This needs to be replaced with a public API.  

Nick


From peter.levart at gmail.com  Tue Jul 30 12:17:50 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 30 Jul 2013 14:17:50 +0200
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: 
References: 
Message-ID: <51F7AEEE.4040305@gmail.com>


On 07/27/2013 09:01 PM, Nick Williams wrote:
> All,
>
> In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted to consolidate it all into this one discussion where I hope we can finalize on a solution and get it implemented for Java 8.
>
> In a nut shell, here are the underlying needs that I have seen expressed through many, many messages:
>
> - Some code needs to get the Class of the caller of the current method, skipping any reflection methods.
> - Some code needs to get the Class of the caller /n/ stack frames before the current method, skipping any reflection methods.
> - Some code needs to get the current stack trace, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
> - Some code needs to get the stack trace from when a Throwable was created, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
> - There needs to be a reflection way to achieve all of this since some libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and 8 (and thus can't use @CallerSensitive).
>
> I believe the solutions to these needs are all related. Importantly, I think it is very important that action be taken in Java 8 due to the changes made to sun.reflect.Reflection#getCallerClass(...). While we all understand that relying on private sun.* APIs is not safe, the fact is that many people have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact that there is simply no other way to do this in the standard API. This includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will stop working correctly in Java 7 >= u25.

Hi,

The needs described above may seem related, but from what I see in this 
commit:

     http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da6addef956e

my observations are as following (please comment if I missed or 
misunderstood anything):

sun.reflect.Reflection.getCallerClass(int) is/was used internally in JDK 
more or less for different purposes than outside the JDK. Inside it was 
used basically for implementing security-sensitive checks like 
optimizations for public methods which can avoid calling SecurityManager 
API wen called from withing JDK classes. It was used for 
security-unrelated purposes too, like for example Class.forName(String) 
or ResourceBundle.getBundle(String). All internal JDK uses do share one 
common thing though: it is very important that the right direct caller 
of a caller-sensitive method is established, since any failure to do so 
can have devastating effect on security or correctness.

The API taking an "int" to count the frames between the top of the 
call-stack to the indirect caller was convenient, but too fragile to 
support such important use cases. Every time some code was refactored, 
there was danger that some call-frame was inadvertently inserted or 
removed. So I think it was decided to "cripple" the API to only support 
obtaining the immediate caller of the method making call to the 
Reflection.getCallerClass() and all uses modified accordingly to make 
the internal JDK code more robust to refactorings.

And there's also MethodHandles which are early-bound. Meaning that the 
caller is established and bound when the MethodHandle instance is 
looked-up. The "lookupClass" which is associated with the Lookup object 
and used in permission checks when obtaining MHs is also used as the 
bound caller class when the MH is invoked. Now there's a method:

java.lang.invoke.MethodHandles.Lookup {
     public java.lang.invoke.MethodHandles.Lookup in(java.lang.Class 
requestedLookupClass)

that returns a Lookup object which reports a different "lookupClass" and 
has capabilities to lookup MHs which are combined from capabilities of 
the original Lookup object and new lookupClass (tipicaly less, never 
more). Most of such Lookup objects are prevented from looking-up MHs for 
caller-sensitive methods, since they could be used to "pose" as a caller 
that is not the one having obtained the MH and therefore gain access to 
restricted resource, for example:

MethodHandle mh = MethodHandles.lookup().in(Object.class).lookupXXX(....)

...such mh could be used to pose as being called from withing Object if 
allowed to be obtained for caller-sensitive methods. So here comes 
@CallerSensitive annotation to mark such methods and prevent such 
lookups (before that - in JDK7, all internal caller-sensitive methods 
were hand-maintained in a list).

So this is, what I think, the background and rationale for changing the API.

For outside JDK use, I think there are two main needs, which are 
actually distinct:

a) the caller-sensitive methods
b) anything else that is not caller-sensitive, but wants to fiddle with 
the call-stack

For caller-sensitive methods, the approach taken with new 
Reflection.getCallerClass() is the right one, I think. There's no need 
to support a fragile API when caller-sensitivity is concerned, so the 
lack of "int" parameter, combined with annotation for marking such 
methods is correct approach, I think. The refactorings to support this 
change in JDK show that this API is adequate. The "surface" public API 
methods must capture the caller class and pass it down the internal API 
where it can be used.

So what would give Groovy or other language runtimes headaches when all 
there was was a parameter-less getCallerClass() API? Aren't the 
intermediate frames inserted by those runtimes controlled by the 
runtimes? Couldn't the "surface" runtime-inserted methods capture the 
caller and pass it down? I guess the problem is supporting calling the 
caller-sensitive methods like Class.forName(String) and such which don't 
have the overloaded variant taking caller Class or ClassLoader as an 
argument...

John Rose suggested to "capture" the caller in the "surface" method and 
bind it with a MethodHandle and then pass such MH down the runtime API 
and finally call that method via MH. For that to work, two problems 
would have to be resolved first:

1) the runtime-inserted "surface" method would have to be annotated with 
@CallerSensitive so that illegal "posers" could be prevented
2) this "surface" method would have to be given permission to "pose as" 
the caller class when looking-up the MethodHandle of the target 
caller-sensitive method.

The 1st part is not a problem I think, but the 2nd part is a problem. 
What makes the runtime-inserted "surface" method so special that it can 
be allowed to "pose" as its caller?

Now that is the question for mlvm-dev mailing list: Isn't preventing 
almost all Lookup objects obtained by 
Lookup.in(RequestedLookupClass.class) from obtaining MHs of 
@CallerSensitive methods too restrictive?

Currently classes are only allowed to "pose as" it's nest-mate classes - 
the classes that share the same outermost enclosing class, since the 
check to look-up @CallerSensitive methods is based on the ability to 
look-up PRIVATE members. So the ability to "pose as" another class when 
binding caller already exists even for @CallerSensitive methods, just 
the restriction is too conservative, isn't it?

Perhaps a class that is visible from the calling class could be allowed 
to look-up MHs of @CallerSensitive methods and "pose" as the calling 
class, bearing all other security checks for combined abilities have 
passed. For example, why wouldn't class A be allowed to "pose as" class 
B if they are loaded by the same ClassLoader or if class B is loaded by 
a ClassLoader that directly or indirectly delegates to the ClassLoader 
of class A?

These are my thoughts about caller-sensitivity and why I think it 
requires special restricted API. Anything else that needs to examine the 
whole call-stack is a separate need that is not infected by the strict 
constraints of caller-sensitivity and for that purpose an API like the 
one presented below (StackTraceFrame) is a good starting-point, maybe it 
just doesn't need the static getCallerFrame() method which suggests that 
it's use is for implementing caller-sensitive methods.

Regards, Peter

> I would point out that this could all easily be solved simply by adding a getElementClass() method to StackTraceElement, but there was strong opposition to this, largely due to serialization issues. Since that is apparently not an option, I propose the following API, based on the various discussions in the last two months, StackTraceElement, and the API that .NET provides to achieve the same needs as listed above:
>
> CallerSensitive.java:
> package java.lang;
>
> /** Previously private API, now public */
> public @interface CallerSensitive {
>      ...
> }
>
> StackTraceFrame.java:
> package java.lang;
>
> import java.util.Objects.
>
> public final class StackTraceFrame {
>      private final Class declaringClass;
>      private final Executable executable;
>      private final String fileName;
>      private final int lineNumber;
>
>      public StackTraceFrame(Class declaringClass, Executable executable, String fileName, int lineNumber) {
>          this.declaringClass = Objects.requireNonNull(declaringClass, "Declaring class is null");
>          this.executable = Objects.requireNonNull(executable, "Executable is null");
>          this.fileName = fileName;
>          this.lineNumber = lineNumber;
>      }
>
>      public Class getDeclaringClass() {
>          return this.declaringClass;
>      }
>
>      public Executable getExecutable() {
>          return this.executable;
>      }
>
>      public String getFileName() {
>          return this.fileName;
>      }
>
>      public int getLineNumber() {
>          return this.lineNumber;
>      }
>
>      public boolean isNative() {
>          return this.lineNumber == -2;
>      }
>
>      public String toString() { /* Same as StackTraceElement */ }
>      public boolean equals() { /* Ditto */ }
>      public int hashCode() { /* Ditto */ }
>
>      /** Uses @CallerSensitive */
>      public static native StackTraceFrame getCallerFrame();
>
>      /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() */
>      public static native StackTraceFrame getCallerFrame(int skipFrames);
>
>      public static native StackTraceFrame[] getCurrentStackTrace();
> }
>
> Throwable.java:
> package java.lang;
>
> ...
>
> public class Throwable {
>      ...
>      public synchronized Throwable fillInStackTraceFrames() { ... }
>
>      private native Throwable fillInStackTraceFrames(int dummy);
>
>      public StackTraceFrame[] getStackTraceFrames() {
>          return this.getOurStackTraceFrames().clone();
>      }
>
>      private synchronized StackTraceFrame[] getOurStackTraceFrames() { ... }
>      ...
> }
>
> Furthermore, I propose that we restore the behavior of sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the proposed above solution cannot be added to Java 7.
>
> I would love if we could quickly coalesce around this solution or a derivative thereof so that it can be implemented before Feature Complete. The absence of any replacement or alternative for sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 that will cause hardships for many projects.
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html



From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 12:25:01 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 07:25:01 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: 
References: 
	<51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com>
	<51F741B1.7020008@oracle.com> <51F7481B.1080903@oracle.com>
	<4C7F7BA9-F099-49BE-BC1D-C7ADD0F4850A@nicholaswilliams.net>
	
Message-ID: 

42 MILLION uses of Reflection.getCallerClass(int) on Ohloh!?!? Holy crap...

In case anyone is interested, I am almost finished implementing the public API StackTraceFrame and associated C/C++ code. It has been an eye-opening experience, but I think I have it figured out now. I just have to write some tests. Looks like installing and configuring jtreg might be more difficult than cloning and compiling JDK was...

Nick

On Jul 30, 2013, at 7:01 AM, J?rn Huxhorn wrote:

> This whole issue started with the "fix" of http://bugs.sun.com/view_bug.do?bug_id=8016814 because, obviously, throwing an UnsupportedOperationException is a straightforward and reasonable way of fixing an off-by-one problem with the description "returns the wrong stack frame" (see http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html).
> Bonus points for doing this instead of just applying the "1-line fix" in the comments of that bug report. I'm pretty sure that this exception wasn't the kind of fix the reporter of the bug was looking for. (Yes, I know. The 1-line fix was applied and is executing if the JVM parameter is set - but this is not my point.)
> 
> Ironically, the comment on the "fix" regarded a sudden, unexpected RuntimeException in an unknown amount of third-party code as "Low risk.".
> 
> This is justified by http://bugs.sun.com/view_bug.do?bug_id=8014925 (created on 2013-05-20 - which is just the blink of an eye in Java time. To put it into perspective: we missed the tenth birthday of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444 which requested this functionality in a proper public API) which contains the following paragraph:
> 
>> The following describes the transition plan to allow customers to migrate their applications away from this private API:
>> 1. Disable sun.reflect.Reflection.getCallerClass(int) in 7u40 and provide a flag to re-enable it
>> 2. Determine how this private API is being used and the use cases
>> 3. Remove this private API if there is no valid use case or there is a proper replacement for it. Allow at least 2 CPU releases to allow customers to make appropriate change.  So the earliest for the removal is 7u55.  If there are valid use cases but no proper replacement, we may keep this private API in jdk7u for longer.
> 
> With regards to 3., I think we were able to give examples of "valid use cases" for this API.
> 
> If the only alternatives available are either slow and fragile (100x slower, achieved by extending SecurityManager for the sake of calling the protected getClassContext() method, will break if the RuntimePermission "createSecurityManager" is not granted by a possibly installed SecurityManager) or even slower (450x slower, using Throwable) then this is a showstopper, especially if the code is executed literally millions of times, as is the case with logging calls.
> 
> Yes. It sucks that a private API call is necessary. Yep, one should not depend on such a private API. But the RFE to rectify this has been idling for more than ten years and the performance impact of *not* using it is substantial.
> 
> The j7u40 change will result in lots of applications simply going BOOM or acting weird after updating which in turn will slow the adoption of Java updates. And that isn't a good idea at all with regards to security fixes. It will likely also prevent reasonable adoption rates for Java 8. Why should I choose a new Java version if it results in a significantly slower overall speed of my applications? If all third-party libraries using the API have been updated so that the application will work at all.
> 
> There's really only one rational way to handle this situation:
> - Remove the UnsupportedOperationException from j7u40 und higher Java 7 versions.
> - Restore sun.reflect.Reflection in Java 8.
> - Define a proper public API (TBD) with similar performance to the private API, as requested ten years ago, for Java 9. This functionality is available in .NET since 1.1, as previously mentioned.
> 
> Anything else will simply hurt the Java platform as a whole and reaffirm the "Java is slow" mantra. If keeping the "but this wasn't part of the public API so we did nothing wrong" stance is worth all of this then feel free to just ignore our objections.
> 
> Seriously, I fail to understand how something like this could have passed the QA. See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough estimate about the impact of this change. This is probably one of the most used private Java API calls, ever.
> 
> Cheers,
> J?rn.
> 
> On 30. Juli 2013 at 06:59:53, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
> 
> 
> On Jul 29, 2013, at 11:59 PM, Joseph Darcy wrote:  
> 
>> 
>> On 7/29/2013 9:31 PM, Alan Bateman wrote:  
>>> On 29/07/2013 19:17, David M. Lloyd wrote:  
>>>> 
>>>> Your phrasing makes me think I missed something: is the Reflection.getCallerClass() method being removed due to some technical issue that it can only be somehow emulated as a workaround? Or is it just a general cleanup effort?  
>>>> 
>>> The sun.reflect.Reflection.getCallerClass(int) method was removed as part of JEP 176 [1].  
>>> 
>>> -Alan.  
>>> 
>>> [1] http://openjdk.java.net/jeps/176  
>>> 
>> 
>> And as a sun.* method, this was officially outside of the exported interface of the JDK and not something that should be expected to work if called from outside of the JDK.  
> 
> As has been said many, many times in the last few days, we are all well aware of this. It doesn't make the problem any less disastrous for the community. This needs to be replaced with a public API.  
> 
> Nick



From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 12:32:56 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 07:32:56 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7AEEE.4040305@gmail.com>
References: 
	<51F7AEEE.4040305@gmail.com>
Message-ID: <257709C4-59DF-4863-859A-C63F95F7C3D0@nicholaswilliams.net>

"For caller-sensitive methods, the approach taken with new Reflection.getCallerClass() is the right one, I think. There's no need to support a fragile API when caller-sensitivity is concerned, so the lack of "int" parameter, combined with annotation for marking such methods is correct approach, I think."

Not when the code running on Java 8 was compiled on Java 6 or 7 and thus can't be annotated @CallerSensitive. In these cases, use of any new public API must use reflection (sudo code: If Java 8, use new public caller-sensitive API), so it needs code that it can pass a number into.

Nick

On Jul 30, 2013, at 7:17 AM, Peter Levart wrote:

> 
> On 07/27/2013 09:01 PM, Nick Williams wrote:
>> All,
>> 
>> In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted to consolidate it all into this one discussion where I hope we can finalize on a solution and get it implemented for Java 8.
>> 
>> In a nut shell, here are the underlying needs that I have seen expressed through many, many messages:
>> 
>> - Some code needs to get the Class of the caller of the current method, skipping any reflection methods.
>> - Some code needs to get the Class of the caller /n/ stack frames before the current method, skipping any reflection methods.
>> - Some code needs to get the current stack trace, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
>> - Some code needs to get the stack trace from when a Throwable was created, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
>> - There needs to be a reflection way to achieve all of this since some libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and 8 (and thus can't use @CallerSensitive).
>> 
>> I believe the solutions to these needs are all related. Importantly, I think it is very important that action be taken in Java 8 due to the changes made to sun.reflect.Reflection#getCallerClass(...). While we all understand that relying on private sun.* APIs is not safe, the fact is that many people have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact that there is simply no other way to do this in the standard API. This includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will stop working correctly in Java 7 >= u25.
> 
> Hi,
> 
> The needs described above may seem related, but from what I see in this commit:
> 
>     http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da6addef956e
> 
> my observations are as following (please comment if I missed or misunderstood anything):
> 
> sun.reflect.Reflection.getCallerClass(int) is/was used internally in JDK more or less for different purposes than outside the JDK. Inside it was used basically for implementing security-sensitive checks like optimizations for public methods which can avoid calling SecurityManager API wen called from withing JDK classes. It was used for security-unrelated purposes too, like for example Class.forName(String) or ResourceBundle.getBundle(String). All internal JDK uses do share one common thing though: it is very important that the right direct caller of a caller-sensitive method is established, since any failure to do so can have devastating effect on security or correctness.
> 
> The API taking an "int" to count the frames between the top of the call-stack to the indirect caller was convenient, but too fragile to support such important use cases. Every time some code was refactored, there was danger that some call-frame was inadvertently inserted or removed. So I think it was decided to "cripple" the API to only support obtaining the immediate caller of the method making call to the Reflection.getCallerClass() and all uses modified accordingly to make the internal JDK code more robust to refactorings.
> 
> And there's also MethodHandles which are early-bound. Meaning that the caller is established and bound when the MethodHandle instance is looked-up. The "lookupClass" which is associated with the Lookup object and used in permission checks when obtaining MHs is also used as the bound caller class when the MH is invoked. Now there's a method:
> 
> java.lang.invoke.MethodHandles.Lookup {
>     public java.lang.invoke.MethodHandles.Lookup in(java.lang.Class requestedLookupClass)
> 
> that returns a Lookup object which reports a different "lookupClass" and has capabilities to lookup MHs which are combined from capabilities of the original Lookup object and new lookupClass (tipicaly less, never more). Most of such Lookup objects are prevented from looking-up MHs for caller-sensitive methods, since they could be used to "pose" as a caller that is not the one having obtained the MH and therefore gain access to restricted resource, for example:
> 
> MethodHandle mh = MethodHandles.lookup().in(Object.class).lookupXXX(....)
> 
> ...such mh could be used to pose as being called from withing Object if allowed to be obtained for caller-sensitive methods. So here comes @CallerSensitive annotation to mark such methods and prevent such lookups (before that - in JDK7, all internal caller-sensitive methods were hand-maintained in a list).
> 
> So this is, what I think, the background and rationale for changing the API.
> 
> For outside JDK use, I think there are two main needs, which are actually distinct:
> 
> a) the caller-sensitive methods
> b) anything else that is not caller-sensitive, but wants to fiddle with the call-stack
> 
> For caller-sensitive methods, the approach taken with new Reflection.getCallerClass() is the right one, I think. There's no need to support a fragile API when caller-sensitivity is concerned, so the lack of "int" parameter, combined with annotation for marking such methods is correct approach, I think. The refactorings to support this change in JDK show that this API is adequate. The "surface" public API methods must capture the caller class and pass it down the internal API where it can be used.
> 
> So what would give Groovy or other language runtimes headaches when all there was was a parameter-less getCallerClass() API? Aren't the intermediate frames inserted by those runtimes controlled by the runtimes? Couldn't the "surface" runtime-inserted methods capture the caller and pass it down? I guess the problem is supporting calling the caller-sensitive methods like Class.forName(String) and such which don't have the overloaded variant taking caller Class or ClassLoader as an argument...
> 
> John Rose suggested to "capture" the caller in the "surface" method and bind it with a MethodHandle and then pass such MH down the runtime API and finally call that method via MH. For that to work, two problems would have to be resolved first:
> 
> 1) the runtime-inserted "surface" method would have to be annotated with @CallerSensitive so that illegal "posers" could be prevented
> 2) this "surface" method would have to be given permission to "pose as" the caller class when looking-up the MethodHandle of the target caller-sensitive method.
> 
> The 1st part is not a problem I think, but the 2nd part is a problem. What makes the runtime-inserted "surface" method so special that it can be allowed to "pose" as its caller?
> 
> Now that is the question for mlvm-dev mailing list: Isn't preventing almost all Lookup objects obtained by Lookup.in(RequestedLookupClass.class) from obtaining MHs of @CallerSensitive methods too restrictive? 
> 
> Currently classes are only allowed to "pose as" it's nest-mate classes - the classes that share the same outermost enclosing class, since the check to look-up @CallerSensitive methods is based on the ability to look-up PRIVATE members. So the ability to "pose as" another class when binding caller already exists even for @CallerSensitive methods, just the restriction is too conservative, isn't it?
> 
> Perhaps a class that is visible from the calling class could be allowed to look-up MHs of @CallerSensitive methods and "pose" as the calling class, bearing all other security checks for combined abilities have passed. For example, why wouldn't class A be allowed to "pose as" class B if they are loaded by the same ClassLoader or if class B is loaded by a ClassLoader that directly or indirectly delegates to the ClassLoader of class A?
> 
> These are my thoughts about caller-sensitivity and why I think it requires special restricted API. Anything else that needs to examine the whole call-stack is a separate need that is not infected by the strict constraints of caller-sensitivity and for that purpose an API like the one presented below (StackTraceFrame) is a good starting-point, maybe it just doesn't need the static getCallerFrame() method which suggests that it's use is for implementing caller-sensitive methods.
> 
> Regards, Peter
> 
>> I would point out that this could all easily be solved simply by adding a getElementClass() method to StackTraceElement, but there was strong opposition to this, largely due to serialization issues. Since that is apparently not an option, I propose the following API, based on the various discussions in the last two months, StackTraceElement, and the API that .NET provides to achieve the same needs as listed above:
>> 
>> CallerSensitive.java:
>> package java.lang;
>> 
>> /** Previously private API, now public */
>> public @interface CallerSensitive {
>>     ...
>> }
>> 
>> StackTraceFrame.java:
>> package java.lang;
>> 
>> import java.util.Objects.
>> 
>> public final class StackTraceFrame {
>>     private final Class declaringClass;
>>     private final Executable executable;
>>     private final String fileName;
>>     private final int lineNumber;
>> 
>>     public StackTraceFrame(Class declaringClass, Executable executable, String fileName, int lineNumber) {
>>         this.declaringClass = Objects.requireNonNull(declaringClass, "Declaring class is null");
>>         this.executable = Objects.requireNonNull(executable, "Executable is null");
>>         this.fileName = fileName;
>>         this.lineNumber = lineNumber;
>>     }
>> 
>>     public Class getDeclaringClass() {
>>         return this.declaringClass;
>>     }
>> 
>>     public Executable getExecutable() {
>>         return this.executable;
>>     }
>> 
>>     public String getFileName() {
>>         return this.fileName;
>>     }
>> 
>>     public int getLineNumber() {
>>         return this.lineNumber;
>>     }
>> 
>>     public boolean isNative() {
>>         return this.lineNumber == -2;
>>     }
>> 
>>     public String toString() { /* Same as StackTraceElement */ }
>>     public boolean equals() { /* Ditto */ }
>>     public int hashCode() { /* Ditto */ }
>> 
>>     /** Uses @CallerSensitive */
>>     public static native StackTraceFrame getCallerFrame();
>> 
>>     /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() */
>>     public static native StackTraceFrame getCallerFrame(int skipFrames);
>> 
>>     public static native StackTraceFrame[] getCurrentStackTrace();
>> }
>> 
>> Throwable.java:
>> package java.lang;
>> 
>> ...
>> 
>> public class Throwable {
>>     ...
>>     public synchronized Throwable fillInStackTraceFrames() { ... }
>> 
>>     private native Throwable fillInStackTraceFrames(int dummy);
>> 
>>     public StackTraceFrame[] getStackTraceFrames() {
>>         return this.getOurStackTraceFrames().clone();
>>     }
>> 
>>     private synchronized StackTraceFrame[] getOurStackTraceFrames() { ... }
>>     ...
>> }
>> 
>> Furthermore, I propose that we restore the behavior of sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the proposed above solution cannot be added to Java 7.
>> 
>> I would love if we could quickly coalesce around this solution or a derivative thereof so that it can be implemented before Feature Complete. The absence of any replacement or alternative for sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 that will cause hardships for many projects.
>> 
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
> 



From chris.hegarty at oracle.com  Tue Jul 30 12:42:58 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 Jul 2013 13:42:58 +0100
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <9CF21EB7-5B38-467E-A8E4-A6E155D3DEA7@oracle.com>
References: <51F72532.3010101@oracle.com> <51F7286C.9000508@oracle.com>
	<9CF21EB7-5B38-467E-A8E4-A6E155D3DEA7@oracle.com>
Message-ID: <51F7B4D2.6030704@oracle.com>

On 07/30/2013 12:02 PM, Paul Sandoz wrote:
>
> On Jul 30, 2013, at 3:43 AM, Henry Jen  wrote:
>
>> Sorry, the webrev is at
>>
>> http://cr.openjdk.java.net/~henryjen/tl/8020977/0/webrev/
>>
>
> Looks ok to me.

+1 looks good to me too.

-Chris.

>
> Paul.
>


From peter.levart at gmail.com  Tue Jul 30 12:45:36 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 30 Jul 2013 14:45:36 +0200
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <257709C4-59DF-4863-859A-C63F95F7C3D0@nicholaswilliams.net>
References: 
	<51F7AEEE.4040305@gmail.com>
	<257709C4-59DF-4863-859A-C63F95F7C3D0@nicholaswilliams.net>
Message-ID: <51F7B570.5040308@gmail.com>

I think there are various techniques to use new API when running on JDK8 
and still use old API when running on JDK6 or 7. One way is to have 2 
classes implementing the same interface or extending basic class where 
one is compiled with JDK6/7 and the other with JDK8. During runtime the 
"correct" implementation is choosen, but code only depends on the 
interface/basic class...

There are other tricks.

But I have an idea. What if Reflection.getCallerClass(int) is restored 
in JDK7 and JDK8 without a @CallerSensitive annotation on it. In order 
to prevent inadvertent internal JDK usage, the method could throw 
exception when called from any internal JDK class...

Regards, Peter


On 07/30/2013 02:32 PM, Nick Williams wrote:
> "For caller-sensitive methods, the approach taken with new 
> Reflection.getCallerClass() is the right one, I think. There's no need 
> to support a fragile API when caller-sensitivity is concerned, so the 
> lack of "int" parameter, combined with annotation for marking such 
> methods is correct approach, I think."
>
> Not when the code running on Java 8 was compiled on Java 6 or 7 and 
> thus can't be annotated @CallerSensitive. In these cases, use of any 
> new public API must use reflection (sudo code: If Java 8, use new 
> public caller-sensitive API), so it needs code that it can pass a 
> number into.
>
> Nick
>
> On Jul 30, 2013, at 7:17 AM, Peter Levart wrote:
>
>>
>> On 07/27/2013 09:01 PM, Nick Williams wrote:
>>> All,
>>>
>>> In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted to consolidate it all into this one discussion where I hope we can finalize on a solution and get it implemented for Java 8.
>>>
>>> In a nut shell, here are the underlying needs that I have seen expressed through many, many messages:
>>>
>>> - Some code needs to get the Class of the caller of the current method, skipping any reflection methods.
>>> - Some code needs to get the Class of the caller /n/ stack frames before the current method, skipping any reflection methods.
>>> - Some code needs to get the current stack trace, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
>>> - Some code needs to get the stack trace from when a Throwable was created, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
>>> - There needs to be a reflection way to achieve all of this since some libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and 8 (and thus can't use @CallerSensitive).
>>>
>>> I believe the solutions to these needs are all related. Importantly, I think it is very important that action be taken in Java 8 due to the changes made to sun.reflect.Reflection#getCallerClass(...). While we all understand that relying on private sun.* APIs is not safe, the fact is that many people have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact that there is simply no other way to do this in the standard API. This includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will stop working correctly in Java 7 >= u25.
>>
>> Hi,
>>
>> The needs described above may seem related, but from what I see in 
>> this commit:
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da6addef956e
>>
>> my observations are as following (please comment if I missed or 
>> misunderstood anything):
>>
>> sun.reflect.Reflection.getCallerClass(int) is/was used internally in 
>> JDK more or less for different purposes than outside the JDK. Inside 
>> it was used basically for implementing security-sensitive checks like 
>> optimizations for public methods which can avoid calling 
>> SecurityManager API wen called from withing JDK classes. It was used 
>> for security-unrelated purposes too, like for example 
>> Class.forName(String) or ResourceBundle.getBundle(String). All 
>> internal JDK uses do share one common thing though: it is very 
>> important that the right direct caller of a caller-sensitive method 
>> is established, since any failure to do so can have devastating 
>> effect on security or correctness.
>>
>> The API taking an "int" to count the frames between the top of the 
>> call-stack to the indirect caller was convenient, but too fragile to 
>> support such important use cases. Every time some code was 
>> refactored, there was danger that some call-frame was inadvertently 
>> inserted or removed. So I think it was decided to "cripple" the API 
>> to only support obtaining the immediate caller of the method making 
>> call to the Reflection.getCallerClass() and all uses modified 
>> accordingly to make the internal JDK code more robust to refactorings.
>>
>> And there's also MethodHandles which are early-bound. Meaning that 
>> the caller is established and bound when the MethodHandle instance is 
>> looked-up. The "lookupClass" which is associated with the Lookup 
>> object and used in permission checks when obtaining MHs is also used 
>> as the bound caller class when the MH is invoked. Now there's a method:
>>
>> java.lang.invoke.MethodHandles.Lookup {
>>     public java.lang.invoke.MethodHandles.Lookup 
>> in(java.lang.Class requestedLookupClass)
>>
>> that returns a Lookup object which reports a different "lookupClass" 
>> and has capabilities to lookup MHs which are combined from 
>> capabilities of the original Lookup object and new lookupClass 
>> (tipicaly less, never more). Most of such Lookup objects are 
>> prevented from looking-up MHs for caller-sensitive methods, since 
>> they could be used to "pose" as a caller that is not the one having 
>> obtained the MH and therefore gain access to restricted resource, for 
>> example:
>>
>> MethodHandle mh = MethodHandles.lookup().in(Object.class).lookupXXX(....)
>>
>> ...such mh could be used to pose as being called from withing Object 
>> if allowed to be obtained for caller-sensitive methods. So here comes 
>> @CallerSensitive annotation to mark such methods and prevent such 
>> lookups (before that - in JDK7, all internal caller-sensitive methods 
>> were hand-maintained in a list).
>>
>> So this is, what I think, the background and rationale for changing 
>> the API.
>>
>> For outside JDK use, I think there are two main needs, which are 
>> actually distinct:
>>
>> a) the caller-sensitive methods
>> b) anything else that is not caller-sensitive, but wants to fiddle 
>> with the call-stack
>>
>> For caller-sensitive methods, the approach taken with new 
>> Reflection.getCallerClass() is the right one, I think. There's no 
>> need to support a fragile API when caller-sensitivity is concerned, 
>> so the lack of "int" parameter, combined with annotation for marking 
>> such methods is correct approach, I think. The refactorings to 
>> support this change in JDK show that this API is adequate. The 
>> "surface" public API methods must capture the caller class and pass 
>> it down the internal API where it can be used.
>>
>> So what would give Groovy or other language runtimes headaches when 
>> all there was was a parameter-less getCallerClass() API? Aren't the 
>> intermediate frames inserted by those runtimes controlled by the 
>> runtimes? Couldn't the "surface" runtime-inserted methods capture the 
>> caller and pass it down? I guess the problem is supporting calling 
>> the caller-sensitive methods like Class.forName(String) and such 
>> which don't have the overloaded variant taking caller Class or 
>> ClassLoader as an argument...
>>
>> John Rose suggested to "capture" the caller in the "surface" method 
>> and bind it with a MethodHandle and then pass such MH down the 
>> runtime API and finally call that method via MH. For that to work, 
>> two problems would have to be resolved first:
>>
>> 1) the runtime-inserted "surface" method would have to be annotated 
>> with @CallerSensitive so that illegal "posers" could be prevented
>> 2) this "surface" method would have to be given permission to "pose 
>> as" the caller class when looking-up the MethodHandle of the target 
>> caller-sensitive method.
>>
>> The 1st part is not a problem I think, but the 2nd part is a problem. 
>> What makes the runtime-inserted "surface" method so special that it 
>> can be allowed to "pose" as its caller?
>>
>> Now that is the question for mlvm-dev mailing list: Isn't preventing 
>> almost all Lookup objects obtained by 
>> Lookup.in(RequestedLookupClass.class) from obtaining MHs of 
>> @CallerSensitive methods too restrictive?
>>
>> Currently classes are only allowed to "pose as" it's nest-mate 
>> classes - the classes that share the same outermost enclosing class, 
>> since the check to look-up @CallerSensitive methods is based on the 
>> ability to look-up PRIVATE members. So the ability to "pose as" 
>> another class when binding caller already exists even for 
>> @CallerSensitive methods, just the restriction is too conservative, 
>> isn't it?
>>
>> Perhaps a class that is visible from the calling class could be 
>> allowed to look-up MHs of @CallerSensitive methods and "pose" as the 
>> calling class, bearing all other security checks for combined 
>> abilities have passed. For example, why wouldn't class A be allowed 
>> to "pose as" class B if they are loaded by the same ClassLoader or if 
>> class B is loaded by a ClassLoader that directly or indirectly 
>> delegates to the ClassLoader of class A?
>>
>> These are my thoughts about caller-sensitivity and why I think it 
>> requires special restricted API. Anything else that needs to examine 
>> the whole call-stack is a separate need that is not infected by the 
>> strict constraints of caller-sensitivity and for that purpose an API 
>> like the one presented below (StackTraceFrame) is a good 
>> starting-point, maybe it just doesn't need the static 
>> getCallerFrame() method which suggests that it's use is for 
>> implementing caller-sensitive methods.
>>
>> Regards, Peter
>>
>>> I would point out that this could all easily be solved simply by adding a getElementClass() method to StackTraceElement, but there was strong opposition to this, largely due to serialization issues. Since that is apparently not an option, I propose the following API, based on the various discussions in the last two months, StackTraceElement, and the API that .NET provides to achieve the same needs as listed above:
>>>
>>> CallerSensitive.java:
>>> package java.lang;
>>>
>>> /** Previously private API, now public */
>>> public @interface CallerSensitive {
>>>      ...
>>> }
>>>
>>> StackTraceFrame.java:
>>> package java.lang;
>>>
>>> import java.util.Objects.
>>>
>>> public final class StackTraceFrame {
>>>      private final Class declaringClass;
>>>      private final Executable executable;
>>>      private final String fileName;
>>>      private final int lineNumber;
>>>
>>>      public StackTraceFrame(Class declaringClass, Executable executable, String fileName, int lineNumber) {
>>>          this.declaringClass = Objects.requireNonNull(declaringClass, "Declaring class is null");
>>>          this.executable = Objects.requireNonNull(executable, "Executable is null");
>>>          this.fileName = fileName;
>>>          this.lineNumber = lineNumber;
>>>      }
>>>
>>>      public Class getDeclaringClass() {
>>>          return this.declaringClass;
>>>      }
>>>
>>>      public Executable getExecutable() {
>>>          return this.executable;
>>>      }
>>>
>>>      public String getFileName() {
>>>          return this.fileName;
>>>      }
>>>
>>>      public int getLineNumber() {
>>>          return this.lineNumber;
>>>      }
>>>
>>>      public boolean isNative() {
>>>          return this.lineNumber == -2;
>>>      }
>>>
>>>      public String toString() { /* Same as StackTraceElement */ }
>>>      public boolean equals() { /* Ditto */ }
>>>      public int hashCode() { /* Ditto */ }
>>>
>>>      /** Uses @CallerSensitive */
>>>      public static native StackTraceFrame getCallerFrame();
>>>
>>>      /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() */
>>>      public static native StackTraceFrame getCallerFrame(int skipFrames);
>>>
>>>      public static native StackTraceFrame[] getCurrentStackTrace();
>>> }
>>>
>>> Throwable.java:
>>> package java.lang;
>>>
>>> ...
>>>
>>> public class Throwable {
>>>      ...
>>>      public synchronized Throwable fillInStackTraceFrames() { ... }
>>>
>>>      private native Throwable fillInStackTraceFrames(int dummy);
>>>
>>>      public StackTraceFrame[] getStackTraceFrames() {
>>>          return this.getOurStackTraceFrames().clone();
>>>      }
>>>
>>>      private synchronized StackTraceFrame[] getOurStackTraceFrames() { ... }
>>>      ...
>>> }
>>>
>>> Furthermore, I propose that we restore the behavior of sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the proposed above solution cannot be added to Java 7.
>>>
>>> I would love if we could quickly coalesce around this solution or a derivative thereof so that it can be implemented before Feature Complete. The absence of any replacement or alternative for sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 that will cause hardships for many projects.
>>>
>>> [1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>>> [2]http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html,http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>>> [3]http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>>
>



From jhuxhorn at googlemail.com  Tue Jul 30 12:50:45 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Tue, 30 Jul 2013 14:50:45 +0200
Subject: =?UTF-8?Q?Re=3A_Classes_on_the_stack_trace_(was=3A_getElementClass/StackTraceElement=2C_was=3A_=40CallerSensitive_public_API=2C_was=3A_sun.reflect.Reflection.getCallerClass)?=
In-Reply-To: <257709C4-59DF-4863-859A-C63F95F7C3D0@nicholaswilliams.net>
References: 
	<51F7AEEE.4040305@gmail.com>
	<257709C4-59DF-4863-859A-C63F95F7C3D0@nicholaswilliams.net>
Message-ID: 

Omitting the "int" parameter would be a bad idea since it would prevent wrappers. One could imagine a common interface to obtain the caller class where the proper implementation is chosen via fallback, e.g.

- if available, use our new API (fastest?)
- else, try to use Reflection.getCallerClass (fast)
- else, use Throwable (slow)

This would guarantee that the caller class could be obtained in some way, albeit probably much slower. That would not by possible if the implementation would only provide access to the direct caller since that would always be the wrapper class. But something like this would be the most backwards compatible way (probably the only one, right?) to use that functionality in projects like logback and log4j that are still required to support Java 6 or even Java 5.

On 30. Juli 2013 at 14:33:48, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:

"For caller-sensitive methods, the approach taken with new Reflection.getCallerClass() is the right one, I think. There's no need to support a fragile API when caller-sensitivity is concerned, so the lack of "int" parameter, combined with annotation for marking such methods is correct approach, I think."  

Not when the code running on Java 8 was compiled on Java 6 or 7 and thus can't be annotated @CallerSensitive. In these cases, use of any new public API must use reflection (sudo code: If Java 8, use new public caller-sensitive API), so it needs code that it can pass a number into.  

Nick  

On Jul 30, 2013, at 7:17 AM, Peter Levart wrote:  

>  
> On 07/27/2013 09:01 PM, Nick Williams wrote:  
>> All,  
>>  
>> In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted to consolidate it all into this one discussion where I hope we can finalize on a solution and get it implemented for Java 8.  
>>  
>> In a nut shell, here are the underlying needs that I have seen expressed through many, many messages:  
>>  
>> - Some code needs to get the Class of the caller of the current method, skipping any reflection methods.  
>> - Some code needs to get the Class of the caller /n/ stack frames before the current method, skipping any reflection methods.  
>> - Some code needs to get the current stack trace, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.  
>> - Some code needs to get the stack trace from when a Throwable was created, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.  
>> - There needs to be a reflection way to achieve all of this since some libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and 8 (and thus can't use @CallerSensitive).  
>>  
>> I believe the solutions to these needs are all related. Importantly, I think it is very important that action be taken in Java 8 due to the changes made to sun.reflect.Reflection#getCallerClass(...). While we all understand that relying on private sun.* APIs is not safe, the fact is that many people have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact that there is simply no other way to do this in the standard API. This includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will stop working correctly in Java 7 >= u25.  
>  
> Hi,  
>  
> The needs described above may seem related, but from what I see in this commit:  
>  
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da6addef956e  
>  
> my observations are as following (please comment if I missed or misunderstood anything):  
>  
> sun.reflect.Reflection.getCallerClass(int) is/was used internally in JDK more or less for different purposes than outside the JDK. Inside it was used basically for implementing security-sensitive checks like optimizations for public methods which can avoid calling SecurityManager API wen called from withing JDK classes. It was used for security-unrelated purposes too, like for example Class.forName(String) or ResourceBundle.getBundle(String). All internal JDK uses do share one common thing though: it is very important that the right direct caller of a caller-sensitive method is established, since any failure to do so can have devastating effect on security or correctness.  
>  
> The API taking an "int" to count the frames between the top of the call-stack to the indirect caller was convenient, but too fragile to support such important use cases. Every time some code was refactored, there was danger that some call-frame was inadvertently inserted or removed. So I think it was decided to "cripple" the API to only support obtaining the immediate caller of the method making call to the Reflection.getCallerClass() and all uses modified accordingly to make the internal JDK code more robust to refactorings.  
>  
> And there's also MethodHandles which are early-bound. Meaning that the caller is established and bound when the MethodHandle instance is looked-up. The "lookupClass" which is associated with the Lookup object and used in permission checks when obtaining MHs is also used as the bound caller class when the MH is invoked. Now there's a method:  
>  
> java.lang.invoke.MethodHandles.Lookup {  
> public java.lang.invoke.MethodHandles.Lookup in(java.lang.Class requestedLookupClass)  
>  
> that returns a Lookup object which reports a different "lookupClass" and has capabilities to lookup MHs which are combined from capabilities of the original Lookup object and new lookupClass (tipicaly less, never more). Most of such Lookup objects are prevented from looking-up MHs for caller-sensitive methods, since they could be used to "pose" as a caller that is not the one having obtained the MH and therefore gain access to restricted resource, for example:  
>  
> MethodHandle mh = MethodHandles.lookup().in(Object.class).lookupXXX(....)  
>  
> ...such mh could be used to pose as being called from withing Object if allowed to be obtained for caller-sensitive methods. So here comes @CallerSensitive annotation to mark such methods and prevent such lookups (before that - in JDK7, all internal caller-sensitive methods were hand-maintained in a list).  
>  
> So this is, what I think, the background and rationale for changing the API.  
>  
> For outside JDK use, I think there are two main needs, which are actually distinct:  
>  
> a) the caller-sensitive methods  
> b) anything else that is not caller-sensitive, but wants to fiddle with the call-stack  
>  
> For caller-sensitive methods, the approach taken with new Reflection.getCallerClass() is the right one, I think. There's no need to support a fragile API when caller-sensitivity is concerned, so the lack of "int" parameter, combined with annotation for marking such methods is correct approach, I think. The refactorings to support this change in JDK show that this API is adequate. The "surface" public API methods must capture the caller class and pass it down the internal API where it can be used.  
>  
> So what would give Groovy or other language runtimes headaches when all there was was a parameter-less getCallerClass() API? Aren't the intermediate frames inserted by those runtimes controlled by the runtimes? Couldn't the "surface" runtime-inserted methods capture the caller and pass it down? I guess the problem is supporting calling the caller-sensitive methods like Class.forName(String) and such which don't have the overloaded variant taking caller Class or ClassLoader as an argument...  
>  
> John Rose suggested to "capture" the caller in the "surface" method and bind it with a MethodHandle and then pass such MH down the runtime API and finally call that method via MH. For that to work, two problems would have to be resolved first:  
>  
> 1) the runtime-inserted "surface" method would have to be annotated with @CallerSensitive so that illegal "posers" could be prevented  
> 2) this "surface" method would have to be given permission to "pose as" the caller class when looking-up the MethodHandle of the target caller-sensitive method.  
>  
> The 1st part is not a problem I think, but the 2nd part is a problem. What makes the runtime-inserted "surface" method so special that it can be allowed to "pose" as its caller?  
>  
> Now that is the question for mlvm-dev mailing list: Isn't preventing almost all Lookup objects obtained by Lookup.in(RequestedLookupClass.class) from obtaining MHs of @CallerSensitive methods too restrictive?  
>  
> Currently classes are only allowed to "pose as" it's nest-mate classes - the classes that share the same outermost enclosing class, since the check to look-up @CallerSensitive methods is based on the ability to look-up PRIVATE members. So the ability to "pose as" another class when binding caller already exists even for @CallerSensitive methods, just the restriction is too conservative, isn't it?  
>  
> Perhaps a class that is visible from the calling class could be allowed to look-up MHs of @CallerSensitive methods and "pose" as the calling class, bearing all other security checks for combined abilities have passed. For example, why wouldn't class A be allowed to "pose as" class B if they are loaded by the same ClassLoader or if class B is loaded by a ClassLoader that directly or indirectly delegates to the ClassLoader of class A?  
>  
> These are my thoughts about caller-sensitivity and why I think it requires special restricted API. Anything else that needs to examine the whole call-stack is a separate need that is not infected by the strict constraints of caller-sensitivity and for that purpose an API like the one presented below (StackTraceFrame) is a good starting-point, maybe it just doesn't need the static getCallerFrame() method which suggests that it's use is for implementing caller-sensitive methods.  
>  
> Regards, Peter  
>  
>> I would point out that this could all easily be solved simply by adding a getElementClass() method to StackTraceElement, but there was strong opposition to this, largely due to serialization issues. Since that is apparently not an option, I propose the following API, based on the various discussions in the last two months, StackTraceElement, and the API that .NET provides to achieve the same needs as listed above:  
>>  
>> CallerSensitive.java:  
>> package java.lang;  
>>  
>> /** Previously private API, now public */  
>> public @interface CallerSensitive {  
>> ...  
>> }  
>>  
>> StackTraceFrame.java:  
>> package java.lang;  
>>  
>> import java.util.Objects.  
>>  
>> public final class StackTraceFrame {  
>> private final Class declaringClass;  
>> private final Executable executable;  
>> private final String fileName;  
>> private final int lineNumber;  
>>  
>> public StackTraceFrame(Class declaringClass, Executable executable, String fileName, int lineNumber) {  
>> this.declaringClass = Objects.requireNonNull(declaringClass, "Declaring class is null");  
>> this.executable = Objects.requireNonNull(executable, "Executable is null");  
>> this.fileName = fileName;  
>> this.lineNumber = lineNumber;  
>> }  
>>  
>> public Class getDeclaringClass() {  
>> return this.declaringClass;  
>> }  
>>  
>> public Executable getExecutable() {  
>> return this.executable;  
>> }  
>>  
>> public String getFileName() {  
>> return this.fileName;  
>> }  
>>  
>> public int getLineNumber() {  
>> return this.lineNumber;  
>> }  
>>  
>> public boolean isNative() {  
>> return this.lineNumber == -2;  
>> }  
>>  
>> public String toString() { /* Same as StackTraceElement */ }  
>> public boolean equals() { /* Ditto */ }  
>> public int hashCode() { /* Ditto */ }  
>>  
>> /** Uses @CallerSensitive */  
>> public static native StackTraceFrame getCallerFrame();  
>>  
>> /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() */  
>> public static native StackTraceFrame getCallerFrame(int skipFrames);  
>>  
>> public static native StackTraceFrame[] getCurrentStackTrace();  
>> }  
>>  
>> Throwable.java:  
>> package java.lang;  
>>  
>> ...  
>>  
>> public class Throwable {  
>> ...  
>> public synchronized Throwable fillInStackTraceFrames() { ... }  
>>  
>> private native Throwable fillInStackTraceFrames(int dummy);  
>>  
>> public StackTraceFrame[] getStackTraceFrames() {  
>> return this.getOurStackTraceFrames().clone();  
>> }  
>>  
>> private synchronized StackTraceFrame[] getOurStackTraceFrames() { ... }  
>> ...  
>> }  
>>  
>> Furthermore, I propose that we restore the behavior of sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the proposed above solution cannot be added to Java 7.  
>>  
>> I would love if we could quickly coalesce around this solution or a derivative thereof so that it can be implemented before Feature Complete. The absence of any replacement or alternative for sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 that will cause hardships for many projects.  
>>  
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html  
>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html  
>> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html  
>


From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 12:53:18 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 07:53:18 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7B570.5040308@gmail.com>
References: 
	<51F7AEEE.4040305@gmail.com>
	<257709C4-59DF-4863-859A-C63F95F7C3D0@nicholaswilliams.net>
	<51F7B570.5040308@gmail.com>
Message-ID: <09D9E046-9E10-4453-9E46-FB340240F113@nicholaswilliams.net>


On Jul 30, 2013, at 7:45 AM, Peter Levart wrote:

> I think there are various techniques to use new API when running on JDK8 and still use old API when running on JDK6 or 7. One way is to have 2 classes implementing the same interface or extending basic class where one is compiled with JDK6/7 and the other with JDK8. During runtime the "correct" implementation is choosen, but code only depends on the interface/basic class?

Now there's an interesting idea I hadn't considered. It sure wouldn't be easy, though. It would make it harder for projects to fix bugs related to this when discovered, and still slow down adoption of Java 8.

> 
> There are other tricks.
> 
> But I have an idea. What if Reflection.getCallerClass(int) is restored in JDK7 and JDK8 without a @CallerSensitive annotation on it. In order to prevent inadvertent internal JDK usage, the method could throw exception when called from any internal JDK class?

I think this MUST happen in Java 7, because adding a public API isn't an option there. As for Java 8, I'm almost done with StackTraceFrame and associated C/C++ code, and it includes both an @CallerSensitive getCallerClass() method and a getCallerClass(int) method. While I would prefer your option for Java 8 over what we have now (obviously), the public StackTraceFrame API is a better approach by the mere fact of being public (and universally available on all JVMs).

Nick

> 
> Regards, Peter
> 
> 
> On 07/30/2013 02:32 PM, Nick Williams wrote:
>> "For caller-sensitive methods, the approach taken with new Reflection.getCallerClass() is the right one, I think. There's no need to support a fragile API when caller-sensitivity is concerned, so the lack of "int" parameter, combined with annotation for marking such methods is correct approach, I think."
>> 
>> Not when the code running on Java 8 was compiled on Java 6 or 7 and thus can't be annotated @CallerSensitive. In these cases, use of any new public API must use reflection (sudo code: If Java 8, use new public caller-sensitive API), so it needs code that it can pass a number into.
>> 
>> Nick
>> 
>> On Jul 30, 2013, at 7:17 AM, Peter Levart wrote:
>> 
>>> 
>>> On 07/27/2013 09:01 PM, Nick Williams wrote:
>>>> All,
>>>> 
>>>> In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted to consolidate it all into this one discussion where I hope we can finalize on a solution and get it implemented for Java 8.
>>>> 
>>>> In a nut shell, here are the underlying needs that I have seen expressed through many, many messages:
>>>> 
>>>> - Some code needs to get the Class of the caller of the current method, skipping any reflection methods.
>>>> - Some code needs to get the Class of the caller /n/ stack frames before the current method, skipping any reflection methods.
>>>> - Some code needs to get the current stack trace, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
>>>> - Some code needs to get the stack trace from when a Throwable was created, populated with Classes, Executables, file names, line numbers, and native flags instead of the String class names and String method names in StackTraceElement. This /should/ include any reflection methods, just like StackTraceElement[]s.
>>>> - There needs to be a reflection way to achieve all of this since some libraries (e.g., Log4j) need to be compiled against Java 6 but run on 7 and 8 (and thus can't use @CallerSensitive).
>>>> 
>>>> I believe the solutions to these needs are all related. Importantly, I think it is very important that action be taken in Java 8 due to the changes made to sun.reflect.Reflection#getCallerClass(...). While we all understand that relying on private sun.* APIs is not safe, the fact is that many people have relied on sun.reflect.Reflection#getCallerClass(...) due to the fact that there is simply no other way to do this in the standard API. This includes Log4j 2, Logback, SLF4j, and Groovy, some features of which will stop working correctly in Java 7 >= u25.
>>> 
>>> Hi,
>>> 
>>> The needs described above may seem related, but from what I see in this commit:
>>> 
>>>     http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da6addef956e
>>> 
>>> my observations are as following (please comment if I missed or misunderstood anything):
>>> 
>>> sun.reflect.Reflection.getCallerClass(int) is/was used internally in JDK more or less for different purposes than outside the JDK. Inside it was used basically for implementing security-sensitive checks like optimizations for public methods which can avoid calling SecurityManager API wen called from withing JDK classes. It was used for security-unrelated purposes too, like for example Class.forName(String) or ResourceBundle.getBundle(String). All internal JDK uses do share one common thing though: it is very important that the right direct caller of a caller-sensitive method is established, since any failure to do so can have devastating effect on security or correctness.
>>> 
>>> The API taking an "int" to count the frames between the top of the call-stack to the indirect caller was convenient, but too fragile to support such important use cases. Every time some code was refactored, there was danger that some call-frame was inadvertently inserted or removed. So I think it was decided to "cripple" the API to only support obtaining the immediate caller of the method making call to the Reflection.getCallerClass() and all uses modified accordingly to make the internal JDK code more robust to refactorings.
>>> 
>>> And there's also MethodHandles which are early-bound. Meaning that the caller is established and bound when the MethodHandle instance is looked-up. The "lookupClass" which is associated with the Lookup object and used in permission checks when obtaining MHs is also used as the bound caller class when the MH is invoked. Now there's a method:
>>> 
>>> java.lang.invoke.MethodHandles.Lookup {
>>>     public java.lang.invoke.MethodHandles.Lookup in(java.lang.Class requestedLookupClass)
>>> 
>>> that returns a Lookup object which reports a different "lookupClass" and has capabilities to lookup MHs which are combined from capabilities of the original Lookup object and new lookupClass (tipicaly less, never more). Most of such Lookup objects are prevented from looking-up MHs for caller-sensitive methods, since they could be used to "pose" as a caller that is not the one having obtained the MH and therefore gain access to restricted resource, for example:
>>> 
>>> MethodHandle mh = MethodHandles.lookup().in(Object.class).lookupXXX(....)
>>> 
>>> ...such mh could be used to pose as being called from withing Object if allowed to be obtained for caller-sensitive methods. So here comes @CallerSensitive annotation to mark such methods and prevent such lookups (before that - in JDK7, all internal caller-sensitive methods were hand-maintained in a list).
>>> 
>>> So this is, what I think, the background and rationale for changing the API.
>>> 
>>> For outside JDK use, I think there are two main needs, which are actually distinct:
>>> 
>>> a) the caller-sensitive methods
>>> b) anything else that is not caller-sensitive, but wants to fiddle with the call-stack
>>> 
>>> For caller-sensitive methods, the approach taken with new Reflection.getCallerClass() is the right one, I think. There's no need to support a fragile API when caller-sensitivity is concerned, so the lack of "int" parameter, combined with annotation for marking such methods is correct approach, I think. The refactorings to support this change in JDK show that this API is adequate. The "surface" public API methods must capture the caller class and pass it down the internal API where it can be used.
>>> 
>>> So what would give Groovy or other language runtimes headaches when all there was was a parameter-less getCallerClass() API? Aren't the intermediate frames inserted by those runtimes controlled by the runtimes? Couldn't the "surface" runtime-inserted methods capture the caller and pass it down? I guess the problem is supporting calling the caller-sensitive methods like Class.forName(String) and such which don't have the overloaded variant taking caller Class or ClassLoader as an argument...
>>> 
>>> John Rose suggested to "capture" the caller in the "surface" method and bind it with a MethodHandle and then pass such MH down the runtime API and finally call that method via MH. For that to work, two problems would have to be resolved first:
>>> 
>>> 1) the runtime-inserted "surface" method would have to be annotated with @CallerSensitive so that illegal "posers" could be prevented
>>> 2) this "surface" method would have to be given permission to "pose as" the caller class when looking-up the MethodHandle of the target caller-sensitive method.
>>> 
>>> The 1st part is not a problem I think, but the 2nd part is a problem. What makes the runtime-inserted "surface" method so special that it can be allowed to "pose" as its caller?
>>> 
>>> Now that is the question for mlvm-dev mailing list: Isn't preventing almost all Lookup objects obtained by Lookup.in(RequestedLookupClass.class) from obtaining MHs of @CallerSensitive methods too restrictive? 
>>> 
>>> Currently classes are only allowed to "pose as" it's nest-mate classes - the classes that share the same outermost enclosing class, since the check to look-up @CallerSensitive methods is based on the ability to look-up PRIVATE members. So the ability to "pose as" another class when binding caller already exists even for @CallerSensitive methods, just the restriction is too conservative, isn't it?
>>> 
>>> Perhaps a class that is visible from the calling class could be allowed to look-up MHs of @CallerSensitive methods and "pose" as the calling class, bearing all other security checks for combined abilities have passed. For example, why wouldn't class A be allowed to "pose as" class B if they are loaded by the same ClassLoader or if class B is loaded by a ClassLoader that directly or indirectly delegates to the ClassLoader of class A?
>>> 
>>> These are my thoughts about caller-sensitivity and why I think it requires special restricted API. Anything else that needs to examine the whole call-stack is a separate need that is not infected by the strict constraints of caller-sensitivity and for that purpose an API like the one presented below (StackTraceFrame) is a good starting-point, maybe it just doesn't need the static getCallerFrame() method which suggests that it's use is for implementing caller-sensitive methods.
>>> 
>>> Regards, Peter
>>> 
>>>> I would point out that this could all easily be solved simply by adding a getElementClass() method to StackTraceElement, but there was strong opposition to this, largely due to serialization issues. Since that is apparently not an option, I propose the following API, based on the various discussions in the last two months, StackTraceElement, and the API that .NET provides to achieve the same needs as listed above:
>>>> 
>>>> CallerSensitive.java:
>>>> package java.lang;
>>>> 
>>>> /** Previously private API, now public */
>>>> public @interface CallerSensitive {
>>>>     ...
>>>> }
>>>> 
>>>> StackTraceFrame.java:
>>>> package java.lang;
>>>> 
>>>> import java.util.Objects.
>>>> 
>>>> public final class StackTraceFrame {
>>>>     private final Class declaringClass;
>>>>     private final Executable executable;
>>>>     private final String fileName;
>>>>     private final int lineNumber;
>>>> 
>>>>     public StackTraceFrame(Class declaringClass, Executable executable, String fileName, int lineNumber) {
>>>>         this.declaringClass = Objects.requireNonNull(declaringClass, "Declaring class is null");
>>>>         this.executable = Objects.requireNonNull(executable, "Executable is null");
>>>>         this.fileName = fileName;
>>>>         this.lineNumber = lineNumber;
>>>>     }
>>>> 
>>>>     public Class getDeclaringClass() {
>>>>         return this.declaringClass;
>>>>     }
>>>> 
>>>>     public Executable getExecutable() {
>>>>         return this.executable;
>>>>     }
>>>> 
>>>>     public String getFileName() {
>>>>         return this.fileName;
>>>>     }
>>>> 
>>>>     public int getLineNumber() {
>>>>         return this.lineNumber;
>>>>     }
>>>> 
>>>>     public boolean isNative() {
>>>>         return this.lineNumber == -2;
>>>>     }
>>>> 
>>>>     public String toString() { /* Same as StackTraceElement */ }
>>>>     public boolean equals() { /* Ditto */ }
>>>>     public int hashCode() { /* Ditto */ }
>>>> 
>>>>     /** Uses @CallerSensitive */
>>>>     public static native StackTraceFrame getCallerFrame();
>>>> 
>>>>     /** Works like Java < 7u25 sun.reflect.Reflection#getCallerClass() */
>>>>     public static native StackTraceFrame getCallerFrame(int skipFrames);
>>>> 
>>>>     public static native StackTraceFrame[] getCurrentStackTrace();
>>>> }
>>>> 
>>>> Throwable.java:
>>>> package java.lang;
>>>> 
>>>> ...
>>>> 
>>>> public class Throwable {
>>>>     ...
>>>>     public synchronized Throwable fillInStackTraceFrames() { ... }
>>>> 
>>>>     private native Throwable fillInStackTraceFrames(int dummy);
>>>> 
>>>>     public StackTraceFrame[] getStackTraceFrames() {
>>>>         return this.getOurStackTraceFrames().clone();
>>>>     }
>>>> 
>>>>     private synchronized StackTraceFrame[] getOurStackTraceFrames() { ... }
>>>>     ...
>>>> }
>>>> 
>>>> Furthermore, I propose that we restore the behavior of sun.reflect.Reflection#getCallerClass(int) /just for Java 7/ since the proposed above solution cannot be added to Java 7.
>>>> 
>>>> I would love if we could quickly coalesce around this solution or a derivative thereof so that it can be implemented before Feature Complete. The absence of any replacement or alternative for sun.reflect.Reflection#getCallerClass(int) will be a serious issue in Java 8 that will cause hardships for many projects.
>>>> 
>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html
>>>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html
>>>> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html
>>> 
>> 
> 



From jawnsy at cpan.org  Tue Jul 30 13:02:18 2013
From: jawnsy at cpan.org (Jonathan Yu)
Date: Tue, 30 Jul 2013 09:02:18 -0400
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: 
References: 
	<51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com>
	<51F741B1.7020008@oracle.com> <51F7481B.1080903@oracle.com>
	<4C7F7BA9-F099-49BE-BC1D-C7ADD0F4850A@nicholaswilliams.net>
	
	
Message-ID: 

On Tue, Jul 30, 2013 at 8:25 AM, Nick Williams <
nicholas+openjdk at nicholaswilliams.net> wrote:

> 42 MILLION uses of Reflection.getCallerClass(int) on Ohloh!?!? Holy crap...
>

Considering that the Ohloh search results page also bolds occurrences of
"Reflection", "class" and "get" for that search [0], I think it might be a
bit of an overestimation. Anyway, only eight million of those results are
in Java code, apparently.

I totally agree with the general sentiment of this thread, however, that
something shouldn't be removed unless there's a viable alternative
available.

[0] I see this as my top result (CallStack.java):

import sun.reflect.*Reflection*;

public class CallStack {

    public static void main(String[] args) {

      new A().a();
   }
    static *class* A{
       void a(){

          System.out.println(*Reflection*.*getCallerClass*(0));
          System.out.println(*Reflection*.*getCallerClass*(1));

          System.out.println(*Reflection*.*getCallerClass*(2));
          System.out.println(*Reflection*.*getCallerClass*(3));


          System.out.println(Thread.currentThread().*get*StackTrace()[0]);

          System.out.println(Thread.currentThread().*get*StackTrace()[1]);



In case anyone is interested, I am almost finished implementing the public
> API StackTraceFrame and associated C/C++ code. It has been an eye-opening
> experience, but I think I have it figured out now. I just have to write
> some tests. Looks like installing and configuring jtreg might be more
> difficult than cloning and compiling JDK was...
>
> Nick
>
> On Jul 30, 2013, at 7:01 AM, J?rn Huxhorn wrote:
>
> > This whole issue started with the "fix" of
> http://bugs.sun.com/view_bug.do?bug_id=8016814 because, obviously,
> throwing an UnsupportedOperationException is a straightforward and
> reasonable way of fixing an off-by-one problem with the description
> "returns the wrong stack frame" (see
> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html).
> > Bonus points for doing this instead of just applying the "1-line fix" in
> the comments of that bug report. I'm pretty sure that this exception wasn't
> the kind of fix the reporter of the bug was looking for. (Yes, I know. The
> 1-line fix was applied and is executing if the JVM parameter is set - but
> this is not my point.)
> >
> > Ironically, the comment on the "fix" regarded a sudden, unexpected
> RuntimeException in an unknown amount of third-party code as "Low risk.".
> >
> > This is justified by http://bugs.sun.com/view_bug.do?bug_id=8014925(created on 2013-05-20 - which is just the blink of an eye in Java time. To
> put it into perspective: we missed the tenth birthday of
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444 which
> requested this functionality in a proper public API) which contains the
> following paragraph:
> >
> >> The following describes the transition plan to allow customers to
> migrate their applications away from this private API:
> >> 1. Disable sun.reflect.Reflection.getCallerClass(int) in 7u40 and
> provide a flag to re-enable it
> >> 2. Determine how this private API is being used and the use cases
> >> 3. Remove this private API if there is no valid use case or there is a
> proper replacement for it. Allow at least 2 CPU releases to allow customers
> to make appropriate change.  So the earliest for the removal is 7u55.  If
> there are valid use cases but no proper replacement, we may keep this
> private API in jdk7u for longer.
> >
> > With regards to 3., I think we were able to give examples of "valid use
> cases" for this API.
> >
> > If the only alternatives available are either slow and fragile (100x
> slower, achieved by extending SecurityManager for the sake of calling the
> protected getClassContext() method, will break if the RuntimePermission
> "createSecurityManager" is not granted by a possibly installed
> SecurityManager) or even slower (450x slower, using Throwable) then this is
> a showstopper, especially if the code is executed literally millions of
> times, as is the case with logging calls.
> >
> > Yes. It sucks that a private API call is necessary. Yep, one should not
> depend on such a private API. But the RFE to rectify this has been idling
> for more than ten years and the performance impact of *not* using it is
> substantial.
> >
> > The j7u40 change will result in lots of applications simply going BOOM
> or acting weird after updating which in turn will slow the adoption of Java
> updates. And that isn't a good idea at all with regards to security fixes.
> It will likely also prevent reasonable adoption rates for Java 8. Why
> should I choose a new Java version if it results in a significantly slower
> overall speed of my applications? If all third-party libraries using the
> API have been updated so that the application will work at all.
> >
> > There's really only one rational way to handle this situation:
> > - Remove the UnsupportedOperationException from j7u40 und higher Java 7
> versions.
> > - Restore sun.reflect.Reflection in Java 8.
> > - Define a proper public API (TBD) with similar performance to the
> private API, as requested ten years ago, for Java 9. This functionality is
> available in .NET since 1.1, as previously mentioned.
> >
> > Anything else will simply hurt the Java platform as a whole and reaffirm
> the "Java is slow" mantra. If keeping the "but this wasn't part of the
> public API so we did nothing wrong" stance is worth all of this then feel
> free to just ignore our objections.
> >
> > Seriously, I fail to understand how something like this could have
> passed the QA. See
> http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough
> estimate about the impact of this change. This is probably one of the most
> used private Java API calls, ever.
> >
> > Cheers,
> > J?rn.
> >
> > On 30. Juli 2013 at 06:59:53, Nick Williams (
> nicholas+openjdk at nicholaswilliams.net) wrote:
> >
> >
> > On Jul 29, 2013, at 11:59 PM, Joseph Darcy wrote:
> >
> >>
> >> On 7/29/2013 9:31 PM, Alan Bateman wrote:
> >>> On 29/07/2013 19:17, David M. Lloyd wrote:
> >>>>
> >>>> Your phrasing makes me think I missed something: is the
> Reflection.getCallerClass() method being removed due to some technical
> issue that it can only be somehow emulated as a workaround? Or is it just a
> general cleanup effort?
> >>>>
> >>> The sun.reflect.Reflection.getCallerClass(int) method was removed as
> part of JEP 176 [1].
> >>>
> >>> -Alan.
> >>>
> >>> [1] http://openjdk.java.net/jeps/176
> >>>
> >>
> >> And as a sun.* method, this was officially outside of the exported
> interface of the JDK and not something that should be expected to work if
> called from outside of the JDK.
> >
> > As has been said many, many times in the last few days, we are all well
> aware of this. It doesn't make the problem any less disastrous for the
> community. This needs to be replaced with a public API.
> >
> > Nick
>
>


From blackdrag at gmx.org  Tue Jul 30 13:19:49 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Tue, 30 Jul 2013 15:19:49 +0200
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7AEEE.4040305@gmail.com>
References: 
	<51F7AEEE.4040305@gmail.com>
Message-ID: <51F7BD75.4030708@gmx.org>

Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
> So what would give Groovy or other language runtimes headaches when all
> there was was a parameter-less getCallerClass() API? Aren't the
> intermediate frames inserted by those runtimes controlled by the
> runtimes? Couldn't the "surface" runtime-inserted methods capture the
> caller and pass it down? I guess the problem is supporting calling the
> caller-sensitive methods like Class.forName(String) and such which don't
> have the overloaded variant taking caller Class or ClassLoader as an
> argument...

Speaking for Groovy...
those intermediate frames are runtime controlled, yes, but passing down 
the caller class is exactly the problem. Imagine I would suggest that 
each and every method definition in Java automatically gets an 
additional parameter for the caller class, just to have access to it 
inside the method. You would not accept that for Java, would you? And so 
we cannot accept that for Groovy if we want to keep integration with 
Java... and the good integration with Java is one of the key points of 
Groovy. Even if we make something like that @CallerSensitive and add the 
parameter only in those cases, we break being able to override methods. 
Plus, before Groovy3 is not done we have to support several call paths. 
And the oldest one, which is still a fallback, does not support 
transporting the caller class through the runtime layers at all. 
Changing here is a breaking change.

> John Rose suggested to "capture" the caller in the "surface" method and
> bind it with a MethodHandle and then pass such MH down the runtime API
> and finally call that method via MH.

Only that you then need a java7+ only version, plus the already 
mentioned problem, that not all of the three general call paths support 
that or can be changed in a way to enable that without breaking user code.


bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From Alan.Bateman at oracle.com  Tue Jul 30 13:24:25 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Jul 2013 06:24:25 -0700
Subject: Review request: JDK-8021245 (process) file leak in
	jdk/src/windows/native/java/lang/ProcessImpl_md.c
In-Reply-To: <51F6A113.3090700@oracle.com>
References: <51F296CF.2050902@oracle.com> <51F55777.5050404@oracle.com>
	<51F6A113.3090700@oracle.com>
Message-ID: <51F7BE89.5020204@oracle.com>

On 29/07/2013 10:06, Alexey Utkin wrote:
> Thanks, Alan
>
> I did "if" reformatting and small refactoring for the code in function 
> in accordance with
>     https://jbs.oracle.com/bugs/browse/JDK-5008166
> recommendations. I am sure that the presence of path separator has no 
> dependence from search direction.
>
> Here is the webrev:
> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8021245/webrev.01/
This looks much nicer so thumbs up from me. One thing just to say that I 
don't think the JDK has been supported for Windows 9x/ME for several 
years so one of the SearchPaths isn't used nowadays. Minor comment is 
that the new comments probably should a space before/after the /* */ to 
be consistent with the other comments (no need to generate a new webrev 
for that of course).

-Alan


From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 13:37:05 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 08:37:05 -0500
Subject: Compiling jtreg?
Message-ID: <21A522C3-C33E-4B30-B41D-90D836E080E5@nicholaswilliams.net>

I'm working on a patch for some core libraries (hence why I'm emailing here -- hopefully someone will be sympathetic and help) and need to run the JDK tests. I'm following the instructions on http://openjdk.java.net/jtreg/build.html to get jtreg installed so that I can run it. I have JDK15HOME and JDK16HOME set to my JDK 6 home directory. I have JavaHelp installed at JAVAHELP_HOME. I have JT Harness installed at JTHARNESS_HOME. I have Xalan installed at XALANHOME. I have JUnit installed at JUNIT_HOME. I have TestNG installed at TESTNG_HOME.

I cloned the HG repository and executed make -C make just like the directions said. I get 58 compile errors: It can't find Ant, JUnit, or TestNG classes. Can someone point me in the right direction?

1) I assume I must have to specify a classpath somehow for JUnit and TestNG, even though the directions don't say so. Thoughts on how?
2) The instructions say Ant is optional. So why is it mandatory?

(I didn't realize that it would take longer / be harder to get the tests running than to get the JDK compiling.)

Thanks,

Nick

From paul.sandoz at oracle.com  Tue Jul 30 13:39:45 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Jul 2013 14:39:45 +0100
Subject: RFR 8021883 j.u.Random/RandomStream.java test needs more robust
	timeout duration
Message-ID: 

Hi,

http://cr.openjdk.java.net/~psandoz/tl/JDK-8021883-random-stream-test/webrev/

This patch updates tests for ThreadLocalRandom streams and increases the timeout duration. Although the original should be enough for most cases in certain virtualized and emulated environments it might not be. I also took the liberty of consolidating the code and sprinkling stream and CompletableFuture dust on things.

Paul.

From Alan.Bateman at oracle.com  Tue Jul 30 14:07:13 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Jul 2013 07:07:13 -0700
Subject: Compiling jtreg?
In-Reply-To: <21A522C3-C33E-4B30-B41D-90D836E080E5@nicholaswilliams.net>
References: <21A522C3-C33E-4B30-B41D-90D836E080E5@nicholaswilliams.net>
Message-ID: <51F7C891.20504@oracle.com>


The jtreg-use list is probably the right place for this question.

-Alan.


On 30/07/2013 06:37, Nick Williams wrote:
> I'm working on a patch for some core libraries (hence why I'm emailing here -- hopefully someone will be sympathetic and help) and need to run the JDK tests. I'm following the instructions on http://openjdk.java.net/jtreg/build.html to get jtreg installed so that I can run it. I have JDK15HOME and JDK16HOME set to my JDK 6 home directory. I have JavaHelp installed at JAVAHELP_HOME. I have JT Harness installed at JTHARNESS_HOME. I have Xalan installed at XALANHOME. I have JUnit installed at JUNIT_HOME. I have TestNG installed at TESTNG_HOME.
>
> I cloned the HG repository and executed make -C make just like the directions said. I get 58 compile errors: It can't find Ant, JUnit, or TestNG classes. Can someone point me in the right direction?
>
> 1) I assume I must have to specify a classpath somehow for JUnit and TestNG, even though the directions don't say so. Thoughts on how?
> 2) The instructions say Ant is optional. So why is it mandatory?
>
> (I didn't realize that it would take longer / be harder to get the tests running than to get the JDK compiling.)
>
> Thanks,
>
> Nick



From alexey.utkin at oracle.com  Tue Jul 30 14:09:24 2013
From: alexey.utkin at oracle.com (Alexey Utkin)
Date: Tue, 30 Jul 2013 18:09:24 +0400
Subject: Review request: JDK-8021245 (process) file leak in
	jdk/src/windows/native/java/lang/ProcessImpl_md.c
In-Reply-To: <51F7BE89.5020204@oracle.com>
References: <51F296CF.2050902@oracle.com> <51F55777.5050404@oracle.com>
	<51F6A113.3090700@oracle.com> <51F7BE89.5020204@oracle.com>
Message-ID: <51F7C914.40204@oracle.com>

On 7/30/2013 5:24 PM, Alan Bateman wrote:
> On 29/07/2013 10:06, Alexey Utkin wrote:
>> Thanks, Alan
>>
>> I did "if" reformatting and small refactoring for the code in 
>> function in accordance with
>>     https://jbs.oracle.com/bugs/browse/JDK-5008166
>> recommendations. I am sure that the presence of path separator has no 
>> dependence from search direction.
>>
>> Here is the webrev:
>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8021245/webrev.01/
> This looks much nicer so thumbs up from me. One thing just to say that 
> I don't think the JDK has been supported for Windows 9x/ME for several 
> years so one of the SearchPaths isn't used nowadays.
The [selectProcessFlag] function is obsolete. But the code needs to be 
clean.
> Minor comment is that the new comments probably should a space 
> before/after the /* */ to be consistent with the other comments (no 
> need to generate a new webrev for that of course).
Accepted.
>
> -Alan
>
>



From peter.levart at gmail.com  Tue Jul 30 14:16:45 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 30 Jul 2013 16:16:45 +0200
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7BD75.4030708@gmx.org>
References: 
	<51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org>
Message-ID: <51F7CACD.2070703@gmail.com>


On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
> Am 30.07.2013 14:17, schrieb Peter Levart:
> [...]
>> So what would give Groovy or other language runtimes headaches when all
>> there was was a parameter-less getCallerClass() API? Aren't the
>> intermediate frames inserted by those runtimes controlled by the
>> runtimes? Couldn't the "surface" runtime-inserted methods capture the
>> caller and pass it down? I guess the problem is supporting calling the
>> caller-sensitive methods like Class.forName(String) and such which don't
>> have the overloaded variant taking caller Class or ClassLoader as an
>> argument...
> Speaking for Groovy...
> those intermediate frames are runtime controlled, yes, but passing down
> the caller class is exactly the problem. Imagine I would suggest that
> each and every method definition in Java automatically gets an
> additional parameter for the caller class, just to have access to it
> inside the method. You would not accept that for Java, would you? And so
> we cannot accept that for Groovy if we want to keep integration with
> Java...

Are you talking about internal Groovy implementation (the 
runtime-inserted methods) or the publicly visible API? One solution for 
internal implementation of Groovy could be (speaking by heart since I 
don't know the internals of Groovy) for the "surface" public API method 
which doesn't have to have the special caller parameter, to capture the 
caller with getCallerClass() parameterless API (possibly enclosed with a 
quick check confirming that it might actually be needed) and bind it to 
a ThreadLocal, then use this ThreadLocal down at the end...

> and the good integration with Java is one of the key points of
> Groovy. Even if we make something like that @CallerSensitive and add the
> parameter only in those cases, we break being able to override methods.

I guess I don't know every Groovy need to obtain the caller class. I 
thought the problem was to support calling caller-sensitive methods in 
Java API (like Class.forName(String)) from within Groovy code, where 
there are runtime-inserted frames between the "call-site" and the target 
method. Are there any other needs?

> Plus, before Groovy3 is not done we have to support several call paths.
> And the oldest one, which is still a fallback, does not support
> transporting the caller class through the runtime layers at all.
> Changing here is a breaking change.

Could you describe those call-paths? Examples of Groovy code and to what 
it gets translated (equivalent Java code at call site) with a brief 
description of what each intermediate layer (between the call-site and 
the target method) does and at which point the caller class is extracted...

Regards, Peter

>> John Rose suggested to "capture" the caller in the "surface" method and
>> bind it with a MethodHandle and then pass such MH down the runtime API
>> and finally call that method via MH.
> Only that you then need a java7+ only version, plus the already
> mentioned problem, that not all of the three general call paths support
> that or can be changed in a way to enable that without breaking user code.
>
>
> bye Jochen
>



From chris.hegarty at oracle.com  Tue Jul 30 14:22:47 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 Jul 2013 15:22:47 +0100
Subject: Java 8 RFR 8020539: Clean up doclint problems in java.util
	package, part 2
In-Reply-To: 
References: <50FE640E-DC42-47F2-9FAD-8472A013EB9B@oracle.com>
	
	
	<51E77802.8070001@oracle.com>
	<67232DB5-4077-4A4D-9729-B06C7FD911BF@oracle.com>
	<51F6142A.2080201@oracle.com>
	
Message-ID: <51F7CC37.2020105@oracle.com>

On 07/29/2013 09:06 PM, Brian Burkhalter wrote:
> Joe / Chris:
>
> The updated webrev is in the same place,
> http://cr.openjdk.java.net/~bpb/8020539/
>
> If this looks good I will need an approval.

It looks ok to me.

-Chris.

>
> On Jul 29, 2013, at 12:05 AM, Joe Darcy wrote:
>
>> I recommend a few changes here:
>>
>> * For readability, rename "NonASCIIDigit" as "NonAsciiDigit"
>
> Changed.
>
>> * Since Scanner is in the regex package, it may be more appropriate to
>> stick more of a regex notation than an ebnf notation, but keeping the
>> definition list structure tags.
>
> Changed back to regex notation.
>
>>>
>>>> Offhand, I wasn't aware Dequeue and Queue were maintained in Doug's
>>>> CVS, but I agree changes to those files should flow through there first.
>>> Deque and Queue removed from the webrev:
>>>
>>> http://cr.openjdk.java.net/~bpb/8020539/
>>>
>>
>> Otherwise, the changes look fine. If you like, the non-Scanner changes
>> can be split out and pushed first.
>
> I've left it as one changeset.
>
> On Jul 29, 2013, at 2:43 AM, Chris Hegarty wrote:
>
>> Looks fine ( I did not go through the Scanner changes ).
>>
>> Some minor comments:
>>
>> 1) List
>>   Trivially I wonder why you decided to go with '< '>', rather
>>   than {@code ... }, which I think is more readable.
>
> Changed.
>
>> 2) Map
>>   Trivially, I would keep the @param's order the same as the actual
>>   method parameters order.
>
> Changed.
>
>> 3) Optional
>>   Strangely, there doesn't appear to be a '@param' for the class level
>>   type T. doclint is not warning about this either.
>
> Not changed.
>
> Thanks,
>
> Brian


From paul.sandoz at oracle.com  Tue Jul 30 14:25:45 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Jul 2013 15:25:45 +0100
Subject: class SplittableRandom
In-Reply-To: <51F6B47E.1040102@gmail.com>
References: <51DDB26D.8050506@cs.oswego.edu> <51DE6069.2060308@gmail.com>
	<51DEA230.2060504@cs.oswego.edu> <51DEA3D5.5000509@oracle.com>
	<51E1549D.4060403@cs.oswego.edu>
	
	<51E414C6.9070400@cs.oswego.edu>
	
	
	<6099D28A-0B95-42A4-A59B-5E1C465EDCA9@oracle.com>
	
	<480BCC80-2A9C-4321-B81B-47487E90C0D7@oracle.com>
	<51F6B47E.1040102@gmail.com>
Message-ID: <1F6D53ED-F853-4444-A5B3-D28D25E6D5E4@oracle.com>

Hi Peter,

Given that the user cannot specify gamma values and the for the first  2^16+1 gamma values the minimum bit count is 15, the maximum bit count is 50 and the minimum width is 45, is that not sufficient? i.e. is it likely there will be more than 65537 splits? 

In the streams API one would be hard pressed to reach this limit, even for splitting an iterator. If i calculated things correctly with an arithmetic progression step size of 1 the limits of the max collection size will be reached (currently we use a step size of 1024) and one is likely to hit other problems way before due to issues with reduction on right-heavy trees.

Paul.
 
On Jul 29, 2013, at 7:29 PM, Peter Levart  wrote:

> 
> On 07/16/2013 06:01 PM, Guy Steele wrote:
>> On Jul 16, 2013, at 3:07 AM, Martin Buchholz  wrote:
>>> Read Appleby and Stafford ...
>>> 
>>> Hmmm.... mix32 has almost the same job as mix64 - have all the bits in the seed affect all the bits in the output, so the obvious implementation is
>>> 
>>> mix32() { return (int) mix64(); }
>>> or more conservatively
>>> mix32() { m = mix64(); return (int)m ^ (int)(m >>> 32); }
>>> although it would be slightly distressing to have nextInt be more expensive than nextLong.
>> Yes---at first I used exactly
>>    mix32() { return (int) mix64(); }
>> but was worried about the time it took, which is why I searched for a cheaper mixing function.
>> 
>>> There might be some clever way of doing murmurhash-style mixing when the input is 64-bit and the output is 32-bit that can do better, but I don't think the current mix32 is it.
>> Again, I was astonished that so simply a mixing function seemed to do the job as far as Dieharder is concerned.  I agree that it does appear to perform poorly for sparse gamma values.  So now the question is: do such sparse gamma values arise in practice?
>> 
>> As Doug has pointed out, we carefully made the two-argument constructor private so that the user cannot specify gamma values.  The gamma values are derived only from the gamma-seed 0, using the gamma value GAMMA_GAMMA, and always running the seed through mix64.
>> 
>> I wrote a little test (code and output below) to generate the first 16 billion (well, 2^34+1) gamma values actually generated and gather certain statistics:
>> (1) the number of 1-bits in the gamma value (output of Long.bitCount)
>> (2) the "width" of the gamma value (64 - Long.numberOfLeadingBits(gamma) - Long.numberOfTrailingBits(gamma))
>> Then it histograms the bit counts, and for each possible bit count tracks the minimum width for gammas having that same bit count.
>> Whenever the number of of gammas examined is one more than a power of 2, it prints a report consisting of those two tables and the min over the minwidth table.
>> 
>> Here's a brief summary:
>> 
>> For the first 65 gamma values, no gamma value has fewer than 21 1-bits or more than 41 1-bits.  The minimum width is 57.  So I predict there will be no weird mixing problems at all when using SplittableRandom to do a balanced split of a stream of generated randoms.
>> 
>> For the first 2^16+1 = 65537 gamma values, the minimum bit count is 15, the maximum bit count is 50 and the minimum width is 45.
>> 
>> For the first 2^24+1 gamma values, the minimum bit count is 12, the maximum bit count is 52 and the minimum width is 35.
>> 
>> For the first 2^32+1 gamma values, the minimum bit count is 9, the maximum bit count is 55 and the minimum width is 28.
>> 
>> For the first 2^34+1 gamma values, the minimum bit count is 8, the maximum bit count is 56 and the minimum width is 28.
>> 
>> So I think we will not hit any really bad gamma values in practice.
>> 
>> --Guy
>> 
> 
> Hi,
> 
> Would it be possible to skip gammas with less than 12 or more than 52 bits?
> 
> I did some playing with dieharder a week ago, testing SR.nextInt() (mix32) and indeed for sparse gamma values, all dieharder tests show failure. In particular test id=1 (diehard_operm5) is the least forgiving, requiring minimum gamma bit count being about 11 and maximum about 54 in order for such "random" gamma to produce nextInt() bit streams that pass the diehard_operm5 test. Here's a sample of the first 3 dieharder tests (0,1 and 2) for differently sparsed "random" gammas:
> 
> https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextInt_results_0to2.txt
> 
> The alternative:
> 
>    public int nextIntAlt1() {
>        return (int) mix64(nextSeed());
>    }
> 
> ... does not exhibit this weakness. It seems to be satisfied with gammas having as few as 1 or as many as 63 bits set to pass dieharder tests:
> 
> https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextIntAlt1_results_0to2.txt
> 
> But such nextInt is slower, approximately as fast as ThreadLocalRandom.nextInt() by my measurements.
> 
> Random streams created by SplittableRandom.nextLong() (mix64) also don't exhibit weaknesses with sparse gammas, so I thought why not using mix64() to produce 64 bits of randomness that is then returned by two consecutive calls to nextInt, like that:
> 
>    private int nextInt;
>    private boolean nextIntZero;
> 
>    public int nextIntAlt2() {
>        if (nextInt != 0) {
>            int result = nextInt;
>            nextInt = 0;
>            return result;
>        } else if (nextIntZero) {
>            nextIntZero = false;
>            return 0;
>        } else {
>            long nextLong = mix64(nextSeed());
>            nextInt = (int)(nextLong >>> 32);
>            if (nextInt == 0) nextIntZero = true;
>            return (int)(nextLong & 0xFFFFFFFFL);
>        }
>    }
> 
> The (little-Indian) bitstream produced by nextIntAlt2() is exactly the same as that produced by nextLong() and 1st 3 dieharder tests pass with sparse gammas too:
> 
> https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextIntAlt2_results_0to2.txt
> 
> the measurements produced by micro benchmark show performance somewhere between nextInt() and nextIntAlt1():
> 
> Benchmark                      Thr    Cnt  Sec         Mean Mean error          Var    Units
> s.g.t.JmhTest.SR_nextInt         1      8    5 477779.670     1151.048   865504.410 ops/msec
> s.g.t.JmhTest.SR_nextIntAlt1     1      8    5 385630.764      513.779   172439.034 ops/msec
> s.g.t.JmhTest.SR_nextIntAlt2     1      8    5 432071.940      572.221   213899.640 ops/msec
> s.g.t.JmhTest.TLR_nextInt        1      8    5 382334.416       28.907      545.871 ops/msec
> 
> 
> Here's the JMH micro benchmark I used:
> 
> https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/sr/JmhTest.java
> 
> 
> Here's the code I used to produce dieharder reports:
> 
> https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/sr/Test.java
> 
> which uses the following utility class to interface dieharder tool:
> 
> https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/si/pele/dieharder/DieharderTest.java
> 
> 
> Regards, Peter
> 



From peter.levart at gmail.com  Tue Jul 30 15:02:04 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 30 Jul 2013 17:02:04 +0200
Subject: class SplittableRandom
In-Reply-To: <1F6D53ED-F853-4444-A5B3-D28D25E6D5E4@oracle.com>
References: <51DDB26D.8050506@cs.oswego.edu> <51DE6069.2060308@gmail.com>
	<51DEA230.2060504@cs.oswego.edu> <51DEA3D5.5000509@oracle.com>
	<51E1549D.4060403@cs.oswego.edu>
	
	<51E414C6.9070400@cs.oswego.edu>
	
	
	<6099D28A-0B95-42A4-A59B-5E1C465EDCA9@oracle.com>
	
	<480BCC80-2A9C-4321-B81B-47487E90C0D7@oracle.com>
	<51F6B47E.1040102@gmail.com>
	<1F6D53ED-F853-4444-A5B3-D28D25E6D5E4@oracle.com>
Message-ID: <51F7D56C.8050300@gmail.com>


On 07/30/2013 04:25 PM, Paul Sandoz wrote:
> Hi Peter,
>
> Given that the user cannot specify gamma values and the for the first  2^16+1 gamma values the minimum bit count is 15, the maximum bit count is 50 and the minimum width is 45, is that not sufficient? i.e. is it likely there will be more than 65537 splits?
>
> In the streams API one would be hard pressed to reach this limit, even for splitting an iterator. If i calculated things correctly with an arithmetic progression step size of 1 the limits of the max collection size will be reached (currently we use a step size of 1024) and one is likely to hit other problems way before due to issues with reduction on right-heavy trees.

Hi Paul,

In streams API it is unlikely, but SplittableRandom is a public API and 
might be used in other unforeseen scenarios. It's not hard to imagine 
submitting way more than 2^16 tasks to an Executor, giving each it's own 
SplittableRandom instance generated from a chain of splits...

If it is very rare to encounter a sparse gamma then it is also very 
cheap to skip it, right? It only takes Long.bitCount(gamma) at each 
split()...

Regards, Peter

> Paul.
>   
> On Jul 29, 2013, at 7:29 PM, Peter Levart  wrote:
>
>> On 07/16/2013 06:01 PM, Guy Steele wrote:
>>> On Jul 16, 2013, at 3:07 AM, Martin Buchholz  wrote:
>>>> Read Appleby and Stafford ...
>>>>
>>>> Hmmm.... mix32 has almost the same job as mix64 - have all the bits in the seed affect all the bits in the output, so the obvious implementation is
>>>>
>>>> mix32() { return (int) mix64(); }
>>>> or more conservatively
>>>> mix32() { m = mix64(); return (int)m ^ (int)(m >>> 32); }
>>>> although it would be slightly distressing to have nextInt be more expensive than nextLong.
>>> Yes---at first I used exactly
>>>     mix32() { return (int) mix64(); }
>>> but was worried about the time it took, which is why I searched for a cheaper mixing function.
>>>
>>>> There might be some clever way of doing murmurhash-style mixing when the input is 64-bit and the output is 32-bit that can do better, but I don't think the current mix32 is it.
>>> Again, I was astonished that so simply a mixing function seemed to do the job as far as Dieharder is concerned.  I agree that it does appear to perform poorly for sparse gamma values.  So now the question is: do such sparse gamma values arise in practice?
>>>
>>> As Doug has pointed out, we carefully made the two-argument constructor private so that the user cannot specify gamma values.  The gamma values are derived only from the gamma-seed 0, using the gamma value GAMMA_GAMMA, and always running the seed through mix64.
>>>
>>> I wrote a little test (code and output below) to generate the first 16 billion (well, 2^34+1) gamma values actually generated and gather certain statistics:
>>> (1) the number of 1-bits in the gamma value (output of Long.bitCount)
>>> (2) the "width" of the gamma value (64 - Long.numberOfLeadingBits(gamma) - Long.numberOfTrailingBits(gamma))
>>> Then it histograms the bit counts, and for each possible bit count tracks the minimum width for gammas having that same bit count.
>>> Whenever the number of of gammas examined is one more than a power of 2, it prints a report consisting of those two tables and the min over the minwidth table.
>>>
>>> Here's a brief summary:
>>>
>>> For the first 65 gamma values, no gamma value has fewer than 21 1-bits or more than 41 1-bits.  The minimum width is 57.  So I predict there will be no weird mixing problems at all when using SplittableRandom to do a balanced split of a stream of generated randoms.
>>>
>>> For the first 2^16+1 = 65537 gamma values, the minimum bit count is 15, the maximum bit count is 50 and the minimum width is 45.
>>>
>>> For the first 2^24+1 gamma values, the minimum bit count is 12, the maximum bit count is 52 and the minimum width is 35.
>>>
>>> For the first 2^32+1 gamma values, the minimum bit count is 9, the maximum bit count is 55 and the minimum width is 28.
>>>
>>> For the first 2^34+1 gamma values, the minimum bit count is 8, the maximum bit count is 56 and the minimum width is 28.
>>>
>>> So I think we will not hit any really bad gamma values in practice.
>>>
>>> --Guy
>>>
>> Hi,
>>
>> Would it be possible to skip gammas with less than 12 or more than 52 bits?
>>
>> I did some playing with dieharder a week ago, testing SR.nextInt() (mix32) and indeed for sparse gamma values, all dieharder tests show failure. In particular test id=1 (diehard_operm5) is the least forgiving, requiring minimum gamma bit count being about 11 and maximum about 54 in order for such "random" gamma to produce nextInt() bit streams that pass the diehard_operm5 test. Here's a sample of the first 3 dieharder tests (0,1 and 2) for differently sparsed "random" gammas:
>>
>> https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextInt_results_0to2.txt
>>
>> The alternative:
>>
>>     public int nextIntAlt1() {
>>         return (int) mix64(nextSeed());
>>     }
>>
>> ... does not exhibit this weakness. It seems to be satisfied with gammas having as few as 1 or as many as 63 bits set to pass dieharder tests:
>>
>> https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextIntAlt1_results_0to2.txt
>>
>> But such nextInt is slower, approximately as fast as ThreadLocalRandom.nextInt() by my measurements.
>>
>> Random streams created by SplittableRandom.nextLong() (mix64) also don't exhibit weaknesses with sparse gammas, so I thought why not using mix64() to produce 64 bits of randomness that is then returned by two consecutive calls to nextInt, like that:
>>
>>     private int nextInt;
>>     private boolean nextIntZero;
>>
>>     public int nextIntAlt2() {
>>         if (nextInt != 0) {
>>             int result = nextInt;
>>             nextInt = 0;
>>             return result;
>>         } else if (nextIntZero) {
>>             nextIntZero = false;
>>             return 0;
>>         } else {
>>             long nextLong = mix64(nextSeed());
>>             nextInt = (int)(nextLong >>> 32);
>>             if (nextInt == 0) nextIntZero = true;
>>             return (int)(nextLong & 0xFFFFFFFFL);
>>         }
>>     }
>>
>> The (little-Indian) bitstream produced by nextIntAlt2() is exactly the same as that produced by nextLong() and 1st 3 dieharder tests pass with sparse gammas too:
>>
>> https://raw.github.com/plevart/lambda-hacks/SplittableRandom/SplittableRandom/nextIntAlt2_results_0to2.txt
>>
>> the measurements produced by micro benchmark show performance somewhere between nextInt() and nextIntAlt1():
>>
>> Benchmark                      Thr    Cnt  Sec         Mean Mean error          Var    Units
>> s.g.t.JmhTest.SR_nextInt         1      8    5 477779.670     1151.048   865504.410 ops/msec
>> s.g.t.JmhTest.SR_nextIntAlt1     1      8    5 385630.764      513.779   172439.034 ops/msec
>> s.g.t.JmhTest.SR_nextIntAlt2     1      8    5 432071.940      572.221   213899.640 ops/msec
>> s.g.t.JmhTest.TLR_nextInt        1      8    5 382334.416       28.907      545.871 ops/msec
>>
>>
>> Here's the JMH micro benchmark I used:
>>
>> https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/sr/JmhTest.java
>>
>>
>> Here's the code I used to produce dieharder reports:
>>
>> https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/sr/Test.java
>>
>> which uses the following utility class to interface dieharder tool:
>>
>> https://github.com/plevart/lambda-hacks/blob/SplittableRandom/SplittableRandom/src/si/pele/dieharder/DieharderTest.java
>>
>>
>> Regards, Peter
>>



From dl at cs.oswego.edu  Tue Jul 30 15:10:51 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 30 Jul 2013 11:10:51 -0400
Subject: class SplittableRandom
In-Reply-To: <51F6B47E.1040102@gmail.com>
References: <51DDB26D.8050506@cs.oswego.edu> <51DE6069.2060308@gmail.com>
	<51DEA230.2060504@cs.oswego.edu> <51DEA3D5.5000509@oracle.com>
	<51E1549D.4060403@cs.oswego.edu>
	
	<51E414C6.9070400@cs.oswego.edu>
	
	
	<6099D28A-0B95-42A4-A59B-5E1C465EDCA9@oracle.com>
	
	<480BCC80-2A9C-4321-B81B-47487E90C0D7@oracle.com>
	<51F6B47E.1040102@gmail.com>
Message-ID: <51F7D77B.6010300@cs.oswego.edu>

On 07/29/13 14:29, Peter Levart wrote:
>
> On 07/16/2013 06:01 PM, Guy Steele wrote:

>> So I think we will not hit any really bad gamma values in practice.
>>
>
> Would it be possible to skip gammas with less than 12 or more than 52 bits?
>

Or better, eliminate dependence on bit density.
I'm working on it...


-Doug





From chris.hegarty at oracle.com  Tue Jul 30 15:18:50 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 Jul 2013 16:18:50 +0100
Subject: RFR 8021863: Stream.concat incorrectly calculates unsized state
In-Reply-To: <7E3DF7C4-32CD-4731-9C10-C38FAE0BB4B8@oracle.com>
References: <7E3DF7C4-32CD-4731-9C10-C38FAE0BB4B8@oracle.com>
Message-ID: <51F7D95A.60604@oracle.com>

Looks ok to me Paul.

-Chris.

On 07/30/2013 11:53 AM, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8021863-concat-size/webrev/
>
> This patch just tidies up calculating whether the concatenating spliterator is unsized or not before splitting. There was a typo when checking spliterator characteristics, but it turns out the characteristics do not need to be checked. Some tests are also added.
>
> Paul.
>


From blackdrag at gmx.org  Tue Jul 30 15:33:36 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Tue, 30 Jul 2013 17:33:36 +0200
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7CACD.2070703@gmail.com>
References: 
	<51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org>
	<51F7CACD.2070703@gmail.com>
Message-ID: <51F7DCD0.1030306@gmx.org>

Am 30.07.2013 16:16, schrieb Peter Levart:
>
> On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
>> Am 30.07.2013 14:17, schrieb Peter Levart:
>> [...]
>>> So what would give Groovy or other language runtimes headaches when all
>>> there was was a parameter-less getCallerClass() API? Aren't the
>>> intermediate frames inserted by those runtimes controlled by the
>>> runtimes? Couldn't the "surface" runtime-inserted methods capture the
>>> caller and pass it down? I guess the problem is supporting calling the
>>> caller-sensitive methods like Class.forName(String) and such which don't
>>> have the overloaded variant taking caller Class or ClassLoader as an
>>> argument...
>> Speaking for Groovy...
>> those intermediate frames are runtime controlled, yes, but passing down
>> the caller class is exactly the problem. Imagine I would suggest that
>> each and every method definition in Java automatically gets an
>> additional parameter for the caller class, just to have access to it
>> inside the method. You would not accept that for Java, would you? And so
>> we cannot accept that for Groovy if we want to keep integration with
>> Java...
>
> Are you talking about internal Groovy implementation (the
> runtime-inserted methods) or the publicly visible API?

that's the problem, it is a mix, some internal, other not. We are going 
to change that in Groovy 3

> One solution for
> internal implementation of Groovy could be (speaking by heart since I
> don't know the internals of Groovy) for the "surface" public API method
> which doesn't have to have the special caller parameter, to capture the
> caller with getCallerClass() parameterless API (possibly enclosed with a
> quick check confirming that it might actually be needed) and bind it to
> a ThreadLocal, then use this ThreadLocal down at the end...

confirming that it might actually be needed is a problem. In the old 
fallback path we don't know what we call until after we are deep in 
runtime code, and there it is too late. In the other paths we could mark 
those methods in a @CallerSensitive style and do it in that case only.

>> and the good integration with Java is one of the key points of
>> Groovy. Even if we make something like that @CallerSensitive and add the
>> parameter only in those cases, we break being able to override methods.
>
> I guess I don't know every Groovy need to obtain the caller class. I
> thought the problem was to support calling caller-sensitive methods in
> Java API (like Class.forName(String)) from within Groovy code, where
> there are runtime-inserted frames between the "call-site" and the target
> method. Are there any other needs?

ok, there is a misunderstanding...

if we call a Java implemented method from Groovy, which is using 
getCallerClass() it may or may not work. In general this does not work 
and our problem is not about that at all. With the change to let 
getCallerClass() ignore some reflective frames it will work actually 
better as long as we use our custom callsite caching implementation, it 
will not work if indy is used or the fallback path.

To be able to call a method Class#forName(String), we need to "replace" 
it with an implementation of our own, which we do with an approach 
similar to extension methods (only that ours can hide existing 
implementation methods for groovy). And in there we need to get to the 
caller class

Our problem though is @Grab which is an annotation to add elements to 
the classpath while running a script.

>> Plus, before Groovy3 is not done we have to support several call paths.
>> And the oldest one, which is still a fallback, does not support
>> transporting the caller class through the runtime layers at all.
>> Changing here is a breaking change.
>
> Could you describe those call-paths? Examples of Groovy code and to what
> it gets translated (equivalent Java code at call site) with a brief
> description of what each intermediate layer (between the call-site and
> the target method) does and at which point the caller class is extracted...

the code generated at the call site depends on several factors 
actually... The call site code itself is usually not very informative

I start with Groovy 1.0, since that is basically the fallback path. Here 
this.foo() translates more or less to
ScriptBytecodeAdapter.invokeMethod0(staticCallerClass, this,"foo")
which basically does this.getMetaClass().invokeMethod(staticCallerClass, 
this, "foo"). The problem is that the meta class might be user supplied 
and the code executed in invokeMethod as well. The invocation is then 
finally done by reflection. That means we have frames from 
ScriptBytecodeAdapter, from the meta class, as well as maybe frames from 
a custom meta class and reflection frames. At the level of 
ScriptBytecodeAdapter there is a means of transporting the caller class, 
but that is the static one. Once there is a subclass, this information 
is different from what is needed here and it cannot simply be exchanged. 
Even if the bytecode adapter is changed, we cannot change the public API 
for MetaClass#invokeMethod now. And then the information would be lost.

In later versions of Groovy (since 1.6) we introduced a custom call site 
caching technique, which uses runtime generated classes to create a 
helper class per call site and is then used for invocation. At the 
callsite we basically have something like callsiteArray[i].invoke(..). 
Here again the staticCallerClass can be found. In this version we are 
able to "get" the method we want to invoke, before invoking it 
(bypassing MetaClass#invokeMethod). But to be able to get the method, 
certain conditions have to be met (like no user supplied meta class). If 
they are not met, then we do basically the same path as in 1.0, only 
that we don't use ScriptBytecodeAdapter. Instead We use our CallSite 
class as entrance point, which then makes the call to the meta class. In 
the "efficent" case we have now frames from the callsite handling code 
between the callsite and the target method only. This includes 
reflection in the first instantiation, later the generated class is used 
so it reduces to two frames of which one is the Callsite entrance point, 
the other a frame form the generated method. In the fallback case we 
have frames from the callsite handling code, plus meta class code, plus 
reflection of course. Again the fallback case prevents us from 
transporting the caller information to the target method. If we ignore 
the fallback case, then we could here maybe use the Threadlocal 
information. It will require a new callsite interface for the bytecode 
though, meaning this code will not work for precompiled grovvy of older 
version, excluding from getting into Groovy 2.1.x, since it would be a 
breaking change. The earliest version for that would be Groovy 2.2.0, 
which is almost in RC now. Effectively it would mean we would have to do 
a 2.3.0 very soon after most probably.

In Groovy 2 we added an indy implementation, which replaces the callsite 
caching code.  At the callsite we have here basically invokedynamic 
"foo" with IndyInterface#bootstrap. bootstrap will first introduce a 
target for IndyInterface#selectMethod, since I need the runtime types 
instead of the static ones. The static caller class information is here 
part of the bootstrap method as Lookup object, added by invokedynamic 
itself. After selectMethod is done we have an initial invocation using 
invokeExact and later invocations by the handle stored in the callsite. 
Of course the same conditions as for the callsite caching above have to 
be met, meaning the fallback path might appear. That makes initially one 
IndyInterface frame, then invokedynamic and lambda related frames, then 
optionally the traget method, or in the fallback case the meta class 
frames plus reflection


bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From ivan.gerasimov at oracle.com  Tue Jul 30 15:35:10 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 30 Jul 2013 19:35:10 +0400
Subject: RFR [7192942] Optimizing calculation of power of 2 in HashMap
Message-ID: <51F7DD2E.6060204@oracle.com>

Hello everybody!

HashTable needs to calculate the power of two that is not less that the 
given number.
This calculation used to be implemented as a relatively inefficient loop 
(that's why the issue 7192942 was created).
The implementation was improved with 
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2e3cc7f599ca

However it can be improved even more. I reused 7192942 number for this 
propose.

Would you please help with reviewing?
Here's the webrev: 
http://cr.openjdk.java.net/~igerasim/7192942/0/webrev/ 


I also created a benchmark test to make sure the improvement is observable.
Here's the jmh benchmark I used:
http://cr.openjdk.java.net/~igerasim/bench/powoftwo/src/main/java/org/benches/PowerOfTwoBench.java 


Benchmark                                Mode Thr    Cnt Sec         
Mean   Mean error    Units
o.b.PowerOfTwoBench.benchPowerOfTwoA     avgt   1     20 5       
60.697        0.850  msec/op
o.b.PowerOfTwoBench.benchPowerOfTwoB     avgt   1     20 5       
53.013        0.940  msec/op

The first line is for the current implementation and the second one is 
for the proposed change.
Thus, the time gets reduced by 12%.

Sincerely yours,
Ivan


From chris.hegarty at oracle.com  Tue Jul 30 15:57:23 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 Jul 2013 16:57:23 +0100
Subject: RFR 8021883 j.u.Random/RandomStream.java test needs more robust
	timeout duration
In-Reply-To: 
References: 
Message-ID: <51F7E263.7060206@oracle.com>

Paul,

This looks like a nice cleanup, as well as fixing the timeout issue.

I just don't get the change in failure criteria. The old test used to 
verify that the arrays of random numbers of all generating threads were 
not equal, but now your checking the number of tasks?

-Chris.

> Hi,
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8021883-random-stream-test/webrev/
>
> This patch updates tests for ThreadLocalRandom streams and increases the timeout duration. Although the original should be enough for most cases in certain virtualized and emulated environments it might not be. I also took the liberty of consolidating the code and sprinkling stream and CompletableFuture dust on things.
>
> Paul.
>


From paul.sandoz at oracle.com  Tue Jul 30 16:14:11 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Jul 2013 17:14:11 +0100
Subject: RFR 8021883 j.u.Random/RandomStream.java test needs more robust
	timeout duration
In-Reply-To: <51F7E263.7060206@oracle.com>
References: 
	<51F7E263.7060206@oracle.com>
Message-ID: <9ED2D38A-0D67-4C1B-A269-8AFBBE7F8B00@oracle.com>

On Jul 30, 2013, at 4:57 PM, Chris Hegarty  wrote:
> Paul,
> 
> This looks like a nice cleanup, as well as fixing the timeout issue.
> 
> I just don't get the change in failure criteria. The old test used to verify that the arrays of random numbers of all generating threads were not equal, but now your checking the number of tasks?
> 

Previously the first result was checked if it was distinct. Now it checks all results are unique: add results to a set, if results are distinct the size should be the same as the # tasks producing the results. Note i was carefully to replace arrays with lists to ensure equals by content not reference.

In fact it would be clearer to do:

  int rc = cfs.stream().map(CompletableFuture::join).distinct().count();
  assertEquals(rc, tasks);

Paul.

From chris.hegarty at oracle.com  Tue Jul 30 16:25:17 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 Jul 2013 17:25:17 +0100
Subject: RFR 8021883 j.u.Random/RandomStream.java test needs more robust
	timeout duration
In-Reply-To: <9ED2D38A-0D67-4C1B-A269-8AFBBE7F8B00@oracle.com>
References: 
	<51F7E263.7060206@oracle.com>
	<9ED2D38A-0D67-4C1B-A269-8AFBBE7F8B00@oracle.com>
Message-ID: <51F7E8ED.5030000@oracle.com>

On 07/30/2013 05:14 PM, Paul Sandoz wrote:
> On Jul 30, 2013, at 4:57 PM, Chris Hegarty  wrote:
>> Paul,
>>
>> This looks like a nice cleanup, as well as fixing the timeout issue.
>>
>> I just don't get the change in failure criteria. The old test used to verify that the arrays of random numbers of all generating threads were not equal, but now your checking the number of tasks?
>>
>
> Previously the first result was checked if it was distinct. Now it checks all results are unique: add results to a set, if results are distinct the size should be the same as the # tasks producing the results. Note i was carefully to replace arrays with lists to ensure equals by content not reference.

Ah ok, got it.

> In fact it would be clearer to do:
>
>    int rc = cfs.stream().map(CompletableFuture::join).distinct().count();
>    assertEquals(rc, tasks);

This would be a little more obvious ( to me ).

-Chris.

>
> Paul.
>


From paul.sandoz at oracle.com  Tue Jul 30 16:31:18 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Jul 2013 17:31:18 +0100
Subject: RFR 8021883 j.u.Random/RandomStream.java test needs more robust
	timeout duration
In-Reply-To: <51F7E8ED.5030000@oracle.com>
References: 
	<51F7E263.7060206@oracle.com>
	<9ED2D38A-0D67-4C1B-A269-8AFBBE7F8B00@oracle.com>
	<51F7E8ED.5030000@oracle.com>
Message-ID: 


On Jul 30, 2013, at 5:25 PM, Chris Hegarty  wrote:

> On 07/30/2013 05:14 PM, Paul Sandoz wrote:
>> On Jul 30, 2013, at 4:57 PM, Chris Hegarty  wrote:
>>> Paul,
>>> 
>>> This looks like a nice cleanup, as well as fixing the timeout issue.
>>> 
>>> I just don't get the change in failure criteria. The old test used to verify that the arrays of random numbers of all generating threads were not equal, but now your checking the number of tasks?
>>> 
>> 
>> Previously the first result was checked if it was distinct. Now it checks all results are unique: add results to a set, if results are distinct the size should be the same as the # tasks producing the results. Note i was carefully to replace arrays with lists to ensure equals by content not reference.
> 
> Ah ok, got it.
> 
>> In fact it would be clearer to do:
>> 
>>   int rc = cfs.stream().map(CompletableFuture::join).distinct().count();
>>   assertEquals(rc, tasks);
> 
> This would be a little more obvious ( to me ).
> 

Updated patch (and lambda repo).

Paul.

From mike.duigou at oracle.com  Tue Jul 30 16:32:04 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 30 Jul 2013 09:32:04 -0700
Subject: RFR [7192942] Optimizing calculation of power of 2 in HashMap
In-Reply-To: <51F7DD2E.6060204@oracle.com>
References: <51F7DD2E.6060204@oracle.com>
Message-ID: <98B37F3D-2B51-4E5C-96E9-52B698BB5E8B@oracle.com>

Hi Ivan;

This looks like a good improvement. My only disappointment is that I didn't notice it when adding the roundUpToPowerOf2 method!

Do you need a sponsor to push the fix?

Mike

On Jul 30 2013, at 08:35 , Ivan Gerasimov wrote:

> Hello everybody!
> 
> HashTable needs to calculate the power of two that is not less that the given number.
> This calculation used to be implemented as a relatively inefficient loop (that's why the issue 7192942 was created).
> The implementation was improved with http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2e3cc7f599ca
> 
> However it can be improved even more. I reused 7192942 number for this propose.
> 
> Would you please help with reviewing?
> Here's the webrev: http://cr.openjdk.java.net/~igerasim/7192942/0/webrev/ 
> 
> I also created a benchmark test to make sure the improvement is observable.
> Here's the jmh benchmark I used:
> http://cr.openjdk.java.net/~igerasim/bench/powoftwo/src/main/java/org/benches/PowerOfTwoBench.java 
> 
> Benchmark                                Mode Thr    Cnt Sec         Mean   Mean error    Units
> o.b.PowerOfTwoBench.benchPowerOfTwoA     avgt   1     20 5       60.697        0.850  msec/op
> o.b.PowerOfTwoBench.benchPowerOfTwoB     avgt   1     20 5       53.013        0.940  msec/op
> 
> The first line is for the current implementation and the second one is for the proposed change.
> Thus, the time gets reduced by 12%.
> 
> Sincerely yours,
> Ivan



From ivan.gerasimov at oracle.com  Tue Jul 30 16:41:31 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 30 Jul 2013 20:41:31 +0400
Subject: RFR [7192942] Optimizing calculation of power of 2 in HashMap
In-Reply-To: <98B37F3D-2B51-4E5C-96E9-52B698BB5E8B@oracle.com>
References: <51F7DD2E.6060204@oracle.com>
	<98B37F3D-2B51-4E5C-96E9-52B698BB5E8B@oracle.com>
Message-ID: <51F7ECBB.707@oracle.com>

Thanks, Mike!

Yes, I need a sponsor and would really appreciate your help.

Sincerely yours,
Ivan

On 30.07.2013 20:32, Mike Duigou wrote:
> Hi Ivan;
>
> This looks like a good improvement. My only disappointment is that I didn't notice it when adding the roundUpToPowerOf2 method!
>
> Do you need a sponsor to push the fix?
>
> Mike
>
> On Jul 30 2013, at 08:35 , Ivan Gerasimov wrote:
>
>> Hello everybody!
>>
>> HashTable needs to calculate the power of two that is not less that the given number.
>> This calculation used to be implemented as a relatively inefficient loop (that's why the issue 7192942 was created).
>> The implementation was improved with http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2e3cc7f599ca
>>
>> However it can be improved even more. I reused 7192942 number for this propose.
>>
>> Would you please help with reviewing?
>> Here's the webrev: http://cr.openjdk.java.net/~igerasim/7192942/0/webrev/ 
>>
>> I also created a benchmark test to make sure the improvement is observable.
>> Here's the jmh benchmark I used:
>> http://cr.openjdk.java.net/~igerasim/bench/powoftwo/src/main/java/org/benches/PowerOfTwoBench.java 
>>
>> Benchmark                                Mode Thr    Cnt Sec         Mean   Mean error    Units
>> o.b.PowerOfTwoBench.benchPowerOfTwoA     avgt   1     20 5       60.697        0.850  msec/op
>> o.b.PowerOfTwoBench.benchPowerOfTwoB     avgt   1     20 5       53.013        0.940  msec/op
>>
>> The first line is for the current implementation and the second one is for the proposed change.
>> Thus, the time gets reduced by 12%.
>>
>> Sincerely yours,
>> Ivan
>
>



From mike.duigou at oracle.com  Tue Jul 30 16:44:20 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 30 Jul 2013 09:44:20 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <51F72532.3010101@oracle.com>
References: <51F72532.3010101@oracle.com>
Message-ID: 

Looks good to me as well.

Mike

On Jul 29 2013, at 19:30 , Henry Jen wrote:

> Hi,
> 
> Please review a simple fix for 8020977.
> 
> The fix grab the length before initiate copying operation, so that the
> 'delimiter' added for this won't be included in copy.
> 
> For rest cases, the timing window changed a little, but that's fine as
> simultaneous changes is not determined.
> 
> Cheers,
> Henry



From aleksey.shipilev at oracle.com  Tue Jul 30 16:47:29 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 30 Jul 2013 20:47:29 +0400
Subject: RFR [7192942] Optimizing calculation of power of 2 in HashMap
In-Reply-To: <51F7DD2E.6060204@oracle.com>
References: <51F7DD2E.6060204@oracle.com>
Message-ID: <51F7EE21.3020907@oracle.com>

On 07/30/2013 07:35 PM, Ivan Gerasimov wrote:
> I also created a benchmark test to make sure the improvement is observable.
> Here's the jmh benchmark I used:
> http://cr.openjdk.java.net/~igerasim/bench/powoftwo/src/main/java/org/benches/PowerOfTwoBench.java
> 

The nit: volatile writes are probably offset the results too much, it's
better to use the explicit idiom to feed the values:

    @GenerateMicroBenchmark
    public void benchPowerOfTwoA(BlackHole bh) {
        for (i = 0; i != MAX_I; ++i) {
            bh.consume(roundUpToPowerOf2A(i));
        }
    }

-Aleksey.


From stuart.marks at oracle.com  Tue Jul 30 17:00:54 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 30 Jul 2013 10:00:54 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <51F7286C.9000508@oracle.com>
References: <51F72532.3010101@oracle.com> <51F7286C.9000508@oracle.com>
Message-ID: <51F7F146.80704@oracle.com>

Hi Henry,

A couple minor comments on this.

I don't think it's necessary to snapshot other.value into a local otherBuilder 
variable. If other == this, when the value is mutated by prepareBuilder(), 
otherBuilder still points to this.value, whose contents have changed. So the 
actual data isn't being snapshotted, as is implied by the comment "seize the 
data".

The essence of the change is to snapshot other's original length. Of course 
this works because we know that prepareBuilder() only appends, so we don't have 
to copy the entire value.

I'd just use other.value and clarify the comment.

**

It's a separate issue but I spent some time puzzling over the 
(other.prefix.length() < length) condition trying to figure out why it's 
necessary. It turns out that it isn't. :-) [At least that I could see; the 
tests may prove me wrong.]

It's invariant that other.prefix.length() <= other.value.length(). They're only 
equal length if somebody has added the empty string to other. So the condition 
saves a call to append() if this is the case. Having this test is an 
optimization of sorts, but append() handles appending a zero-length interval 
just fine, so IMO this extra test adds a bit of clutter to the code.

Up to you whether you want to do anything about this.

Thanks,

s'marks




On 7/29/13 7:43 PM, Henry Jen wrote:
> Sorry, the webrev is at
>
> http://cr.openjdk.java.net/~henryjen/tl/8020977/0/webrev/
>
> Cheers,
> Henry
>
> On 07/29/2013 07:30 PM, Henry Jen wrote:
>> Hi,
>>
>> Please review a simple fix for 8020977.
>>
>> The fix grab the length before initiate copying operation, so that the
>> 'delimiter' added for this won't be included in copy.
>>
>> For rest cases, the timing window changed a little, but that's fine as
>> simultaneous changes is not determined.
>>
>> Cheers,
>> Henry
>>
>


From ivan.gerasimov at oracle.com  Tue Jul 30 17:05:23 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 30 Jul 2013 21:05:23 +0400
Subject: RFR [7192942] Optimizing calculation of power of 2 in HashMap
In-Reply-To: <51F7EE21.3020907@oracle.com>
References: <51F7DD2E.6060204@oracle.com> <51F7EE21.3020907@oracle.com>
Message-ID: <51F7F253.2090708@oracle.com>


On 30.07.2013 20:47, Aleksey Shipilev wrote:
> On 07/30/2013 07:35 PM, Ivan Gerasimov wrote:
>> I also created a benchmark test to make sure the improvement is observable.
>> Here's the jmh benchmark I used:
>> http://cr.openjdk.java.net/~igerasim/bench/powoftwo/src/main/java/org/benches/PowerOfTwoBench.java
>> 
> The nit: volatile writes are probably offset the results too much, it's
> better to use the explicit idiom to feed the values:
>
>      @GenerateMicroBenchmark
>      public void benchPowerOfTwoA(BlackHole bh) {
>          for (i = 0; i != MAX_I; ++i) {
>              bh.consume(roundUpToPowerOf2A(i));
>          }
>      }

Thanks, Aleksey!
Yes, this is much clearer. And shows much better improvement too :-)
Now it becomes ~45%.

Benchmark                                Mode Thr    Cnt Sec         
Mean   Mean error    Units
o.b.PowerOfTwoBench.benchPowerOfTwoA     avgt   1     20 5       
16.872        0.276  msec/op
o.b.PowerOfTwoBench.benchPowerOfTwoB     avgt   1     20 5        
9.304        0.378  msec/op

Sincerely yours,
Ivan

> -Aleksey.
>
>



From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 18:02:45 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 13:02:45 -0500
Subject: Try to run core libs tests -- All IO tests failing
Message-ID: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>

I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...

Thoughts?

Here's the output from one of the tests. It looks like all the other test outputs:

#Test Results (version 2)
#Tue Jul 30 12:38:15 CDT 2013
#-----testdescription-----
$file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
$root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
keywords=bug4143651
run=ASSUMED_ACTION main ReadAfterClose\n
source=ReadAfterClose.java
title=Test if I/O methods will check if the stream has been closed.

#-----environment-----

#-----testresult-----
description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
elapsed=60007 0\:01\:00.007
end=Tue Jul 30 12\:38\:15 CDT 2013
environment=regtest
execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
hostname=unknown
javatestOS=Mac OS X 10.7.5 (x86_64)
javatestVersion=4.4.1
jtregVersion=jtreg 4.1 dev b00
script=com.sun.javatest.regtest.RegressionScript 
sections=script_messages build compile
start=Tue Jul 30 12\:37\:15 CDT 2013
test=java/io/BufferedInputStream/ReadAfterClose.java
user.name=Nicholas
work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream

#section:script_messages
----------messages:(5/308)----------
JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)


#section:build
----------messages:(3/100)----------
command: build ReadAfterClose
reason: Named class compiled on demand
elapsed time (seconds): 60.005
result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out

#section:compile
----------messages:(3/235)----------
command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
reason: .class file out of date or does not exist
elapsed time (seconds): 60.005
result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out


test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out



From jason.uh at oracle.com  Tue Jul 30 18:05:19 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Tue, 30 Jul 2013 18:05:19 +0000
Subject: hg: jdk8/tl/jdk: 8021833: javadoc cleanup in java.net
Message-ID: <20130730180543.A4C1A48485@hg.openjdk.java.net>

Changeset: c76f89695c90
Author:    juh
Date:      2013-07-30 11:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c76f89695c90

8021833: javadoc cleanup in java.net
Summary:  and  converted to {@code }; package.html to package-info.java
Reviewed-by: darcy, chegar

! src/share/classes/java/net/Authenticator.java
! src/share/classes/java/net/ContentHandler.java
! src/share/classes/java/net/ContentHandlerFactory.java
! src/share/classes/java/net/CookieHandler.java
! src/share/classes/java/net/CookieManager.java
! src/share/classes/java/net/CookiePolicy.java
! src/share/classes/java/net/CookieStore.java
! src/share/classes/java/net/DatagramPacket.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/DatagramSocketImpl.java
! src/share/classes/java/net/DatagramSocketImplFactory.java
! src/share/classes/java/net/FileNameMap.java
! src/share/classes/java/net/HttpCookie.java
! src/share/classes/java/net/HttpRetryException.java
! src/share/classes/java/net/HttpURLConnection.java
! src/share/classes/java/net/IDN.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/Inet6Address.java
! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/InetSocketAddress.java
! src/share/classes/java/net/InterfaceAddress.java
! src/share/classes/java/net/JarURLConnection.java
! src/share/classes/java/net/MalformedURLException.java
! src/share/classes/java/net/MulticastSocket.java
! src/share/classes/java/net/NetPermission.java
! src/share/classes/java/net/NetworkInterface.java
! src/share/classes/java/net/PasswordAuthentication.java
! src/share/classes/java/net/PortUnreachableException.java
! src/share/classes/java/net/ProtocolException.java
! src/share/classes/java/net/Proxy.java
! src/share/classes/java/net/ProxySelector.java
! src/share/classes/java/net/ResponseCache.java
! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/SocketException.java
! src/share/classes/java/net/SocketImpl.java
! src/share/classes/java/net/SocketImplFactory.java
! src/share/classes/java/net/SocketInputStream.java
! src/share/classes/java/net/SocketOptions.java
! src/share/classes/java/net/SocketOutputStream.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/URI.java
! src/share/classes/java/net/URISyntaxException.java
! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLDecoder.java
! src/share/classes/java/net/URLEncoder.java
! src/share/classes/java/net/URLStreamHandler.java
! src/share/classes/java/net/URLStreamHandlerFactory.java
! src/share/classes/java/net/UnknownHostException.java
! src/share/classes/java/net/UnknownServiceException.java
+ src/share/classes/java/net/package-info.java
- src/share/classes/java/net/package.html



From Alan.Bateman at oracle.com  Tue Jul 30 18:10:32 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Jul 2013 11:10:32 -0700
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
Message-ID: <51F80198.4050209@oracle.com>

On 30/07/2013 11:02, Nick Williams wrote:
> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>
> Thoughts?
What command are you using? From the output it suggests that the 
connection between jtreg and the agent VM cannot be established.

-Alan.


>
> Here's the output from one of the tests. It looks like all the other test outputs:
>
> #Test Results (version 2)
> #Tue Jul 30 12:38:15 CDT 2013
> #-----testdescription-----
> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
> keywords=bug4143651
> run=ASSUMED_ACTION main ReadAfterClose\n
> source=ReadAfterClose.java
> title=Test if I/O methods will check if the stream has been closed.
>
> #-----environment-----
>
> #-----testresult-----
> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
> elapsed=60007 0\:01\:00.007
> end=Tue Jul 30 12\:38\:15 CDT 2013
> environment=regtest
> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
> hostname=unknown
> javatestOS=Mac OS X 10.7.5 (x86_64)
> javatestVersion=4.4.1
> jtregVersion=jtreg 4.1 dev b00
> script=com.sun.javatest.regtest.RegressionScript
> sections=script_messages build compile
> start=Tue Jul 30 12\:37\:15 CDT 2013
> test=java/io/BufferedInputStream/ReadAfterClose.java
> user.name=Nicholas
> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>
> #section:script_messages
> ----------messages:(5/308)----------
> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
> openjdk version "1.8.0-internal"
> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>
>
> #section:build
> ----------messages:(3/100)----------
> command: build ReadAfterClose
> reason: Named class compiled on demand
> elapsed time (seconds): 60.005
> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>
> #section:compile
> ----------messages:(3/235)----------
> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
> reason: .class file out of date or does not exist
> elapsed time (seconds): 60.005
> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>
>
> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>



From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 18:16:54 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 13:16:54 -0500
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <51F80198.4050209@oracle.com>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
Message-ID: 


On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:

> On 30/07/2013 11:02, Nick Williams wrote:
>> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>> 
>> Thoughts?
> What command are you using? From the output it suggests that the connection between jtreg and the agent VM cannot be established.
> 
> -Alan.

Command, just like README-builds.html#testing says:

cd test && make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all

I assume this is specifically an java.io-related problem because all the java.beans tests passed without exception and so far every java.io test through java.io.Externalizable (that's as far as it has gotten) has failed without exception. Wouldn't a problem with jtreg communicating with the agent VM have shown up in java.beans as well? I could be wrong of course.

> 
> 
>> 
>> Here's the output from one of the tests. It looks like all the other test outputs:
>> 
>> #Test Results (version 2)
>> #Tue Jul 30 12:38:15 CDT 2013
>> #-----testdescription-----
>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>> keywords=bug4143651
>> run=ASSUMED_ACTION main ReadAfterClose\n
>> source=ReadAfterClose.java
>> title=Test if I/O methods will check if the stream has been closed.
>> 
>> #-----environment-----
>> 
>> #-----testresult-----
>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>> elapsed=60007 0\:01\:00.007
>> end=Tue Jul 30 12\:38\:15 CDT 2013
>> environment=regtest
>> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
>> hostname=unknown
>> javatestOS=Mac OS X 10.7.5 (x86_64)
>> javatestVersion=4.4.1
>> jtregVersion=jtreg 4.1 dev b00
>> script=com.sun.javatest.regtest.RegressionScript
>> sections=script_messages build compile
>> start=Tue Jul 30 12\:37\:15 CDT 2013
>> test=java/io/BufferedInputStream/ReadAfterClose.java
>> user.name=Nicholas
>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>> 
>> #section:script_messages
>> ----------messages:(5/308)----------
>> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>> openjdk version "1.8.0-internal"
>> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>> 
>> 
>> #section:build
>> ----------messages:(3/100)----------
>> command: build ReadAfterClose
>> reason: Named class compiled on demand
>> elapsed time (seconds): 60.005
>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>> 
>> #section:compile
>> ----------messages:(3/235)----------
>> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>> reason: .class file out of date or does not exist
>> elapsed time (seconds): 60.005
>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>> 
>> 
>> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>> 
> 



From henry.jen at oracle.com  Tue Jul 30 18:27:16 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 30 Jul 2013 11:27:16 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <51F7F146.80704@oracle.com>
References: <51F72532.3010101@oracle.com> <51F7286C.9000508@oracle.com>
	<51F7F146.80704@oracle.com>
Message-ID: 


On Jul 30, 2013, at 10:00 AM, Stuart Marks  wrote:

> Hi Henry,
> 
> A couple minor comments on this.
> 
> I don't think it's necessary to snapshot other.value into a local otherBuilder variable. If other == this, when the value is mutated by prepareBuilder(), otherBuilder still points to this.value, whose contents have changed. So the actual data isn't being snapshotted, as is implied by the comment "seize the data".
> 
> The essence of the change is to snapshot other's original length. Of course this works because we know that prepareBuilder() only appends, so we don't have to copy the entire value.
> 
> I'd just use other.value and clarify the comment.
> 

That's fine, I think the reason in earlier version to capture the other.value is to avoid member access multiple times?

As you said, I only try to get the length as that's  enough to ensure we "seize" the data.

> **
> 
> It's a separate issue but I spent some time puzzling over the (other.prefix.length() < length) condition trying to figure out why it's necessary. It turns out that it isn't. :-) [At least that I could see; the tests may prove me wrong.]
> 
> It's invariant that other.prefix.length() <= other.value.length(). They're only equal length if somebody has added the empty string to other. So the condition saves a call to append() if this is the case. Having this test is an optimization of sorts, but append() handles appending a zero-length interval just fine, so IMO this extra test adds a bit of clutter to the code.
> 
> Up to you whether you want to do anything about this.
> 

Your analysis is correct, and I think it's really just defensive. I don't think it can happen as we do guard against other.value == null, which is the only case length will be less than prefix.

Cheers,
Henry



From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 18:39:22 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 13:39:22 -0500
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: 
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
Message-ID: 


On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:

> 
> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
> 
>> On 30/07/2013 11:02, Nick Williams wrote:
>>> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>>> 
>>> Thoughts?
>> What command are you using? From the output it suggests that the connection between jtreg and the agent VM cannot be established.
>> 
>> -Alan.
> 
> Command, just like README-builds.html#testing says:
> 
> cd test && make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
> 
> I assume this is specifically an java.io-related problem because all the java.beans tests passed without exception and so far every java.io test through java.io.Externalizable (that's as far as it has gotten) has failed without exception. Wouldn't a problem with jtreg communicating with the agent VM have shown up in java.beans as well? I could be wrong of course.

I see now that java.beans tests run in "othervm mode" while java.io tests run in "agentvm mode." Didn't realize they were being run differently. Your explanation makes much more sense now, but I still don't know what's wrong...

> 
>> 
>> 
>>> 
>>> Here's the output from one of the tests. It looks like all the other test outputs:
>>> 
>>> #Test Results (version 2)
>>> #Tue Jul 30 12:38:15 CDT 2013
>>> #-----testdescription-----
>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>> keywords=bug4143651
>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>> source=ReadAfterClose.java
>>> title=Test if I/O methods will check if the stream has been closed.
>>> 
>>> #-----environment-----
>>> 
>>> #-----testresult-----
>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>> elapsed=60007 0\:01\:00.007
>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>> environment=regtest
>>> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
>>> hostname=unknown
>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>> javatestVersion=4.4.1
>>> jtregVersion=jtreg 4.1 dev b00
>>> script=com.sun.javatest.regtest.RegressionScript
>>> sections=script_messages build compile
>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>> user.name=Nicholas
>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>> 
>>> #section:script_messages
>>> ----------messages:(5/308)----------
>>> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>> openjdk version "1.8.0-internal"
>>> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>> 
>>> 
>>> #section:build
>>> ----------messages:(3/100)----------
>>> command: build ReadAfterClose
>>> reason: Named class compiled on demand
>>> elapsed time (seconds): 60.005
>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>> 
>>> #section:compile
>>> ----------messages:(3/235)----------
>>> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>> reason: .class file out of date or does not exist
>>> elapsed time (seconds): 60.005
>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>> 
>>> 
>>> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>> 
>> 
> 



From stuart.marks at oracle.com  Tue Jul 30 20:00:10 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 30 Jul 2013 13:00:10 -0700
Subject: 8016036: RMI specification needs to be updated to allow Activation
	on remote hosts
In-Reply-To: <51F680BF.5060804@oracle.com>
References: <51DE3146.2000908@oracle.com> <51F41E5F.6030407@oracle.com>
	
	<51F680BF.5060804@oracle.com>
Message-ID: <51F81B4A.1000209@oracle.com>

On 7/29/13 7:48 AM, Alan Bateman wrote:
> On 29/07/2013 07:12, Bob Vandette wrote:
>> Excuse me if I'm a bit frustrated by this issue ...
>>
>> We keep going around and around on this issue.  We had a discussion with
>> Stuart and the JCK
>> team and Stuart didn't want to change the specification.  Has he now changed
>> his mind?
>>
>> Security and configuration issues aside, I don't understand why it doesn't
>> make sense to remote
>> activate an Object in an API that is supposed implement "Remote Method
>> Invocation" support.
>> The fact that it only supports activation on a local host seems to be a bug
>> to me.
>>
> I understand that this is a bit frustrating but I think we should at least
> explore relaxing the specification (if it hasn't been explored already). I'm
> not an export on RMI but I'm just concerned that the currently "agreed"
> solution to do the activation on another system feels more like a solution to
> get tests to pass. Stuart told me that he would look into it and see if
> relaxing the specification is feasible or not. Stuart - do you have anything to
> add?

Well, while one might say that I've changed my mind, I think it's more accurate 
to say that Alan has corrected a mistake on my part.

I had previously thought that it was forbidden to make things optional. Alan 
showed up on my doorstep the other day wondering why optionality wasn't pursued 
more thoroughly, and then he showed me some examples where something was made 
optional in a fairly precise manner. See for example the spec changes in this 
changeset:

http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/edb71a37fcb7

It seems plausible to investigate similar kinds of changes for RMI Activation.

s'marks


From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 20:13:53 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 15:13:53 -0500
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: 
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
Message-ID: 

Okay, this is indeed very interesting. After two hours it was only about half-way through the java.io tests and all of them had failed so far. On a sheer hunch and nothing more, I unplugged my ethernet cable, thus disconnecting me from any/all networks and the Internet. BOOM. The rest of the java.io tests finished (and passed) in a few seconds, leaving 137 that had failed. I then re-ran the tests while still disconnected from the Internet and 312 of the java.io tests passed this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, output below).

I plugged my Ethernet back in and ran the tests again and java.io started failing every test again, timing out after 60 seconds each. Curiously extending my hunch I remained connected over Ethernet and connected to a remote network via OpenVPN. Now all of the java.io test pass again (except that same one, with the same output).

What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)

Unfortunately, the one failed java.io test prevents jtreg from continuing on to the next set of tests (java.lang). Anyone know how to tell jtreg to continue running on error?

Nick

#Test Results (version 2)
#Tue Jul 30 14:53:42 CDT 2013
#-----testdescription-----
$file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
$root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
keywords=bug8003258
run=USER_SPECIFIED testng Lines\n
source=Lines.java
title=\ 

#-----environment-----

#-----testresult-----
end=Tue Jul 30 14\:53\:42 CDT 2013
execStatus=Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
sections=script_messages Details

#section:script_messages
----------messages:(0/0)----------

#section:Details
----------messages:(0/0)----------
----------Stack trace:(10/672)----------
java.lang.NullPointerException
	at com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
	at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
	at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
	at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
	at com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
	at com.sun.javatest.Script.run(Script.java:228)
	at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
	at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
	at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
result: Not run. Test running...


test result: Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java: java.lang.NullPointerException


On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:

> 
> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
> 
>> 
>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>> 
>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>>>> 
>>>> Thoughts?
>>> What command are you using? From the output it suggests that the connection between jtreg and the agent VM cannot be established.
>>> 
>>> -Alan.
>> 
>> Command, just like README-builds.html#testing says:
>> 
>> cd test && make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>> 
>> I assume this is specifically an java.io-related problem because all the java.beans tests passed without exception and so far every java.io test through java.io.Externalizable (that's as far as it has gotten) has failed without exception. Wouldn't a problem with jtreg communicating with the agent VM have shown up in java.beans as well? I could be wrong of course.
> 
> I see now that java.beans tests run in "othervm mode" while java.io tests run in "agentvm mode." Didn't realize they were being run differently. Your explanation makes much more sense now, but I still don't know what's wrong...
> 
>> 
>>> 
>>> 
>>>> 
>>>> Here's the output from one of the tests. It looks like all the other test outputs:
>>>> 
>>>> #Test Results (version 2)
>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>> #-----testdescription-----
>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>> keywords=bug4143651
>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>> source=ReadAfterClose.java
>>>> title=Test if I/O methods will check if the stream has been closed.
>>>> 
>>>> #-----environment-----
>>>> 
>>>> #-----testresult-----
>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>> elapsed=60007 0\:01\:00.007
>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>> environment=regtest
>>>> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
>>>> hostname=unknown
>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>> javatestVersion=4.4.1
>>>> jtregVersion=jtreg 4.1 dev b00
>>>> script=com.sun.javatest.regtest.RegressionScript
>>>> sections=script_messages build compile
>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>> user.name=Nicholas
>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>> 
>>>> #section:script_messages
>>>> ----------messages:(5/308)----------
>>>> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>> openjdk version "1.8.0-internal"
>>>> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>> 
>>>> 
>>>> #section:build
>>>> ----------messages:(3/100)----------
>>>> command: build ReadAfterClose
>>>> reason: Named class compiled on demand
>>>> elapsed time (seconds): 60.005
>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>> 
>>>> #section:compile
>>>> ----------messages:(3/235)----------
>>>> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>> reason: .class file out of date or does not exist
>>>> elapsed time (seconds): 60.005
>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>> 
>>>> 
>>>> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>> 
>>> 
>> 
> 



From jonathan.gibbons at oracle.com  Tue Jul 30 20:46:34 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 30 Jul 2013 13:46:34 -0700
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: 
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
Message-ID: <51F8262A.3060809@oracle.com>


jtreg itself does not "stop on error". If you're driving the tests 
through the makefiles, the makefiles may partition the work into 
separate jtreg runs on separate parts of the test suite.

-- Jon


On 07/30/2013 01:13 PM, Nick Williams wrote:
> Okay, this is indeed very interesting. After two hours it was only about half-way through the java.io tests and all of them had failed so far. On a sheer hunch and nothing more, I unplugged my ethernet cable, thus disconnecting me from any/all networks and the Internet. BOOM. The rest of the java.io tests finished (and passed) in a few seconds, leaving 137 that had failed. I then re-ran the tests while still disconnected from the Internet and 312 of the java.io tests passed this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, output below).
>
> I plugged my Ethernet back in and ran the tests again and java.io started failing every test again, timing out after 60 seconds each. Curiously extending my hunch I remained connected over Ethernet and connected to a remote network via OpenVPN. Now all of the java.io test pass again (except that same one, with the same output).
>
> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>
> Unfortunately, the one failed java.io test prevents jtreg from continuing on to the next set of tests (java.lang). Anyone know how to tell jtreg to continue running on error?
>
> Nick
>
> #Test Results (version 2)
> #Tue Jul 30 14:53:42 CDT 2013
> #-----testdescription-----
> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
> keywords=bug8003258
> run=USER_SPECIFIED testng Lines\n
> source=Lines.java
> title=\
>
> #-----environment-----
>
> #-----testresult-----
> end=Tue Jul 30 14\:53\:42 CDT 2013
> execStatus=Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
> sections=script_messages Details
>
> #section:script_messages
> ----------messages:(0/0)----------
>
> #section:Details
> ----------messages:(0/0)----------
> ----------Stack trace:(10/672)----------
> java.lang.NullPointerException
> 	at com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
> 	at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
> 	at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
> 	at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
> 	at com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
> 	at com.sun.javatest.Script.run(Script.java:228)
> 	at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
> 	at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
> 	at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
> result: Not run. Test running...
>
>
> test result: Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>
>
> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>
>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>
>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>
>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>>>>>
>>>>> Thoughts?
>>>> What command are you using? From the output it suggests that the connection between jtreg and the agent VM cannot be established.
>>>>
>>>> -Alan.
>>> Command, just like README-builds.html#testing says:
>>>
>>> cd test && make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>>>
>>> I assume this is specifically an java.io-related problem because all the java.beans tests passed without exception and so far every java.io test through java.io.Externalizable (that's as far as it has gotten) has failed without exception. Wouldn't a problem with jtreg communicating with the agent VM have shown up in java.beans as well? I could be wrong of course.
>> I see now that java.beans tests run in "othervm mode" while java.io tests run in "agentvm mode." Didn't realize they were being run differently. Your explanation makes much more sense now, but I still don't know what's wrong...
>>
>>>>
>>>>> Here's the output from one of the tests. It looks like all the other test outputs:
>>>>>
>>>>> #Test Results (version 2)
>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>> #-----testdescription-----
>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>> keywords=bug4143651
>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>> source=ReadAfterClose.java
>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>
>>>>> #-----environment-----
>>>>>
>>>>> #-----testresult-----
>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>> elapsed=60007 0\:01\:00.007
>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>> environment=regtest
>>>>> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
>>>>> hostname=unknown
>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>> javatestVersion=4.4.1
>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>> sections=script_messages build compile
>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>> user.name=Nicholas
>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>
>>>>> #section:script_messages
>>>>> ----------messages:(5/308)----------
>>>>> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>> openjdk version "1.8.0-internal"
>>>>> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>
>>>>>
>>>>> #section:build
>>>>> ----------messages:(3/100)----------
>>>>> command: build ReadAfterClose
>>>>> reason: Named class compiled on demand
>>>>> elapsed time (seconds): 60.005
>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>
>>>>> #section:compile
>>>>> ----------messages:(3/235)----------
>>>>> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>> reason: .class file out of date or does not exist
>>>>> elapsed time (seconds): 60.005
>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>
>>>>>
>>>>> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>



From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 20:50:55 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 15:50:55 -0500
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <51F8262A.3060809@oracle.com>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com>
Message-ID: <77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>

Gotchya.

I commented out the java.io tests locally for now.

By the way, I noticed something. Before, when the java.io tests were failing, the output said "hostname=unknown." However, now that I'm connected to the VPN and they're passing, the output says "hostname=10.211.55.2." When I unplug from the ethernet altogether, the output says "hostname=127.0.0.1."

Sounds like that has something to do with this weird failure of all java.io tests.

N

On Jul 30, 2013, at 3:46 PM, Jonathan Gibbons wrote:

> 
> jtreg itself does not "stop on error". If you're driving the tests through the makefiles, the makefiles may partition the work into separate jtreg runs on separate parts of the test suite.
> 
> -- Jon
> 
> 
> On 07/30/2013 01:13 PM, Nick Williams wrote:
>> Okay, this is indeed very interesting. After two hours it was only about half-way through the java.io tests and all of them had failed so far. On a sheer hunch and nothing more, I unplugged my ethernet cable, thus disconnecting me from any/all networks and the Internet. BOOM. The rest of the java.io tests finished (and passed) in a few seconds, leaving 137 that had failed. I then re-ran the tests while still disconnected from the Internet and 312 of the java.io tests passed this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, output below).
>> 
>> I plugged my Ethernet back in and ran the tests again and java.io started failing every test again, timing out after 60 seconds each. Curiously extending my hunch I remained connected over Ethernet and connected to a remote network via OpenVPN. Now all of the java.io test pass again (except that same one, with the same output).
>> 
>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>> 
>> Unfortunately, the one failed java.io test prevents jtreg from continuing on to the next set of tests (java.lang). Anyone know how to tell jtreg to continue running on error?
>> 
>> Nick
>> 
>> #Test Results (version 2)
>> #Tue Jul 30 14:53:42 CDT 2013
>> #-----testdescription-----
>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>> keywords=bug8003258
>> run=USER_SPECIFIED testng Lines\n
>> source=Lines.java
>> title=\
>> 
>> #-----environment-----
>> 
>> #-----testresult-----
>> end=Tue Jul 30 14\:53\:42 CDT 2013
>> execStatus=Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>> sections=script_messages Details
>> 
>> #section:script_messages
>> ----------messages:(0/0)----------
>> 
>> #section:Details
>> ----------messages:(0/0)----------
>> ----------Stack trace:(10/672)----------
>> java.lang.NullPointerException
>> 	at com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>> 	at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>> 	at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>> 	at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>> 	at com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>> 	at com.sun.javatest.Script.run(Script.java:228)
>> 	at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>> 	at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>> 	at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>> result: Not run. Test running...
>> 
>> 
>> test result: Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>> 
>> 
>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>> 
>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>> 
>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>> 
>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>>>>>> 
>>>>>> Thoughts?
>>>>> What command are you using? From the output it suggests that the connection between jtreg and the agent VM cannot be established.
>>>>> 
>>>>> -Alan.
>>>> Command, just like README-builds.html#testing says:
>>>> 
>>>> cd test && make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>>>> 
>>>> I assume this is specifically an java.io-related problem because all the java.beans tests passed without exception and so far every java.io test through java.io.Externalizable (that's as far as it has gotten) has failed without exception. Wouldn't a problem with jtreg communicating with the agent VM have shown up in java.beans as well? I could be wrong of course.
>>> I see now that java.beans tests run in "othervm mode" while java.io tests run in "agentvm mode." Didn't realize they were being run differently. Your explanation makes much more sense now, but I still don't know what's wrong...
>>> 
>>>>> 
>>>>>> Here's the output from one of the tests. It looks like all the other test outputs:
>>>>>> 
>>>>>> #Test Results (version 2)
>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>> #-----testdescription-----
>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>> keywords=bug4143651
>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>> source=ReadAfterClose.java
>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>> 
>>>>>> #-----environment-----
>>>>>> 
>>>>>> #-----testresult-----
>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>> elapsed=60007 0\:01\:00.007
>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>> environment=regtest
>>>>>> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
>>>>>> hostname=unknown
>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>> javatestVersion=4.4.1
>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>> sections=script_messages build compile
>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>> user.name=Nicholas
>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>> 
>>>>>> #section:script_messages
>>>>>> ----------messages:(5/308)----------
>>>>>> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>> openjdk version "1.8.0-internal"
>>>>>> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>> 
>>>>>> 
>>>>>> #section:build
>>>>>> ----------messages:(3/100)----------
>>>>>> command: build ReadAfterClose
>>>>>> reason: Named class compiled on demand
>>>>>> elapsed time (seconds): 60.005
>>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>> 
>>>>>> #section:compile
>>>>>> ----------messages:(3/235)----------
>>>>>> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>> reason: .class file out of date or does not exist
>>>>>> elapsed time (seconds): 60.005
>>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>> 
>>>>>> 
>>>>>> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>> 
> 



From jonathan.gibbons at oracle.com  Tue Jul 30 20:53:49 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 30 Jul 2013 13:53:49 -0700
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com>
	<77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>
Message-ID: <51F827DD.6060505@oracle.com>

Regarding the hostname, jtreg is executing the following code for all 
tests, not just java.io tests

         String hostname;
         try {
             hostname = InetAddress.getLocalHost().getCanonicalHostName();
         } catch (UnknownHostException e) {
             hostname = "unknown";
         }



On 07/30/2013 01:50 PM, Nick Williams wrote:
> Gotchya.
>
> I commented out the java.io tests locally for now.
>
> By the way, I noticed something. Before, when the java.io tests were failing, the output said "hostname=unknown." However, now that I'm connected to the VPN and they're passing, the output says "hostname=10.211.55.2." When I unplug from the ethernet altogether, the output says "hostname=127.0.0.1."
>
> Sounds like that has something to do with this weird failure of all java.io tests.
>
> N
>
> On Jul 30, 2013, at 3:46 PM, Jonathan Gibbons wrote:
>
>> jtreg itself does not "stop on error". If you're driving the tests through the makefiles, the makefiles may partition the work into separate jtreg runs on separate parts of the test suite.
>>
>> -- Jon
>>
>>
>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>> Okay, this is indeed very interesting. After two hours it was only about half-way through the java.io tests and all of them had failed so far. On a sheer hunch and nothing more, I unplugged my ethernet cable, thus disconnecting me from any/all networks and the Internet. BOOM. The rest of the java.io tests finished (and passed) in a few seconds, leaving 137 that had failed. I then re-ran the tests while still disconnected from the Internet and 312 of the java.io tests passed this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, output below).
>>>
>>> I plugged my Ethernet back in and ran the tests again and java.io started failing every test again, timing out after 60 seconds each. Curiously extending my hunch I remained connected over Ethernet and connected to a remote network via OpenVPN. Now all of the java.io test pass again (except that same one, with the same output).
>>>
>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>>
>>> Unfortunately, the one failed java.io test prevents jtreg from continuing on to the next set of tests (java.lang). Anyone know how to tell jtreg to continue running on error?
>>>
>>> Nick
>>>
>>> #Test Results (version 2)
>>> #Tue Jul 30 14:53:42 CDT 2013
>>> #-----testdescription-----
>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>> keywords=bug8003258
>>> run=USER_SPECIFIED testng Lines\n
>>> source=Lines.java
>>> title=\
>>>
>>> #-----environment-----
>>>
>>> #-----testresult-----
>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>> execStatus=Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>> sections=script_messages Details
>>>
>>> #section:script_messages
>>> ----------messages:(0/0)----------
>>>
>>> #section:Details
>>> ----------messages:(0/0)----------
>>> ----------Stack trace:(10/672)----------
>>> java.lang.NullPointerException
>>> 	at com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>> 	at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>> 	at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>> 	at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>> 	at com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>> 	at com.sun.javatest.Script.run(Script.java:228)
>>> 	at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>> 	at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>> 	at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>> result: Not run. Test running...
>>>
>>>
>>> test result: Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>>
>>>
>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>>
>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>>
>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>>
>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>>>>>>>
>>>>>>> Thoughts?
>>>>>> What command are you using? From the output it suggests that the connection between jtreg and the agent VM cannot be established.
>>>>>>
>>>>>> -Alan.
>>>>> Command, just like README-builds.html#testing says:
>>>>>
>>>>> cd test && make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>>>>>
>>>>> I assume this is specifically an java.io-related problem because all the java.beans tests passed without exception and so far every java.io test through java.io.Externalizable (that's as far as it has gotten) has failed without exception. Wouldn't a problem with jtreg communicating with the agent VM have shown up in java.beans as well? I could be wrong of course.
>>>> I see now that java.beans tests run in "othervm mode" while java.io tests run in "agentvm mode." Didn't realize they were being run differently. Your explanation makes much more sense now, but I still don't know what's wrong...
>>>>
>>>>>>> Here's the output from one of the tests. It looks like all the other test outputs:
>>>>>>>
>>>>>>> #Test Results (version 2)
>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>> #-----testdescription-----
>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>> keywords=bug4143651
>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>> source=ReadAfterClose.java
>>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>>>
>>>>>>> #-----environment-----
>>>>>>>
>>>>>>> #-----testresult-----
>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>> environment=regtest
>>>>>>> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
>>>>>>> hostname=unknown
>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>> javatestVersion=4.4.1
>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>> sections=script_messages build compile
>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> user.name=Nicholas
>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>>
>>>>>>> #section:script_messages
>>>>>>> ----------messages:(5/308)----------
>>>>>>> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>> openjdk version "1.8.0-internal"
>>>>>>> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>>
>>>>>>>
>>>>>>> #section:build
>>>>>>> ----------messages:(3/100)----------
>>>>>>> command: build ReadAfterClose
>>>>>>> reason: Named class compiled on demand
>>>>>>> elapsed time (seconds): 60.005
>>>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>
>>>>>>> #section:compile
>>>>>>> ----------messages:(3/235)----------
>>>>>>> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> reason: .class file out of date or does not exist
>>>>>>> elapsed time (seconds): 60.005
>>>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>
>>>>>>>
>>>>>>> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>



From jonathan.gibbons at oracle.com  Tue Jul 30 20:57:06 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 30 Jul 2013 13:57:06 -0700
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com>
	<77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>
Message-ID: <51F828A2.8010503@oracle.com>

I note, and will fix the NPE in the stack trace.

-- Jon

On 07/30/2013 01:50 PM, Nick Williams wrote:
> Gotchya.
>
> I commented out the java.io tests locally for now.
>
> By the way, I noticed something. Before, when the java.io tests were failing, the output said "hostname=unknown." However, now that I'm connected to the VPN and they're passing, the output says "hostname=10.211.55.2." When I unplug from the ethernet altogether, the output says "hostname=127.0.0.1."
>
> Sounds like that has something to do with this weird failure of all java.io tests.
>
> N
>
> On Jul 30, 2013, at 3:46 PM, Jonathan Gibbons wrote:
>
>> jtreg itself does not "stop on error". If you're driving the tests through the makefiles, the makefiles may partition the work into separate jtreg runs on separate parts of the test suite.
>>
>> -- Jon
>>
>>
>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>> Okay, this is indeed very interesting. After two hours it was only about half-way through the java.io tests and all of them had failed so far. On a sheer hunch and nothing more, I unplugged my ethernet cable, thus disconnecting me from any/all networks and the Internet. BOOM. The rest of the java.io tests finished (and passed) in a few seconds, leaving 137 that had failed. I then re-ran the tests while still disconnected from the Internet and 312 of the java.io tests passed this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, output below).
>>>
>>> I plugged my Ethernet back in and ran the tests again and java.io started failing every test again, timing out after 60 seconds each. Curiously extending my hunch I remained connected over Ethernet and connected to a remote network via OpenVPN. Now all of the java.io test pass again (except that same one, with the same output).
>>>
>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>>
>>> Unfortunately, the one failed java.io test prevents jtreg from continuing on to the next set of tests (java.lang). Anyone know how to tell jtreg to continue running on error?
>>>
>>> Nick
>>>
>>> #Test Results (version 2)
>>> #Tue Jul 30 14:53:42 CDT 2013
>>> #-----testdescription-----
>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>> keywords=bug8003258
>>> run=USER_SPECIFIED testng Lines\n
>>> source=Lines.java
>>> title=\
>>>
>>> #-----environment-----
>>>
>>> #-----testresult-----
>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>> execStatus=Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>> sections=script_messages Details
>>>
>>> #section:script_messages
>>> ----------messages:(0/0)----------
>>>
>>> #section:Details
>>> ----------messages:(0/0)----------
>>> ----------Stack trace:(10/672)----------
>>> java.lang.NullPointerException
>>> 	at com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>> 	at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>> 	at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>> 	at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>> 	at com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>> 	at com.sun.javatest.Script.run(Script.java:228)
>>> 	at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>> 	at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>> 	at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>> result: Not run. Test running...
>>>
>>>
>>> test result: Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>>
>>>
>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>>
>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>>
>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>>
>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>>>>>>>
>>>>>>> Thoughts?
>>>>>> What command are you using? From the output it suggests that the connection between jtreg and the agent VM cannot be established.
>>>>>>
>>>>>> -Alan.
>>>>> Command, just like README-builds.html#testing says:
>>>>>
>>>>> cd test && make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>>>>>
>>>>> I assume this is specifically an java.io-related problem because all the java.beans tests passed without exception and so far every java.io test through java.io.Externalizable (that's as far as it has gotten) has failed without exception. Wouldn't a problem with jtreg communicating with the agent VM have shown up in java.beans as well? I could be wrong of course.
>>>> I see now that java.beans tests run in "othervm mode" while java.io tests run in "agentvm mode." Didn't realize they were being run differently. Your explanation makes much more sense now, but I still don't know what's wrong...
>>>>
>>>>>>> Here's the output from one of the tests. It looks like all the other test outputs:
>>>>>>>
>>>>>>> #Test Results (version 2)
>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>> #-----testdescription-----
>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>> keywords=bug4143651
>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>> source=ReadAfterClose.java
>>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>>>
>>>>>>> #-----environment-----
>>>>>>>
>>>>>>> #-----testresult-----
>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>> environment=regtest
>>>>>>> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
>>>>>>> hostname=unknown
>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>> javatestVersion=4.4.1
>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>> sections=script_messages build compile
>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> user.name=Nicholas
>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>>
>>>>>>> #section:script_messages
>>>>>>> ----------messages:(5/308)----------
>>>>>>> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>> openjdk version "1.8.0-internal"
>>>>>>> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>>
>>>>>>>
>>>>>>> #section:build
>>>>>>> ----------messages:(3/100)----------
>>>>>>> command: build ReadAfterClose
>>>>>>> reason: Named class compiled on demand
>>>>>>> elapsed time (seconds): 60.005
>>>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>
>>>>>>> #section:compile
>>>>>>> ----------messages:(3/235)----------
>>>>>>> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> reason: .class file out of date or does not exist
>>>>>>> elapsed time (seconds): 60.005
>>>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>
>>>>>>>
>>>>>>> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>



From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 20:57:37 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 15:57:37 -0500
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <51F827DD.6060505@oracle.com>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com>
	<77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>
	<51F827DD.6060505@oracle.com>
Message-ID: <2C77DEF7-8588-41D9-8A5B-CBBE73201440@nicholaswilliams.net>

Ahhh. I know what's going on.

http://blog.leon-rosenberg.net/2012/08/oracle-kills-getlocalhost-on-macos-x-in.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180557

Maybe someone can fix this year-old Java 7 bug that makes getLocalHost() not work sometimes on Mac OS X? :-)

N

On Jul 30, 2013, at 3:53 PM, Jonathan Gibbons wrote:

> Regarding the hostname, jtreg is executing the following code for all tests, not just java.io tests
> 
>        String hostname;
>        try {
>            hostname = InetAddress.getLocalHost().getCanonicalHostName();
>        } catch (UnknownHostException e) {
>            hostname = "unknown";
>        }
> 
> 
> 
> On 07/30/2013 01:50 PM, Nick Williams wrote:
>> Gotchya.
>> 
>> I commented out the java.io tests locally for now.
>> 
>> By the way, I noticed something. Before, when the java.io tests were failing, the output said "hostname=unknown." However, now that I'm connected to the VPN and they're passing, the output says "hostname=10.211.55.2." When I unplug from the ethernet altogether, the output says "hostname=127.0.0.1."
>> 
>> Sounds like that has something to do with this weird failure of all java.io tests.
>> 
>> N
>> 
>> On Jul 30, 2013, at 3:46 PM, Jonathan Gibbons wrote:
>> 
>>> jtreg itself does not "stop on error". If you're driving the tests through the makefiles, the makefiles may partition the work into separate jtreg runs on separate parts of the test suite.
>>> 
>>> -- Jon
>>> 
>>> 
>>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>>> Okay, this is indeed very interesting. After two hours it was only about half-way through the java.io tests and all of them had failed so far. On a sheer hunch and nothing more, I unplugged my ethernet cable, thus disconnecting me from any/all networks and the Internet. BOOM. The rest of the java.io tests finished (and passed) in a few seconds, leaving 137 that had failed. I then re-ran the tests while still disconnected from the Internet and 312 of the java.io tests passed this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, output below).
>>>> 
>>>> I plugged my Ethernet back in and ran the tests again and java.io started failing every test again, timing out after 60 seconds each. Curiously extending my hunch I remained connected over Ethernet and connected to a remote network via OpenVPN. Now all of the java.io test pass again (except that same one, with the same output).
>>>> 
>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>>> 
>>>> Unfortunately, the one failed java.io test prevents jtreg from continuing on to the next set of tests (java.lang). Anyone know how to tell jtreg to continue running on error?
>>>> 
>>>> Nick
>>>> 
>>>> #Test Results (version 2)
>>>> #Tue Jul 30 14:53:42 CDT 2013
>>>> #-----testdescription-----
>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>> keywords=bug8003258
>>>> run=USER_SPECIFIED testng Lines\n
>>>> source=Lines.java
>>>> title=\
>>>> 
>>>> #-----environment-----
>>>> 
>>>> #-----testresult-----
>>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>>> execStatus=Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>>> sections=script_messages Details
>>>> 
>>>> #section:script_messages
>>>> ----------messages:(0/0)----------
>>>> 
>>>> #section:Details
>>>> ----------messages:(0/0)----------
>>>> ----------Stack trace:(10/672)----------
>>>> java.lang.NullPointerException
>>>> 	at com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>>> 	at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>>> 	at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>>> 	at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>>> 	at com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>>> 	at com.sun.javatest.Script.run(Script.java:228)
>>>> 	at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>>> 	at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>>> 	at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>>> result: Not run. Test running...
>>>> 
>>>> 
>>>> test result: Error. Unexpected exception caught from test java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>>> 
>>>> 
>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>>> 
>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>>> 
>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>>> 
>>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>>> I'm running the core libs tests locally (for the first time), and every java.io test is failing. They're all failing for the same reason (output below), and I suspect it's something local and not an actual problem. But the test output is not very helpful. Note that all of the java.beans tests passed with flying colors. Once it got to java.io, everything started failing. Worse, each test is taking 60 seconds to fail. I could be here a while...
>>>>>>>> 
>>>>>>>> Thoughts?
>>>>>>> What command are you using? From the output it suggests that the connection between jtreg and the agent VM cannot be established.
>>>>>>> 
>>>>>>> -Alan.
>>>>>> Command, just like README-builds.html#testing says:
>>>>>> 
>>>>>> cd test && make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>>>>>> 
>>>>>> I assume this is specifically an java.io-related problem because all the java.beans tests passed without exception and so far every java.io test through java.io.Externalizable (that's as far as it has gotten) has failed without exception. Wouldn't a problem with jtreg communicating with the agent VM have shown up in java.beans as well? I could be wrong of course.
>>>>> I see now that java.beans tests run in "othervm mode" while java.io tests run in "agentvm mode." Didn't realize they were being run differently. Your explanation makes much more sense now, but I still don't know what's wrong...
>>>>> 
>>>>>>>> Here's the output from one of the tests. It looks like all the other test outputs:
>>>>>>>> 
>>>>>>>> #Test Results (version 2)
>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>>> #-----testdescription-----
>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>>> keywords=bug4143651
>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>>> source=ReadAfterClose.java
>>>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>>>> 
>>>>>>>> #-----environment-----
>>>>>>>> 
>>>>>>>> #-----testresult-----
>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>>> environment=regtest
>>>>>>>> execStatus=Error. Cannot get VM for test\: java.net.SocketTimeoutException\: Accept timed out
>>>>>>>> hostname=unknown
>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>>> javatestVersion=4.4.1
>>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>>> sections=script_messages build compile
>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>> user.name=Nicholas
>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>>> 
>>>>>>>> #section:script_messages
>>>>>>>> ----------messages:(5/308)----------
>>>>>>>> JDK under test: (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>>> openjdk version "1.8.0-internal"
>>>>>>>> OpenJDK Runtime Environment (build 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> #section:build
>>>>>>>> ----------messages:(3/100)----------
>>>>>>>> command: build ReadAfterClose
>>>>>>>> reason: Named class compiled on demand
>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>> 
>>>>>>>> #section:compile
>>>>>>>> ----------messages:(3/235)----------
>>>>>>>> command: compile -XDignore.symbol.file=true /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>> reason: .class file out of date or does not exist
>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>> result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>> 
>>>>>>>> 
>>>>>>>> test result: Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out
>>>>>>>> 
> 



From henry.jen at oracle.com  Tue Jul 30 20:58:13 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 30 Jul 2013 13:58:13 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: 
References: <51F72532.3010101@oracle.com> <51F7286C.9000508@oracle.com>
	<51F7F146.80704@oracle.com>
	
Message-ID: <51F828E5.8010708@oracle.com>

Updated webrev adapting feedback from Stuart.

I need a sponsor to push the fix. Thanks for reviewing.

Cheers,
Henry


On 07/30/2013 11:27 AM, Henry Jen wrote:
> 
> On Jul 30, 2013, at 10:00 AM, Stuart Marks  wrote:
> 
>> Hi Henry,
>>
>> A couple minor comments on this.
>>
>> I don't think it's necessary to snapshot other.value into a local otherBuilder variable. If other == this, when the value is mutated by prepareBuilder(), otherBuilder still points to this.value, whose contents have changed. So the actual data isn't being snapshotted, as is implied by the comment "seize the data".
>>
>> The essence of the change is to snapshot other's original length. Of course this works because we know that prepareBuilder() only appends, so we don't have to copy the entire value.
>>
>> I'd just use other.value and clarify the comment.
>>
> 
> That's fine, I think the reason in earlier version to capture the other.value is to avoid member access multiple times?
> 
> As you said, I only try to get the length as that's  enough to ensure we "seize" the data.
> 
>> **
>>
>> It's a separate issue but I spent some time puzzling over the (other.prefix.length() < length) condition trying to figure out why it's necessary. It turns out that it isn't. :-) [At least that I could see; the tests may prove me wrong.]
>>
>> It's invariant that other.prefix.length() <= other.value.length(). They're only equal length if somebody has added the empty string to other. So the condition saves a call to append() if this is the case. Having this test is an optimization of sorts, but append() handles appending a zero-length interval just fine, so IMO this extra test adds a bit of clutter to the code.
>>
>> Up to you whether you want to do anything about this.
>>
> 
> Your analysis is correct, and I think it's really just defensive. I don't think it can happen as we do guard against other.value == null, which is the only case length will be less than prefix.
> 
> Cheers,
> Henry
> 



From henry.jen at oracle.com  Tue Jul 30 20:59:11 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 30 Jul 2013 13:59:11 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <51F828E5.8010708@oracle.com>
References: <51F72532.3010101@oracle.com> <51F7286C.9000508@oracle.com>
	<51F7F146.80704@oracle.com>
	
	<51F828E5.8010708@oracle.com>
Message-ID: <51F8291F.9080308@oracle.com>

On 07/30/2013 01:58 PM, Henry Jen wrote:
> Updated webrev adapting feedback from Stuart.
> 
> I need a sponsor to push the fix. Thanks for reviewing.
> 

Sigh, again, the webrev is at
http://cr.openjdk.java.net/~henryjen/tl/8020977/1/webrev/

Cheers,
Henry


From jonathan.gibbons at oracle.com  Tue Jul 30 21:05:07 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 30 Jul 2013 14:05:07 -0700
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <2C77DEF7-8588-41D9-8A5B-CBBE73201440@nicholaswilliams.net>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com>
	<77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>
	<51F827DD.6060505@oracle.com>
	<2C77DEF7-8588-41D9-8A5B-CBBE73201440@nicholaswilliams.net>
Message-ID: <51F82A83.8020903@oracle.com>

Bumped the isue to P2, marked it "Affect 8" and added a link to this thread.

-- Jon

On 07/30/2013 01:57 PM, Nick Williams wrote:
> Ahhh. I know what's going on.
>
> http://blog.leon-rosenberg.net/2012/08/oracle-kills-getlocalhost-on-macos-x-in.html
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180557
>
> Maybe someone can fix this year-old Java 7 bug that makes 
> getLocalHost() not work sometimes on Mac OS X? :-)
>
> N
>
> On Jul 30, 2013, at 3:53 PM, Jonathan Gibbons wrote:
>
>> Regarding the hostname, jtreg is executing the following code for all 
>> tests, not just java.io tests
>>
>>        String hostname;
>>        try {
>>            hostname = InetAddress.getLocalHost().getCanonicalHostName();
>>        } catch (UnknownHostException e) {
>>            hostname = "unknown";
>>        }
>>
>>
>>
>> On 07/30/2013 01:50 PM, Nick Williams wrote:
>>> Gotchya.
>>>
>>> I commented out the java.io tests locally for now.
>>>
>>> By the way, I noticed something. Before, when the java.io tests were 
>>> failing, the output said "hostname=unknown." However, now that I'm 
>>> connected to the VPN and they're passing, the output says 
>>> "hostname=10.211.55.2." When I unplug from the ethernet altogether, 
>>> the output says "hostname=127.0.0.1."
>>>
>>> Sounds like that has something to do with this weird failure of all 
>>> java.io tests.
>>>
>>> N
>>>
>>> On Jul 30, 2013, at 3:46 PM, Jonathan Gibbons wrote:
>>>
>>>> jtreg itself does not "stop on error". If you're driving the tests 
>>>> through the makefiles, the makefiles may partition the work into 
>>>> separate jtreg runs on separate parts of the test suite.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>>>> Okay, this is indeed very interesting. After two hours it was only 
>>>>> about half-way through the java.io tests and all of them had 
>>>>> failed so far. On a sheer hunch and nothing more, I unplugged my 
>>>>> ethernet cable, thus disconnecting me from any/all networks and 
>>>>> the Internet. BOOM. The rest of the java.io tests finished (and 
>>>>> passed) in a few seconds, leaving 137 that had failed. I then 
>>>>> re-ran the tests while still disconnected from the Internet and 
>>>>> 312 of the java.io tests passed this time, leaving only 1 failure 
>>>>> (java/io/BufferedReader/Lines.java, output below).
>>>>>
>>>>> I plugged my Ethernet back in and ran the tests again and java.io 
>>>>> started failing every test again, timing out after 60 seconds 
>>>>> each. Curiously extending my hunch I remained connected over 
>>>>> Ethernet and connected to a remote network via OpenVPN. Now all of 
>>>>> the java.io test pass again (except that same one, with the same 
>>>>> output).
>>>>>
>>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>>>>
>>>>> Unfortunately, the one failed java.io test prevents jtreg from 
>>>>> continuing on to the next set of tests (java.lang). Anyone know 
>>>>> how to tell jtreg to continue running on error?
>>>>>
>>>>> Nick
>>>>>
>>>>> #Test Results (version 2)
>>>>> #Tue Jul 30 14:53:42 CDT 2013
>>>>> #-----testdescription-----
>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>> keywords=bug8003258
>>>>> run=USER_SPECIFIED testng Lines\n
>>>>> source=Lines.java
>>>>> title=\
>>>>>
>>>>> #-----environment-----
>>>>>
>>>>> #-----testresult-----
>>>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>>>> execStatus=Error. Unexpected exception caught from test 
>>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>>>> sections=script_messages Details
>>>>>
>>>>> #section:script_messages
>>>>> ----------messages:(0/0)----------
>>>>>
>>>>> #section:Details
>>>>> ----------messages:(0/0)----------
>>>>> ----------Stack trace:(10/672)----------
>>>>> java.lang.NullPointerException
>>>>> at 
>>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>>>> at 
>>>>> com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>>>> at 
>>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>>>> at com.sun.javatest.Script.run(Script.java:228)
>>>>> at 
>>>>> com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>>>> at 
>>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>>>> result: Not run. Test running...
>>>>>
>>>>>
>>>>> test result: Error. Unexpected exception caught from test 
>>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>>>>
>>>>>
>>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>>>>
>>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>>>>
>>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>>>>
>>>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>>>> I'm running the core libs tests locally (for the first time), 
>>>>>>>>> and every java.io test is failing. They're all failing for the 
>>>>>>>>> same reason (output below), and I suspect it's something local 
>>>>>>>>> and not an actual problem. But the test output is not very 
>>>>>>>>> helpful. Note that all of the java.beans tests passed with 
>>>>>>>>> flying colors. Once it got to java.io, everything started 
>>>>>>>>> failing. Worse, each test is taking 60 seconds to fail. I 
>>>>>>>>> could be here a while...
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>> What command are you using? From the output it suggests that 
>>>>>>>> the connection between jtreg and the agent VM cannot be 
>>>>>>>> established.
>>>>>>>>
>>>>>>>> -Alan.
>>>>>>> Command, just like README-builds.html#testing says:
>>>>>>>
>>>>>>> cd test && make 
>>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ 
>>>>>>> all
>>>>>>>
>>>>>>> I assume this is specifically an java.io-related problem because 
>>>>>>> all the java.beans tests passed without exception and so far 
>>>>>>> every java.io test through java.io.Externalizable (that's as far 
>>>>>>> as it has gotten) has failed without exception. Wouldn't a 
>>>>>>> problem with jtreg communicating with the agent VM have shown up 
>>>>>>> in java.beans as well? I could be wrong of course.
>>>>>> I see now that java.beans tests run in "othervm mode" while 
>>>>>> java.io tests run in "agentvm mode." Didn't realize they were 
>>>>>> being run differently. Your explanation makes much more sense 
>>>>>> now, but I still don't know what's wrong...
>>>>>>
>>>>>>>>> Here's the output from one of the tests. It looks like all the 
>>>>>>>>> other test outputs:
>>>>>>>>>
>>>>>>>>> #Test Results (version 2)
>>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>>>> #-----testdescription-----
>>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>>>> keywords=bug4143651
>>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>>>> source=ReadAfterClose.java
>>>>>>>>> title=Test if I/O methods will check if the stream has been 
>>>>>>>>> closed.
>>>>>>>>>
>>>>>>>>> #-----environment-----
>>>>>>>>>
>>>>>>>>> #-----testresult-----
>>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>>>> environment=regtest
>>>>>>>>> execStatus=Error. Cannot get VM for test\: 
>>>>>>>>> java.net.SocketTimeoutException\: Accept timed out
>>>>>>>>> hostname=unknown
>>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>>>> javatestVersion=4.4.1
>>>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>>>> sections=script_messages build compile
>>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>> user.name=Nicholas
>>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>>>>
>>>>>>>>> #section:script_messages
>>>>>>>>> ----------messages:(5/308)----------
>>>>>>>>> JDK under test: 
>>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>>>> openjdk version "1.8.0-internal"
>>>>>>>>> OpenJDK Runtime Environment (build 
>>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> #section:build
>>>>>>>>> ----------messages:(3/100)----------
>>>>>>>>> command: build ReadAfterClose
>>>>>>>>> reason: Named class compiled on demand
>>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>>> result: Error. Cannot get VM for test: 
>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>>
>>>>>>>>> #section:compile
>>>>>>>>> ----------messages:(3/235)----------
>>>>>>>>> command: compile -XDignore.symbol.file=true 
>>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>> reason: .class file out of date or does not exist
>>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>>> result: Error. Cannot get VM for test: 
>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> test result: Error. Cannot get VM for test: 
>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>>
>>
>



From xueming.shen at oracle.com  Tue Jul 30 21:41:44 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Tue, 30 Jul 2013 21:41:44 +0000
Subject: hg: jdk8/tl/jdk: 8021767:
	test/java/time/tck/java/time/format/TCKFormatStyle.java failing
Message-ID: <20130730214210.B172D48490@hg.openjdk.java.net>

Changeset: 8bc1bbd5b659
Author:    sherman
Date:      2013-07-30 14:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bc1bbd5b659

8021767: test/java/time/tck/java/time/format/TCKFormatStyle.java failing
Summary: Correct to use fixed locale, not locale of test environment
Reviewed-by: alanb, okutsu
Contributed-by: roger.riggs at oracle.com

! test/java/time/tck/java/time/format/TCKFormatStyle.java



From stuart.marks at oracle.com  Tue Jul 30 22:03:16 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 30 Jul 2013 15:03:16 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <51F8291F.9080308@oracle.com>
References: <51F72532.3010101@oracle.com> <51F7286C.9000508@oracle.com>
	<51F7F146.80704@oracle.com>
	
	<51F828E5.8010708@oracle.com> <51F8291F.9080308@oracle.com>
Message-ID: <51F83824.1010307@oracle.com>

On 7/30/13 1:59 PM, Henry Jen wrote:
> On 07/30/2013 01:58 PM, Henry Jen wrote:
>> Updated webrev adapting feedback from Stuart.
>>
>> I need a sponsor to push the fix. Thanks for reviewing.
>>
>
> Sigh, again, the webrev is at
> http://cr.openjdk.java.net/~henryjen/tl/8020977/1/webrev/

Looks good, thanks for updating.

I'll push it, but only if you add me to the reviewer line. ;-)

s'marks



From henry.jen at oracle.com  Tue Jul 30 22:50:56 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 30 Jul 2013 15:50:56 -0700
Subject: CFR: 8020977: StringJoiner merges with itself not as expected
In-Reply-To: <51F83824.1010307@oracle.com>
References: <51F72532.3010101@oracle.com> <51F7286C.9000508@oracle.com>
	<51F7F146.80704@oracle.com>
	
	<51F828E5.8010708@oracle.com> <51F8291F.9080308@oracle.com>
	<51F83824.1010307@oracle.com>
Message-ID: <575D6D6C-05BE-43E6-B59F-D64B1EF1E6D1@oracle.com>

My bad, you should be on the reviewer list. After all, this update is based on your feedback.

Webrev updated with Reviewed-by.

Cheers,
Henry


On Jul 30, 2013, at 3:03 PM, Stuart Marks  wrote:

> On 7/30/13 1:59 PM, Henry Jen wrote:
>> On 07/30/2013 01:58 PM, Henry Jen wrote:
>>> Updated webrev adapting feedback from Stuart.
>>> 
>>> I need a sponsor to push the fix. Thanks for reviewing.
>>> 
>> 
>> Sigh, again, the webrev is at
>> http://cr.openjdk.java.net/~henryjen/tl/8020977/1/webrev/
> 
> Looks good, thanks for updating.
> 
> I'll push it, but only if you add me to the reviewer line. ;-)
> 
> s'marks
> 



From swingler at apple.com  Tue Jul 30 22:53:30 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 30 Jul 2013 15:53:30 -0700
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org>
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>
	
	
	<8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org>
Message-ID: <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com>

Apple is highly unlikely to change the behavior of nl_langinfo().

There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose.

Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X.

Regards,
Mike Swingler
Apple Inc.

On Jul 30, 2013, at 9:05 AM, Francis Devereux  wrote:

> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset.
> 
> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X.
> 
> On 30 Jul 2013, at 15:56, Scott Palmer  wrote:
> 
>> Then shouldn't you be complaining to Apple that the value returned by
>> nl_langinfo needs to be changed?
>> David's point seems to be that second guessing the character set reported
>> by the OS is likely to cause a different set of problems.
>> 
>> Scott
>> 
>> 
>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin <
>> Johannes.Schindelin at gmx.de> wrote:
>> 
>>> Hi,
>>> 
>>> On Tue, 30 Jul 2013, David Holmes wrote:
>>> 
>>>> On 30/07/2013 5:54 AM, Brent Christian wrote:
>>>>> On 7/28/13 10:13 PM, David Holmes wrote:
>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote:
>>>>>>> Please review my fix for 8011194 : "Apps launched via
>>> double-clicked
>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X"
>>>>>>> 
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194
>>>>>>> 
>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or
>>>>>>> from a native .app bundle), reading and displaying UTF-8
>>>>>>> characters beyond the standard ASCII range works fine.
>>>>>>> 
>>>>>>> A notable exception is the launching of an app by double-clicking
>>>>>>> a .jar file.  In this case, file.encoding defaults to US-ASCII,
>>>>>>> and characters outside of the ASCII range show up as garbage.
>>>>>> 
>>>>>> Why does this occur? What sets the encoding to US-ASCII?
>>>>> 
>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
>>>>> values for LANG/LC* are set in the environment when double-clicking a
>>>>> .jar.
>>>>> 
>>>>> We get "UTF-8" when launching from the command line because the
>>>>> default Terminal.app setup on Mac will setup LANG for you (to
>>>>> "en_US.UTF-8" in the US).
>>>> 
>>>> Sounds like a user environment error to me. This isn't my area but I'm
>>>> not convinced we should be second guessing what we think the encoding
>>>> should be.
>>> 
>>> Except that that is not the case here, of course. The user did *not* set
>>> any environment variable in this case.
>>> 
>>> So we are not talking about "second guessing" or "user environment error"
>>> but about a sensible default.
>>> 
>>> As to US-ASCII, sorry to say: the seventies called and want their
>>> character set back.
>>> 
>>> There can be no question that UTF-8 is the best default character
>>> encoding, or are you even going to question *that*?
>>> 
>>>> What if someone intends for it to be US-ASCII?
>>> 
>>> Then LANG would not be unset, would it.
>>> 
>>> Hth,
>>> Johannes
>>> 
>> 
> 



From david.dehaven at oracle.com  Tue Jul 30 23:06:42 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 30 Jul 2013 16:06:42 -0700
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com>
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>
	
	
	<8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org>
	<4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com>
Message-ID: 


I was about to chime in that UTF-8 has been the preferred encoding for (stored) text on Mac OS X as long as I've been hacking on it (think "Rhapsody"), so why is this even an issue?

Judging from the docs, nl_langinfo seems like a Unix portability function (something more likely to be happier with ASCII in a terminal), not something to be used by a native Cocoa application.



Set it to UTF-8 and forget about it


-DrD-

> Apple is highly unlikely to change the behavior of nl_langinfo().
> 
> There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose.
> 
> Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X.
> 
> Regards,
> Mike Swingler
> Apple Inc.
> 
> On Jul 30, 2013, at 9:05 AM, Francis Devereux  wrote:
> 
>> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset.
>> 
>> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X.
>> 
>> On 30 Jul 2013, at 15:56, Scott Palmer  wrote:
>> 
>>> Then shouldn't you be complaining to Apple that the value returned by
>>> nl_langinfo needs to be changed?
>>> David's point seems to be that second guessing the character set reported
>>> by the OS is likely to cause a different set of problems.
>>> 
>>> Scott
>>> 
>>> 
>>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin <
>>> Johannes.Schindelin at gmx.de> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> On Tue, 30 Jul 2013, David Holmes wrote:
>>>> 
>>>>> On 30/07/2013 5:54 AM, Brent Christian wrote:
>>>>>> On 7/28/13 10:13 PM, David Holmes wrote:
>>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote:
>>>>>>>> Please review my fix for 8011194 : "Apps launched via
>>>> double-clicked
>>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X"
>>>>>>>> 
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194
>>>>>>>> 
>>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or
>>>>>>>> from a native .app bundle), reading and displaying UTF-8
>>>>>>>> characters beyond the standard ASCII range works fine.
>>>>>>>> 
>>>>>>>> A notable exception is the launching of an app by double-clicking
>>>>>>>> a .jar file.  In this case, file.encoding defaults to US-ASCII,
>>>>>>>> and characters outside of the ASCII range show up as garbage.
>>>>>>> 
>>>>>>> Why does this occur? What sets the encoding to US-ASCII?
>>>>>> 
>>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
>>>>>> values for LANG/LC* are set in the environment when double-clicking a
>>>>>> .jar.
>>>>>> 
>>>>>> We get "UTF-8" when launching from the command line because the
>>>>>> default Terminal.app setup on Mac will setup LANG for you (to
>>>>>> "en_US.UTF-8" in the US).
>>>>> 
>>>>> Sounds like a user environment error to me. This isn't my area but I'm
>>>>> not convinced we should be second guessing what we think the encoding
>>>>> should be.
>>>> 
>>>> Except that that is not the case here, of course. The user did *not* set
>>>> any environment variable in this case.
>>>> 
>>>> So we are not talking about "second guessing" or "user environment error"
>>>> but about a sensible default.
>>>> 
>>>> As to US-ASCII, sorry to say: the seventies called and want their
>>>> character set back.
>>>> 
>>>> There can be no question that UTF-8 is the best default character
>>>> encoding, or are you even going to question *that*?
>>>> 
>>>>> What if someone intends for it to be US-ASCII?
>>>> 
>>>> Then LANG would not be unset, would it.
>>>> 
>>>> Hth,
>>>> Johannes
>>>> 
>>> 
>> 
> 



From nicholas+openjdk at nicholaswilliams.net  Tue Jul 30 23:11:20 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 30 Jul 2013 18:11:20 -0500
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <51F7DCD0.1030306@gmx.org>
References: 
	<51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org>
	<51F7CACD.2070703@gmail.com> <51F7DCD0.1030306@gmx.org>
Message-ID: <50B05474-BD3F-47C7-8412-F0F305E0F0FF@nicholaswilliams.net>

Quick question for those of you that know anything about @CallerSensitive...

After looking at the code and experimenting some, I've discovered that getCallerClass() doesn't actually keep going until it finds the first method without @CallerSensitive. It only returns the caller of the caller. So, for example:

Stack 1
@CallerSensitive Reflection.getCallerClass()
@CallerSensitive MyClass1.method1();
MyClass2.method2();

In this case, getCallerClass() returns MyClass2.class. BUT:

Stack 2
@CallerSensitive Reflection.getCallerClass()
@CallerSensitive MyClass1.method1();
@CallerSensitive MyClass2.method2();
MyClass3.method3();

In this case, getCallerClass() STILL returns MyClass2.class. Based on the plain-language meaning of @CallerSensitive, I would expect getCallerClass() to return MyClass3.class in the second case. But, indeed, the JavaDoc for Reflection.getCallerClass() says: "Returns the class of the caller of the method calling this method." So, then, what's the point of @CallerSensitive? Looking at the code:

   vframeStream vfst(thread);
   // Cf. LibraryCallKit::inline_native_Reflection_getCallerClass
   for (int n = 0; !vfst.at_end(); vfst.security_next(), n++) {
     Method* m = vfst.method();
     assert(m != NULL, "sanity");
     switch (n) {
     case 0:
       // This must only be called from Reflection.getCallerClass
       if (m->intrinsic_id() != vmIntrinsics::_getCallerClass) {
         THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), "JVM_GetCallerClass must only be called from Reflection.getCallerClass");
       }
       // fall-through
     case 1:
       // Frame 0 and 1 must be caller sensitive.
       if (!m->caller_sensitive()) {
         THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), err_msg("CallerSensitive annotation expected at frame %d", n));
       }
       break;
     default:
       if (!m->is_ignored_by_security_stack_walk()) {
         // We have reached the desired frame; return the holder class.
         return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror());
       }
       break;
     }
   }

It seems to me that @CallerSensitive is completely pointless. This is ALWAYS going to return the first non-reflection frame after frame 1, regardless of @CallerSensitive. If @CallerSensitive were really supposed to have an actual purpose, it would seem to me that the last part should be this:

       if (!m->is_ignored_by_security_stack_walk() && !m->caller_sensitive()) {
         // We have reached the desired frame; return the holder class.
         return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror());
       }

Am I completely missing the point here? I just don't see a reason for @CallerSensitive. The code could do the exact same thing it currently is without @CallerSensitive (except for enforcing that frame 1 is @CallerSensitive, which really isn't necessary if you aren't using it in further frames).

Thoughts?

Nick

On Jul 30, 2013, at 10:33 AM, Jochen Theodorou wrote:

> Am 30.07.2013 16:16, schrieb Peter Levart:
>> 
>> On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
>>> Am 30.07.2013 14:17, schrieb Peter Levart:
>>> [...]
>>>> So what would give Groovy or other language runtimes headaches when all
>>>> there was was a parameter-less getCallerClass() API? Aren't the
>>>> intermediate frames inserted by those runtimes controlled by the
>>>> runtimes? Couldn't the "surface" runtime-inserted methods capture the
>>>> caller and pass it down? I guess the problem is supporting calling the
>>>> caller-sensitive methods like Class.forName(String) and such which don't
>>>> have the overloaded variant taking caller Class or ClassLoader as an
>>>> argument...
>>> Speaking for Groovy...
>>> those intermediate frames are runtime controlled, yes, but passing down
>>> the caller class is exactly the problem. Imagine I would suggest that
>>> each and every method definition in Java automatically gets an
>>> additional parameter for the caller class, just to have access to it
>>> inside the method. You would not accept that for Java, would you? And so
>>> we cannot accept that for Groovy if we want to keep integration with
>>> Java...
>> 
>> Are you talking about internal Groovy implementation (the
>> runtime-inserted methods) or the publicly visible API?
> 
> that's the problem, it is a mix, some internal, other not. We are going to change that in Groovy 3
> 
>> One solution for
>> internal implementation of Groovy could be (speaking by heart since I
>> don't know the internals of Groovy) for the "surface" public API method
>> which doesn't have to have the special caller parameter, to capture the
>> caller with getCallerClass() parameterless API (possibly enclosed with a
>> quick check confirming that it might actually be needed) and bind it to
>> a ThreadLocal, then use this ThreadLocal down at the end...
> 
> confirming that it might actually be needed is a problem. In the old fallback path we don't know what we call until after we are deep in runtime code, and there it is too late. In the other paths we could mark those methods in a @CallerSensitive style and do it in that case only.
> 
>>> and the good integration with Java is one of the key points of
>>> Groovy. Even if we make something like that @CallerSensitive and add the
>>> parameter only in those cases, we break being able to override methods.
>> 
>> I guess I don't know every Groovy need to obtain the caller class. I
>> thought the problem was to support calling caller-sensitive methods in
>> Java API (like Class.forName(String)) from within Groovy code, where
>> there are runtime-inserted frames between the "call-site" and the target
>> method. Are there any other needs?
> 
> ok, there is a misunderstanding...
> 
> if we call a Java implemented method from Groovy, which is using getCallerClass() it may or may not work. In general this does not work and our problem is not about that at all. With the change to let getCallerClass() ignore some reflective frames it will work actually better as long as we use our custom callsite caching implementation, it will not work if indy is used or the fallback path.
> 
> To be able to call a method Class#forName(String), we need to "replace" it with an implementation of our own, which we do with an approach similar to extension methods (only that ours can hide existing implementation methods for groovy). And in there we need to get to the caller class
> 
> Our problem though is @Grab which is an annotation to add elements to the classpath while running a script.
> 
>>> Plus, before Groovy3 is not done we have to support several call paths.
>>> And the oldest one, which is still a fallback, does not support
>>> transporting the caller class through the runtime layers at all.
>>> Changing here is a breaking change.
>> 
>> Could you describe those call-paths? Examples of Groovy code and to what
>> it gets translated (equivalent Java code at call site) with a brief
>> description of what each intermediate layer (between the call-site and
>> the target method) does and at which point the caller class is extracted...
> 
> the code generated at the call site depends on several factors actually... The call site code itself is usually not very informative
> 
> I start with Groovy 1.0, since that is basically the fallback path. Here this.foo() translates more or less to
> ScriptBytecodeAdapter.invokeMethod0(staticCallerClass, this,"foo")
> which basically does this.getMetaClass().invokeMethod(staticCallerClass, this, "foo"). The problem is that the meta class might be user supplied and the code executed in invokeMethod as well. The invocation is then finally done by reflection. That means we have frames from ScriptBytecodeAdapter, from the meta class, as well as maybe frames from a custom meta class and reflection frames. At the level of ScriptBytecodeAdapter there is a means of transporting the caller class, but that is the static one. Once there is a subclass, this information is different from what is needed here and it cannot simply be exchanged. Even if the bytecode adapter is changed, we cannot change the public API for MetaClass#invokeMethod now. And then the information would be lost.
> 
> In later versions of Groovy (since 1.6) we introduced a custom call site caching technique, which uses runtime generated classes to create a helper class per call site and is then used for invocation. At the callsite we basically have something like callsiteArray[i].invoke(..). Here again the staticCallerClass can be found. In this version we are able to "get" the method we want to invoke, before invoking it (bypassing MetaClass#invokeMethod). But to be able to get the method, certain conditions have to be met (like no user supplied meta class). If they are not met, then we do basically the same path as in 1.0, only that we don't use ScriptBytecodeAdapter. Instead We use our CallSite class as entrance point, which then makes the call to the meta class. In the "efficent" case we have now frames from the callsite handling code between the callsite and the target method only. This includes reflection in the first instantiation, later the generated class is used so it reduces to two frames of which one is the Callsite entrance point, the other a frame form the generated method. In the fallback case we have frames from the callsite handling code, plus meta class code, plus reflection of course. Again the fallback case prevents us from transporting the caller information to the target method. If we ignore the fallback case, then we could here maybe use the Threadlocal information. It will require a new callsite interface for the bytecode though, meaning this code will not work for precompiled grovvy of older version, excluding from getting into Groovy 2.1.x, since it would be a breaking change. The earliest version for that would be Groovy 2.2.0, which is almost in RC now. Effectively it would mean we would have to do a 2.3.0 very soon after most probably.
> 
> In Groovy 2 we added an indy implementation, which replaces the callsite caching code.  At the callsite we have here basically invokedynamic "foo" with IndyInterface#bootstrap. bootstrap will first introduce a target for IndyInterface#selectMethod, since I need the runtime types instead of the static ones. The static caller class information is here part of the bootstrap method as Lookup object, added by invokedynamic itself. After selectMethod is done we have an initial invocation using invokeExact and later invocations by the handle stored in the callsite. Of course the same conditions as for the callsite caching above have to be met, meaning the fallback path might appear. That makes initially one IndyInterface frame, then invokedynamic and lambda related frames, then optionally the traget method, or in the fallback case the meta class frames plus reflection
> 
> 
> bye Jochen
> 
> -- 
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
> 



From naoto.sato at oracle.com  Tue Jul 30 23:28:40 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 30 Jul 2013 16:28:40 -0700
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: 
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>
	
	
	<8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org>
	<4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com>
	
Message-ID: <51F84C28.3050209@oracle.com>

On 7/30/13 4:06 PM, David DeHaven wrote:
>
> I was about to chime in that UTF-8 has been the preferred encoding for (stored) text on Mac OS X as long as I've been hacking on it (think "Rhapsody"), so why is this even an issue?
>
> Judging from the docs, nl_langinfo seems like a Unix portability function (something more likely to be happier with ASCII in a terminal), not something to be used by a native Cocoa application.
>
>
> 
> Set it to UTF-8 and forget about it
> 

+1. Yet another reasoning is that UTF-8 is backward compatible with 
ASCII, i.e., exact same mapping for 0x0000-0x007F code points.

Naoto

>
> -DrD-
>
>> Apple is highly unlikely to change the behavior of nl_langinfo().
>>
>> There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose.
>>
>> Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X.
>>
>> Regards,
>> Mike Swingler
>> Apple Inc.
>>
>> On Jul 30, 2013, at 9:05 AM, Francis Devereux  wrote:
>>
>>> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset.
>>>
>>> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X.
>>>
>>> On 30 Jul 2013, at 15:56, Scott Palmer  wrote:
>>>
>>>> Then shouldn't you be complaining to Apple that the value returned by
>>>> nl_langinfo needs to be changed?
>>>> David's point seems to be that second guessing the character set reported
>>>> by the OS is likely to cause a different set of problems.
>>>>
>>>> Scott
>>>>
>>>>
>>>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin <
>>>> Johannes.Schindelin at gmx.de> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, 30 Jul 2013, David Holmes wrote:
>>>>>
>>>>>> On 30/07/2013 5:54 AM, Brent Christian wrote:
>>>>>>> On 7/28/13 10:13 PM, David Holmes wrote:
>>>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote:
>>>>>>>>> Please review my fix for 8011194 : "Apps launched via
>>>>> double-clicked
>>>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X"
>>>>>>>>>
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194
>>>>>>>>>
>>>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or
>>>>>>>>> from a native .app bundle), reading and displaying UTF-8
>>>>>>>>> characters beyond the standard ASCII range works fine.
>>>>>>>>>
>>>>>>>>> A notable exception is the launching of an app by double-clicking
>>>>>>>>> a .jar file.  In this case, file.encoding defaults to US-ASCII,
>>>>>>>>> and characters outside of the ASCII range show up as garbage.
>>>>>>>>
>>>>>>>> Why does this occur? What sets the encoding to US-ASCII?
>>>>>>>
>>>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
>>>>>>> values for LANG/LC* are set in the environment when double-clicking a
>>>>>>> .jar.
>>>>>>>
>>>>>>> We get "UTF-8" when launching from the command line because the
>>>>>>> default Terminal.app setup on Mac will setup LANG for you (to
>>>>>>> "en_US.UTF-8" in the US).
>>>>>>
>>>>>> Sounds like a user environment error to me. This isn't my area but I'm
>>>>>> not convinced we should be second guessing what we think the encoding
>>>>>> should be.
>>>>>
>>>>> Except that that is not the case here, of course. The user did *not* set
>>>>> any environment variable in this case.
>>>>>
>>>>> So we are not talking about "second guessing" or "user environment error"
>>>>> but about a sensible default.
>>>>>
>>>>> As to US-ASCII, sorry to say: the seventies called and want their
>>>>> character set back.
>>>>>
>>>>> There can be no question that UTF-8 is the best default character
>>>>> encoding, or are you even going to question *that*?
>>>>>
>>>>>> What if someone intends for it to be US-ASCII?
>>>>>
>>>>> Then LANG would not be unset, would it.
>>>>>
>>>>> Hth,
>>>>> Johannes
>>>>>
>>>>
>>>
>>
>



From stuart.marks at oracle.com  Tue Jul 30 23:23:59 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Tue, 30 Jul 2013 23:23:59 +0000
Subject: hg: jdk8/tl/jdk: 8020977: StringJoiner merges with itself not as
	expected
Message-ID: <20130730232423.2F97748491@hg.openjdk.java.net>

Changeset: 09a77a1bdbc3
Author:    henryjen
Date:      2013-07-30 15:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09a77a1bdbc3

8020977: StringJoiner merges with itself not as expected
Reviewed-by: psandoz, chegar, mduigou, smarks

! src/share/classes/java/util/StringJoiner.java
! test/java/util/StringJoiner/MergeTest.java



From mike.duigou at oracle.com  Tue Jul 30 23:57:41 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 30 Jul 2013 16:57:41 -0700
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: <97903415-01F4-4FE2-B5F8-AFBF54217D32@oracle.com>
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
	<97903415-01F4-4FE2-B5F8-AFBF54217D32@oracle.com>
Message-ID: 


On Jul 29 2013, at 04:20 , Paul Sandoz wrote:

> Hi Mike,
> 
> V. quick review below.
> 
> 
> On Jul 27, 2013, at 12:31 AM, Mike Duigou  wrote:
> 
>> Hello all;
>> 
>> This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases. 
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/
>> 
>> The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures.
>> 
> 
> diff --git a/src/share/classes/java/util/Map.java b/src/share/classes/java/util/Map.java
> --- a/src/share/classes/java/util/Map.java
> +++ b/src/share/classes/java/util/Map.java
> @@ -804,6 +804,10 @@
>      *     return false;
>      * }
>      *
> +     * @implNote The default implementation does not throw NullPointerException
> +     * for maps that do not support null values if oldValue is null unless
> +     * newValue is also null.
> 
> 
> Is that really more a clarification of the default impl specification?

Yes. I will switch to @implSpec tag.

> 
> 
> -     * @throws NullPointerException if a specified key or value is null,
> +     * @throws NullPointerException if a specified key or newValue is null,
>      *         and this map does not permit null keys or values
> +     * @throws NullPointerException if oldValue is null and this map does not
> +     *         permit null values
> +     *         (optional)
> 
> 
> More curious than anything else, is it fine to have two declarations of NPE here?


Throwing NPE isn't optional if either key or newValue is null and the map does not permit null values.

This restriction has to be softened for oldValue because the default implementation doesn't test whether oldValue could be added to the map and doesn't know if the map allows null values. 

The multiple @throws approach is used as an alternative to a complicated legalistic description in a single throws declaration. It's used uncommonly elsewhere in the JDK. 

> +++ b/src/share/classes/java/util/TreeMap.java
> @@ -948,6 +948,27 @@
>     }
> 
>     @Override
> +    public synchronized boolean replace(K key, V oldValue, V newValue) {
> +        Entry p = getEntry(key);
> +        if (p!=null && Objects.equals(oldValue, p.value)) {
> +            p.value = newValue;
> +            return true;
> +        }
> +        return false;
> +    }
> +
> +    @Override
> +    public synchronized V replace(K key, V value) {
> 
> Remove the synchronized?

Yes, thanks for catching that. 

> I might be missing something but i cannot see where ExtendsAbstractCollection is used.

It may not be. I will check.


Mike

From david.holmes at oracle.com  Wed Jul 31 03:12:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 31 Jul 2013 13:12:38 +1000
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com>
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>
	
	
	<8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org>
	<4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com>
Message-ID: <51F880A6.3070207@oracle.com>

If Mike endorses this approach then I step aside.

My point, as Scott noted, is that we get this info from the OS. So 
either the OS is at fault or we're asking the wrong question. Based on 
Mike's response we're asking the wrong question - but if the end result 
will be UTF-8 regardless then fine.

David

On 31/07/2013 8:53 AM, Mike Swingler wrote:
> Apple is highly unlikely to change the behavior of nl_langinfo().
>
> There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose.
>
> Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X.
>
> Regards,
> Mike Swingler
> Apple Inc.
>
> On Jul 30, 2013, at 9:05 AM, Francis Devereux  wrote:
>
>> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset.
>>
>> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X.
>>
>> On 30 Jul 2013, at 15:56, Scott Palmer  wrote:
>>
>>> Then shouldn't you be complaining to Apple that the value returned by
>>> nl_langinfo needs to be changed?
>>> David's point seems to be that second guessing the character set reported
>>> by the OS is likely to cause a different set of problems.
>>>
>>> Scott
>>>
>>>
>>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin <
>>> Johannes.Schindelin at gmx.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Tue, 30 Jul 2013, David Holmes wrote:
>>>>
>>>>> On 30/07/2013 5:54 AM, Brent Christian wrote:
>>>>>> On 7/28/13 10:13 PM, David Holmes wrote:
>>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote:
>>>>>>>> Please review my fix for 8011194 : "Apps launched via
>>>> double-clicked
>>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X"
>>>>>>>>
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194
>>>>>>>>
>>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or
>>>>>>>> from a native .app bundle), reading and displaying UTF-8
>>>>>>>> characters beyond the standard ASCII range works fine.
>>>>>>>>
>>>>>>>> A notable exception is the launching of an app by double-clicking
>>>>>>>> a .jar file.  In this case, file.encoding defaults to US-ASCII,
>>>>>>>> and characters outside of the ASCII range show up as garbage.
>>>>>>>
>>>>>>> Why does this occur? What sets the encoding to US-ASCII?
>>>>>>
>>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
>>>>>> values for LANG/LC* are set in the environment when double-clicking a
>>>>>> .jar.
>>>>>>
>>>>>> We get "UTF-8" when launching from the command line because the
>>>>>> default Terminal.app setup on Mac will setup LANG for you (to
>>>>>> "en_US.UTF-8" in the US).
>>>>>
>>>>> Sounds like a user environment error to me. This isn't my area but I'm
>>>>> not convinced we should be second guessing what we think the encoding
>>>>> should be.
>>>>
>>>> Except that that is not the case here, of course. The user did *not* set
>>>> any environment variable in this case.
>>>>
>>>> So we are not talking about "second guessing" or "user environment error"
>>>> but about a sensible default.
>>>>
>>>> As to US-ASCII, sorry to say: the seventies called and want their
>>>> character set back.
>>>>
>>>> There can be no question that UTF-8 is the best default character
>>>> encoding, or are you even going to question *that*?
>>>>
>>>>> What if someone intends for it to be US-ASCII?
>>>>
>>>> Then LANG would not be unset, would it.
>>>>
>>>> Hth,
>>>> Johannes
>>>>
>>>
>>
>


From paul.sandoz at oracle.com  Wed Jul 31 06:54:09 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 31 Jul 2013 06:54:09 +0000
Subject: hg: jdk8/tl/jdk: 8021863: Stream.concat incorrectly calculates
	unsized state
Message-ID: <20130731065435.5AA1748499@hg.openjdk.java.net>

Changeset: 76d88a752a03
Author:    psandoz
Date:      2013-07-30 11:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76d88a752a03

8021863: Stream.concat incorrectly calculates unsized state
Reviewed-by: chegar

! src/share/classes/java/util/stream/Streams.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java



From paul.sandoz at oracle.com  Wed Jul 31 07:10:33 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 31 Jul 2013 08:10:33 +0100
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: 
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
	<97903415-01F4-4FE2-B5F8-AFBF54217D32@oracle.com>
	
Message-ID: 

On Jul 31, 2013, at 12:57 AM, Mike Duigou  wrote:
>> 
>> 
>> -     * @throws NullPointerException if a specified key or value is null,
>> +     * @throws NullPointerException if a specified key or newValue is null,
>>     *         and this map does not permit null keys or values
>> +     * @throws NullPointerException if oldValue is null and this map does not
>> +     *         permit null values
>> +     *         (optional)
>> 
>> 
>> More curious than anything else, is it fine to have two declarations of NPE here?
> 
> 
> Throwing NPE isn't optional if either key or newValue is null and the map does not permit null values.
> 
> This restriction has to be softened for oldValue because the default implementation doesn't test whether oldValue could be added to the map and doesn't know if the map allows null values. 
> 

Since that restriction is softened by @implSpec does it need to be propagated to the exception? the implication is that overriding implementations could do the same?


> The multiple @throws approach is used as an alternative to a complicated legalistic description in a single throws declaration. It's used uncommonly elsewhere in the JDK. 


OK.

Paul.

From paul.sandoz at oracle.com  Wed Jul 31 07:14:52 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 31 Jul 2013 07:14:52 +0000
Subject: hg: jdk8/tl/jdk: 8021883: j.u.Random/RandomStream.java test needs
	more robust timeout duration
Message-ID: <20130731071533.EF3144849A@hg.openjdk.java.net>

Changeset: d30f357c6050
Author:    psandoz
Date:      2013-07-30 14:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d30f357c6050

8021883: j.u.Random/RandomStream.java test needs more robust timeout duration
Reviewed-by: chegar

! test/java/util/Random/RandomStreamTest.java



From peter.levart at gmail.com  Wed Jul 31 07:36:32 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 31 Jul 2013 09:36:32 +0200
Subject: Classes on the stack trace
In-Reply-To: <50B05474-BD3F-47C7-8412-F0F305E0F0FF@nicholaswilliams.net>
References: 
	<51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org>
	<51F7CACD.2070703@gmail.com> <51F7DCD0.1030306@gmx.org>
	<50B05474-BD3F-47C7-8412-F0F305E0F0FF@nicholaswilliams.net>
Message-ID: <51F8BE80.1040005@gmail.com>

Hi Nick,

The @CallerSensitive annotation is an annotation that prevents some 
other infrastructure, namely the MethodHandles, to "spoof" caller classes.

Try this:

         MethodHandles.Lookup lookup = 
MethodHandles.lookup().in(Object.class);
         MethodHandle mh = lookup.findStatic(Class.class, "forName", 
MethodType.methodType(Class.class, String.class));

...you won't be able to pretend that you are the j.l.Object that is 
calling method Class.forName(String)...

The annotation might have (or will have?) other effects like making sure 
some infrastructure-inserted frames are hidden-away just for 
@CallerSensitive methods which might be less optimal and not needed for 
normal methods.


Regards, Peter

On 07/31/2013 01:11 AM, Nick Williams wrote:
> Quick question for those of you that know anything about @CallerSensitive...
>
> After looking at the code and experimenting some, I've discovered that getCallerClass() doesn't actually keep going until it finds the first method without @CallerSensitive. It only returns the caller of the caller. So, for example:
>
> Stack 1
> @CallerSensitive Reflection.getCallerClass()
> @CallerSensitive MyClass1.method1();
> MyClass2.method2();
>
> In this case, getCallerClass() returns MyClass2.class. BUT:
>
> Stack 2
> @CallerSensitive Reflection.getCallerClass()
> @CallerSensitive MyClass1.method1();
> @CallerSensitive MyClass2.method2();
> MyClass3.method3();
>
> In this case, getCallerClass() STILL returns MyClass2.class. Based on the plain-language meaning of @CallerSensitive, I would expect getCallerClass() to return MyClass3.class in the second case. But, indeed, the JavaDoc for Reflection.getCallerClass() says: "Returns the class of the caller of the method calling this method." So, then, what's the point of @CallerSensitive? Looking at the code:
>
>     vframeStream vfst(thread);
>     // Cf. LibraryCallKit::inline_native_Reflection_getCallerClass
>     for (int n = 0; !vfst.at_end(); vfst.security_next(), n++) {
>       Method* m = vfst.method();
>       assert(m != NULL, "sanity");
>       switch (n) {
>       case 0:
>         // This must only be called from Reflection.getCallerClass
>         if (m->intrinsic_id() != vmIntrinsics::_getCallerClass) {
>           THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), "JVM_GetCallerClass must only be called from Reflection.getCallerClass");
>         }
>         // fall-through
>       case 1:
>         // Frame 0 and 1 must be caller sensitive.
>         if (!m->caller_sensitive()) {
>           THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), err_msg("CallerSensitive annotation expected at frame %d", n));
>         }
>         break;
>       default:
>         if (!m->is_ignored_by_security_stack_walk()) {
>           // We have reached the desired frame; return the holder class.
>           return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror());
>         }
>         break;
>       }
>     }
>
> It seems to me that @CallerSensitive is completely pointless. This is ALWAYS going to return the first non-reflection frame after frame 1, regardless of @CallerSensitive. If @CallerSensitive were really supposed to have an actual purpose, it would seem to me that the last part should be this:
>
>         if (!m->is_ignored_by_security_stack_walk() && !m->caller_sensitive()) {
>           // We have reached the desired frame; return the holder class.
>           return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror());
>         }
>
> Am I completely missing the point here? I just don't see a reason for @CallerSensitive. The code could do the exact same thing it currently is without @CallerSensitive (except for enforcing that frame 1 is @CallerSensitive, which really isn't necessary if you aren't using it in further frames).
>
> Thoughts?
>
> Nick
>
> On Jul 30, 2013, at 10:33 AM, Jochen Theodorou wrote:
>
>> Am 30.07.2013 16:16, schrieb Peter Levart:
>>> On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
>>>> Am 30.07.2013 14:17, schrieb Peter Levart:
>>>> [...]
>>>>> So what would give Groovy or other language runtimes headaches when all
>>>>> there was was a parameter-less getCallerClass() API? Aren't the
>>>>> intermediate frames inserted by those runtimes controlled by the
>>>>> runtimes? Couldn't the "surface" runtime-inserted methods capture the
>>>>> caller and pass it down? I guess the problem is supporting calling the
>>>>> caller-sensitive methods like Class.forName(String) and such which don't
>>>>> have the overloaded variant taking caller Class or ClassLoader as an
>>>>> argument...
>>>> Speaking for Groovy...
>>>> those intermediate frames are runtime controlled, yes, but passing down
>>>> the caller class is exactly the problem. Imagine I would suggest that
>>>> each and every method definition in Java automatically gets an
>>>> additional parameter for the caller class, just to have access to it
>>>> inside the method. You would not accept that for Java, would you? And so
>>>> we cannot accept that for Groovy if we want to keep integration with
>>>> Java...
>>> Are you talking about internal Groovy implementation (the
>>> runtime-inserted methods) or the publicly visible API?
>> that's the problem, it is a mix, some internal, other not. We are going to change that in Groovy 3
>>
>>> One solution for
>>> internal implementation of Groovy could be (speaking by heart since I
>>> don't know the internals of Groovy) for the "surface" public API method
>>> which doesn't have to have the special caller parameter, to capture the
>>> caller with getCallerClass() parameterless API (possibly enclosed with a
>>> quick check confirming that it might actually be needed) and bind it to
>>> a ThreadLocal, then use this ThreadLocal down at the end...
>> confirming that it might actually be needed is a problem. In the old fallback path we don't know what we call until after we are deep in runtime code, and there it is too late. In the other paths we could mark those methods in a @CallerSensitive style and do it in that case only.
>>
>>>> and the good integration with Java is one of the key points of
>>>> Groovy. Even if we make something like that @CallerSensitive and add the
>>>> parameter only in those cases, we break being able to override methods.
>>> I guess I don't know every Groovy need to obtain the caller class. I
>>> thought the problem was to support calling caller-sensitive methods in
>>> Java API (like Class.forName(String)) from within Groovy code, where
>>> there are runtime-inserted frames between the "call-site" and the target
>>> method. Are there any other needs?
>> ok, there is a misunderstanding...
>>
>> if we call a Java implemented method from Groovy, which is using getCallerClass() it may or may not work. In general this does not work and our problem is not about that at all. With the change to let getCallerClass() ignore some reflective frames it will work actually better as long as we use our custom callsite caching implementation, it will not work if indy is used or the fallback path.
>>
>> To be able to call a method Class#forName(String), we need to "replace" it with an implementation of our own, which we do with an approach similar to extension methods (only that ours can hide existing implementation methods for groovy). And in there we need to get to the caller class
>>
>> Our problem though is @Grab which is an annotation to add elements to the classpath while running a script.
>>
>>>> Plus, before Groovy3 is not done we have to support several call paths.
>>>> And the oldest one, which is still a fallback, does not support
>>>> transporting the caller class through the runtime layers at all.
>>>> Changing here is a breaking change.
>>> Could you describe those call-paths? Examples of Groovy code and to what
>>> it gets translated (equivalent Java code at call site) with a brief
>>> description of what each intermediate layer (between the call-site and
>>> the target method) does and at which point the caller class is extracted...
>> the code generated at the call site depends on several factors actually... The call site code itself is usually not very informative
>>
>> I start with Groovy 1.0, since that is basically the fallback path. Here this.foo() translates more or less to
>> ScriptBytecodeAdapter.invokeMethod0(staticCallerClass, this,"foo")
>> which basically does this.getMetaClass().invokeMethod(staticCallerClass, this, "foo"). The problem is that the meta class might be user supplied and the code executed in invokeMethod as well. The invocation is then finally done by reflection. That means we have frames from ScriptBytecodeAdapter, from the meta class, as well as maybe frames from a custom meta class and reflection frames. At the level of ScriptBytecodeAdapter there is a means of transporting the caller class, but that is the static one. Once there is a subclass, this information is different from what is needed here and it cannot simply be exchanged. Even if the bytecode adapter is changed, we cannot change the public API for MetaClass#invokeMethod now. And then the information would be lost.
>>
>> In later versions of Groovy (since 1.6) we introduced a custom call site caching technique, which uses runtime generated classes to create a helper class per call site and is then used for invocation. At the callsite we basically have something like callsiteArray[i].invoke(..). Here again the staticCallerClass can be found. In this version we are able to "get" the method we want to invoke, before invoking it (bypassing MetaClass#invokeMethod). But to be able to get the method, certain conditions have to be met (like no user supplied meta class). If they are not met, then we do basically the same path as in 1.0, only that we don't use ScriptBytecodeAdapter. Instead We use our CallSite class as entrance point, which then makes the call to the meta class. In the "efficent" case we have now frames from the callsite handling code between the callsite and the target method only. This includes reflection in the first instantiation, later the generated class is used so it reduces to two frames of which one is the Callsite entrance point, the other a frame form the generated method. In the fallback case we have frames from the callsite handling code, plus meta class code, plus reflection of course. Again the fallback case prevents us from transporting the caller information to the target method. If we ignore the fallback case, then we could here maybe use the Threadlocal information. It will require a new callsite interface for the bytecode though, meaning this code will not work for precompiled grovvy of older version, excluding from getting into Groovy 2.1.x, since it would be a breaking change. The earliest version for that would be Groovy 2.2.0, which is almost in RC now. Effectively it would mean we would have to do a 2.3.0 very soon after most probably.
>>
>> In Groovy 2 we added an indy implementation, which replaces the callsite caching code.  At the callsite we have here basically invokedynamic "foo" with IndyInterface#bootstrap. bootstrap will first introduce a target for IndyInterface#selectMethod, since I need the runtime types instead of the static ones. The static caller class information is here part of the bootstrap method as Lookup object, added by invokedynamic itself. After selectMethod is done we have an initial invocation using invokeExact and later invocations by the handle stored in the callsite. Of course the same conditions as for the callsite caching above have to be met, meaning the fallback path might appear. That makes initially one IndyInterface frame, then invokedynamic and lambda related frames, then optionally the traget method, or in the fallback case the meta class frames plus reflection
>>
>>
>> bye Jochen
>>
>> -- 
>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>> blog: http://blackdragsview.blogspot.com/
>> german groovy discussion newsgroup: de.comp.lang.misc
>> For Groovy programming sources visit http://groovy-lang.org
>>



From vicente.romero at oracle.com  Wed Jul 31 09:53:34 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Wed, 31 Jul 2013 09:53:34 +0000
Subject: hg: jdk8/tl/langtools: 8013179: assertion failure in javac when
	compiling with -source 1.6 -target 1.6
Message-ID: <20130731095340.41BED484A2@hg.openjdk.java.net>

Changeset: 7696282873f6
Author:    vromero
Date:      2013-07-31 10:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7696282873f6

8013179: assertion failure in javac when compiling with -source 1.6 -target 1.6
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/MethodInvokedWithWrongNumberOfArgs.java



From aleksej.efimov at oracle.com  Wed Jul 31 12:15:51 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 31 Jul 2013 16:15:51 +0400
Subject: RFR 8015987: The corba repo contains unneeded .sjava files
Message-ID: <51F8FFF7.7030908@oracle.com>

Hi,

There are unused .sjava files in corba repository which can be deleted.
The webrev: http://cr.openjdk.java.net/~aefimov/8015987/webrev.00/ 

BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015987

After execution of tests from CORBA SQE test suite - no issues were 
discovered. This confirms that we can safely delete them.

-Aleksej


From aleksej.efimov at oracle.com  Wed Jul 31 12:18:05 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 31 Jul 2013 16:18:05 +0400
Subject: RFR 8021820: Number of opened files used in select() is limited to
	1024 [macosx]
Message-ID: <51F9007D.8090801@oracle.com>

Hi,
Can I have a review for the following problem:
The MACOSX JDK (more precisely - the java.net classes) uses the select() 
system call to wait for different events on sockets fds. And the default 
behaviour for select() on Darwin is to fail when fdset contains the fd 
with id greater than FDSET_SIZE(=1024). Test case in webrev illustrates 
this behavior.
There is at least one solution for it: use -D_DARWIN_UNLIMITED_SELECT 
compilation flag for all macosx sources: this won't affect other parts 
of JDK because they are not using select().
Currently, I have added this compilation flag to 
common/autoconf/generated-configure.sh and 
common/autoconf/generated-configure.sh. I wonder, if there is a better 
place where I can put this flag?

The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820


Thanks,
-Aleksej



From chris.hegarty at oracle.com  Wed Jul 31 12:53:59 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Jul 2013 13:53:59 +0100
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <51F82A83.8020903@oracle.com>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com>
	<77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>
	<51F827DD.6060505@oracle.com>
	<2C77DEF7-8588-41D9-8A5B-CBBE73201440@nicholaswilliams.net>
	<51F82A83.8020903@oracle.com>
Message-ID: <51F908E7.20008@oracle.com>

On 30/07/2013 22:05, Jonathan Gibbons wrote:
> Bumped the isue to P2, marked it "Affect 8" and added a link to this
> thread.

Thanks for bringing this back to our attention Jon. I will follow up 
with the Apple folks to see what system call they are using in their 
Java6 implementation. I suspect they are using getsockname to determine 
the local IP address. It may be appropriate for OpenJDK to do the same.

 >Regarding the hostname, jtreg is executing the following code for all
 >tests, not just java.io tests
 >
 >        String hostname;
 >        try {
 >            hostname = >InetAddress.getLocalHost().getCanonicalHostName();
 >        } catch (UnknownHostException e) {
 >            hostname = "unknown";
 >        }

To be more graceful you could return "localhost" or "127.0.0.1".

-Chris.

>
> -- Jon
>
> On 07/30/2013 01:57 PM, Nick Williams wrote:
>> Ahhh. I know what's going on.
>>
>> http://blog.leon-rosenberg.net/2012/08/oracle-kills-getlocalhost-on-macos-x-in.html
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180557
>>
>> Maybe someone can fix this year-old Java 7 bug that makes
>> getLocalHost() not work sometimes on Mac OS X? :-)
>>
>> N
>>
>> On Jul 30, 2013, at 3:53 PM, Jonathan Gibbons wrote:
>>
>>> Regarding the hostname, jtreg is executing the following code for all
>>> tests, not just java.io tests
>>>
>>> String hostname;
>>> try {
>>> hostname = InetAddress.getLocalHost().getCanonicalHostName();
>>> } catch (UnknownHostException e) {
>>> hostname = "unknown";
>>> }
>>>
>>>
>>>
>>> On 07/30/2013 01:50 PM, Nick Williams wrote:
>>>> Gotchya.
>>>>
>>>> I commented out the java.io tests locally for now.
>>>>
>>>> By the way, I noticed something. Before, when the java.io tests were
>>>> failing, the output said "hostname=unknown." However, now that I'm
>>>> connected to the VPN and they're passing, the output says
>>>> "hostname=10.211.55.2." When I unplug from the ethernet altogether,
>>>> the output says "hostname=127.0.0.1."
>>>>
>>>> Sounds like that has something to do with this weird failure of all
>>>> java.io tests.
>>>>
>>>> N
>>>>
>>>> On Jul 30, 2013, at 3:46 PM, Jonathan Gibbons wrote:
>>>>
>>>>> jtreg itself does not "stop on error". If you're driving the tests
>>>>> through the makefiles, the makefiles may partition the work into
>>>>> separate jtreg runs on separate parts of the test suite.
>>>>>
>>>>> -- Jon
>>>>>
>>>>>
>>>>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>>>>> Okay, this is indeed very interesting. After two hours it was only
>>>>>> about half-way through the java.io tests and all of them had
>>>>>> failed so far. On a sheer hunch and nothing more, I unplugged my
>>>>>> ethernet cable, thus disconnecting me from any/all networks and
>>>>>> the Internet. BOOM. The rest of the java.io tests finished (and
>>>>>> passed) in a few seconds, leaving 137 that had failed. I then
>>>>>> re-ran the tests while still disconnected from the Internet and
>>>>>> 312 of the java.io tests passed this time, leaving only 1 failure
>>>>>> (java/io/BufferedReader/Lines.java, output below).
>>>>>>
>>>>>> I plugged my Ethernet back in and ran the tests again and java.io
>>>>>> started failing every test again, timing out after 60 seconds
>>>>>> each. Curiously extending my hunch I remained connected over
>>>>>> Ethernet and connected to a remote network via OpenVPN. Now all of
>>>>>> the java.io test pass again (except that same one, with the same
>>>>>> output).
>>>>>>
>>>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>>>>>
>>>>>> Unfortunately, the one failed java.io test prevents jtreg from
>>>>>> continuing on to the next set of tests (java.lang). Anyone know
>>>>>> how to tell jtreg to continue running on error?
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>> #Test Results (version 2)
>>>>>> #Tue Jul 30 14:53:42 CDT 2013
>>>>>> #-----testdescription-----
>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>>>>>
>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>> keywords=bug8003258
>>>>>> run=USER_SPECIFIED testng Lines\n
>>>>>> source=Lines.java
>>>>>> title=\
>>>>>>
>>>>>> #-----environment-----
>>>>>>
>>>>>> #-----testresult-----
>>>>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>>>>> execStatus=Error. Unexpected exception caught from test
>>>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>>>>> sections=script_messages Details
>>>>>>
>>>>>> #section:script_messages
>>>>>> ----------messages:(0/0)----------
>>>>>>
>>>>>> #section:Details
>>>>>> ----------messages:(0/0)----------
>>>>>> ----------Stack trace:(10/672)----------
>>>>>> java.lang.NullPointerException
>>>>>> at
>>>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>>>>>
>>>>>> at
>>>>>> com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>>>>> at
>>>>>> com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>>>>>
>>>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>>>>> at
>>>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>>>>>
>>>>>> at com.sun.javatest.Script.run(Script.java:228)
>>>>>> at
>>>>>> com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>>>>>
>>>>>> at
>>>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>>>>>
>>>>>> at
>>>>>> com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>>>>> result: Not run. Test running...
>>>>>>
>>>>>>
>>>>>> test result: Error. Unexpected exception caught from test
>>>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>>>>>
>>>>>>
>>>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>>>>>
>>>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>>>>>
>>>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>>>>>
>>>>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>>>>> I'm running the core libs tests locally (for the first time),
>>>>>>>>>> and every java.io test is failing. They're all failing for the
>>>>>>>>>> same reason (output below), and I suspect it's something local
>>>>>>>>>> and not an actual problem. But the test output is not very
>>>>>>>>>> helpful. Note that all of the java.beans tests passed with
>>>>>>>>>> flying colors. Once it got to java.io, everything started
>>>>>>>>>> failing. Worse, each test is taking 60 seconds to fail. I
>>>>>>>>>> could be here a while...
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>> What command are you using? From the output it suggests that
>>>>>>>>> the connection between jtreg and the agent VM cannot be
>>>>>>>>> established.
>>>>>>>>>
>>>>>>>>> -Alan.
>>>>>>>> Command, just like README-builds.html#testing says:
>>>>>>>>
>>>>>>>> cd test && make
>>>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/
>>>>>>>> all
>>>>>>>>
>>>>>>>> I assume this is specifically an java.io-related problem because
>>>>>>>> all the java.beans tests passed without exception and so far
>>>>>>>> every java.io test through java.io.Externalizable (that's as far
>>>>>>>> as it has gotten) has failed without exception. Wouldn't a
>>>>>>>> problem with jtreg communicating with the agent VM have shown up
>>>>>>>> in java.beans as well? I could be wrong of course.
>>>>>>> I see now that java.beans tests run in "othervm mode" while
>>>>>>> java.io tests run in "agentvm mode." Didn't realize they were
>>>>>>> being run differently. Your explanation makes much more sense
>>>>>>> now, but I still don't know what's wrong...
>>>>>>>
>>>>>>>>>> Here's the output from one of the tests. It looks like all the
>>>>>>>>>> other test outputs:
>>>>>>>>>>
>>>>>>>>>> #Test Results (version 2)
>>>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>>>>> #-----testdescription-----
>>>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>>>
>>>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>>>>>
>>>>>>>>>> keywords=bug4143651
>>>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>>>>> source=ReadAfterClose.java
>>>>>>>>>> title=Test if I/O methods will check if the stream has been
>>>>>>>>>> closed.
>>>>>>>>>>
>>>>>>>>>> #-----environment-----
>>>>>>>>>>
>>>>>>>>>> #-----testresult-----
>>>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>>>
>>>>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>>>>> environment=regtest
>>>>>>>>>> execStatus=Error. Cannot get VM for test\:
>>>>>>>>>> java.net.SocketTimeoutException\: Accept timed out
>>>>>>>>>> hostname=unknown
>>>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>>>>> javatestVersion=4.4.1
>>>>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>>>>> sections=script_messages build compile
>>>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>>> user.name=Nicholas
>>>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> #section:script_messages
>>>>>>>>>> ----------messages:(5/308)----------
>>>>>>>>>> JDK under test:
>>>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>>>>>
>>>>>>>>>> openjdk version "1.8.0-internal"
>>>>>>>>>> OpenJDK Runtime Environment (build
>>>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> #section:build
>>>>>>>>>> ----------messages:(3/100)----------
>>>>>>>>>> command: build ReadAfterClose
>>>>>>>>>> reason: Named class compiled on demand
>>>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>>>> result: Error. Cannot get VM for test:
>>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>>>
>>>>>>>>>> #section:compile
>>>>>>>>>> ----------messages:(3/235)----------
>>>>>>>>>> command: compile -XDignore.symbol.file=true
>>>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>>>
>>>>>>>>>> reason: .class file out of date or does not exist
>>>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>>>> result: Error. Cannot get VM for test:
>>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> test result: Error. Cannot get VM for test:
>>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>>>
>>>
>>
>


From alexey.utkin at oracle.com  Wed Jul 31 12:53:30 2013
From: alexey.utkin at oracle.com (Alexey Utkin)
Date: Wed, 31 Jul 2013 16:53:30 +0400
Subject: Review request: JDK-8020191 System.getProperty( " os.name " ) returns
	" Windows NT (unknown) " on Windows 8.1
Message-ID: <51F908CA.1070502@oracle.com>

Bug description:
     https://jbs.oracle.com/bugs/browse/JDK-8020191
     http://bugs.sun.com/view_bug.do?bug_id=8020191

Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.00/

Summary:
We need to be consistent with the rest of OS, so I extend the case for 
6.3 internal version number by values "Windows 8.1" for workstation OS, 
and "Windows Server 2012 R2" for server OS.
(http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx)

But we get a chance to have a wrong OS name due to MS compatibility 
problems.

Here is the problem description:
 
http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200

and MS respond:
     http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx

Quotations:
"In Windows 8.1 Preview, we have introduced a new API, Versionhelpers 
API, that deprecates the need for using GetVersion(Ex) APIs. This 
addresses difficulties in interpreting the numerical value returned by 
the GetVersion(Ex) APIs."

"The internal version number for Windows 8.1 Preview and Windows Server 
2012 R2 Preview is 6.3. Only apps that are targeting Windows 8.1 will 
receive a return value of 6.3. Those apps that are not targeted for 
Windows 8.1 will receive a return value of 6.2 unless previously shimmed 
as discussed below."


Regards,
-uta


From nicholas+openjdk at nicholaswilliams.net  Wed Jul 31 13:18:07 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 31 Jul 2013 08:18:07 -0500
Subject: Classes on the stack trace
In-Reply-To: <51F8BE80.1040005@gmail.com>
References: 
	<51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org>
	<51F7CACD.2070703@gmail.com> <51F7DCD0.1030306@gmx.org>
	<50B05474-BD3F-47C7-8412-F0F305E0F0FF@nicholaswilliams.net>
	<51F8BE80.1040005@gmail.com>
Message-ID: 

Okay, but I don't think @CallerSensitive is necessary to prevent MethodHandles from spoofing caller classes. I'll admit I don't know very much about MethodHandle, what it does, or how its invocation methods are different from Method.invoke(). In the code that I copied into this email from jvm.cpp last night, the third frame (frame #2) will always be returned unless it is one ignored by the security stack walk. @CallerSensitive doesn't come in to play here.

Nick

On Jul 31, 2013, at 2:36 AM, Peter Levart wrote:

> Hi Nick,
> 
> The @CallerSensitive annotation is an annotation that prevents some other infrastructure, namely the MethodHandles, to "spoof" caller classes.
> 
> Try this:
> 
>         MethodHandles.Lookup lookup = MethodHandles.lookup().in(Object.class);
>         MethodHandle mh = lookup.findStatic(Class.class, "forName", MethodType.methodType(Class.class, String.class));
> 
> ...you won't be able to pretend that you are the j.l.Object that is calling method Class.forName(String)...
> 
> The annotation might have (or will have?) other effects like making sure some infrastructure-inserted frames are hidden-away just for @CallerSensitive methods which might be less optimal and not needed for normal methods.
> 
> 
> Regards, Peter
> 
> On 07/31/2013 01:11 AM, Nick Williams wrote:
>> Quick question for those of you that know anything about @CallerSensitive...
>> 
>> After looking at the code and experimenting some, I've discovered that getCallerClass() doesn't actually keep going until it finds the first method without @CallerSensitive. It only returns the caller of the caller. So, for example:
>> 
>> Stack 1
>> @CallerSensitive Reflection.getCallerClass()
>> @CallerSensitive MyClass1.method1();
>> MyClass2.method2();
>> 
>> In this case, getCallerClass() returns MyClass2.class. BUT:
>> 
>> Stack 2
>> @CallerSensitive Reflection.getCallerClass()
>> @CallerSensitive MyClass1.method1();
>> @CallerSensitive MyClass2.method2();
>> MyClass3.method3();
>> 
>> In this case, getCallerClass() STILL returns MyClass2.class. Based on the plain-language meaning of @CallerSensitive, I would expect getCallerClass() to return MyClass3.class in the second case. But, indeed, the JavaDoc for Reflection.getCallerClass() says: "Returns the class of the caller of the method calling this method." So, then, what's the point of @CallerSensitive? Looking at the code:
>> 
>>    vframeStream vfst(thread);
>>    // Cf. LibraryCallKit::inline_native_Reflection_getCallerClass
>>    for (int n = 0; !vfst.at_end(); vfst.security_next(), n++) {
>>      Method* m = vfst.method();
>>      assert(m != NULL, "sanity");
>>      switch (n) {
>>      case 0:
>>        // This must only be called from Reflection.getCallerClass
>>        if (m->intrinsic_id() != vmIntrinsics::_getCallerClass) {
>>          THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), "JVM_GetCallerClass must only be called from Reflection.getCallerClass");
>>        }
>>        // fall-through
>>      case 1:
>>        // Frame 0 and 1 must be caller sensitive.
>>        if (!m->caller_sensitive()) {
>>          THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), err_msg("CallerSensitive annotation expected at frame %d", n));
>>        }
>>        break;
>>      default:
>>        if (!m->is_ignored_by_security_stack_walk()) {
>>          // We have reached the desired frame; return the holder class.
>>          return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror());
>>        }
>>        break;
>>      }
>>    }
>> 
>> It seems to me that @CallerSensitive is completely pointless. This is ALWAYS going to return the first non-reflection frame after frame 1, regardless of @CallerSensitive. If @CallerSensitive were really supposed to have an actual purpose, it would seem to me that the last part should be this:
>> 
>>        if (!m->is_ignored_by_security_stack_walk() && !m->caller_sensitive()) {
>>          // We have reached the desired frame; return the holder class.
>>          return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror());
>>        }
>> 
>> Am I completely missing the point here? I just don't see a reason for @CallerSensitive. The code could do the exact same thing it currently is without @CallerSensitive (except for enforcing that frame 1 is @CallerSensitive, which really isn't necessary if you aren't using it in further frames).
>> 
>> Thoughts?
>> 
>> Nick
>> 
>> On Jul 30, 2013, at 10:33 AM, Jochen Theodorou wrote:
>> 
>>> Am 30.07.2013 16:16, schrieb Peter Levart:
>>>> On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
>>>>> Am 30.07.2013 14:17, schrieb Peter Levart:
>>>>> [...]
>>>>>> So what would give Groovy or other language runtimes headaches when all
>>>>>> there was was a parameter-less getCallerClass() API? Aren't the
>>>>>> intermediate frames inserted by those runtimes controlled by the
>>>>>> runtimes? Couldn't the "surface" runtime-inserted methods capture the
>>>>>> caller and pass it down? I guess the problem is supporting calling the
>>>>>> caller-sensitive methods like Class.forName(String) and such which don't
>>>>>> have the overloaded variant taking caller Class or ClassLoader as an
>>>>>> argument...
>>>>> Speaking for Groovy...
>>>>> those intermediate frames are runtime controlled, yes, but passing down
>>>>> the caller class is exactly the problem. Imagine I would suggest that
>>>>> each and every method definition in Java automatically gets an
>>>>> additional parameter for the caller class, just to have access to it
>>>>> inside the method. You would not accept that for Java, would you? And so
>>>>> we cannot accept that for Groovy if we want to keep integration with
>>>>> Java...
>>>> Are you talking about internal Groovy implementation (the
>>>> runtime-inserted methods) or the publicly visible API?
>>> that's the problem, it is a mix, some internal, other not. We are going to change that in Groovy 3
>>> 
>>>> One solution for
>>>> internal implementation of Groovy could be (speaking by heart since I
>>>> don't know the internals of Groovy) for the "surface" public API method
>>>> which doesn't have to have the special caller parameter, to capture the
>>>> caller with getCallerClass() parameterless API (possibly enclosed with a
>>>> quick check confirming that it might actually be needed) and bind it to
>>>> a ThreadLocal, then use this ThreadLocal down at the end...
>>> confirming that it might actually be needed is a problem. In the old fallback path we don't know what we call until after we are deep in runtime code, and there it is too late. In the other paths we could mark those methods in a @CallerSensitive style and do it in that case only.
>>> 
>>>>> and the good integration with Java is one of the key points of
>>>>> Groovy. Even if we make something like that @CallerSensitive and add the
>>>>> parameter only in those cases, we break being able to override methods.
>>>> I guess I don't know every Groovy need to obtain the caller class. I
>>>> thought the problem was to support calling caller-sensitive methods in
>>>> Java API (like Class.forName(String)) from within Groovy code, where
>>>> there are runtime-inserted frames between the "call-site" and the target
>>>> method. Are there any other needs?
>>> ok, there is a misunderstanding...
>>> 
>>> if we call a Java implemented method from Groovy, which is using getCallerClass() it may or may not work. In general this does not work and our problem is not about that at all. With the change to let getCallerClass() ignore some reflective frames it will work actually better as long as we use our custom callsite caching implementation, it will not work if indy is used or the fallback path.
>>> 
>>> To be able to call a method Class#forName(String), we need to "replace" it with an implementation of our own, which we do with an approach similar to extension methods (only that ours can hide existing implementation methods for groovy). And in there we need to get to the caller class
>>> 
>>> Our problem though is @Grab which is an annotation to add elements to the classpath while running a script.
>>> 
>>>>> Plus, before Groovy3 is not done we have to support several call paths.
>>>>> And the oldest one, which is still a fallback, does not support
>>>>> transporting the caller class through the runtime layers at all.
>>>>> Changing here is a breaking change.
>>>> Could you describe those call-paths? Examples of Groovy code and to what
>>>> it gets translated (equivalent Java code at call site) with a brief
>>>> description of what each intermediate layer (between the call-site and
>>>> the target method) does and at which point the caller class is extracted...
>>> the code generated at the call site depends on several factors actually... The call site code itself is usually not very informative
>>> 
>>> I start with Groovy 1.0, since that is basically the fallback path. Here this.foo() translates more or less to
>>> ScriptBytecodeAdapter.invokeMethod0(staticCallerClass, this,"foo")
>>> which basically does this.getMetaClass().invokeMethod(staticCallerClass, this, "foo"). The problem is that the meta class might be user supplied and the code executed in invokeMethod as well. The invocation is then finally done by reflection. That means we have frames from ScriptBytecodeAdapter, from the meta class, as well as maybe frames from a custom meta class and reflection frames. At the level of ScriptBytecodeAdapter there is a means of transporting the caller class, but that is the static one. Once there is a subclass, this information is different from what is needed here and it cannot simply be exchanged. Even if the bytecode adapter is changed, we cannot change the public API for MetaClass#invokeMethod now. And then the information would be lost.
>>> 
>>> In later versions of Groovy (since 1.6) we introduced a custom call site caching technique, which uses runtime generated classes to create a helper class per call site and is then used for invocation. At the callsite we basically have something like callsiteArray[i].invoke(..). Here again the staticCallerClass can be found. In this version we are able to "get" the method we want to invoke, before invoking it (bypassing MetaClass#invokeMethod). But to be able to get the method, certain conditions have to be met (like no user supplied meta class). If they are not met, then we do basically the same path as in 1.0, only that we don't use ScriptBytecodeAdapter. Instead We use our CallSite class as entrance point, which then makes the call to the meta class. In the "efficent" case we have now frames from the callsite handling code between the callsite and the target method only. This includes reflection in the first instantiation, later the generated class is used so it reduces to two frame
>>> s of which one is the Callsite entrance point, the other a frame form the generated method. In the fallback case we have frames from the callsite handling code, plus meta class code, plus reflection of course. Again the fallback case prevents us from transporting the caller information to the target method. If we ignore the fallback case, then we could here maybe use the Threadlocal information. It will require a new callsite interface for the bytecode though, meaning this code will not work for precompiled grovvy of older version, excluding from getting into Groovy 2.1.x, since it would be a breaking change. The earliest version for that would be Groovy 2.2.0, which is almost in RC now. Effectively it would mean we would have to do a 2.3.0 very soon after most probably.
>>> 
>>> In Groovy 2 we added an indy implementation, which replaces the callsite caching code.  At the callsite we have here basically invokedynamic "foo" with IndyInterface#bootstrap. bootstrap will first introduce a target for IndyInterface#selectMethod, since I need the runtime types instead of the static ones. The static caller class information is here part of the bootstrap method as Lookup object, added by invokedynamic itself. After selectMethod is done we have an initial invocation using invokeExact and later invocations by the handle stored in the callsite. Of course the same conditions as for the callsite caching above have to be met, meaning the fallback path might appear. That makes initially one IndyInterface frame, then invokedynamic and lambda related frames, then optionally the traget method, or in the fallback case the meta class frames plus reflection
>>> 
>>> 
>>> bye Jochen
>>> 
>>> -- 
>>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>>> blog: http://blackdragsview.blogspot.com/
>>> german groovy discussion newsgroup: de.comp.lang.misc
>>> For Groovy programming sources visit http://groovy-lang.org
>>> 
> 



From Alan.Bateman at oracle.com  Wed Jul 31 13:45:47 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Jul 2013 06:45:47 -0700
Subject: RFR 8021820: Number of opened files used in select() is limited
	to 1024 [macosx]
In-Reply-To: <51F9007D.8090801@oracle.com>
References: <51F9007D.8090801@oracle.com>
Message-ID: <51F9150B.4000008@oracle.com>

On 31/07/2013 05:18, Aleksej Efimov wrote:
> Hi,
> Can I have a review for the following problem:
> The MACOSX JDK (more precisely - the java.net classes) uses the 
> select() system call to wait for different events on sockets fds. And 
> the default behaviour for select() on Darwin is to fail when fdset 
> contains the fd with id greater than FDSET_SIZE(=1024). Test case in 
> webrev illustrates this behavior.
> There is at least one solution for it: use -D_DARWIN_UNLIMITED_SELECT 
> compilation flag for all macosx sources: this won't affect other parts 
> of JDK because they are not using select().
> Currently, I have added this compilation flag to 
> common/autoconf/generated-configure.sh and 
> common/autoconf/generated-configure.sh. I wonder, if there is a better 
> place where I can put this flag?
>
> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820

Thanks for looking into this one. The build changes look okay to me but 
it's probably best that someone on build-dev agree to those. Michael 
McMahon can probably explain why the net code is using select for timed 
read/accept (I have a vague recollection of there being an issue with 
poll due to the way that it is implemented on kqueue with the result 
that it had to be changed to use select).

I think the test needs re-work. It looks to me that the it attempts to 
connect to an Oracle internal site so that's not going to work 
everywhere. In general we don't want the tests to be dependent on hosts 
that may or may not exist (we had tests that used to this in the past 
but they caused a lot of grief). It also looks like the test doesn't 
close the 1023 files that it opens at the start and so I assume this 
test will always fail on Windows when jtreg tries to clean-up.

-Alan.


From Alan.Bateman at oracle.com  Wed Jul 31 14:15:03 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Jul 2013 07:15:03 -0700
Subject: Review request: JDK-8020191 System.getProperty( " os.name " )
	returns " Windows NT (unknown) " on Windows 8.1
In-Reply-To: <51F908CA.1070502@oracle.com>
References: <51F908CA.1070502@oracle.com>
Message-ID: <51F91BE7.70403@oracle.com>


The changes in the webrev look okay to me but the reference to the "app 
compatibility shim" in the MS article is a bit confusing and not clear 
to me (with checking into it more) whether this might consider java.exe 
as something that isn't targeted to Windows 8.1. So can you verify that 
you have checked it on the latest 8.1 preview?

As regards the helper library then this could be useful in the future 
(for now then it probably complicates things because the JDK still has 
to run on older versions of Windows).

-Alan.


On 31/07/2013 05:53, Alexey Utkin wrote:
> Bug description:
>     https://jbs.oracle.com/bugs/browse/JDK-8020191
>     http://bugs.sun.com/view_bug.do?bug_id=8020191
>
> Here is the suggested fix:
> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.00/
>
> Summary:
> We need to be consistent with the rest of OS, so I extend the case for 
> 6.3 internal version number by values "Windows 8.1" for workstation 
> OS, and "Windows Server 2012 R2" for server OS.
> (http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx)
>
> But we get a chance to have a wrong OS name due to MS compatibility 
> problems.
>
> Here is the problem description:
>
> http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200 
>
>
> and MS respond:
>     http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx
>
> Quotations:
> "In Windows 8.1 Preview, we have introduced a new API, Versionhelpers 
> API, that deprecates the need for using GetVersion(Ex) APIs. This 
> addresses difficulties in interpreting the numerical value returned by 
> the GetVersion(Ex) APIs."
>
> "The internal version number for Windows 8.1 Preview and Windows 
> Server 2012 R2 Preview is 6.3. Only apps that are targeting Windows 
> 8.1 will receive a return value of 6.3. Those apps that are not 
> targeted for Windows 8.1 will receive a return value of 6.2 unless 
> previously shimmed as discussed below."
>
>
> Regards,
> -uta



From Alan.Bateman at oracle.com  Wed Jul 31 14:18:19 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Jul 2013 07:18:19 -0700
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <51F908E7.20008@oracle.com>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com>
	<77FAF780-7A65-4516-B47E-69FB9EADD426@nicholaswilliams.net>
	<51F827DD.6060505@oracle.com>
	<2C77DEF7-8588-41D9-8A5B-CBBE73201440@nicholaswilliams.net>
	<51F82A83.8020903@oracle.com> <51F908E7.20008@oracle.com>
Message-ID: <51F91CAB.1030609@oracle.com>

On 31/07/2013 05:53, Chris Hegarty wrote:
>
> Thanks for bringing this back to our attention Jon. I will follow up 
> with the Apple folks to see what system call they are using in their 
> Java6 implementation. I suspect they are using getsockname to 
> determine the local IP address. It may be appropriate for OpenJDK to 
> do the same.
You might want to check with Rob McKenna on this. There were one or two 
reports previously that he looked into and I think (need to find the 
mails) that there weren't actually JDK issues but more likely transient 
or configuration issues. There were a couple of issues related to 
problems introduced by the Mac port (like changing other platforms to 
use getaddrinfo) but I thought we were will past all of those at this point.


>
> >Regarding the hostname, jtreg is executing the following code for all
> >tests, not just java.io tests
> >
> >        String hostname;
> >        try {
> >            hostname = 
> >InetAddress.getLocalHost().getCanonicalHostName();
> >        } catch (UnknownHostException e) {
> >            hostname = "unknown";
> >        }
>
> To be more graceful you could return "localhost" or "127.0.0.1".
I agree, there are slew of reasons why it may not be possible to get the 
canonical host name so a fallback to use the loopback would be much better.

-Alan.


From chris.hegarty at oracle.com  Wed Jul 31 14:25:35 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Jul 2013 15:25:35 +0100
Subject: RFR 8021820: Number of opened files used in select() is limited
	to 1024 [macosx]
In-Reply-To: <51F9150B.4000008@oracle.com>
References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com>
Message-ID: <51F91E5F.2080805@oracle.com>

On 31/07/2013 14:45, Alan Bateman wrote:
> On 31/07/2013 05:18, Aleksej Efimov wrote:
>> Hi,
>> Can I have a review for the following problem:
>> The MACOSX JDK (more precisely - the java.net classes) uses the
>> select() system call to wait for different events on sockets fds. And
>> the default behaviour for select() on Darwin is to fail when fdset
>> contains the fd with id greater than FDSET_SIZE(=1024). Test case in
>> webrev illustrates this behavior.
>> There is at least one solution for it: use -D_DARWIN_UNLIMITED_SELECT
>> compilation flag for all macosx sources: this won't affect other parts
>> of JDK because they are not using select().
>> Currently, I have added this compilation flag to
>> common/autoconf/generated-configure.sh and
>> common/autoconf/generated-configure.sh. I wonder, if there is a better
>> place where I can put this flag?
>>
>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820
>
> Thanks for looking into this one. The build changes look okay to me but

Agreed.

> it's probably best that someone on build-dev agree to those. Michael
> McMahon can probably explain why the net code is using select for timed
> read/accept (I have a vague recollection of there being an issue with
> poll due to the way that it is implemented on kqueue with the result
> that it had to be changed to use select).

I don't remember the the specifics either, but that sounds familiar.

-Chris.

> I think the test needs re-work. It looks to me that the it attempts to
> connect to an Oracle internal site so that's not going to work
> everywhere. In general we don't want the tests to be dependent on hosts
> that may or may not exist (we had tests that used to this in the past
> but they caused a lot of grief). It also looks like the test doesn't
> close the 1023 files that it opens at the start and so I assume this
> test will always fail on Windows when jtreg tries to clean-up.
>
> -Alan.


From chris.hegarty at oracle.com  Wed Jul 31 14:44:34 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Jul 2013 15:44:34 +0100
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <51F8262A.3060809@oracle.com>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com>
Message-ID: <51F922D2.4030305@oracle.com>

I believe if you run the tests from the top-level test/Makefile, not 
jdk/test/Makefile, all individual test batches ( invocations of jtreg ) 
get run.

-Chris.

On 30/07/2013 21:46, Jonathan Gibbons wrote:
>
> jtreg itself does not "stop on error". If you're driving the tests
> through the makefiles, the makefiles may partition the work into
> separate jtreg runs on separate parts of the test suite.
>
> -- Jon
>
>
> On 07/30/2013 01:13 PM, Nick Williams wrote:
>> Okay, this is indeed very interesting. After two hours it was only
>> about half-way through the java.io tests and all of them had failed so
>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable,
>> thus disconnecting me from any/all networks and the Internet. BOOM.
>> The rest of the java.io tests finished (and passed) in a few seconds,
>> leaving 137 that had failed. I then re-ran the tests while still
>> disconnected from the Internet and 312 of the java.io tests passed
>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java,
>> output below).
>>
>> I plugged my Ethernet back in and ran the tests again and java.io
>> started failing every test again, timing out after 60 seconds each.
>> Curiously extending my hunch I remained connected over Ethernet and
>> connected to a remote network via OpenVPN. Now all of the java.io test
>> pass again (except that same one, with the same output).
>>
>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>
>> Unfortunately, the one failed java.io test prevents jtreg from
>> continuing on to the next set of tests (java.lang). Anyone know how to
>> tell jtreg to continue running on error?
>>
>> Nick
>>
>> #Test Results (version 2)
>> #Tue Jul 30 14:53:42 CDT 2013
>> #-----testdescription-----
>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>
>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>> keywords=bug8003258
>> run=USER_SPECIFIED testng Lines\n
>> source=Lines.java
>> title=\
>>
>> #-----environment-----
>>
>> #-----testresult-----
>> end=Tue Jul 30 14\:53\:42 CDT 2013
>> execStatus=Error. Unexpected exception caught from test
>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>> sections=script_messages Details
>>
>> #section:script_messages
>> ----------messages:(0/0)----------
>>
>> #section:Details
>> ----------messages:(0/0)----------
>> ----------Stack trace:(10/672)----------
>> java.lang.NullPointerException
>> at
>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>
>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>> at
>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>> at com.sun.javatest.Script.run(Script.java:228)
>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>> at
>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>> result: Not run. Test running...
>>
>>
>> test result: Error. Unexpected exception caught from test
>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>
>>
>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>
>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>
>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>
>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>> I'm running the core libs tests locally (for the first time), and
>>>>>> every java.io test is failing. They're all failing for the same
>>>>>> reason (output below), and I suspect it's something local and not
>>>>>> an actual problem. But the test output is not very helpful. Note
>>>>>> that all of the java.beans tests passed with flying colors. Once
>>>>>> it got to java.io, everything started failing. Worse, each test is
>>>>>> taking 60 seconds to fail. I could be here a while...
>>>>>>
>>>>>> Thoughts?
>>>>> What command are you using? From the output it suggests that the
>>>>> connection between jtreg and the agent VM cannot be established.
>>>>>
>>>>> -Alan.
>>>> Command, just like README-builds.html#testing says:
>>>>
>>>> cd test && make
>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/
>>>> all
>>>>
>>>> I assume this is specifically an java.io-related problem because all
>>>> the java.beans tests passed without exception and so far every
>>>> java.io test through java.io.Externalizable (that's as far as it has
>>>> gotten) has failed without exception. Wouldn't a problem with jtreg
>>>> communicating with the agent VM have shown up in java.beans as well?
>>>> I could be wrong of course.
>>> I see now that java.beans tests run in "othervm mode" while java.io
>>> tests run in "agentvm mode." Didn't realize they were being run
>>> differently. Your explanation makes much more sense now, but I still
>>> don't know what's wrong...
>>>
>>>>>
>>>>>> Here's the output from one of the tests. It looks like all the
>>>>>> other test outputs:
>>>>>>
>>>>>> #Test Results (version 2)
>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>> #-----testdescription-----
>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>
>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>> keywords=bug4143651
>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>> source=ReadAfterClose.java
>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>>
>>>>>> #-----environment-----
>>>>>>
>>>>>> #-----testresult-----
>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>
>>>>>> elapsed=60007 0\:01\:00.007
>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>> environment=regtest
>>>>>> execStatus=Error. Cannot get VM for test\:
>>>>>> java.net.SocketTimeoutException\: Accept timed out
>>>>>> hostname=unknown
>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>> javatestVersion=4.4.1
>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>> sections=script_messages build compile
>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>> user.name=Nicholas
>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>
>>>>>>
>>>>>> #section:script_messages
>>>>>> ----------messages:(5/308)----------
>>>>>> JDK under test:
>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>
>>>>>> openjdk version "1.8.0-internal"
>>>>>> OpenJDK Runtime Environment (build
>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>
>>>>>>
>>>>>> #section:build
>>>>>> ----------messages:(3/100)----------
>>>>>> command: build ReadAfterClose
>>>>>> reason: Named class compiled on demand
>>>>>> elapsed time (seconds): 60.005
>>>>>> result: Error. Cannot get VM for test:
>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>
>>>>>> #section:compile
>>>>>> ----------messages:(3/235)----------
>>>>>> command: compile -XDignore.symbol.file=true
>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>
>>>>>> reason: .class file out of date or does not exist
>>>>>> elapsed time (seconds): 60.005
>>>>>> result: Error. Cannot get VM for test:
>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>
>>>>>>
>>>>>> test result: Error. Cannot get VM for test:
>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>
>


From chris.hegarty at oracle.com  Wed Jul 31 14:46:02 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Jul 2013 15:46:02 +0100
Subject: RFR 8015987: The corba repo contains unneeded .sjava files
In-Reply-To: <51F8FFF7.7030908@oracle.com>
References: <51F8FFF7.7030908@oracle.com>
Message-ID: <51F9232A.2020100@oracle.com>

OK for me.

-Chris.

On 31/07/2013 13:15, Aleksej Efimov wrote:
> Hi,
>
> There are unused .sjava files in corba repository which can be deleted.
> The webrev: http://cr.openjdk.java.net/~aefimov/8015987/webrev.00/
> 
> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015987
>
> After execution of tests from CORBA SQE test suite - no issues were
> discovered. This confirms that we can safely delete them.
>
> -Aleksej


From nicholas+openjdk at nicholaswilliams.net  Wed Jul 31 14:49:02 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 31 Jul 2013 09:49:02 -0500
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <51F922D2.4030305@oracle.com>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com> <51F922D2.4030305@oracle.com>
Message-ID: 

That's how I'm running it.

$ pwd
/foo/bar/jdk8/jdk8
$ cd test
$ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all

If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult to run all of the tests, especial since there are two tests in java.lang (ThreadLocalSupplierTests due to java.lang.VerifyError: Bad local variable type, and DefaultMethodModeling due to java.lang.NullPointerException at java.util.Objects.requireNonNull when checking class B) that fail consistently (on Mac OS X at least) that I haven't been able to solve by identifying issues with the testing environment.

Nick

On Jul 31, 2013, at 9:44 AM, Chris Hegarty wrote:

> I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run.
> 
> -Chris.
> 
> On 30/07/2013 21:46, Jonathan Gibbons wrote:
>> 
>> jtreg itself does not "stop on error". If you're driving the tests
>> through the makefiles, the makefiles may partition the work into
>> separate jtreg runs on separate parts of the test suite.
>> 
>> -- Jon
>> 
>> 
>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>> Okay, this is indeed very interesting. After two hours it was only
>>> about half-way through the java.io tests and all of them had failed so
>>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable,
>>> thus disconnecting me from any/all networks and the Internet. BOOM.
>>> The rest of the java.io tests finished (and passed) in a few seconds,
>>> leaving 137 that had failed. I then re-ran the tests while still
>>> disconnected from the Internet and 312 of the java.io tests passed
>>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java,
>>> output below).
>>> 
>>> I plugged my Ethernet back in and ran the tests again and java.io
>>> started failing every test again, timing out after 60 seconds each.
>>> Curiously extending my hunch I remained connected over Ethernet and
>>> connected to a remote network via OpenVPN. Now all of the java.io test
>>> pass again (except that same one, with the same output).
>>> 
>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>> 
>>> Unfortunately, the one failed java.io test prevents jtreg from
>>> continuing on to the next set of tests (java.lang). Anyone know how to
>>> tell jtreg to continue running on error?
>>> 
>>> Nick
>>> 
>>> #Test Results (version 2)
>>> #Tue Jul 30 14:53:42 CDT 2013
>>> #-----testdescription-----
>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>> 
>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>> keywords=bug8003258
>>> run=USER_SPECIFIED testng Lines\n
>>> source=Lines.java
>>> title=\
>>> 
>>> #-----environment-----
>>> 
>>> #-----testresult-----
>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>> execStatus=Error. Unexpected exception caught from test
>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>> sections=script_messages Details
>>> 
>>> #section:script_messages
>>> ----------messages:(0/0)----------
>>> 
>>> #section:Details
>>> ----------messages:(0/0)----------
>>> ----------Stack trace:(10/672)----------
>>> java.lang.NullPointerException
>>> at
>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>> 
>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>> at
>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>> at com.sun.javatest.Script.run(Script.java:228)
>>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>> at
>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>> result: Not run. Test running...
>>> 
>>> 
>>> test result: Error. Unexpected exception caught from test
>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>> 
>>> 
>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>> 
>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>> 
>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>> 
>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>> I'm running the core libs tests locally (for the first time), and
>>>>>>> every java.io test is failing. They're all failing for the same
>>>>>>> reason (output below), and I suspect it's something local and not
>>>>>>> an actual problem. But the test output is not very helpful. Note
>>>>>>> that all of the java.beans tests passed with flying colors. Once
>>>>>>> it got to java.io, everything started failing. Worse, each test is
>>>>>>> taking 60 seconds to fail. I could be here a while...
>>>>>>> 
>>>>>>> Thoughts?
>>>>>> What command are you using? From the output it suggests that the
>>>>>> connection between jtreg and the agent VM cannot be established.
>>>>>> 
>>>>>> -Alan.
>>>>> Command, just like README-builds.html#testing says:
>>>>> 
>>>>> cd test && make
>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/
>>>>> all
>>>>> 
>>>>> I assume this is specifically an java.io-related problem because all
>>>>> the java.beans tests passed without exception and so far every
>>>>> java.io test through java.io.Externalizable (that's as far as it has
>>>>> gotten) has failed without exception. Wouldn't a problem with jtreg
>>>>> communicating with the agent VM have shown up in java.beans as well?
>>>>> I could be wrong of course.
>>>> I see now that java.beans tests run in "othervm mode" while java.io
>>>> tests run in "agentvm mode." Didn't realize they were being run
>>>> differently. Your explanation makes much more sense now, but I still
>>>> don't know what's wrong...
>>>> 
>>>>>> 
>>>>>>> Here's the output from one of the tests. It looks like all the
>>>>>>> other test outputs:
>>>>>>> 
>>>>>>> #Test Results (version 2)
>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>> #-----testdescription-----
>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> 
>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>> keywords=bug4143651
>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>> source=ReadAfterClose.java
>>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>>> 
>>>>>>> #-----environment-----
>>>>>>> 
>>>>>>> #-----testresult-----
>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> 
>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>> environment=regtest
>>>>>>> execStatus=Error. Cannot get VM for test\:
>>>>>>> java.net.SocketTimeoutException\: Accept timed out
>>>>>>> hostname=unknown
>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>> javatestVersion=4.4.1
>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>> sections=script_messages build compile
>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> user.name=Nicholas
>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>> 
>>>>>>> 
>>>>>>> #section:script_messages
>>>>>>> ----------messages:(5/308)----------
>>>>>>> JDK under test:
>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>> 
>>>>>>> openjdk version "1.8.0-internal"
>>>>>>> OpenJDK Runtime Environment (build
>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>> 
>>>>>>> 
>>>>>>> #section:build
>>>>>>> ----------messages:(3/100)----------
>>>>>>> command: build ReadAfterClose
>>>>>>> reason: Named class compiled on demand
>>>>>>> elapsed time (seconds): 60.005
>>>>>>> result: Error. Cannot get VM for test:
>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>> 
>>>>>>> #section:compile
>>>>>>> ----------messages:(3/235)----------
>>>>>>> command: compile -XDignore.symbol.file=true
>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>> 
>>>>>>> reason: .class file out of date or does not exist
>>>>>>> elapsed time (seconds): 60.005
>>>>>>> result: Error. Cannot get VM for test:
>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>> 
>>>>>>> 
>>>>>>> test result: Error. Cannot get VM for test:
>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>> 
>> 



From jonathan.gibbons at oracle.com  Wed Jul 31 14:56:03 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 31 Jul 2013 07:56:03 -0700
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: 
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com> <51F922D2.4030305@oracle.com>
	
Message-ID: <51F92583.2080706@oracle.com>

Nick,

A *workaround* for this problem would be to locally edit the names of 
the problem tests into jdk/test/ProblemList.txt so that they are not run.

There is general work underway to improve/simplify the Makefile support 
for jtreg, that should address this problem.

-- Jon

On 07/31/2013 07:49 AM, Nick Williams wrote:
> That's how I'm running it.
>
> $ pwd
> /foo/bar/jdk8/jdk8
> $ cd test
> $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>
> If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult to run all of the tests, especial since there are two tests in java.lang (ThreadLocalSupplierTests due to java.lang.VerifyError: Bad local variable type, and DefaultMethodModeling due to java.lang.NullPointerException at java.util.Objects.requireNonNull when checking class B) that fail consistently (on Mac OS X at least) that I haven't been able to solve by identifying issues with the testing environment.
>
> Nick
>
> On Jul 31, 2013, at 9:44 AM, Chris Hegarty wrote:
>
>> I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run.
>>
>> -Chris.
>>
>> On 30/07/2013 21:46, Jonathan Gibbons wrote:
>>> jtreg itself does not "stop on error". If you're driving the tests
>>> through the makefiles, the makefiles may partition the work into
>>> separate jtreg runs on separate parts of the test suite.
>>>
>>> -- Jon
>>>
>>>
>>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>>> Okay, this is indeed very interesting. After two hours it was only
>>>> about half-way through the java.io tests and all of them had failed so
>>>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable,
>>>> thus disconnecting me from any/all networks and the Internet. BOOM.
>>>> The rest of the java.io tests finished (and passed) in a few seconds,
>>>> leaving 137 that had failed. I then re-ran the tests while still
>>>> disconnected from the Internet and 312 of the java.io tests passed
>>>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java,
>>>> output below).
>>>>
>>>> I plugged my Ethernet back in and ran the tests again and java.io
>>>> started failing every test again, timing out after 60 seconds each.
>>>> Curiously extending my hunch I remained connected over Ethernet and
>>>> connected to a remote network via OpenVPN. Now all of the java.io test
>>>> pass again (except that same one, with the same output).
>>>>
>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>>>
>>>> Unfortunately, the one failed java.io test prevents jtreg from
>>>> continuing on to the next set of tests (java.lang). Anyone know how to
>>>> tell jtreg to continue running on error?
>>>>
>>>> Nick
>>>>
>>>> #Test Results (version 2)
>>>> #Tue Jul 30 14:53:42 CDT 2013
>>>> #-----testdescription-----
>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>>>
>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>> keywords=bug8003258
>>>> run=USER_SPECIFIED testng Lines\n
>>>> source=Lines.java
>>>> title=\
>>>>
>>>> #-----environment-----
>>>>
>>>> #-----testresult-----
>>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>>> execStatus=Error. Unexpected exception caught from test
>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>>> sections=script_messages Details
>>>>
>>>> #section:script_messages
>>>> ----------messages:(0/0)----------
>>>>
>>>> #section:Details
>>>> ----------messages:(0/0)----------
>>>> ----------Stack trace:(10/672)----------
>>>> java.lang.NullPointerException
>>>> at
>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>>>
>>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>>> at
>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>>> at com.sun.javatest.Script.run(Script.java:228)
>>>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>>> at
>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>>> result: Not run. Test running...
>>>>
>>>>
>>>> test result: Error. Unexpected exception caught from test
>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>>>
>>>>
>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>>>
>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>>>
>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>>>
>>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>>> I'm running the core libs tests locally (for the first time), and
>>>>>>>> every java.io test is failing. They're all failing for the same
>>>>>>>> reason (output below), and I suspect it's something local and not
>>>>>>>> an actual problem. But the test output is not very helpful. Note
>>>>>>>> that all of the java.beans tests passed with flying colors. Once
>>>>>>>> it got to java.io, everything started failing. Worse, each test is
>>>>>>>> taking 60 seconds to fail. I could be here a while...
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>> What command are you using? From the output it suggests that the
>>>>>>> connection between jtreg and the agent VM cannot be established.
>>>>>>>
>>>>>>> -Alan.
>>>>>> Command, just like README-builds.html#testing says:
>>>>>>
>>>>>> cd test && make
>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/
>>>>>> all
>>>>>>
>>>>>> I assume this is specifically an java.io-related problem because all
>>>>>> the java.beans tests passed without exception and so far every
>>>>>> java.io test through java.io.Externalizable (that's as far as it has
>>>>>> gotten) has failed without exception. Wouldn't a problem with jtreg
>>>>>> communicating with the agent VM have shown up in java.beans as well?
>>>>>> I could be wrong of course.
>>>>> I see now that java.beans tests run in "othervm mode" while java.io
>>>>> tests run in "agentvm mode." Didn't realize they were being run
>>>>> differently. Your explanation makes much more sense now, but I still
>>>>> don't know what's wrong...
>>>>>
>>>>>>>> Here's the output from one of the tests. It looks like all the
>>>>>>>> other test outputs:
>>>>>>>>
>>>>>>>> #Test Results (version 2)
>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>>> #-----testdescription-----
>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>
>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>>> keywords=bug4143651
>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>>> source=ReadAfterClose.java
>>>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>>>>
>>>>>>>> #-----environment-----
>>>>>>>>
>>>>>>>> #-----testresult-----
>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>
>>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>>> environment=regtest
>>>>>>>> execStatus=Error. Cannot get VM for test\:
>>>>>>>> java.net.SocketTimeoutException\: Accept timed out
>>>>>>>> hostname=unknown
>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>>> javatestVersion=4.4.1
>>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>>> sections=script_messages build compile
>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>> user.name=Nicholas
>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>>>
>>>>>>>>
>>>>>>>> #section:script_messages
>>>>>>>> ----------messages:(5/308)----------
>>>>>>>> JDK under test:
>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>>>
>>>>>>>> openjdk version "1.8.0-internal"
>>>>>>>> OpenJDK Runtime Environment (build
>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>>>
>>>>>>>>
>>>>>>>> #section:build
>>>>>>>> ----------messages:(3/100)----------
>>>>>>>> command: build ReadAfterClose
>>>>>>>> reason: Named class compiled on demand
>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>> result: Error. Cannot get VM for test:
>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>
>>>>>>>> #section:compile
>>>>>>>> ----------messages:(3/235)----------
>>>>>>>> command: compile -XDignore.symbol.file=true
>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>
>>>>>>>> reason: .class file out of date or does not exist
>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>> result: Error. Cannot get VM for test:
>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>
>>>>>>>>
>>>>>>>> test result: Error. Cannot get VM for test:
>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>



From nicholas+openjdk at nicholaswilliams.net  Wed Jul 31 14:58:05 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 31 Jul 2013 09:58:05 -0500
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: <51F92583.2080706@oracle.com>
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com> <51F922D2.4030305@oracle.com>
	
	<51F92583.2080706@oracle.com>
Message-ID: <44EB4BAF-7699-4E08-9D93-74C60F19676F@nicholaswilliams.net>

Yea, I've been working around it by running the modules one at a time. It's just a pain, that's all.

N

On Jul 31, 2013, at 9:56 AM, Jonathan Gibbons wrote:

> Nick,
> 
> A *workaround* for this problem would be to locally edit the names of the problem tests into jdk/test/ProblemList.txt so that they are not run.
> 
> There is general work underway to improve/simplify the Makefile support for jtreg, that should address this problem.
> 
> -- Jon
> 
> On 07/31/2013 07:49 AM, Nick Williams wrote:
>> That's how I'm running it.
>> 
>> $ pwd
>> /foo/bar/jdk8/jdk8
>> $ cd test
>> $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>> 
>> If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult to run all of the tests, especial since there are two tests in java.lang (ThreadLocalSupplierTests due to java.lang.VerifyError: Bad local variable type, and DefaultMethodModeling due to java.lang.NullPointerException at java.util.Objects.requireNonNull when checking class B) that fail consistently (on Mac OS X at least) that I haven't been able to solve by identifying issues with the testing environment.
>> 
>> Nick
>> 
>> On Jul 31, 2013, at 9:44 AM, Chris Hegarty wrote:
>> 
>>> I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run.
>>> 
>>> -Chris.
>>> 
>>> On 30/07/2013 21:46, Jonathan Gibbons wrote:
>>>> jtreg itself does not "stop on error". If you're driving the tests
>>>> through the makefiles, the makefiles may partition the work into
>>>> separate jtreg runs on separate parts of the test suite.
>>>> 
>>>> -- Jon
>>>> 
>>>> 
>>>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>>>> Okay, this is indeed very interesting. After two hours it was only
>>>>> about half-way through the java.io tests and all of them had failed so
>>>>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable,
>>>>> thus disconnecting me from any/all networks and the Internet. BOOM.
>>>>> The rest of the java.io tests finished (and passed) in a few seconds,
>>>>> leaving 137 that had failed. I then re-ran the tests while still
>>>>> disconnected from the Internet and 312 of the java.io tests passed
>>>>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java,
>>>>> output below).
>>>>> 
>>>>> I plugged my Ethernet back in and ran the tests again and java.io
>>>>> started failing every test again, timing out after 60 seconds each.
>>>>> Curiously extending my hunch I remained connected over Ethernet and
>>>>> connected to a remote network via OpenVPN. Now all of the java.io test
>>>>> pass again (except that same one, with the same output).
>>>>> 
>>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>>>> 
>>>>> Unfortunately, the one failed java.io test prevents jtreg from
>>>>> continuing on to the next set of tests (java.lang). Anyone know how to
>>>>> tell jtreg to continue running on error?
>>>>> 
>>>>> Nick
>>>>> 
>>>>> #Test Results (version 2)
>>>>> #Tue Jul 30 14:53:42 CDT 2013
>>>>> #-----testdescription-----
>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>>>> 
>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>> keywords=bug8003258
>>>>> run=USER_SPECIFIED testng Lines\n
>>>>> source=Lines.java
>>>>> title=\
>>>>> 
>>>>> #-----environment-----
>>>>> 
>>>>> #-----testresult-----
>>>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>>>> execStatus=Error. Unexpected exception caught from test
>>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>>>> sections=script_messages Details
>>>>> 
>>>>> #section:script_messages
>>>>> ----------messages:(0/0)----------
>>>>> 
>>>>> #section:Details
>>>>> ----------messages:(0/0)----------
>>>>> ----------Stack trace:(10/672)----------
>>>>> java.lang.NullPointerException
>>>>> at
>>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>>>> 
>>>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>>>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>>>> at
>>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>>>> at com.sun.javatest.Script.run(Script.java:228)
>>>>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>>>> at
>>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>>>> result: Not run. Test running...
>>>>> 
>>>>> 
>>>>> test result: Error. Unexpected exception caught from test
>>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>>>> 
>>>>> 
>>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>>>> 
>>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>>>> 
>>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>>>> 
>>>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>>>> I'm running the core libs tests locally (for the first time), and
>>>>>>>>> every java.io test is failing. They're all failing for the same
>>>>>>>>> reason (output below), and I suspect it's something local and not
>>>>>>>>> an actual problem. But the test output is not very helpful. Note
>>>>>>>>> that all of the java.beans tests passed with flying colors. Once
>>>>>>>>> it got to java.io, everything started failing. Worse, each test is
>>>>>>>>> taking 60 seconds to fail. I could be here a while...
>>>>>>>>> 
>>>>>>>>> Thoughts?
>>>>>>>> What command are you using? From the output it suggests that the
>>>>>>>> connection between jtreg and the agent VM cannot be established.
>>>>>>>> 
>>>>>>>> -Alan.
>>>>>>> Command, just like README-builds.html#testing says:
>>>>>>> 
>>>>>>> cd test && make
>>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/
>>>>>>> all
>>>>>>> 
>>>>>>> I assume this is specifically an java.io-related problem because all
>>>>>>> the java.beans tests passed without exception and so far every
>>>>>>> java.io test through java.io.Externalizable (that's as far as it has
>>>>>>> gotten) has failed without exception. Wouldn't a problem with jtreg
>>>>>>> communicating with the agent VM have shown up in java.beans as well?
>>>>>>> I could be wrong of course.
>>>>>> I see now that java.beans tests run in "othervm mode" while java.io
>>>>>> tests run in "agentvm mode." Didn't realize they were being run
>>>>>> differently. Your explanation makes much more sense now, but I still
>>>>>> don't know what's wrong...
>>>>>> 
>>>>>>>>> Here's the output from one of the tests. It looks like all the
>>>>>>>>> other test outputs:
>>>>>>>>> 
>>>>>>>>> #Test Results (version 2)
>>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>>>> #-----testdescription-----
>>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>> 
>>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>>>> keywords=bug4143651
>>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>>>> source=ReadAfterClose.java
>>>>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>>>>> 
>>>>>>>>> #-----environment-----
>>>>>>>>> 
>>>>>>>>> #-----testresult-----
>>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>> 
>>>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>>>> environment=regtest
>>>>>>>>> execStatus=Error. Cannot get VM for test\:
>>>>>>>>> java.net.SocketTimeoutException\: Accept timed out
>>>>>>>>> hostname=unknown
>>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>>>> javatestVersion=4.4.1
>>>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>>>> sections=script_messages build compile
>>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>> user.name=Nicholas
>>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> #section:script_messages
>>>>>>>>> ----------messages:(5/308)----------
>>>>>>>>> JDK under test:
>>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>>>> 
>>>>>>>>> openjdk version "1.8.0-internal"
>>>>>>>>> OpenJDK Runtime Environment (build
>>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> #section:build
>>>>>>>>> ----------messages:(3/100)----------
>>>>>>>>> command: build ReadAfterClose
>>>>>>>>> reason: Named class compiled on demand
>>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>>> result: Error. Cannot get VM for test:
>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>> 
>>>>>>>>> #section:compile
>>>>>>>>> ----------messages:(3/235)----------
>>>>>>>>> command: compile -XDignore.symbol.file=true
>>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>> 
>>>>>>>>> reason: .class file out of date or does not exist
>>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>>> result: Error. Cannot get VM for test:
>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> test result: Error. Cannot get VM for test:
>>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>> 
> 



From Alan.Bateman at oracle.com  Wed Jul 31 15:05:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Jul 2013 08:05:56 -0700
Subject: RFR 8015987: The corba repo contains unneeded .sjava files
In-Reply-To: <51F9232A.2020100@oracle.com>
References: <51F8FFF7.7030908@oracle.com> <51F9232A.2020100@oracle.com>
Message-ID: <51F927D4.6030709@oracle.com>

On 31/07/2013 07:46, Chris Hegarty wrote:
> OK for me.
>
> -Chris.
Looks okay to me too (and I actually thought these had been deleted 
already).

-Alan


From chris.hegarty at oracle.com  Wed Jul 31 15:12:07 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Jul 2013 16:12:07 +0100
Subject: Try to run core libs tests -- All IO tests failing
In-Reply-To: 
References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net>
	<51F80198.4050209@oracle.com>
	
	
	
	<51F8262A.3060809@oracle.com> <51F922D2.4030305@oracle.com>
	
Message-ID: <51F92947.70402@oracle.com>


try:
   make 
PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ 
  *jdk_core*

-Chris.

On 31/07/2013 15:49, Nick Williams wrote:
> That's how I'm running it.
>
> $ pwd
> /foo/bar/jdk8/jdk8
> $ cd test
> $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all
>
> If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult to run all of the tests, especial since there are two tests in java.lang (ThreadLocalSupplierTests due to java.lang.VerifyError: Bad local variable type, and DefaultMethodModeling due to java.lang.NullPointerException at java.util.Objects.requireNonNull when checking class B) that fail consistently (on Mac OS X at least) that I haven't been able to solve by identifying issues with the testing environment.
>
> Nick
>
> On Jul 31, 2013, at 9:44 AM, Chris Hegarty wrote:
>
>> I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run.
>>
>> -Chris.
>>
>> On 30/07/2013 21:46, Jonathan Gibbons wrote:
>>>
>>> jtreg itself does not "stop on error". If you're driving the tests
>>> through the makefiles, the makefiles may partition the work into
>>> separate jtreg runs on separate parts of the test suite.
>>>
>>> -- Jon
>>>
>>>
>>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>>> Okay, this is indeed very interesting. After two hours it was only
>>>> about half-way through the java.io tests and all of them had failed so
>>>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable,
>>>> thus disconnecting me from any/all networks and the Internet. BOOM.
>>>> The rest of the java.io tests finished (and passed) in a few seconds,
>>>> leaving 137 that had failed. I then re-ran the tests while still
>>>> disconnected from the Internet and 312 of the java.io tests passed
>>>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java,
>>>> output below).
>>>>
>>>> I plugged my Ethernet back in and ran the tests again and java.io
>>>> started failing every test again, timing out after 60 seconds each.
>>>> Curiously extending my hunch I remained connected over Ethernet and
>>>> connected to a remote network via OpenVPN. Now all of the java.io test
>>>> pass again (except that same one, with the same output).
>>>>
>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.)
>>>>
>>>> Unfortunately, the one failed java.io test prevents jtreg from
>>>> continuing on to the next set of tests (java.lang). Anyone know how to
>>>> tell jtreg to continue running on error?
>>>>
>>>> Nick
>>>>
>>>> #Test Results (version 2)
>>>> #Tue Jul 30 14:53:42 CDT 2013
>>>> #-----testdescription-----
>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java
>>>>
>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>> keywords=bug8003258
>>>> run=USER_SPECIFIED testng Lines\n
>>>> source=Lines.java
>>>> title=\
>>>>
>>>> #-----environment-----
>>>>
>>>> #-----testresult-----
>>>> end=Tue Jul 30 14\:53\:42 CDT 2013
>>>> execStatus=Error. Unexpected exception caught from test
>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException
>>>> sections=script_messages Details
>>>>
>>>> #section:script_messages
>>>> ----------messages:(0/0)----------
>>>>
>>>> #section:Details
>>>> ----------messages:(0/0)----------
>>>> ----------Stack trace:(10/672)----------
>>>> java.lang.NullPointerException
>>>> at
>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97)
>>>>
>>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80)
>>>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131)
>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260)
>>>> at
>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149)
>>>> at com.sun.javatest.Script.run(Script.java:228)
>>>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>>> at
>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>>>> result: Not run. Test running...
>>>>
>>>>
>>>> test result: Error. Unexpected exception caught from test
>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException
>>>>
>>>>
>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>>>>
>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>>>>>
>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>>>>>
>>>>>>> On 30/07/2013 11:02, Nick Williams wrote:
>>>>>>>> I'm running the core libs tests locally (for the first time), and
>>>>>>>> every java.io test is failing. They're all failing for the same
>>>>>>>> reason (output below), and I suspect it's something local and not
>>>>>>>> an actual problem. But the test output is not very helpful. Note
>>>>>>>> that all of the java.beans tests passed with flying colors. Once
>>>>>>>> it got to java.io, everything started failing. Worse, each test is
>>>>>>>> taking 60 seconds to fail. I could be here a while...
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>> What command are you using? From the output it suggests that the
>>>>>>> connection between jtreg and the agent VM cannot be established.
>>>>>>>
>>>>>>> -Alan.
>>>>>> Command, just like README-builds.html#testing says:
>>>>>>
>>>>>> cd test&&  make
>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/
>>>>>> all
>>>>>>
>>>>>> I assume this is specifically an java.io-related problem because all
>>>>>> the java.beans tests passed without exception and so far every
>>>>>> java.io test through java.io.Externalizable (that's as far as it has
>>>>>> gotten) has failed without exception. Wouldn't a problem with jtreg
>>>>>> communicating with the agent VM have shown up in java.beans as well?
>>>>>> I could be wrong of course.
>>>>> I see now that java.beans tests run in "othervm mode" while java.io
>>>>> tests run in "agentvm mode." Didn't realize they were being run
>>>>> differently. Your explanation makes much more sense now, but I still
>>>>> don't know what's wrong...
>>>>>
>>>>>>>
>>>>>>>> Here's the output from one of the tests. It looks like all the
>>>>>>>> other test outputs:
>>>>>>>>
>>>>>>>> #Test Results (version 2)
>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013
>>>>>>>> #-----testdescription-----
>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>
>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test
>>>>>>>> keywords=bug4143651
>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n
>>>>>>>> source=ReadAfterClose.java
>>>>>>>> title=Test if I/O methods will check if the stream has been closed.
>>>>>>>>
>>>>>>>> #-----environment-----
>>>>>>>>
>>>>>>>> #-----testresult-----
>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>
>>>>>>>> elapsed=60007 0\:01\:00.007
>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013
>>>>>>>> environment=regtest
>>>>>>>> execStatus=Error. Cannot get VM for test\:
>>>>>>>> java.net.SocketTimeoutException\: Accept timed out
>>>>>>>> hostname=unknown
>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64)
>>>>>>>> javatestVersion=4.4.1
>>>>>>>> jtregVersion=jtreg 4.1 dev b00
>>>>>>>> script=com.sun.javatest.regtest.RegressionScript
>>>>>>>> sections=script_messages build compile
>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013
>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>> user.name=Nicholas
>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream
>>>>>>>>
>>>>>>>>
>>>>>>>> #section:script_messages
>>>>>>>> ----------messages:(5/308)----------
>>>>>>>> JDK under test:
>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image)
>>>>>>>>
>>>>>>>> openjdk version "1.8.0-internal"
>>>>>>>> OpenJDK Runtime Environment (build
>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00)
>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode)
>>>>>>>>
>>>>>>>>
>>>>>>>> #section:build
>>>>>>>> ----------messages:(3/100)----------
>>>>>>>> command: build ReadAfterClose
>>>>>>>> reason: Named class compiled on demand
>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>> result: Error. Cannot get VM for test:
>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>
>>>>>>>> #section:compile
>>>>>>>> ----------messages:(3/235)----------
>>>>>>>> command: compile -XDignore.symbol.file=true
>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java
>>>>>>>>
>>>>>>>> reason: .class file out of date or does not exist
>>>>>>>> elapsed time (seconds): 60.005
>>>>>>>> result: Error. Cannot get VM for test:
>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>
>>>>>>>>
>>>>>>>> test result: Error. Cannot get VM for test:
>>>>>>>> java.net.SocketTimeoutException: Accept timed out
>>>>>>>>
>>>
>


From kurchisubhra at gmail.com  Wed Jul 31 15:14:31 2013
From: kurchisubhra at gmail.com (Kurchi Subhra Hazra)
Date: Wed, 31 Jul 2013 08:14:31 -0700
Subject: Review request: JDK-8020191 System.getProperty( " os.name " )
	returns " Windows NT (unknown) " on Windows 8.1
In-Reply-To: <51F91BE7.70403@oracle.com>
References: <51F908CA.1070502@oracle.com>
	<51F91BE7.70403@oracle.com>
Message-ID: 

Changes look good to me (once Alan's point is verified).

Thanks,

- Kurchi


On Wed, Jul 31, 2013 at 7:15 AM, Alan Bateman wrote:

>
> The changes in the webrev look okay to me but the reference to the "app
> compatibility shim" in the MS article is a bit confusing and not clear to
> me (with checking into it more) whether this might consider java.exe as
> something that isn't targeted to Windows 8.1. So can you verify that you
> have checked it on the latest 8.1 preview?
>
> As regards the helper library then this could be useful in the future (for
> now then it probably complicates things because the JDK still has to run on
> older versions of Windows).
>
> -Alan.
>
>
>
> On 31/07/2013 05:53, Alexey Utkin wrote:
>
>> Bug description:
>>     https://jbs.oracle.com/bugs/**browse/JDK-8020191
>>     http://bugs.sun.com/view_bug.**do?bug_id=8020191
>>
>> Here is the suggested fix:
>> http://cr.openjdk.java.net/~**uta/openjdk-webrevs/JDK-**
>> 8020191/webrev.00/
>>
>> Summary:
>> We need to be consistent with the rest of OS, so I extend the case for
>> 6.3 internal version number by values "Windows 8.1" for workstation OS, and
>> "Windows Server 2012 R2" for server OS.
>> (http://msdn.microsoft.com/en-**us/library/windows/desktop/**
>> dn302074.aspx
>> )
>>
>> But we get a chance to have a wrong OS name due to MS compatibility
>> problems.
>>
>> Here is the problem description:
>>
>> http://social.msdn.microsoft.**com/forums/windowsazure/zh-tw/**
>> c471de52-611f-435d-ab44-**56064e5fd7d5/windows-81-**
>> preview-getversionex-reports-**629200
>>
>> and MS respond:
>>     http://msdn.microsoft.com/en-**us/library/windows/desktop/**
>> dn302074.aspx
>>
>> Quotations:
>> "In Windows 8.1 Preview, we have introduced a new API, Versionhelpers
>> API, that deprecates the need for using GetVersion(Ex) APIs. This addresses
>> difficulties in interpreting the numerical value returned by the
>> GetVersion(Ex) APIs."
>>
>> "The internal version number for Windows 8.1 Preview and Windows Server
>> 2012 R2 Preview is 6.3. Only apps that are targeting Windows 8.1 will
>> receive a return value of 6.3. Those apps that are not targeted for Windows
>> 8.1 will receive a return value of 6.2 unless previously shimmed as
>> discussed below."
>>
>>
>> Regards,
>> -uta
>>
>
>


From chris.hegarty at oracle.com  Wed Jul 31 15:12:32 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 31 Jul 2013 15:12:32 +0000
Subject: hg: jdk8/tl/jdk: 8020539: Clean up doclint problems in java.util
	package, part 2
Message-ID: <20130731151331.5A430484B8@hg.openjdk.java.net>

Changeset: 5561b34f6d4c
Author:    bpb
Date:      2013-07-30 10:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5561b34f6d4c

8020539: Clean up doclint problems in java.util package, part 2
Summary: Clean up doclint errors and warnings in classes in java.util
Reviewed-by: darcy, chegar
Contributed-by: Brian Burkhalter 

! src/share/classes/java/util/List.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/java/util/StringJoiner.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/UUID.java
! src/share/classes/java/util/Vector.java



From chris.hegarty at oracle.com  Wed Jul 31 15:20:03 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Jul 2013 16:20:03 +0100
Subject: ProblemList.txt Update ( add ThreadLocalSupplierTest  )
Message-ID: <51F92B23.7000902@oracle.com>

I would to add ThreadLocalSupplierTest to the ProblemList.txt until 
8021230 issue can be resolved.

hg diff test/ProblemList.txt
diff -r 5561b34f6d4c test/ProblemList.txt
--- a/test/ProblemList.txt      Tue Jul 30 10:35:06 2013 -0700
+++ b/test/ProblemList.txt      Wed Jul 31 16:15:25 2013 +0100
@@ -137,6 +137,9 @@ java/lang/reflect/Method/GenericStringTe
  # 8019845 due to memleak not related to the tested fix
  java/lang/instrument/RedefineBigClass.sh                        linux-x64
  java/lang/instrument/RetransformBigClass.sh                     linux-x64
+
+# 8021230
+java/lang/ThreadLocal/ThreadLocalSupplierTest.java              generic-all

 
############################################################################

-Chris.



From sean.coffey at oracle.com  Wed Jul 31 15:17:58 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 31 Jul 2013 16:17:58 +0100
Subject: RFR 8015987: The corba repo contains unneeded .sjava files
In-Reply-To: <51F8FFF7.7030908@oracle.com>
References: <51F8FFF7.7030908@oracle.com>
Message-ID: <51F92AA6.10905@oracle.com>

Looks good from me also. I think these files were leftovers from some 
old development projects. Good to clean up.

regards,
Sean.

On 31/07/13 13:15, Aleksej Efimov wrote:
> Hi,
>
> There are unused .sjava files in corba repository which can be deleted.
> The webrev: http://cr.openjdk.java.net/~aefimov/8015987/webrev.00/ 
> 
> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015987
>
> After execution of tests from CORBA SQE test suite - no issues were 
> discovered. This confirms that we can safely delete them.
>
> -Aleksej



From Alan.Bateman at oracle.com  Wed Jul 31 15:22:38 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Jul 2013 08:22:38 -0700
Subject: ProblemList.txt Update ( add ThreadLocalSupplierTest  )
In-Reply-To: <51F92B23.7000902@oracle.com>
References: <51F92B23.7000902@oracle.com>
Message-ID: <51F92BBE.9010203@oracle.com>

On 31/07/2013 08:20, Chris Hegarty wrote:
> I would to add ThreadLocalSupplierTest to the ProblemList.txt until 
> 8021230 issue can be resolved.
>
> hg diff test/ProblemList.txt
> diff -r 5561b34f6d4c test/ProblemList.txt
> --- a/test/ProblemList.txt      Tue Jul 30 10:35:06 2013 -0700
> +++ b/test/ProblemList.txt      Wed Jul 31 16:15:25 2013 +0100
> @@ -137,6 +137,9 @@ java/lang/reflect/Method/GenericStringTe
>  # 8019845 due to memleak not related to the tested fix
>  java/lang/instrument/RedefineBigClass.sh                        
> linux-x64
>  java/lang/instrument/RetransformBigClass.sh                     
> linux-x64
> +
> +# 8021230
> +java/lang/ThreadLocal/ThreadLocalSupplierTest.java              
> generic-all
>
>
> ############################################################################ 
>
>
> -Chris.
>
Looks fine to me, hopefully the verification issue or whatever this is 
hiding can be tracked down soon.

-Alan


From Johannes.Schindelin at gmx.de  Tue Jul 30 14:14:58 2013
From: Johannes.Schindelin at gmx.de (Johannes Schindelin)
Date: Tue, 30 Jul 2013 16:14:58 +0200 (CEST)
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: <51F72EAD.7040201@oracle.com>
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>
Message-ID: 

Hi,

On Tue, 30 Jul 2013, David Holmes wrote:

> On 30/07/2013 5:54 AM, Brent Christian wrote:
> > On 7/28/13 10:13 PM, David Holmes wrote:
> > > On 27/07/2013 3:53 AM, Brent Christian wrote:
> > > > Please review my fix for 8011194 : "Apps launched via double-clicked
> > > > .jars have file.encoding value of US-ASCII on Mac OS X"
> > > >
> > > > http://bugs.sun.com/view_bug.do?bug_id=8011194
> > > >
> > > > In most cases of launching a Java app on Mac (from the cmdline, or
> > > > from a native .app bundle), reading and displaying UTF-8
> > > > characters beyond the standard ASCII range works fine.
> > > >
> > > > A notable exception is the launching of an app by double-clicking
> > > > a .jar file.  In this case, file.encoding defaults to US-ASCII,
> > > > and characters outside of the ASCII range show up as garbage.
> > >
> > > Why does this occur? What sets the encoding to US-ASCII?
> >
> > "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
> > values for LANG/LC* are set in the environment when double-clicking a
> > .jar.
> >
> > We get "UTF-8" when launching from the command line because the
> > default Terminal.app setup on Mac will setup LANG for you (to
> > "en_US.UTF-8" in the US).
> 
> Sounds like a user environment error to me. This isn't my area but I'm
> not convinced we should be second guessing what we think the encoding
> should be.

Except that that is not the case here, of course. The user did *not* set
any environment variable in this case.

So we are not talking about "second guessing" or "user environment error"
but about a sensible default.

As to US-ASCII, sorry to say: the seventies called and want their
character set back.

There can be no question that UTF-8 is the best default character
encoding, or are you even going to question *that*?

> What if someone intends for it to be US-ASCII?

Then LANG would not be unset, would it.

Hth,
Johannes


From swpalmer at gmail.com  Tue Jul 30 14:56:59 2013
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 30 Jul 2013 10:56:59 -0400
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: 
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>
	
Message-ID: 

Then shouldn't you be complaining to Apple that the value returned by
nl_langinfo needs to be changed?
David's point seems to be that second guessing the character set reported
by the OS is likely to cause a different set of problems.

Scott


On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:

> Hi,
>
> On Tue, 30 Jul 2013, David Holmes wrote:
>
> > On 30/07/2013 5:54 AM, Brent Christian wrote:
> > > On 7/28/13 10:13 PM, David Holmes wrote:
> > > > On 27/07/2013 3:53 AM, Brent Christian wrote:
> > > > > Please review my fix for 8011194 : "Apps launched via
> double-clicked
> > > > > .jars have file.encoding value of US-ASCII on Mac OS X"
> > > > >
> > > > > http://bugs.sun.com/view_bug.do?bug_id=8011194
> > > > >
> > > > > In most cases of launching a Java app on Mac (from the cmdline, or
> > > > > from a native .app bundle), reading and displaying UTF-8
> > > > > characters beyond the standard ASCII range works fine.
> > > > >
> > > > > A notable exception is the launching of an app by double-clicking
> > > > > a .jar file.  In this case, file.encoding defaults to US-ASCII,
> > > > > and characters outside of the ASCII range show up as garbage.
> > > >
> > > > Why does this occur? What sets the encoding to US-ASCII?
> > >
> > > "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
> > > values for LANG/LC* are set in the environment when double-clicking a
> > > .jar.
> > >
> > > We get "UTF-8" when launching from the command line because the
> > > default Terminal.app setup on Mac will setup LANG for you (to
> > > "en_US.UTF-8" in the US).
> >
> > Sounds like a user environment error to me. This isn't my area but I'm
> > not convinced we should be second guessing what we think the encoding
> > should be.
>
> Except that that is not the case here, of course. The user did *not* set
> any environment variable in this case.
>
> So we are not talking about "second guessing" or "user environment error"
> but about a sensible default.
>
> As to US-ASCII, sorry to say: the seventies called and want their
> character set back.
>
> There can be no question that UTF-8 is the best default character
> encoding, or are you even going to question *that*?
>
> > What if someone intends for it to be US-ASCII?
>
> Then LANG would not be unset, would it.
>
> Hth,
> Johannes
>


From francis at devrx.org  Tue Jul 30 16:05:16 2013
From: francis at devrx.org (Francis Devereux)
Date: Tue, 30 Jul 2013 17:05:16 +0100
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: 
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>
	
	
Message-ID: <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org>

I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset.

However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X.

On 30 Jul 2013, at 15:56, Scott Palmer  wrote:

> Then shouldn't you be complaining to Apple that the value returned by
> nl_langinfo needs to be changed?
> David's point seems to be that second guessing the character set reported
> by the OS is likely to cause a different set of problems.
> 
> Scott
> 
> 
> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin <
> Johannes.Schindelin at gmx.de> wrote:
> 
>> Hi,
>> 
>> On Tue, 30 Jul 2013, David Holmes wrote:
>> 
>>> On 30/07/2013 5:54 AM, Brent Christian wrote:
>>>> On 7/28/13 10:13 PM, David Holmes wrote:
>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote:
>>>>>> Please review my fix for 8011194 : "Apps launched via
>> double-clicked
>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X"
>>>>>> 
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194
>>>>>> 
>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or
>>>>>> from a native .app bundle), reading and displaying UTF-8
>>>>>> characters beyond the standard ASCII range works fine.
>>>>>> 
>>>>>> A notable exception is the launching of an app by double-clicking
>>>>>> a .jar file.  In this case, file.encoding defaults to US-ASCII,
>>>>>> and characters outside of the ASCII range show up as garbage.
>>>>> 
>>>>> Why does this occur? What sets the encoding to US-ASCII?
>>>> 
>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
>>>> values for LANG/LC* are set in the environment when double-clicking a
>>>> .jar.
>>>> 
>>>> We get "UTF-8" when launching from the command line because the
>>>> default Terminal.app setup on Mac will setup LANG for you (to
>>>> "en_US.UTF-8" in the US).
>>> 
>>> Sounds like a user environment error to me. This isn't my area but I'm
>>> not convinced we should be second guessing what we think the encoding
>>> should be.
>> 
>> Except that that is not the case here, of course. The user did *not* set
>> any environment variable in this case.
>> 
>> So we are not talking about "second guessing" or "user environment error"
>> but about a sensible default.
>> 
>> As to US-ASCII, sorry to say: the seventies called and want their
>> character set back.
>> 
>> There can be no question that UTF-8 is the best default character
>> encoding, or are you even going to question *that*?
>> 
>>> What if someone intends for it to be US-ASCII?
>> 
>> Then LANG would not be unset, would it.
>> 
>> Hth,
>> Johannes
>> 
> 



From rickard.backman at oracle.com  Wed Jul 31 17:00:24 2013
From: rickard.backman at oracle.com (rickard.backman at oracle.com)
Date: Wed, 31 Jul 2013 17:00:24 +0000
Subject: hg: jdk8/tl/jdk: 8006324: [TEST_BUG]
	sun/invoke/util/ValueConversionsTest.java should be modified
Message-ID: <20130731170109.E1992484BC@hg.openjdk.java.net>

Changeset: 4bd51f6268f4
Author:    rbackman
Date:      2013-07-24 10:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bd51f6268f4

8006324: [TEST_BUG] sun/invoke/util/ValueConversionsTest.java should be modified
Reviewed-by: kvn, twisti

! test/sun/invoke/util/ValueConversionsTest.java



From nicholas+openjdk at nicholaswilliams.net  Wed Jul 31 19:17:54 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 31 Jul 2013 14:17:54 -0500
Subject: Getting ciObject from oop/jobject
Message-ID: <25D4AFB8-82DE-43E0-92E5-754BFC4DBBAD@nicholaswilliams.net>

In native code (library_call.cpp), if I have an oop (which I can convert to a jobject if need be), how do I get a ciObject? I see that ciEnv has a ciObject* get_object(oop) method, but it's private. And ciObjectFactory has a ciObject* get(oop) method, but I can't figure out how to get the ciObjectFactory instance.

I know that ciObject keeps a jobject internally, and I know that ciObject has a ciObject(oop) constructor, but it's protected (for good reason).

If it helps, I'm trying to inline a method and need to set_result(makecon(TypeInstPtr::make(oopInstance))). I may be going down the wrong path.

Thanks in advance for any help,

Nick

From mark.reinhold at oracle.com  Wed Jul 31 20:42:11 2013
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 31 Jul 2013 13:42:11 -0700
Subject: problems with sun.reflect.Reflection.getCallerClass(int)
In-Reply-To: <51DE6B0A.1010207@gmx.org>
References: <51DE6B0A.1010207@gmx.org>
Message-ID: <20130731134211.948357@eggemoggin.niobe.net>

FYI, we're going to revert this method to its previous behavior in
JDK 7u40: http://bugs.sun.com/view_bug.do?bug_id=8021946 .

What will happen to this method in JDK 8 requires further thought.

- Mark


From brent.christian at oracle.com  Wed Jul 31 20:43:46 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 31 Jul 2013 13:43:46 -0700
Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have
	file.encoding value of US-ASCII on Mac OS X
In-Reply-To: 
References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com>
	<51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>
	
	
	<8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org>
	<4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com>
	
Message-ID: <51F97702.5090203@oracle.com>

On 7/30/13 4:06 PM, David DeHaven wrote:
>
> Judging from the docs, nl_langinfo seems like a Unix portability
> function (something more likely to be happier with ASCII in a
> terminal), not something to be used by a native Cocoa application.

Exactly - so I think it expects to be called from a cmdline with a 
shell-style surrounding environment, with LANG/etc variables set.

David suggests that calling nl_langinfo() is "asking the wrong 
question."  In the particular context of double-click launching on Mac, 
you could say that's true (or at least asking the question in the wrong 
way).

But consider - the code in question is shared with other Unix platforms, 
and when running from the cmdline/shell scripts/etc, nl_langinfo() *is* 
the right way to ask the question.

To ask the right question for this specific context on MacOS X (NSLocale 
or CFLocale) I suspect would involve a fair amount of code surgery, and 
the end result would be the same.  Given this, I think my proposed 
change is a good one from a practical standpoint.

Thank you, everyone, for your feedback.

-Brent

>> Apple is highly unlikely to change the behavior of nl_langinfo().
>>
>> There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose.
>>
>> Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X.
>>
>> Regards,
>> Mike Swingler
>> Apple Inc.
>>
>> On Jul 30, 2013, at 9:05 AM, Francis Devereux  wrote:
>>
>>> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset.
>>>
>>> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X.
>>>
>>> On 30 Jul 2013, at 15:56, Scott Palmer  wrote:
>>>
>>>> Then shouldn't you be complaining to Apple that the value returned by
>>>> nl_langinfo needs to be changed?
>>>> David's point seems to be that second guessing the character set reported
>>>> by the OS is likely to cause a different set of problems.
>>>>
>>>> Scott
>>>>
>>>>
>>>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin <
>>>> Johannes.Schindelin at gmx.de> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, 30 Jul 2013, David Holmes wrote:
>>>>>
>>>>>> On 30/07/2013 5:54 AM, Brent Christian wrote:
>>>>>>> On 7/28/13 10:13 PM, David Holmes wrote:
>>>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote:
>>>>>>>>> Please review my fix for 8011194 : "Apps launched via
>>>>> double-clicked
>>>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X"
>>>>>>>>>
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194
>>>>>>>>>
>>>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or
>>>>>>>>> from a native .app bundle), reading and displaying UTF-8
>>>>>>>>> characters beyond the standard ASCII range works fine.
>>>>>>>>>
>>>>>>>>> A notable exception is the launching of an app by double-clicking
>>>>>>>>> a .jar file.  In this case, file.encoding defaults to US-ASCII,
>>>>>>>>> and characters outside of the ASCII range show up as garbage.
>>>>>>>>
>>>>>>>> Why does this occur? What sets the encoding to US-ASCII?
>>>>>>>
>>>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no
>>>>>>> values for LANG/LC* are set in the environment when double-clicking a
>>>>>>> .jar.
>>>>>>>
>>>>>>> We get "UTF-8" when launching from the command line because the
>>>>>>> default Terminal.app setup on Mac will setup LANG for you (to
>>>>>>> "en_US.UTF-8" in the US).
>>>>>>
>>>>>> Sounds like a user environment error to me. This isn't my area but I'm
>>>>>> not convinced we should be second guessing what we think the encoding
>>>>>> should be.
>>>>>
>>>>> Except that that is not the case here, of course. The user did *not* set
>>>>> any environment variable in this case.
>>>>>
>>>>> So we are not talking about "second guessing" or "user environment error"
>>>>> but about a sensible default.
>>>>>
>>>>> As to US-ASCII, sorry to say: the seventies called and want their
>>>>> character set back.
>>>>>
>>>>> There can be no question that UTF-8 is the best default character
>>>>> encoding, or are you even going to question *that*?
>>>>>
>>>>>> What if someone intends for it to be US-ASCII?
>>>>>
>>>>> Then LANG would not be unset, would it.
>>>>>
>>>>> Hth,
>>>>> Johannes
>>>>>
>>>>
>>>
>>
>


From nicholas+openjdk at nicholaswilliams.net  Wed Jul 31 20:50:53 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 31 Jul 2013 15:50:53 -0500
Subject: problems with sun.reflect.Reflection.getCallerClass(int)
In-Reply-To: <20130731134211.948357@eggemoggin.niobe.net>
References: <51DE6B0A.1010207@gmx.org>
	<20130731134211.948357@eggemoggin.niobe.net>
Message-ID: 

That is, indeed, great news!

I have almost completed a patch that I will propose later this week to make this a public API.

Nick

On Jul 31, 2013, at 3:42 PM, mark.reinhold at oracle.com wrote:

> FYI, we're going to revert this method to its previous behavior in
> JDK 7u40: http://bugs.sun.com/view_bug.do?bug_id=8021946 .
> 
> What will happen to this method in JDK 8 requires further thought.
> 
> - Mark



From stuart.marks at oracle.com  Wed Jul 31 21:38:26 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 31 Jul 2013 14:38:26 -0700
Subject: Remaining doclint issues in java.net
In-Reply-To: <51F67C14.5040804@oracle.com>
References: <51F67C14.5040804@oracle.com>
Message-ID: <51F983D2.3050501@oracle.com>

On 7/29/13 7:28 AM, Chris Hegarty wrote:
>
> There are two remaining doclint warnings in the java.net package.
>
>  >:javac -Xdoclint:all/protected src/share/classes/java/net/DatagramPacket.java
> src/share/classes/java/net/DatagramPacket.java:142: warning: no @throws for
> java.net.SocketException
>      public DatagramPacket(byte buf[], int offset, int length,
>             ^
> src/share/classes/java/net/DatagramPacket.java:178: warning: no @throws for
> java.net.SocketException
>      public DatagramPacket(byte buf[], int length,
>             ^
>
> These are caused by no @throws SE declaration on the constructors.
>
> As it happens 'throws SE' was incorrectly added to these constructors when
> introduced in 1.4. The original API specified that SE was thrown when the given
> SocketAddress was not supported. That was later changed to throw IAE, in 1.4.2.
> These constructor now can never throw SE.
>
> Removing 'throws SE' from the method declaration is a binary compatible change,
> but not source compatible ( XXX  is never thrown in body of corresponding try
> statement ). I don't think breaking source compatibility for this kind of
> change is justified. If it is, then the solution is to simply remove 'throws SE'.
>
> Back in the real world, I guess we need to come up with some wording for the
> '@throws SE' declaration. Something vague like "If an I/O Exception occurs", or
> can we put something stronger like "will never be thrown" ??

I'd like to make a case for removing 'throws SE' even though it's a source 
incompatible change.

It's not that source incompatibilities are strictly prohibited. They are 
allowed, and it depends on how often they occur and how difficult they are to 
fix. I seem to recall there was a similar issue when "more precise rethrow" was 
added in Java 7; this was indeed a source incompatibility but a survey was done 
and it was quite rare.

How often are these DatagramPacket constructors used? I'd have to say, probably 
more often than the fairly obscure cases that the "more precise rethrow" 
feature caused issues with.

On the other hand, fixing up code that constructs a DatagramPacket ought to be 
pretty simple: removing the catch of SocketException. This is already known to 
be dead code, so it can simply be removed.

The alternative is to add "@throws SocketException never" to the javadoc, just 
to get rid of the doclint warning, but this has the consequence of requiring 
people to keep dead code around indefinitely, and furthermore it requires them 
to add new dead code every time they create a DatagramPacket.

I'm not claiming that removing 'throws SE' is obviously the right answer, but 
I'd like to see it considered seriously.

s'marks


From kumar.x.srinivasan at oracle.com  Wed Jul 31 21:47:18 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Wed, 31 Jul 2013 21:47:18 +0000
Subject: hg: jdk8/tl/langtools: 8014826:
	c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate
	dimension markers
Message-ID: <20130731214726.BCE15484D0@hg.openjdk.java.net>

Changeset: 05370ef9dccb
Author:    ksrini
Date:      2013-07-31 08:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05370ef9dccb

8014826: c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate dimension markers
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/tree/Pretty.java
+ test/tools/javac/tree/NewArrayPretty.java



From mhall at mhcomputing.net  Wed Jul 31 21:39:57 2013
From: mhall at mhcomputing.net (Matthew Hall)
Date: Wed, 31 Jul 2013 14:39:57 -0700
Subject: Remaining doclint issues in java.net
In-Reply-To: <51F983D2.3050501@oracle.com>
References: <51F67C14.5040804@oracle.com>
 <51F983D2.3050501@oracle.com>
Message-ID: <20130731213957.GA24485@mhcomputing.net>

On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote:
> The alternative is to add "@throws SocketException never" to the
> javadoc, just to get rid of the doclint warning, but this has the
> consequence of requiring people to keep dead code around
> indefinitely, and furthermore it requires them to add new dead code
> every time they create a DatagramPacket.

I have never understood in many years using Java why the compiler generates 
errors about attempting to catch supposedly-impossible exceptions, instead of 
warnings.

For me it only leads to difficulties when I'm trying to write prototypes or 
refactor and clean up some old brittle code, and I run into that rather 
dubious sort of error.

This is a good example of where it causes more harm than good. Is there still 
a really good reason for this over-paranoid compiler error given that checked 
exceptions aren't as popular as they used to be anyways?

Matthew.

Packaging of Locale Sensitive Service Provider Implementations

Packaging of Locale Sensitive Service Provider Implementations

Packaging of Locale Sensitive Service Provider Implementations

Packaging of Locale Sensitive Service Provider Implementations

Summary of regular-expression constructs

Backslashes, escapes, and quoting

Backslashes, escapes, and quoting

Character Classes

Line terminators

Groups and capturing

Group number

Group number

Group name

Group name

Unicode support

Unicode support

Comparison to Perl 5

Comparison to Perl 5

Summary of regular-expression constructs

Backslashes, escapes, and quoting

Backslashes, escapes, and quoting

Character Classes

Line terminators

Groups and capturing

Group number

Group number

Group name

Group name

Unicode support

Unicode support

Comparison to Perl 5

Comparison to Perl 5

...

Charset names

Standard charsets

Symbolic Links

Interoperability

Visibility

Synchronized I/O File Integrity

General Exceptions

Charset names

Standard charsets

Symbolic Links

Interoperability

Visibility

Synchronized I/O File Integrity

General Exceptions

and