Hello Alan, Martin, everyone!
Some update on the issue.
When trying to integrate my test into Basic.java, I found that it
already contains exactly the same.
I have just overlooked it before.
Additional investigation showed that inheritIO() doesn't always fail on
Windows.
If the scenario is
On 12/09/2013 01:13, Brent Christian wrote:
Please review my fix to remove the jdk.map.useRandomSeed system
property added earlier in jdk8.
It's good to see this going away, the changes (and clean-up) look good
to me too.
-Alan
Changeset: e407df8093dc
Author:sjiang
Date: 2013-09-12 09:41 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e407df8093dc
8023529: OpenMBeanInfoSupport.equals/hashCode throw NPE
Reviewed-by: dholmes, dfuchs
!
On 11/09/2013 18:59, Daniel Fuchs wrote:
Hi,
Please find below a changeset for a small logging RFE:
8024525 - Make Logger log methods call isLoggable()
http://cr.openjdk.java.net/~dfuchs/webrev_8024525/webrev.00/
This change makes the various Logger logging method call isLoggable()
instead
Changeset: 262a625809fd
Author:darcy
Date: 2013-09-12 01:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/262a625809fd
8024643: Turn on javac lint checking in building the jdk repo
Reviewed-by: erikj, ihse, smarks
! makefiles/Setup.gmk
This explanation seems to combine numbers of binary digits (1075)
and numbers of decimal digits (17), and therefore makes me a little
nervous, though I think 1100 is a conservative choice that, even if not
100% correct, will be 99.(over 700 9s)% correct.
David
On 2013-09-12, at 1:17 AM, Dmitry
The reason while binary and decimal digits are mixed can be ullustrated by
such example.
It is necessary 3 decimal fraction digits to represent exactly pbinary
power pow(2,-3) :
pow(2,-3)=1/8=0.125
On Thu, Sep 12, 2013 at 3:57 PM, David Chase david.r.ch...@oracle.comwrote:
This explanation
Hi,
New changeset incorporating Alan's feedback:
http://cr.openjdk.java.net/~dfuchs/webrev_8024525/webrev.01/
How/why the test works should now appear more clearly :-)
-- daniel
On 9/12/13 10:40 AM, Alan Bateman wrote:
On 11/09/2013 18:59, Daniel Fuchs wrote:
Hi,
Please find below a
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 for getMethod(), both
positive and negative.
Please
Hi Stephen,
On 9/11/2013 8:56 PM, Stephen Colebourne wrote:
HijrahChronology mixes final transient and transient final. They
should be consistently one way or the other files should be checked,
and I think there is an official coding standard for this).
Yes, will fix in a future update.
On 12/09/2013 14:36, Daniel Fuchs wrote:
Hi,
New changeset incorporating Alan's feedback:
http://cr.openjdk.java.net/~dfuchs/webrev_8024525/webrev.01/
How/why the test works should now appear more clearly :-)
-- daniel
Thanks for that. I guess I would have used javadoc comments for some of
On 12/09/2013 15:14, roger riggs wrote:
Hi,
Testing of java.time has found a problematic test on compact 1 and 2.
The test relies on localization data for the French locale that is not
present.
Changing the tests to the US locale would be sufficient but then are
redundant
with other tests.
On 09/12/2013 09:17 AM, Dmitry Nadezhin wrote:
The patch is correct when decimal ULP of kept digits is pow(10,-1075)
of less. pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100
1075 + 17 .
OK. That makes more sense. Can we please add the short comment in the
code (maybe next time
On 2013-09-12, at 8:18 AM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
The reason while binary and decimal digits are mixed can be ullustrated by
such example.
It is necessary 3 decimal fraction digits to represent exactly pbinary
power pow(2,-3) :
pow(2,-3)=1/8=0.125
On Thu, Sep
I'd be more comfortable with them moving to the non-TCK area. But if
they have to be deleted, so be it.
Stephen
On 12 September 2013 15:14, roger riggs roger.ri...@oracle.com wrote:
Hi,
Testing of java.time has found a problematic test on compact 1 and 2.
The test relies on localization data
Hi,
Testing of java.time has found a problematic test on compact 1 and 2.
The test relies on localization data for the French locale that is not
present.
Changing the tests to the US locale would be sufficient but then are
redundant
with other tests. The tests are unnecessary and are
Looking for a reviewer for this trivial change to clarify the long outstanding
behavior of registererDriver:
$ hg diff DriverManager.java
diff -r 262a625809fd src/share/classes/java/sql/DriverManager.java
--- a/src/share/classes/java/sql/DriverManager.java Thu Sep 12 01:47:05
2013 -0700
On 12 September 2013 14:49, roger riggs roger.ri...@oracle.com wrote:
Some classes have had transient added, while others haven't. For
example LocalDate doesn't use transient. Since the instance fields are
never directly serialized, but do appear in the serialized form,
perhaps they should be
On 12/09/2013 15:45, Lance Andersen - Oracle wrote:
:
registerDriver has thrown this NPE since the early days of DriverManager (1997)
so it was requested that we clarify this.
Alan, could you please confirm whether I need a CCC given this behavior has
been there since JDBC 1.0 and this
Hi,
While testing behavior of reflection on default and static interface
methods, using self-built JDK from latest tip of jdk8/tl, I found:
The following program:
public class DefaultVsStaticInterfaceMethodTest {
public interface A {
default void m() {
Hi Alan,
For conformance tests, the configurations are more limited (Only the US
locale).
The other java.time tests that refer to specific locales don't rely on
the locale data
only the identity of the locale or depend on the fallback to the US locale.
Otherwise a wider refactoring would be
Changeset: 631c8dcd91f4
Author:dfuchs
Date: 2013-09-12 17:01 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/631c8dcd91f4
8024525: Make Logger log methods call isLoggable()
Summary: This changeset makes the various Logger logging method call
isLoggable() instead of inlining
Looking for a reviewer for this trivial fix:
hg diff PreparedStatement.java
diff -r 262a625809fd src/share/classes/java/sql/PreparedStatement.java
--- a/src/share/classes/java/sql/PreparedStatement.java Thu Sep 12 01:47:05
2013 -0700
+++ b/src/share/classes/java/sql/PreparedStatement.java Thu
On 12/09/2013 06:59, Ivan Gerasimov wrote:
Hello Alan, Martin, everyone!
Some update on the issue.
When trying to integrate my test into Basic.java, I found that it
already contains exactly the same.
I have just overlooked it before.
Additional investigation showed that inheritIO() doesn't
I think the reason you use 1075 digits is because it takes 1075 decimal digits
behind the decimal point to exactly represent 2^-1075,
and that is 1/2 ulp. When you discard the tail, if it happens to be all
zeroes, I hope you replace it with a zero, not a one, because otherwise you can
round
Look fine Lance; cheers,
-Joe
On 09/12/2013 08:21 AM, Lance Andersen - Oracle wrote:
Looking for a reviewer for this trivial fix:
hg diff PreparedStatement.java
diff -r 262a625809fd src/share/classes/java/sql/PreparedStatement.java
--- a/src/share/classes/java/sql/PreparedStatement.java
Changeset: 672f349fbad7
Author:rriggs
Date: 2013-09-12 10:58 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/672f349fbad7
8024618: Issues with French locale on compact1,2: expected:janvier but
was:January
Summary: Tests against the data of the French locale are not valid as
Never mind, this is in the context of FloatingDecimal and any trailing zeroes
are properly discarded.
Carry on, this code looks correct, despite my misunderstanding the explanation.
David
On 2013-09-12, at 12:32 PM, David Chase david.r.ch...@oracle.com wrote:
I think the reason you use 1075
New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
On 2013-09-12, at 1:53 PM, David Chase david.r.ch...@oracle.com wrote:
I believe it produced extraneous output -- it was not clear to me that it was
either necessary or useful to fully describe all the
Aleksey, I like your wording of the comment. Thank you very much.
I would reformulate a little:
We can demonstrate (link) that decimal ulp should be less than 10^(-1075)
to guarantee correctness
===
We can demonstrate (link) that decimal ulp less than 10^(-1075) is enough
to guarantee
Looks good (I'll take your word that the nasty awk scripts are correct...).
I think you should have included serviceability-dev on this review request.
/Staffan
On 10 sep 2013, at 18:56, Erik Helin erik.he...@oracle.com wrote:
Hi all,
this is the JDK part of the fix for 8014659 [0]. I've
JDK repository constains sources and tests now.
Where should proofs live ?
And also where should benchmarks live ?
On Thu, Sep 12, 2013 at 10:32 PM, Brian Burkhalter
brian.burkhal...@oracle.com wrote:
What should be put in for link?
Thanks,
Brian
On Sep 12, 2013, at 11:10 AM, Dmitry
+ // err.initCause(ex);
Why is this commented?
-- Chris
On Sep 6, 2013, at 4:59 PM, David Chase david.r.ch...@oracle.com wrote:
new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
Same small changes to the sources, plus a test.
bug: wrong exception was
I believe it produced extraneous output -- it was not clear to me that it was
either necessary or useful to fully describe all the converted exceptions that
lead to the defined exception being thrown. The commented line should have
just been removed (I think).
On 2013-09-12, at 1:24 PM,
What should be put in for link?
Thanks,
Brian
On Sep 12, 2013, at 11:10 AM, Dmitry Nadezhin wrote:
Aleksey, I like your wording of the comment. Thank you very much.
I would reformulate a little:
We can demonstrate (link) that decimal ulp should be less than 10^(-1075)
to guarantee
The test is adapted from the test in the bug report.
The headline on the bug report is wrong -- because it uses reflection in the
test to do the invocation,
the thrown exception is wrapped with InvocationTargetException, which is
completely correct.
HOWEVER, the exception inside the wrapper is
Thank you, we really appreciate all testing.
I have a fix in a prototype in the vm for this. Let me know if you want an
early patch.
Or you can just file a bug and that way you'll know when the fix is officially
in the tree.
thanks,
Karen
On Sep 12, 2013, at 10:59 AM, Peter Levart wrote:
Changeset: 60d6f60416ca
Author:lancea
Date: 2013-09-12 13:20 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60d6f60416ca
8015340: remove erroneous @since tag
Reviewed-by: darcy
! src/share/classes/java/sql/PreparedStatement.java
On Sep 12, 2013, at 11:28 AM, David Chase david.r.ch...@oracle.com wrote:
New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
I think the change is good given that the tests work now. Is your test derived
from the test in the bug report?
And it would
Changeset: be6f5f027bc2
Author:henryjen
Date: 2013-09-06 22:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be6f5f027bc2
8011916: Spec update for java.util.stream
8024339: j.u.s.Stream.reduce(BinaryOperator) throws unexpected NPE
Reviewed-by: mduigou
Contributed-by:
On 2013-09-12, at 1:17 AM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
The optimal constant for double conversion could be 768 ,
the optimal constant for float conversion could be 142,
but I leave this optimization to JDK 9.
It would be helpful to mention in the proof/comment, that 768
On 9/12/13 1:09 AM, Alan Bateman wrote:
On 12/09/2013 01:13, Brent Christian wrote:
Please review my fix to remove the jdk.map.useRandomSeed system
property added earlier in jdk8.
It's good to see this going away, the changes (and clean-up) look good
to me too.
Thanks guys.
Can someone push
Changeset: 5d2d484a1216
Author:emc
Date: 2013-09-12 14:52 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5d2d484a1216
8013846: javac fails to reject semantically equivalent generic method
declarations
Summary: Cause javac to consider intersection types with the same
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:
http://cr.openjdk.java.net/~emc/8020981/
This review is also on
It looks good. I have three requests.
Regarding this comment:
+ * See MethodSupplier.java to see how to produce these bytes.
+ * They encode that class, except that method m is private, not public.
The recipe is incomplete, since it does not say which bits to tweak to make m
private.
Changeset: 917fffe971c8
Author:bpb
Date: 2013-09-11 17:07 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/917fffe971c8
8010430: Math.round has surprising behavior for odd values of ulp 1
Summary: If the effective floating point exponent is zero return the
significand
I know, I checked the census. The Reviewed-by header field can include any
OpenJDK member AFAIK. The approval for pushing is a separate story and has to
be handled via e-mail on the 7u-dev list (and a 7u-dev committer will be needed
eventually).
Thanks,
Brian
On Sep 12, 2013, at 1:57 PM,
On Sep 12, 2013, at 1:00 PM, David Chase wrote:
On 2013-09-12, at 1:17 AM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
The optimal constant for double conversion could be 768 ,
the optimal constant for float conversion could be 142,
but I leave this optimization to JDK 9.
It would be
On 13.09.2013, at 0:49, Brian Burkhalter brian.burkhal...@oracle.com wrote:
I updated the webrev to include a comment for MAX_NDIGITS sans both hyperlink
and the foregoing verbiage:
http://cr.openjdk.java.net/~bpb/8024356/
Thumbs up.
-Aleksey
Changeset: 3ae1814f7c59
Author:vromero
Date: 2013-09-12 22:40 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ae1814f7c59
8023558: Javac creates invalid bootstrap methods for complex lambda/methodref
case
Reviewed-by: jjg
Contributed-by:
No problems :)
It's certainly worth knowing if there will be an issue or not.
-DrD-
Ok, I've tried this out with my app in the sandbox. I can confirm that
opening a file dialog (NSSavePanel underneath), with a directory pointing to
the Container's Documents directory
Careful, I don't think I'm a Reviewer.
I merely had the misfortune to care a whole lot about this stuff once long long
ago.
David
On 2013-09-12, at 4:49 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote:
On Sep 12, 2013, at 1:00 PM, David Chase wrote:
On 2013-09-12, at 1:17 AM, Dmitry
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8019417/webrev.00
The change is to javadoc and unit tests, documenting and testing some corner
cases of JSR 292 APIs.
Since the RI is already correct, there are no implementation code
Do these sibling bugs have numbers?
And I take it you would like to see
1) a test enhanced with ASM to do all 3 variants of this
2) DO attach the underlying cause
David
On 2013-09-12, at 5:35 PM, John Rose john.r.r...@oracle.com wrote:
It looks good. I have three requests.
Regarding this
On Sep 12, 2013, at 4:34 PM, John Rose john.r.r...@oracle.com wrote:
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8019417/webrev.00
The change is to javadoc and unit tests, documenting and testing some corner
cases of JSR 292
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001109/webrev.00/
The change is mostly to javadoc and unit tests, documenting and testing some
corner cases of JSR 292 APIs.
In the RI, the exception-raising code is simplified to throw
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001108/webrev.00
Summary: add an explicit check for leading , upgrade the unit tests
The change is mostly to javadoc and unit tests, documenting and testing some
corner cases of JSR 292
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
Summary: Align MH semantic with bytecode behavior of constructor and static
member accesses, regarding clinit invocation.
The change is to javadoc and unit tests,
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001110/webrev.00/
Summary: promote an existing private method; make unit tests on all argument
positions to arity 10 with mixed types
The change is to javadoc and unit tests, documenting
Should we change conservative constant 1100 to optimal constant 768 ?
My opinion is no (in JDK7), because the constant 1100 has lower cost of
review.
I mean that chances that a reviewer approves 1100 are higher than chances
that [s]he approves 768.
On Fri, Sep 13, 2013 at 12:49 AM, Brian
If that's the only consideration then just use 0x300 instead, which is
easier to read *and* makes more sense anyway, in the context of the test.
On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote:
Should we change conservative constant 1100 to optimal constant 768 ?
My opinion is no (in JDK7),
On Sep 12, 2013, at 5:44 PM, David Chase david.r.ch...@oracle.com wrote:
Do these sibling bugs have numbers?
Yes, 8022701. I just updated the bug to explain their common genesis.
And I take it you would like to see
1) a test enhanced with ASM to do all 3 variants of this
Yes, please.
For me, it is the only consideration.
I'm sure in 768 because I proved it formally using ACL2 tool.
On Fri, Sep 13, 2013 at 7:45 AM, David M. Lloyd david.ll...@redhat.comwrote:
If that's the only consideration then just use 0x300 instead, which is
easier to read *and* makes more sense anyway,
P.S. To see the proposed JSR 292 spec changes only (no code, rendered
javadoc), see:
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/1-specdiff-meth-info-8008688
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/2-specdiff-meth-arity-8019417
64 matches
Mail list logo
