Hi,
Thanks Karen and Peter.
FWIW my interpretation is that javac is doing the right thing. The bytecode
generated is an invokeinterface DefaultStaticMethodTest$C.m(). This looks
consistent with the other bytecodes generated for calls to methods of anonymous
classes implementing an interface.
On 09/13/2013 11:05 AM, Joel Borggrén-Franck wrote:
Hi,
Thanks Karen and Peter.
FWIW my interpretation is that javac is doing the right thing. The bytecode generated is
an invokeinterface DefaultStaticMethodTest$C.m(). This looks consistent with
the other bytecodes generated for calls to
Changeset: ba0b95f310c8
Author:sjiang
Date: 2013-09-13 10:48 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba0b95f310c8
8023669: MBean*Info.hashCode : NPE
Reviewed-by: dholmes, dfuchs, jbachorik
! src/share/classes/javax/management/MBeanAttributeInfo.java
!
On 09/12/2013 03:37 PM, Joel Borggrén-Franck wrote:
Hi again,
New webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.01/
Thanks to Remi and Peter for the quick feedback, I've updated the code
to use for-each as well as fixing getMethod(...).
Andreas Lundblad also added ~100 testcases
On 09/13/2013 12:18 PM, Peter Levart wrote:
The C.class.getMethods() returns a 1 element array containing A.m(),
but C.class.getMethod(m) throws NoSuchMethodException.
This seems inconsistent, but it's a corner case that can only happen
with separate compilation.
Sorry Joel, I must have
Changeset: cc2bae7f8fbb
Author:bchristi
Date: 2013-09-12 14:22 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc2bae7f8fbb
8024009: Remove jdk.map.useRandomSeed system property
Summary: Removed usage of hashSeed in Hashtable WeakHashMap, and removed tests
Reviewed-by:
Changeset: c53411f89b4c
Author:msheppar
Date: 2013-09-13 12:20 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c53411f89b4c
8024675: java/net/NetworkInterface/UniqueMacAddressesTest.java fails on Windows
Summary: amended test to add active, i.e. isUp(), NetworkInterfaces to
Changeset: e60f6add90d7
Author:hannesw
Date: 2013-09-12 14:02 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e60f6add90d7
8024476: Octane regression on Richards
Reviewed-by: sundar, jlaskey
! src/jdk/nashorn/internal/runtime/JSType.java
Changeset: 572a2e50ba9e
Author:
Hi Peter,
Interesting case, thanks for the testing.
On Sep 13, 2013, at 1:15 PM, Peter Levart peter.lev...@gmail.com wrote:
On 09/13/2013 12:18 PM, Peter Levart wrote:
The C.class.getMethods() returns a 1 element array containing A.m(), but
C.class.getMethod(m) throws NoSuchMethodException.
On 09/13/2013 02:55 PM, Joel Borggrén-Franck wrote:
Hi Peter,
Interesting case, thanks for the testing.
On Sep 13, 2013, at 1:15 PM, Peter Levart peter.lev...@gmail.com wrote:
On 09/13/2013 12:18 PM, Peter Levart wrote:
The C.class.getMethods() returns a 1 element array containing A.m(),
On Sep 13, 2013, at 3:18 PM, Peter Levart peter.lev...@gmail.com wrote:
On 09/13/2013 02:55 PM, Joel Borggrén-Franck wrote:
Hi Peter,
Interesting case, thanks for the testing.
On Sep 13, 2013, at 1:15 PM, Peter Levart peter.lev...@gmail.com wrote:
On 09/13/2013 12:18 PM, Peter Levart
A new webrev is posted (and crucible updated), which actually validates
parameter names correctly. Apologies for the last one.
On 09/12/13 16:02, Eric McCorkle wrote:
Hello,
Please review this patch, which implements correct behavior for the
Parameter Reflection API in the case of malformed
MalformedParametersException should receive a @since tag.
Additionally, the javadoc doesn't describe what it means for a parameter to
be malformed. The answer doesn't need to be exhaustive, but I think some
examples would help developers if they catch one and need to dig into class
files. Or if
Hi Eric,
IIRC we don't check in classfiles into the repo.
I'm not sure how we handle testing of broken class-files in jdk, but ASM might
be an option, or storing the class file as an embedded byte array in the test.
cheers
/Joel
On Sep 13, 2013, at 3:40 PM, Eric McCorkle
There is no simple means of generating bad class files for testing.
This is a huge deficiency in our testing abilities.
If these class files shouldn't go in, then I'm left with no choice but
to check in no test for this patch.
However, anyone can run the test I've provided with the class files
I think the right thing to do is to include the original compiling source in a
comment, together with a comment on how you modify them, and then the result as
a byte array.
IIRC I have seen test of that kind before somewhere in our repo.
cheers
/Joel
On Sep 13, 2013, at 4:49 PM, Eric McCorkle
On 09/13/2013 03:38 PM, Joel Borggrén-Franck wrote:
I fully agree this will most probably occur in practice. But the situation is
more complicated for an invoke, since there must have been a A.m() present when
C was compiled in order to have an invokeinterface to be there in the first
place.
Ugh. Byte arrays of class file data is really a horrible solution.
I have already filed a task for test development post ZBB to develop a
solution for generating bad class files. I'd prefer to file a follow-up
to this to add the bad class file tests when that's done.
On 09/13/13 10:55, Joel
I don't know Cocoa memory management but from a quick look at the
NSAutoreleasePool docs then what you seems to be right. Folks on
macosx-port-dev would be better to comment on that.
Perhaps Dave could comment?
The use of NSAutoreleasePool is fine in this case.
I see that
I need a review for this simple change.
The problem here is that on Mac the file names with composite letters
(like letters with diacritic symbols)
are being kept in the Normalized Form Decomposed, so if file contains
class with the Composed name the
command-line utility or badly configured
Replying to Alan and Mike...
On 9/6/13 2:27 AM, Alan Bateman wrote:
On 05/09/2013 22:30, Brent Christian wrote:
I don't know Cocoa memory management but from a quick look at the
NSAutoreleasePool docs then what you seems to be right. Folks on
macosx-port-dev would be better to comment on
On Sep 13 2013, at 10:20 , Brent Christian wrote:
Done, new webrev is here:
http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/
On 9/6/13 4:09 PM, Mike Duigou wrote:
I am surprised that strdup isn't needed for the constant ? string
but java_props_md.c seems to include other
Hi Eric,
How did you create those class files? By hand using a HEX editor? Did
you create a program that patched the original class file? If the later
is the case, you could pack that patching logic inside a custom
ClassLoader...
To hacky? Dependent on future changes of javac? At least the
Done, new webrev is here:
http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/
On 9/6/13 4:09 PM, Mike Duigou wrote:
I am surprised that strdup isn't needed for the constant ? string
but java_props_md.c seems to include other constant strings in sprops
so I will assume it is just
I did it by hand with emacs.
I would really rather tackle the bad class files for testing issue once
and for all, the Right Way (tm). But with ZBB looming, now is not the
time to do it.
Hence, I have created this task
https://bugs.openjdk.java.net/browse/JDK-8024674
I also just created this
Ping, Reviewer needed for these minor updates, the test is now more
robust thanks to Peter's nudging.
http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
Please review for two corrections:
- The java/time/tck/java/time/TCKLocalTime test failed on a slow
runtime due to -Xcomp;
Changeset: 67f64101616e
Author:mduigou
Date: 2013-09-13 12:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/67f64101616e
8024201: Update bugdatabase url
Reviewed-by: wetmore
! make/scripts/webrev.ksh
Changeset: c65848f2b6a1
Author:mduigou
Date: 2013-09-13 11:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c65848f2b6a1
8021591: Additional explicit null checks
Reviewed-by: psandoz, alanb
! src/share/classes/java/util/Collections.java
!
Hi,
This is change to clarify the java doc to match the existing behavior.
If there is a pending level/strategy change (via setLevel/Stragety()) when
deflate(...) is invoked, the implementation goes down to zlib's
deflateParams()
for deflating operation, which clearly specifies its behavior
On 09/13/13 09:53, Paul Benedict wrote:
MalformedParametersException should receive a @since tag.
Additionally, the javadoc doesn't describe what it means for a parameter to
be malformed. The answer doesn't need to be exhaustive, but I think some
examples would help developers if they catch
Based upon feedback we've decided to withdraw this change. It will remain
removeIf()
Mike
On Sep 4 2013, at 14:08 , Mike Duigou wrote:
Hello all;
The naming of the Collection.removeIf(Predicate) method has always been an
uncertain choice. We've gone back and forth between naming it
Hi Everyone,
Looking for a reviewer for this trivial fix to correct the sample example in
the Predicate javadoc for the evaluate method()
--
!hg
hg diff Predicate.java
diff -r 60d6f60416ca src/share/classes/javax/sql/rowset/Predicate.java
---
Hello all;
A very small patch that refines the declared conditions under which the
Collection.removeIf() method will throw UOE. The intent of this patch is to
allow the default implementation to be used for immutable collections. It's
important that the default implementations provided and the
Looks fine; cheers,
-Joe
On 9/13/2013 12:07 PM, roger riggs wrote:
Ping, Reviewer needed for these minor updates, the test is now more
robust thanks to Peter's nudging.
http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
Please review for two corrections:
- The
Changeset: 5c7690923663
Author:lancea
Date: 2013-09-13 19:10 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c7690923663
8014967: EBehavior of DriverManager.registerDriver(dr) is unspecified if driver
is null
Reviewed-by: alanb
!
Hi,
Please kindly review webrev at
http://cr.openjdk.java.net/~henryjen/tl/8024825/0/webrev/
This webrev is a typo fix + the cleanup made in lambda repo in following
changeset.
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a4babe938c8c
Summary of the changeset,
- Typo fix, Short-circuting
looks fine.
On 9/13/13 12:07 PM, roger riggs wrote:
Ping, Reviewer needed for these minor updates, the test is now more
robust thanks to Peter's nudging.
http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
Please review for two corrections:
- The
I would suggest leaving it at 1100 for this review (JDK7) and to 768 (0x003) in
JDK8. The latter will require another issue to be filed.
On Sep 12, 2013, at 9:25 PM, Dmitry Nadezhin wrote:
For me, it is the only consideration.
I'm sure in 768 because I proved it formally using ACL2 tool.
changes look fine.
Mike
On Sep 13 2013, at 17:22 , Henry Jen wrote:
Hi,
Please kindly review webrev at
http://cr.openjdk.java.net/~henryjen/tl/8024825/0/webrev/
This webrev is a typo fix + the cleanup made in lambda repo in following
changeset.
On 09/12/2013 01:02 PM, Eric McCorkle wrote:
Hello,
Please review this patch, which implements correct behavior for the
Parameter Reflection API in the case of malformed class files.
The bug report is here:
https://bugs.openjdk.java.net/browse/JDK-8020981
The webrev is here:
To avoid storing binaries in Hg, you could try something like:
* uuencode / ascii armor the class file
* convert to byte array in the test
* load classes from byte array
-Joe
On 09/13/2013 11:54 AM, Eric McCorkle wrote:
I did it by hand with emacs.
I would really rather tackle the bad class
Changeset: a7980b099af1
Author:henryjen
Date: 2013-09-06 15:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7980b099af1
8024825: Some fixes are missing from java.util.stream spec update
Reviewed-by: mduigou
! src/share/classes/java/util/stream/ReferencePipeline.java
!
I agree with 1100 for this review (JDK7).
I think that we shouldn't change from 1100 to 768 in JDK8 because this is a
small performance enhancement.
This will save time for fixing other bugs.
The performance enhancement could be smarter if we replace constant
MAX_NDIGIT by some piece-linear
43 matches
Mail list logo
