date:20131113


On 13/11/2013 14:55, harold seigel wrote:

Hi,

Please review this fix, submitted by Ekaterina Pavlova, to update the 
CDS classlist files for JDK 8.


The classlist files were generated using the process described in 
jdk/make/tools/sharing/README.txt.  In addition, a checksum was included.


The open webrev is at: 
http://cr.openjdk.java.net/~hseigel/bug_8023041/ 
http://cr.openjdk.java.net/%7Ehseigel/bug_8023041/


The bug is at: https://bugs.openjdk.java.net/browse/JDK-8023041

Additional information about this change, including testing 
information, is in the bug.
Good to see these sync'ed up. I assume this will remove a lot of 
warnings from the build too.


Assuming that the process to generate these was indeed followed then I'd 
suggest going ahead and just push it (as there isn't much we can 
actually review except to spot classes removed from the list that no 
longer exist).


-Alan.

Re: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess

2013-11-13 Thread Daniel Fuchs


Hi Mandy,

looks good!

-- daniel

On 11/12/13 8:29 PM, Mandy Chung wrote:

This is a simple code deletion in sun.misc.JavaAWTAccess and its
implementation class:

Webrev:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/

This patch removes the methods from sun.misc.JavaAWTAccess that are no
longer used.  The only dependency remaining from core-libs to AppContext
is the ability to obtain an opaque unique object to represent an applet
context ifit is running in an applet environment.

thanks
Mandy

hg: jdk8/tl/jdk: 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary

2013-11-13 Thread staffan . larsen

Changeset: a42a416351b8
Author:ykantser
Date:  2013-11-13 11:46 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a42a416351b8

8015497: Take new fixes from hotspot/test/testlibrary to 
jdk/test/lib/testlibrary
Reviewed-by: sla

+ test/lib/testlibrary/AssertsTest.java
+ test/lib/testlibrary/OutputAnalyzerReportingTest.java
+ test/lib/testlibrary/jdk/testlibrary/InputArguments.java
! test/lib/testlibrary/jdk/testlibrary/JcmdBase.java
- test/lib/testlibrary/jdk/testlibrary/JdkFinder.java
! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java
! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java

hg: jdk8/tl/jdk: 8028234: Remove unused methods in sun.misc.JavaAWTAccess

2013-11-13 Thread mandy . chung

Changeset: 7c55fecfae65
Author:mchung
Date:  2013-11-13 07:49 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c55fecfae65

8028234: Remove unused methods in sun.misc.JavaAWTAccess
Reviewed-by: art, dfuchs, lancea

! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/misc/JavaAWTAccess.java
! test/java/util/logging/TestAppletLoggerContext.java

Re: RFR 8025003: Base64 should be less strict with padding


On 11/12/13 11:44 PM, Bill Shannon wrote:

Xueming Shen wrote on 11/12/2013 09:24 PM:

On 11/12/13 8:21 PM, Bill Shannon wrote:

Xueming Shen wrote on 11/12/2013 04:25 PM:

On 11/12/2013 03:32 PM, Bill Shannon wrote:

This still seems like an inconsistent, and inconvenient, approach to me.

You've decided that some encoding errors (i.e., missing pad characters)
can be ignored.  You're willing to assume that the missing characters aren't
missing data but just missing padding.  But if you find a padding character
where you don't expect it you won't assume that the missing data is zero.

missing pad characters in theory is not an encoding errors. As the RFC
suggested, the
use of padding in base64 data is not required or used. They mainly serve the
purpose of
providing the indication of end of the data. This is why the padding
character(s) is not
required (optional) by our decoder at first place. However, if the padding
character(s) is
present, they need to be correctly encoded, otherwise, it's a malformed base64
stream.

I think we're interpreting the spec differently.

I meant to say The RFC says the use of padding in base64 data is not required
nor used, in some circumstances.
I interpret it as the padding is optional in some circumstances.

It's never optional.  There's two specific cases in which it's required
and one specific case in which it is not present.


My apology, It appears we are not talking about the same thing. What I'm 
trying to say is
that whether or not to USE the padding characters =  is optional for 
base encoding FOR
SOME CIRCUMSTANCES.  Maybe it's more clear to just cite the original 
wording here


   In some circumstances, the use of padding (=) in base encoded data
   is not required nor used.  In the general case, when assumptions on
   size of transported data cannot be made, padding is required to yield
   correct decoded data.

   Implementations MUST include appropriate pad characters at the end of
   encoded data unless the specification referring to this document
   explicitly states otherwise.

My interpretation is that it is possible for some types/styles of Base64 
implementation
it is optional to not generate the padding character at the end of the 
encoding operation.
Though the RFC requires if it does omitting the padding character, it 
need to explicitly

specify this in its spec.

When encoding the existing implementation, by default, always add the 
padding characters
at the end of the encoded stream, if needed (for xx==, xxx=). Decoder is 
try to be liberal/
lenient in what your accept (with the assumption is that the encoded may 
come from some
encoder that not generate the padding characters), so it accept data 
with padding and
dta without padding. However, it requires that if padding characters are 
used, it need
to be CORRECTLY encoded. That was the original specification and 
implementation.
Upon your original request, I made the compromise to give MIME type a 
more liberal
spec/implementation for incorrect padding character combination as 
showed below


Patterns of possible incorrectly encoded padding final base64 unit are:

 =   unnecessary padding character at the end of encoded stream
 xx= missing the last padding character
 xx=ymissing the last padding character, instead having a 
non-padding char

Now it appears this compromise became part of your complain.

Our difference is that I believe the padding character is not part of 
the original
data, we can be liberal/lenient for that. But x=== (or simply a 
dangling x)

is missing part of the original data for decoding, I'm concerned about to be
liberal on guessing what is missed.

-Sherman

Re: RFR 8025003: Base64 should be less strict with padding


On 13/11/2013 04:21, Bill Shannon wrote:

:
There's really no error recovery possible, and certainly no program is
going to attempt error recovery.  As I said, there's only two reasonable
things to do:  1) throw up your hands, claim the data is corrupt, and tell
the user there's nothing you can do, or 2) do your best job to give the user
as much data as possible, and let the user decide if the data is in fact 
corrupt.
I'd be happy for you to provide options to do both.  Doing something that's
half way between the two just isn't useful.

A variation of the second might be for the decoder to stop when it 
encounters an error (illegal character, missing pad characters, 
insufficient bits in the last unit). That is, give the user the bytes 
that have been successfully decoded plus an indication that the 
remaining bytes have not been processed due to an error. This wouldn't 
be too hard to add with changes or variations of the decode methods that 
decode buffers (as the source buffer can report if it has 
remaining/unprocessed bytes). It's just a bit more work for users of the 
API that want to be able to handle corrupt or truncated input. From a 
quick look then it actually isn't too far from where Sherman was going, 
at least it wouldn't be if missing pad characters were treated as an 
error (as they were previously).


The other thought is the charset API where a charset decoder can be 
configured to ignore, replace or report then malformed or unmappable 
input. Having support for all these actions is important for charset 
encoding/decoding but seems way too much for Base64 where I think the 
API should be simple for the majority of usages.


In any case, it's not clear what we can do this late in the schedule. It 
might be prudent to just fix the MIME decoder to throw IAE consistently 
and re-visit the API support for a lenient decoder in JDK 9.


-Alan.

hg: jdk8/tl/jdk: 8022213: Intermittent test failures in java/net/URLClassLoader

2013-11-13 Thread chris . hegarty

Changeset: 70f1bed5e7fd
Author:chegar
Date:  2013-11-13 16:44 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70f1bed5e7fd

8022213: Intermittent test failures in java/net/URLClassLoader
Reviewed-by: dxu, alanb

! test/java/net/URLClassLoader/closetest/CloseTest.java
! test/java/net/URLClassLoader/closetest/Common.java
! test/java/net/URLClassLoader/closetest/GetResourceAsStream.java
+ test/lib/testlibrary/jdk/testlibrary/FileUtils.java

hg: jdk8/tl/jdk: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission

2013-11-13 Thread alan . bateman

Changeset: a493871959c2
Author:alanb
Date:  2013-11-13 16:52 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a493871959c2

8028270: Files.readSymbolicLink calls AccessController directly so security 
manager can't grant the permission
Reviewed-by: mchung, martin, chegar

! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! test/java/nio/file/Files/CheckPermissions.java

hg: jdk8/tl/jdk: 6954510: TEST_BUG: Testcase failure com/sun/jdi/BreakpointWithFullGC.sh

2013-11-13 Thread erik . gahlin

Changeset: 256b3395346b
Author:egahlin
Date:  2013-11-13 18:41 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/256b3395346b

6954510: TEST_BUG: Testcase failure com/sun/jdi/BreakpointWithFullGC.sh
Reviewed-by: sla, sspitsyn

! test/com/sun/jdi/BreakpointWithFullGC.sh

Re: RFR raw types lint warnings fixes for java.util.concurrent

2013-11-13 Thread Joe Darcy


On 11/13/2013 1:42 AM, Chris Hegarty wrote:

The changes look fine to me.

Since Martin has already brought the changes into the JSR166 CVS, Joe 
you can go ahead and push these changes to jdk8.


Will do; I'll shortly push the fix under JDK-8028300 Fix raw type lint 
warnings in java.util.concurrent.


Thanks,

-Joe



Thanks,
-Chris.

On 11/12/2013 10:52 PM, Joe Darcy wrote:

Hello concurrency maestros,

I submit for your consideration a simple patch to silence the three
remaining javac lint warnings in the java.util.concurrent package:

diff -r 69432cb5bca2
src/share/classes/java/util/concurrent/ForkJoinPool.java
--- a/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov
12 09:44:39 2013 -0800
+++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov
12 14:40:40 2013 -0800
@@ -1820,7 +1820,7 @@
  }
  }
  for (;;) { // help stealer or descend to its 
stealer

-ForkJoinTask[] a; int b;
+ForkJoinTask?[] a; int b;
  if (subtask.status  0) // surround probes
with
  continue restart;   // consistency 
checks

  if ((b = v.base) - v.top  0  (a = v.array)
!= null) {
diff -r 69432cb5bca2
src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
---
a/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java 
Tue

Nov 12 09:44:39 2013 -0800
+++
b/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java 
Tue

Nov 12 14:40:40 2013 -0800
@@ -1253,11 +1253,11 @@
   * Snapshot iterator that works off copy of underlying q 
array.

   */
  private class Itr implements IteratorRunnable {
-final RunnableScheduledFuture[] array;
+final RunnableScheduledFuture?[] array;
  int cursor = 0; // index of next element to return
  int lastRet = -1;   // index of last element, or -1 if no
such

-Itr(RunnableScheduledFuture[] array) {
+Itr(RunnableScheduledFuture?[] array) {
  this.array = array;
  }

I am content to relinquish ownership in seeing this patch through the
166 - JDK 8 integration process :-)

Thanks,

-Joe

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/13/13 08:28:
 On 11/12/13 11:44 PM, Bill Shannon wrote:
 Xueming Shen wrote on 11/12/2013 09:24 PM:
 On 11/12/13 8:21 PM, Bill Shannon wrote:
 Xueming Shen wrote on 11/12/2013 04:25 PM:
 On 11/12/2013 03:32 PM, Bill Shannon wrote:
 This still seems like an inconsistent, and inconvenient, approach to me.

 You've decided that some encoding errors (i.e., missing pad characters)
 can be ignored.  You're willing to assume that the missing characters 
 aren't
 missing data but just missing padding.  But if you find a padding 
 character
 where you don't expect it you won't assume that the missing data is zero.
 missing pad characters in theory is not an encoding errors. As the RFC
 suggested, the
 use of padding in base64 data is not required or used. They mainly serve 
 the
 purpose of
 providing the indication of end of the data. This is why the padding
 character(s) is not
 required (optional) by our decoder at first place. However, if the padding
 character(s) is
 present, they need to be correctly encoded, otherwise, it's a malformed 
 base64
 stream.
 I think we're interpreting the spec differently.
 I meant to say The RFC says the use of padding in base64 data is not 
 required
 nor used, in some circumstances.
 I interpret it as the padding is optional in some circumstances.
 It's never optional.  There's two specific cases in which it's required
 and one specific case in which it is not present.

 My apology, It appears we are not talking about the same thing. What I'm
 trying to say is
 that whether or not to USE the padding characters =  is optional for base
 encoding FOR
 SOME CIRCUMSTANCES.  Maybe it's more clear to just cite the original wording 
 here

In some circumstances, the use of padding (=) in base encoded data
is not required nor used.  In the general case, when assumptions on
size of transported data cannot be made, padding is required to yield
correct decoded data.
Implementations MUST include appropriate pad characters at the end of
encoded data unless the specification referring to this document
explicitly states otherwise.
I don't know what you're quoting from, but that's not in RFC 2045 where base64
is defined for MIME.  RFC 2045 is pretty clear about when the padding character
must or must not be present.

 My interpretation is that it is possible for some types/styles of Base64
 implementation
 it is optional to not generate the padding character at the end of the
 encoding operation.
I think those would be non-MIME uses.

 Though the RFC requires if it does omitting the padding character, it need to
 explicitly
 specify this in its spec.

 When encoding the existing implementation, by default, always add the padding
 characters
 at the end of the encoded stream, if needed (for xx==, xxx=). Decoder is try
 to be liberal/
 lenient in what your accept (with the assumption is that the encoded may come
 from some
 encoder that not generate the padding characters), so it accept data with
 padding and
 dta without padding. However, it requires that if padding characters are used,
 it need
 to be CORRECTLY encoded. That was the original specification and 
 implementation.
 Upon your original request, I made the compromise to give MIME type a more 
 liberal
 spec/implementation for incorrect padding character combination as showed 
 below

 Patterns of possible incorrectly encoded padding final base64 unit are:

  =   unnecessary padding character at the end of encoded stream
  xx= missing the last padding character
  xx=ymissing the last padding character, instead having a 
 non-padding char
 Now it appears this compromise became part of your complain.
No, my complaint is that you missed one case  x.

 Our difference is that I believe the padding character is not part of the
 original
 data, we can be liberal/lenient for that. But x=== (or simply a dangling 
 x)
 is missing part of the original data for decoding, I'm concerned about to be
 liberal on guessing what is missed.
Again, I can understand a strict decoding that detects all encoding errors and
a lenient decoding that ignores encoding errors, but you've got a
half-lenient/half-strict decoding that I don't think is useful.

Re: RFR 8025003: Base64 should be less strict with padding

Alan Bateman wrote on 11/13/13 08:51:
 On 13/11/2013 04:21, Bill Shannon wrote:
 :
 There's really no error recovery possible, and certainly no program is
 going to attempt error recovery.  As I said, there's only two reasonable
 things to do:  1) throw up your hands, claim the data is corrupt, and tell
 the user there's nothing you can do, or 2) do your best job to give the user
 as much data as possible, and let the user decide if the data is in fact 
 corrupt.
 I'd be happy for you to provide options to do both.  Doing something that's
 half way between the two just isn't useful.

 A variation of the second might be for the decoder to stop when it encounters 
 an
 error (illegal character, missing pad characters, insufficient bits in the 
 last
 unit). That is, give the user the bytes that have been successfully decoded 
 plus
 an indication that the remaining bytes have not been processed due to an 
 error.
 This wouldn't be too hard to add with changes or variations of the decode
 methods that decode buffers (as the source buffer can report if it has
 remaining/unprocessed bytes). It's just a bit more work for users of the API
 that want to be able to handle corrupt or truncated input. From a quick look
 then it actually isn't too far from where Sherman was going, at least it
 wouldn't be if missing pad characters were treated as an error (as they were
 previously).

I think always taking a strict approach is fine as long as it's straightforward
for a user of the API to turn that into a lenient decoding.  But if that's the
approach you prefer, you should detect more errors than currently proposed.

 The other thought is the charset API where a charset decoder can be configured
 to ignore, replace or report then malformed or unmappable input. Having 
 support
 for all these actions is important for charset encoding/decoding but seems way
 too much for Base64 where I think the API should be simple for the majority of
 usages.

We started this with a request for a strict/lenient option.  That may still be
simpler than figuring out how to do strict decoding and report the error in a
way that users of the API can ignore the error and provide as much data as
possible.

 In any case, it's not clear what we can do this late in the schedule. It might
 be prudent to just fix the MIME decoder to throw IAE consistently and re-visit
 the API support for a lenient decoder in JDK 9.

When we started this conversation there was plenty of time to fix this.  :-(

hg: jdk8/tl/jdk: 8028300: Fix raw type lint warnings in java.util.concurrent

2013-11-13 Thread joe . darcy

Changeset: e6333788b117
Author:darcy
Date:  2013-11-13 11:06 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6333788b117

8028300: Fix raw type lint warnings in java.util.concurrent
Reviewed-by: chegar, martin

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java

Re: RFR 8025003: Base64 should be less strict with padding


On 11/13/2013 10:41 AM, Bill Shannon wrote:




The other thought is the charset API where a charset decoder can be configured
to ignore, replace or report then malformed or unmappable input. Having support
for all these actions is important for charset encoding/decoding but seems way
too much for Base64 where I think the API should be simple for the majority of
usages.

We started this with a request for a strict/lenient option.  That may still be
simpler than figuring out how to do strict decoding and report the error in a
way that users of the API can ignore the error and provide as much data as
possible.


In any case, it's not clear what we can do this late in the schedule. It might
be prudent to just fix the MIME decoder to throw IAE consistently and re-visit
the API support for a lenient decoder in JDK 9.

When we started this conversation there was plenty of time to fix this.  :-(


The issue here is we disagree on the specification of what lenient should be 
and how the
API should look like.

Here is the proposed change to undo the lenient padding handling for mime 
change we
did earlier to leave the option open for a complete lenient base64 in future 
release,
when we have a consensus

http://cr.openjdk.java.net/~sherman/base64_malformed2/webrev/

Alan, I still keep the decode(buf, buf) change on the table, as I feel it might 
be better than
the existing one. But I'm fine if you prefer to keep the existing IAE throwing 
behavior.

-Sherman

hg: jdk8/tl/jdk: 8027645: Pattern.split() with positive lookahead; ...

2013-11-13 Thread xueming . shen

Changeset: 9e37caf07ce0
Author:sherman
Date:  2013-11-13 11:26 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e37caf07ce0

8027645: Pattern.split() with positive lookahead
6559590: Pattern.compile(.*).split() returns incorrect result
Summary: updated spec/impl for these two corner cases
Reviewed-by: alanb, psandoz

! src/share/classes/java/lang/String.java
! src/share/classes/java/util/regex/Pattern.java
! test/java/lang/String/Split.java
! test/java/util/regex/RegExTest.java

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/13/13 11:11:
 On 11/13/2013 10:41 AM, Bill Shannon wrote:


 The other thought is the charset API where a charset decoder can be 
 configured
 to ignore, replace or report then malformed or unmappable input. Having 
 support
 for all these actions is important for charset encoding/decoding but seems 
 way
 too much for Base64 where I think the API should be simple for the majority 
 of
 usages.
 We started this with a request for a strict/lenient option.  That may still 
 be
 simpler than figuring out how to do strict decoding and report the error in a
 way that users of the API can ignore the error and provide as much data as
 possible.

 In any case, it's not clear what we can do this late in the schedule. It 
 might
 be prudent to just fix the MIME decoder to throw IAE consistently and 
 re-visit
 the API support for a lenient decoder in JDK 9.
 When we started this conversation there was plenty of time to fix this.  :-(
 
 The issue here is we disagree on the specification of what lenient should be 
 and
 how the
 API should look like.
 
 Here is the proposed change to undo the lenient padding handling for mime
 change we
 did earlier to leave the option open for a complete lenient base64 in future
 release,
 when we have a consensus

What other implementors of base64 MIME decoding software have you consulted,
or do you intend to consult in the future?

What experiments have you done with other base64 MIME decoding software or
applications to determine how they handle these cases?

I'm trying to determine how we're going to reach consensus in the future.

My base64 MIME decoding software has evolved over time based on customer
requirements.  I'm trying to give you the benefit of that experience so
that you don't need to waste years getting to the same point I got to.
I started in a similar place as you, believing that applications would
want to know about improperly encoded data.  I learned that many do not,
and that most end-user applications simply want to be as lenient as possible
to provide the best data possible to the user.

RFR (JAXP): 8028111 : XML readers share the same entity expansion counter

2013-11-13 Thread huizhe wang


Hi,

The issue is that the limits applied to each processing process rather 
than each file processing. This applies to not only StAX as reported, 
but also other parsers and validators. The fix is to add reset to 
XMLSecurityManager and call it upon each file processing. XSLT Transform 
is verified fixed as the underlying parsers are fixed.


webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/

Thanks,
Joe

hg: jdk8/tl/hotspot: 18 new changesets

2013-11-13 Thread lana . steuck

Changeset: 5b84039ca739
Author:amurillo
Date:  2013-11-01 08:35 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b84039ca739

8027580: new hotspot build - hs25-b58
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ea79ab313e98
Author:mgerdin
Date:  2013-10-30 15:35 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea79ab313e98

8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 
bytes
Summary: Use 2-byte loads to load indexes from the byte code stream to avoid 
out of bounds reads.
Reviewed-by: coleenp, sspitsyn

! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: fdd464c8d62e
Author:acorn
Date:  2013-10-30 09:11 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fdd464c8d62e

8027304: Lambda: inheriting abstract + 1 default - default, not ICCE
Reviewed-by: hseigel, zgu

! src/share/vm/classfile/defaultMethods.cpp

Changeset: 4fe7815b04f5
Author:acorn
Date:  2013-10-30 09:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4fe7815b04f5

Merge


Changeset: c8fc12209830
Author:coleenp
Date:  2013-10-31 14:11 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8fc12209830

8027616: Off by one error in putback for compressed oops nashorn performance 
improvement
Summary: Should compare bounds greater than or equal 4G when deciding if shift 
is needed or CDS area + compressed class space are within 4G of each other.
Reviewed-by: stefank, hseigel, zgu

! src/share/vm/memory/metaspace.cpp

Changeset: 910026b800b8
Author:coleenp
Date:  2013-11-01 10:32 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/910026b800b8

8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use 
MethodHandle
8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work 
with anonymous classes
Summary: Walk methods in breakpoints for marking on stack so they aren't 
deallocated by redefine classes.  Use class_holder rather than class_loader to 
keep GC from reclaiming class owning the method.
Reviewed-by: sspitsyn, ehelin, sla

! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiImpl.hpp

Changeset: 42790b7e4d48
Author:mgronlun
Date:  2013-11-01 15:56 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42790b7e4d48

Merge

! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: f8b56489e455
Author:mgronlun
Date:  2013-11-01 17:10 +
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8b56489e455

Merge


Changeset: 04df110c8655
Author:mgronlun
Date:  2013-11-02 20:56 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04df110c8655

Merge


Changeset: 208ebea980f8
Author:roland
Date:  2013-11-04 21:59 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/208ebea980f8

8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I
Summary: String.equals() intrinsic shouldn't use integer length input in 
pointer arithmetic without an i2l.
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.ad
+ test/compiler/intrinsics/stringequals/TestStringEqualsBadLength.java

Changeset: e428d5e768e3
Author:rbackman
Date:  2013-11-04 10:44 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e428d5e768e3

8027622: java.time.Instant.create failing since hs25-b56
Reviewed-by: kvn, iveresov

! src/share/vm/opto/compile.cpp
+ test/compiler/intrinsics/mathexact/CompareTest.java

Changeset: a905d33ce13a
Author:iveresov
Date:  2013-11-05 00:59 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a905d33ce13a

8027751: C1 crashes in Weblogic with G1 enabled
Summary: Keep T_OBJECT operands in registers for logical operations on x64
Reviewed-by: kvn, roland

! src/share/vm/c1/c1_LinearScan.cpp
+ test/compiler/regalloc/C1ObjectSpillInLogicOp.java

Changeset: 94a83e0f9ce1
Author:iveresov
Date:  2013-11-05 01:57 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94a83e0f9ce1

8017065: C2 allows safepoint checks to leak into G1 pre-barriers
Summary: Make all raw loads strictly respect control dependencies, make sure 
RCE doesn't move raw loads, add verification of G1 pre-barriers.
Reviewed-by: kvn, roland

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/memnode.hpp

Changeset: 613e6a6fc328
Author:iveresov
Date:  2013-11-05 02:29 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/613e6a6fc328

Merge

! src/share/vm/opto/compile.cpp

Changeset: be525e91f65b
Author:mikael
Date:  2013-11-06 06:51 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be525e91f65b

8026775: nsk/jvmti/RedefineClasses/StressRedefine

Re: RFR 8025003: Base64 should be less strict with padding

On 11/13/2013 11:37 AM, Bill Shannon wrote:

Xueming Shen wrote on 11/13/13 11:11:

On 11/13/2013 10:41 AM, Bill Shannon wrote:

We started this with a request for a strict/lenient option. That may still be
simpler than figuring out how to do strict decoding and report the error in a
way that users of the API can ignore the error and provide as much data as
possible.

When we started this conversation there was plenty of time to fix this. :-(

The issue here is we disagree on the specification of what lenient should be and
how the
API should look like.

Here is the proposed change to undo the lenient padding handling for mime
change we
did earlier to leave the option open for a complete lenient base64 in future
release,
when we have a consensus

What other implementors of base64 MIME decoding software have you consulted,
or do you intend to consult in the future?

Yes, the plan is to see what other implementations do.

So far

(1) google's guava [1] just throws the exception

com.google.common.io.BaseEncoding.base64().decode(QUJDA);

== java.lang.IllegalArgumentException:
com.google.common.io.BaseEncoding$DecodingException: Invalid input length 5

I don't think any of the configuration options provide can make this exception
go away.

(2) apache's commons-codec [2] silently drops the dangling 6-bits
new String(org.apache.commons.codec.binary.Base64.decodeBase64(QUJDA))

== ABC

Its source code [3] at ln#465 suggests it's TODO
...
case 1: // 6 bits - ignore entirely
// TODO not currently tested; perhaps it is impossible?
break;
...

-Sherman

[1]
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/BaseEncoding.html
[2]
http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html
[3]
http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Base64.java?revision=1447577view=markup

What experiments have you done with other base64 MIME decoding software or
applications to determine how they handle these cases?

I'm trying to determine how we're going to reach consensus in the future.

My base64 MIME decoding software has evolved over time based on customer
requirements. I'm trying to give you the benefit of that experience so
that you don't need to waste years getting to the same point I got to.
I started in a similar place as you, believing that applications would
want to know about improperly encoded data. I learned that many do not,
and that most end-user applications simply want to be as lenient as possible
to provide the best data possible to the user.

Review request for JDK-8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in generated api docs

2013-11-13 Thread Eric McCorkle

Hello,

Please review this trivial fix that adds @since documentation tags to
changes added in support of parameter reflection.

Webrev here:
http://cr.openjdk.java.net/~emc/8028021/

Thanks,
Eric

Re: Review request for JDK-8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in generated api docs

2013-11-13 Thread Joe Darcy


Looks good; approved,

Thanks,

-Joe

On 11/13/2013 12:34 PM, Eric McCorkle wrote:

Hello,

Please review this trivial fix that adds @since documentation tags to
changes added in support of parameter reflection.

Webrev here:
http://cr.openjdk.java.net/~emc/8028021/

Thanks,
Eric

hg: jdk8/tl/jdk: 8026884: test for fix of JDK-8021398 does not have @bug tag; ...

2013-11-13 Thread eric . mccorkle

Changeset: ea91826bc2e9
Author:emc
Date:  2013-11-13 15:48 -0500
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea91826bc2e9

8026884: test for fix of JDK-8021398 does not have @bug tag
8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in 
generated api docs
Summary: two documentation fixes
Reviewed-by: darcy

! src/share/classes/java/lang/reflect/Executable.java
! test/java/lang/reflect/Parameter/GetAnnotatedTypeTest.java

Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter


On 13/11/2013 20:02, huizhe wang wrote:

Hi,

The issue is that the limits applied to each processing process rather 
than each file processing. This applies to not only StAX as reported, 
but also other parsers and validators. The fix is to add reset to 
XMLSecurityManager and call it upon each file processing. XSLT 
Transform is verified fixed as the underlying parsers are fixed.


webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/
This looks okay as a band-aid but won't this be replaced if fixed to 
have limits per document?


-Alan.

Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter

2013-11-13 Thread Lance Andersen - Oracle

looks fine joe
On Nov 13, 2013, at 3:02 PM, huizhe wang wrote:

 Hi,
 
 The issue is that the limits applied to each processing process rather than 
 each file processing. This applies to not only StAX as reported, but also 
 other parsers and validators. The fix is to add reset to XMLSecurityManager 
 and call it upon each file processing. XSLT Transform is verified fixed as 
 the underlying parsers are fixed.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/
 
 Thanks,
 Joe
 


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

Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter

2013-11-13 Thread huizhe wang



On 11/13/2013 1:33 PM, Alan Bateman wrote:

On 13/11/2013 20:02, huizhe wang wrote:

Hi,

The issue is that the limits applied to each processing process 
rather than each file processing. This applies to not only StAX as 
reported, but also other parsers and validators. The fix is to add 
reset to XMLSecurityManager and call it upon each file processing. 
XSLT Transform is verified fixed as the underlying parsers are fixed.


webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/
This looks okay as a band-aid but won't this be replaced if fixed to 
have limits per document?


Each parser has its own copy of XMLSecurityManager that maintains the 
values of the limits. The parser is reset before it starts to parse a 
document. Resetting the values managed by XMLSecurityManager therefore 
makes sure that the limits are per document.


Daniel sent me a private email to question if the reset in 
PropertyManager is safe. He was right. I traced that back to the 
previous patch in that the StAX parsers actually were sharing the same 
XMLSecurityManager, and also XMLSecurityPropertyManager. I've changed 
the code so that they are cloned.


webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/

Thanks,
Joe



-Alan.

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/13/13 12:28:
On 11/13/2013 11:37 AM, Bill Shannon wrote:
Xueming Shen wrote on 11/13/13 11:11:
On 11/13/2013 10:41 AM, Bill Shannon wrote:

The other thought is the charset API where a charset decoder can be
configured
to ignore, replace or report then malformed or unmappable input. Having
support
for all these actions is important for charset encoding/decoding but
seems way
too much for Base64 where I think the API should be simple for the
majority of
usages.
We started this with a request for a strict/lenient option. That may
still be
simpler than figuring out how to do strict decoding and report the error
in a
way that users of the API can ignore the error and provide as much data as
possible.

In any case, it's not clear what we can do this late in the schedule. It
might
be prudent to just fix the MIME decoder to throw IAE consistently and
re-visit
the API support for a lenient decoder in JDK 9.
When we started this conversation there was plenty of time to fix this.
:-(
The issue here is we disagree on the specification of what lenient should
be and
how the
API should look like.

Here is the proposed change to undo the lenient padding handling for mime
change we
did earlier to leave the option open for a complete lenient base64 in
future
release,
when we have a consensus
What other implementors of base64 MIME decoding software have you consulted,
or do you intend to consult in the future?

Yes, the plan is to see what other implementations do.

So far

(1) google's guava [1] just throws the exception

com.google.common.io.BaseEncoding.base64().decode(QUJDA);

== java.lang.IllegalArgumentException:
com.google.common.io.BaseEncoding$DecodingException: Invalid input length 5

I don't think any of the configuration options provide can make this exception
go away.

(2) apache's commons-codec [2] silently drops the dangling 6-bits
new String(org.apache.commons.codec.binary.Base64.decodeBase64(QUJDA))

== ABC

Its source code [3] at ln#465 suggests it's TODO
...
case 1: // 6 bits - ignore entirely
// TODO not currently tested; perhaps it is impossible?
break;
...

-Sherman

[1]
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/BaseEncoding.html

[2]
http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html

[3]
http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Base64.java?revision=1447577view=markup

base64 decoders that deal with simple, short strings aren't really a challenge.
Such strings are almost always encoded correctly.

The challenge is decoding base64 encoded content in a MIME part, e.g., in
an email message. There's lots of really bad email software out there,
often spamming software, that doesn't always follow the rules of the spec.

Look at what other libraries that parse email messages do. Look at what
email applications do. If you send incorrectly encoded data to Gmail,
what does the Gmail web UI do? What does Thunderbird or Outlook do?

Reported but unconfirmed JDK issue (Bug Id: 9002739)

2013-11-13 Thread Florian Brunner

Hi,

My name is Florian Brunner. This is my first E-Mail to this list. (So far I was 
only involved with the swing-dev and openjfx-dev mailing lists of OpenJDK.) So 
I hope, I'm sending my question to the right list.

Back in May I filed a JDK issue regarding the ZipFileSystemProvider (see the 
message below). But so far I cannot find the issue with the Bug Id: 9002739 on 
the Java Bug Database at http://bugs.sun.com.

Since a bug has been reported for Drombler FX (an Open Source project providing 
a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first)), 
which probably is caused by this issue, I would like to work on this issue. 

http://issues.drombler.org/14

Could someone from Oracle confirm this issue and make sure it appears in the 
Bug Database?

Thanks.

-Florian

-Original Message-
From: bug-report-daemon...@oracle.com [mailto:bug-report-daemon...@oracle.com] 
Sent: Friday, May 17, 2013 7:09 PM
To: Brunner Florian (IT-SWE-CD2-T25)
Subject: Your Report (Bug ID: 9002739 ) - ZipFileSystemProvider: newFileSystem 
URI format issue

Dear Java Developer, 
 
Thank you for reporting this issue.

We have determined that this report is a new bug and have entered the bug into 
our bug tracking system under Bug Id: 9002739. You can look for related issues 
on the Java Bug Database at http://bugs.sun.com.

We will try to process all newly posted bugs in a timely manner, but we make no 
promises about the amount of time in which a bug will be fixed. If you just 
reported a bug that could have a major impact on your project, consider using 
one of the technical support offerings available at Oracle Support.

Thanks again for your submission!

Regards, 
Java Developer Support

hg: jdk8/tl/langtools: 8025113: Convert 7 tools TryWithResources tests to jtreg format

2013-11-13 Thread sonali . goel

Changeset: f90d88913c5f
Author:sogoel
Date:  2013-11-13 16:36 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f90d88913c5f

8025113: Convert 7 tools TryWithResources tests to jtreg format
Reviewed-by: darcy, jjg

+ test/tools/javac/TryWithResources/ResDeclOutsideTry.java
+ test/tools/javac/TryWithResources/ResDeclOutsideTry.out
+ test/tools/javac/TryWithResources/ResInNestedExpr.java
+ test/tools/javac/TryWithResources/ResourceNameConflict.java
+ test/tools/javac/TryWithResources/ResourceNameConflict.out
+ test/tools/javac/TryWithResources/ResourceRedecl.java
+ test/tools/javac/TryWithResources/ResourceRedecl.out
+ test/tools/javac/TryWithResources/ResourceShadow.java
+ test/tools/javac/TryWithResources/TestTwr09.java

Re: RFR(2): 7174936: several String methods claim to always create new String

2013-11-13 Thread David Holmes


Hi Stuart,

Sorry for the delay (been enroute). Only issue I have remains the 
subSequence change - you can't weaken the post-condition of 
CharSequence.subSequence without breaking subtype substitutability.


Thanks,
David

On 12/11/2013 8:43 AM, Stuart Marks wrote:

Hi all,

Here's an updated version of the String spec change. Changes from the
previous version address comments made by Brent Christian and David
Holmes. Specifically:

  - Specify copyValueOf() overloads as equivalent to corresponding
valueOf() overloads.
  - Remove extranous changes to subSequence() method
  - Clarify wording of concat() method doc.

Bug report:

 https://bugs.openjdk.java.net/browse/JDK-7174936

Webrev:

 http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.1/

Specdiff:

 
http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.1/overview-summary.html

Thanks!

s'marks

On 11/7/13 2:31 AM, Stuart Marks wrote:

Hi all,

Please review the following spec changes to java.lang.String.

In several places the specs mention returning new strings. This is
overspecified; it's sufficient to return a string that satisfies the
required
properties. In some cases the current implementation doesn't create a
new string
-- for example, substring(0) returns 'this' -- which is strictly a
violation of
the spec. The solution is to relax the spec requirement to create new
strings.

Also, this change cleans up the specs for the copyValueOf() overloads
to make
them identical to the corresponding valueOf() overloads. Previously,
they were
gratuitously different. I think that some time in the dim, distant past,
probably before JDK 1.0, they had different semantics, but now they're
identical. The specs should say they're identical.

This change is spec only, no code changes.

Bug report:

 https://bugs.openjdk.java.net/browse/jdk-7174936

Webrev:

 http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/

Specdiff:


http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html


Thanks!

s'marks

RFR JDK-8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression.


Hi,

The change set for JDK-6559590 [1] triggers couple regression test failures in 
various areas.
It appears jdk8 source code itself has dependency on the old behavior of 
split() method
when the input sequence is an empty string (split-ing a zero-length input 
sequence always
returns the resulting array has just one element, the empty string itself). 
Given we are
at a very late stage of the release, seems like the best way to solve this 
issue for now is
to undo the change for 6559590. I will re-open 6559590 for future releases.

Here is the webrev for the undo. We still keep the change for 8027645

http://cr.openjdk.java.net/%7Esherman/8027645/webrev/http://cr.openjdk.java.net/~sherman/8028321/webrev/

Thanks!
-Sherman

[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e37caf07ce0

Re: Reported but unconfirmed JDK issue (Bug Id: 9002739)

2013-11-13 Thread Joseph Darcy


Hello,

The incident 9002739 became bug JDK-8014852 (zipfs) 
ZipFileSystemProvider: newFileSystem URI format issue, which in turn 
was marked as a duplicate of JDK-7156873 (zipfs) 
FileSystems.newFileSystem(uri, env) fails for uri with escaped octets.:


https://bugs.openjdk.java.net/browse/JDK-7156873

JDK-7156873 is fixed in JDK 8, 7u40, and 7u45.

HTH,

-Joe

On 11/13/2013 3:52 PM, Florian Brunner wrote:

Hi,

My name is Florian Brunner. This is my first E-Mail to this list. (So far I was 
only involved with the swing-dev and openjfx-dev mailing lists of OpenJDK.) So 
I hope, I'm sending my question to the right list.

Back in May I filed a JDK issue regarding the ZipFileSystemProvider (see the 
message below). But so far I cannot find the issue with the Bug Id: 9002739 on 
the Java Bug Database at http://bugs.sun.com.

Since a bug has been reported for Drombler FX (an Open Source project providing 
a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first)), 
which probably is caused by this issue, I would like to work on this issue.

http://issues.drombler.org/14

Could someone from Oracle confirm this issue and make sure it appears in the 
Bug Database?

Thanks.

-Florian

-Original Message-
From: bug-report-daemon...@oracle.com [mailto:bug-report-daemon...@oracle.com]
Sent: Friday, May 17, 2013 7:09 PM
To: Brunner Florian (IT-SWE-CD2-T25)
Subject: Your Report (Bug ID: 9002739 ) - ZipFileSystemProvider: newFileSystem 
URI format issue

Dear Java Developer,
  
Thank you for reporting this issue.


We have determined that this report is a new bug and have entered the bug into 
our bug tracking system under Bug Id: 9002739. You can look for related issues 
on the Java Bug Database at http://bugs.sun.com.

We will try to process all newly posted bugs in a timely manner, but we make no 
promises about the amount of time in which a bug will be fixed. If you just 
reported a bug that could have a major impact on your project, consider using 
one of the technical support offerings available at Oracle Support.

Thanks again for your submission!

Regards,
Java Developer Support

RFR for JDK-7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently

2013-11-13 Thread Eric Wang


Hi Everyone,

I'm working on the bug https://bugs.openjdk.java.net/browse/JDK-7067973.

It is a test bug as the test doesn't guarantee memory allocated from the 
Old Gen, if the used memory is zero and doesn't cross the threshold, no 
notification is sent, so both the main thread and Checker thread are 
blocked to wait for the GC notification.


so the suggested fix is similar as the fix ResetPeakMemoryUsage.java 
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0896634ab46 to create big 
object to make sure the old gen usage crosses the threshold and run test 
with different GC vmoptions.


Please let me know if you have any comments or suggestions. If you are 
OK with the solution, I'll send a webrev in the next mail.


Thanks,
Eric

hg: jdk8/tl/jdk: 8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression

2013-11-13 Thread xueming . shen

Changeset: 1d790a56de4e
Author:sherman
Date:  2013-11-13 22:22 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d790a56de4e

8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers 
regression
Summary: to undo the change for 6559590
Reviewed-by: darcy

! src/share/classes/java/lang/String.java
! src/share/classes/java/util/regex/Pattern.java
! test/java/lang/String/Split.java
! test/java/util/regex/RegExTest.java

Re: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess

2013-11-13 Thread Staffan Larsen

Looks good!

Thanks,
/Staffan

On 12 Nov 2013, at 20:29, Mandy Chung mandy.ch...@oracle.com wrote:

 This is a simple code deletion in sun.misc.JavaAWTAccess and its 
 implementation class:
 
 Webrev:
 http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/
 
 This patch removes the methods from sun.misc.JavaAWTAccess that are no longer 
 used.  The only dependency remaining from core-libs to AppContext is the 
 ability to obtain an opaque unique object to represent an applet context ifit 
 is running in an applet environment.
 
 thanks
 Mandy

Re: RFR for JDK-7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently