Re: RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows
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 like following:
- java application creates a child java process (no IO inheritance,
redirecting IO through pipes by default),
- child process creates a grandchild which inherits the child's
stdin/out/err,
everything works as expected.
However, if the java app (started from a console) creates an immediate
child that inherits its parent stdin/out/err, it fails.
That's why this bug hasn't been caught by Basic.java before - because it
uses the first testing scenario.
And that's why I had to introduce a new shell script test - because the
problem couldn't be reproduced otherwise.
Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/
http://cr.openjdk.java.net/%7Eigerasim/8023130/1/webrev/
The proposed fix remained the same.
I only created a new shell script that reuses Basic.java functionality.
I also made a minor change to Basic.java to include testing of
ProcessBuilder#redirectXXX(Redirect.INHERIT) method calls.
I manually tested the fixed jdk to check that we haven't reintroduced
4244515 bug with this fix.
As Martin said, unfortunately there is no automated test for windowed
apps behavior.
Sincerely yours,
Ivan Gerasimov
On 26.08.2013 3:31, Martin Buchholz wrote:
Historical notes:
I maintained this code for a while, but I've never been a Windows
guy, and I rarely sat at an actual Windows machine console. I don't
know of any test infrastructure for windowed apps.
On Fri, Aug 23, 2013 at 9:11 AM, Ivan Gerasimov
ivan.gerasi...@oracle.com mailto:ivan.gerasi...@oracle.com wrote:
Thank you Alan!
On 23.08.2013 14:28, Alan Bateman wrote:
On 23/08/2013 04:07, Ivan Gerasimov wrote:
Hello everybody!
The method ProcessBuilder#inheritIO() is reported to not
have any effect on Windows platform.
The same story is with
redirectOutput/Input/Error(Redirect.INHERIT) methods.
As the result, standard in/out/err aren't inherited.
It turn out that the culprit is the CREATE_NO_WINDOW flag
passed to CreateProcessW().
MS doc says about this flag: The process is a console
application that is being run without a console window.
CREATE_NO_WINDOW flag was added with the fix for
http://bugs.sun.com/view_bug.do?bug_id=4244515 to suppress
a console window on a newly created process, when it is
created from a program launched with javaw.exe.
Thus, I left this flag only for cases when the program
doesn't have a console associated with it.
Would you please help review a fix for this problem?
BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8023130
WEBREV:
http://cr.openjdk.java.net/~igerasim/8023130/0/webrev/
http://cr.openjdk.java.net/%7Eigerasim/8023130/0/webrev/
Good sleuthing!
Just so I understand, if we have a console (DOS command window
for example) then will dropping CREATE_NO_WINDOW result in a
new window or not?
No new console for a console application without CREATE_NO_WINDOW
flag.
I used a sample program to confirm that:
---
class InheritIO {
public static void main(String[] args) throws Exception {
int err = new
ProcessBuilder(args).inheritIO().redirectErrorStream(true).start().waitFor();
System.err.println(Exit value: + err);
}
}
---
With the proposed fix running it as ' java InheritIO cmd /?'
copies the output of the command to the existing console.
No new console is created.
One thing that it does highlight is that the coverage for
inherit in ProcessBuilder/Basic.java was not sufficient as
this should have been caught a long time ago. My preference
would be to add to this test rather than introduce a new one
(ProcessBuilder.java is Martin's original mother-of-all tests
for ProcessBuilder).
Yes, I agree. It would be better to integrate this test into
Basic.java.
Sincerely yours,
Ivan
-Alan.
Re: RFR: 8024009 : Remove jdk.map.useRandomSeed system property
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
hg: jdk8/tl/jdk: 8023529: OpenMBeanInfoSupport.equals/hashCode throw NPE
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 ! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java + test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java + test/javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java
Re: RFR: 8024525 - Make Logger log methods call isLoggable()
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 of simply inlining the checks. This should make the life easier for subclasses of Logger which want to control when messages should be logged. The test is a bit obscure but it calls all the methods that have been modified and checks that they log when isLoggable() is true and don't log when isLoggable() is false. The update to Logger looks okay to me. I think the test could benefit from a comment to more fully explain why it checks that isLoggable has been called (as you say, the test is a bit obscure). A minor comment is that levels should probably be in uppercase. Also I assume the commented-out debug message in publish isn't needed. -Alan.
hg: jdk8/tl/jdk: 8024643: Turn on javac lint checking in building the jdk repo
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
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 Nadezhin dmitry.nadez...@gmail.com wrote: When I prepared the patch I didn't try to find the optimal MAX_NDIGITS, but I was sure that MAX_NDIGITS = 1100 is enough. Here is an expanation: 1) If value of decimal string is larger than pow(10,309) then it is converted to positive infinity before the test of nDigits; 2) If value of decimal string is smaller than pow(10,309) and larger than pow(2,53) then it rounds to Java double with ulp = 2. Half-ulp = 1. The patch is correct when decimal ULP of kept digits is 1 or less. It is true beacuse MAX_NDIGITS = 1100 309; 3) If value of decimal string is smaller than pow(2,53) but larger than 0.5*Doulle.MIN_VALUE = pow(2,-1022-52-1), than binary ULP is a multiple of pow(2,-1074). Half-ULP is a multiple of pow(2,-1075). 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 . 4) If value of decimal string is smaller than 0.5*Double.MIN_VALUE then it is converted to zero before the test of nDigits. You can treat replacement of 1075 + 17 by 1100 as my paranoia. It still was interesting for me what is the optimal truncation of decimal string.
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 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 Nadezhin dmitry.nadez...@gmail.com wrote: When I prepared the patch I didn't try to find the optimal MAX_NDIGITS, but I was sure that MAX_NDIGITS = 1100 is enough. Here is an expanation: 1) If value of decimal string is larger than pow(10,309) then it is converted to positive infinity before the test of nDigits; 2) If value of decimal string is smaller than pow(10,309) and larger than pow(2,53) then it rounds to Java double with ulp = 2. Half-ulp = 1. The patch is correct when decimal ULP of kept digits is 1 or less. It is true beacuse MAX_NDIGITS = 1100 309; 3) If value of decimal string is smaller than pow(2,53) but larger than 0.5*Doulle.MIN_VALUE = pow(2,-1022-52-1), than binary ULP is a multiple of pow(2,-1074). Half-ULP is a multiple of pow(2,-1075). 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 . 4) If value of decimal string is smaller than 0.5*Double.MIN_VALUE then it is converted to zero before the test of nDigits. You can treat replacement of 1075 + 17 by 1100 as my paranoia. It still was interesting for me what is the optimal truncation of decimal string.
Re: RFR: 8024525 - Make Logger log methods call isLoggable()
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 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 of simply inlining the checks. This should make the life easier for subclasses of Logger which want to control when messages should be logged. The test is a bit obscure but it calls all the methods that have been modified and checks that they log when isLoggable() is true and don't log when isLoggable() is false. The update to Logger looks okay to me. I think the test could benefit from a comment to more fully explain why it checks that isLoggable has been called (as you say, the test is a bit obscure). A minor comment is that levels should probably be in uppercase. Also I assume the commented-out debug message in publish isn't needed. -Alan.
Re: RFR: 8009411 : getMethods should not inherit static methods from interfaces
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 review cheers /Joel On 2013-09-09, Joel Borggrén-Franck wrote: Hi Pleaser review fix for 8009411 : getMethods should not inherit static methods from interfaces The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). Webrev is based on the clarification to getMethods and friends out for review on this list. Webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.00/ Bug is here: http://bugs.sun.com/view_bug.do?bug_id=8009411 For oracle reviewers, ccc is approved. cheers /Joel
Re: Please review clarification of java.time serialized form
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. 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 marked as transient? Marking as transient will make them disappear from the serialized form. The comments on the individual fields seemed useful to document the data in the stream and they were kept when the writeReplace method documented writing them to the stream.In other cases the writeReplace method refers to the get method that returned the value instead of a field. The byte code numbers for MinguoDate and ThaiBuddhistDate are now out of line as you removed the ERA constants in Ser. How should that be fixed, restore the gaps or re-order? Thanks, Roger Otherwise looks like a good improvement. Stephen On 6 September 2013 20:06, roger riggs roger.ri...@oracle.com wrote: The specification of the serialized-form[1] of the java.time classes has been improved in response to issue 8024164: JSR310 serialization should be described in detail - Add descriptions in the Ser classes of the mapping between the type bytes and corresponding serialized classes. - Add missing specification of the serial data to writeReplace methods - Add missing readResolve methods that prevent deserialization from improperly formatted streams. - The Era that are Enum's do not need customized serialization; remove unused writeReplace, writeExternal, and readExternal methods, remove unused java.time.chrono.Ser type codes for *Eras and renumber. [1]: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/serialized-form.html Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-8024164/ Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/ Please review and comment. Thanks, Roger
Re: RFR: 8024525 - Make Logger log methods call isLoggable()
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 these but it's otherwise okay with me. -Alan
Re: Please review: fix for java.time Issues with French locale on compact1, 2
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. The tests are unnecessary and are removed. Please review: http://cr.openjdk.java.net/~rriggs/webrev-nofrench-8024618/ Thanks, Roger TCK tests can't depend on optional locales so the change looks okay to me. In general however, there are several tests that uses FR and other locales. I wasn't aware that we are testing without localedata.jar being present. I hope not as it would require more yucky lists in TEST.groups. -Alan
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 around)? I expected to see something like The value below is chosen as the conservative threshold. We can demonstrate (link) that decimal ulp should be less than 10^(-1075) to guarantee correctness; we also compensate for binary mantissa which takes 53 binary digits, or 17 decimal ones. Hence, 1075+17 =~ 1100. -Aleksey.
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 12, 2013 at 3:57 PM, David Chase david.r.ch...@oracle.comwrote: 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 Yes, but you are adding them. It is as if you took two lengths, 1075 feet and 17 yards, added them, rounded up, and said that 1100 yards will be adequate (which is entirely true, though perhaps overconservative). Overconservative is okay. 2^-1075 is the binary ulp, give or take a fencepost, not the decimal ulp. David
Re: Please review: fix for java.time Issues with French locale on compact1, 2
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 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 removed. Please review: http://cr.openjdk.java.net/~rriggs/webrev-nofrench-8024618/ Thanks, Roger
Please review: fix for java.time Issues with French locale on compact1, 2
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 removed. Please review: http://cr.openjdk.java.net/~rriggs/webrev-nofrench-8024618/ Thanks, Roger
Review request for 8014967: Clarify NPE thrown by DriverManager.registerDriver when driver is null
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
+++ b/src/share/classes/java/sql/DriverManager.java Thu Sep 12 10:35:48
2013 -0400
@@ -326,6 +326,7 @@
* @param driver the new JDBC Driver that is to be registered with the
* {@code DriverManager}
* @exception SQLException if a database access error occurs
+ * @exception NullPointerException if {@code driver} is null
*/
public static synchronized void registerDriver(java.sql.Driver driver)
throws SQLException {
@@ -345,6 +346,7 @@
* @param da the {@code DriverAction} implementation to be used when
* {@code DriverManager#deregisterDriver} is called
* @exception SQLException if a database access error occurs
+ * @exception NullPointerException if {@code driver} is null
*/
public static synchronized void registerDriver(java.sql.Driver driver,
DriverAction da)
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 just adds the @exception and there is no
behavior change.
Best
Lance
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: Please review clarification of java.time serialized form
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 marked as transient? Marking as transient will make them disappear from the serialized form. The comments on the individual fields seemed useful to document the data in the stream and they were kept when the writeReplace method documented writing them to the stream.In other cases the writeReplace method refers to the get method that returned the value instead of a field. Most consistent would be to always refer to the get method. The comment is useful as is, but sometimes you get a byte in one place and a short in another for example (LocalDate) which might be confusing. The byte code numbers for MinguoDate and ThaiBuddhistDate are now out of line as you removed the ERA constants in Ser. How should that be fixed, restore the gaps or re-order? At this stage, the docs should be updated and the Ser constants kept packed. Stephen
Re: Review request for 8014967: Clarify NPE thrown by DriverManager.registerDriver when driver is null
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 just adds the @exception and there is no behavior change. The changes looks okay to me and just specifying long standing behavior. As it's adding an assertion to the spec then I think it should be tracked. -Alan
static vs. default interface methods and inheritance VM/javac issues
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() {
System.out.println(A.m() called);
}
}
public interface B {
static void m() {
System.out.println(B.m() called);
}
}
public interface C extends A, B {
}
public static void main(String[] args) throws Exception {
C c = new C() {};
c.m();
}
}
...compiles, but gives a runtime error:
Exception in thread main java.lang.AbstractMethodError: Conflicting
default methods: DefaultVsStaticInterfaceMethodTest$A.m
DefaultVsStaticInterfaceMethodTest$B.m
at
DefaultVsStaticInterfaceMethodTest$1.m(DefaultVsStaticInterfaceMethodTest.java)
at
DefaultVsStaticInterfaceMethodTest.main(DefaultVsStaticInterfaceMethodTest.java:28)
A slightly modified program: C extends A, B replaced with C extends
B, A:
http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/DefaultVsStaticInterfaceMethodTest.java
...also compiles, but crashes the VM when run:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7fd4d5020bf9, pid=9964, tid=140552419804928
#
# JRE version: OpenJDK Runtime Environment (8.0) (build
1.8.0-internal-peter_2013_09_12_16_29-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b48 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# j DefaultVsStaticInterfaceMethodTest.main([Ljava/lang/String;)V+9
#
# Failed to write core dump. Core dumps have been disabled. To enable
core dumping, try ulimit -c unlimited before starting Java again
#
# An error report file with more information is saved as:
# /home/peter/work/git/jdk8-tl/out/production/test/hs_err_pid9964.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
Aborted (core dumped)
Here's the hs_err_pid file:
http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/hs_err_pid9964.log
Regards, Peter
Re: Please review: fix for java.time Issues with French locale on compact1, 2
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 needed and still the configurations needed for unit testing would need to be more fine grained. Thanks, Roger On 9/12/2013 10:32 AM, Alan Bateman wrote: 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. The tests are unnecessary and are removed. Please review: http://cr.openjdk.java.net/~rriggs/webrev-nofrench-8024618/ Thanks, Roger TCK tests can't depend on optional locales so the change looks okay to me. In general however, there are several tests that uses FR and other locales. I wasn't aware that we are testing without localedata.jar being present. I hope not as it would require more yucky lists in TEST.groups. -Alan
hg: jdk8/tl/jdk: 8024525: Make Logger log methods call isLoggable()
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 the level checks. Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/isLoggable/TestIsLoggable.java
review request: 8015340: remove erroneous @since tag
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 Sep 12 11:18:13 2013 -0400 @@ -954,7 +954,6 @@ * the JDBC driver does not support this data type * @see Types * - * @since 1.6 */ void setObject(int parameterIndex, Object x, int targetSqlType, int scaleOrLength) throws SQLException; This method dates back to JDBC 1.0. Looks like when the javadocs were updated for JDBC 4.0, the IEC team accidentally added the @since 1.6. Best Lance 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 [8023130] (process) ProcessBuilder#inheritIO does not work on Windows
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 always fail on Windows. If the scenario is like following: - java application creates a child java process (no IO inheritance, redirecting IO through pipes by default), - child process creates a grandchild which inherits the child's stdin/out/err, everything works as expected. However, if the java app (started from a console) creates an immediate child that inherits its parent stdin/out/err, it fails. That's why this bug hasn't been caught by Basic.java before - because it uses the first testing scenario. And that's why I had to introduce a new shell script test - because the problem couldn't be reproduced otherwise. Would you please review the updated webrev? http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ http://cr.openjdk.java.net/%7Eigerasim/8023130/1/webrev/ Based on the previous mails then the update to ProcessImpl_md.c seems right. It's probably best to give this one some bake time in jdk8 before you backport it to jdk7u-dev. The reason is that the Process code likes to bite back when it is changed. On the tests then you probably know we don't like shell tests because they are usually slower and statistically more troublesome. Given the scenario that you are trying to test (and it's useful that you've got to the bottom of the issue) there they may not be other options here. One small concern with the shell test as it stands is that it looks like it is depend on the exact output. This makes me wonder about how it will behave with a debug or fastdebug build that might have additional output. Also a minor point but it might be more readable if the body of the for statement was indented. -Alan.
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 incorrectly if the answer is otherwise equal to EVEN + 1/2 ULP. EVEN + 1/2 ULP rounds to EVEN, EVEN + 1/2 ULP + 1 rounds to EVEN + 1. Whoops, no, you don't do that. But I'd call that another bug, and not one worth getting terribly excited about. Strictly speaking, if your input is decimal_rep_of_half_ulp + a billion zeroes + 1, then the answer is 1 ulp (2^-1074), if the trailing one is missing, then the answer is zero (which is even in the mantissa). David On 2013-09-12, at 10:37 AM, David Chase david.r.ch...@oracle.com wrote: 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 12, 2013 at 3:57 PM, David Chase david.r.ch...@oracle.comwrote: 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 Yes, but you are adding them. It is as if you took two lengths, 1075 feet and 17 yards, added them, rounded up, and said that 1100 yards will be adequate (which is entirely true, though perhaps overconservative). Overconservative is okay. 2^-1075 is the binary ulp, give or take a fencepost, not the decimal ulp. David
Re: review request: 8015340: remove erroneous @since tag
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 Thu Sep 12 01:47:05 2013 -0700 +++ b/src/share/classes/java/sql/PreparedStatement.java Thu Sep 12 11:18:13 2013 -0400 @@ -954,7 +954,6 @@ * the JDBC driver does not support this data type * @see Types * - * @since 1.6 */ void setObject(int parameterIndex, Object x, int targetSqlType, int scaleOrLength) throws SQLException; This method dates back to JDBC 1.0. Looks like when the javadocs were updated for JDBC 4.0, the IEC team accidentally added the @since 1.6. Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/jdk: 8024618: Issues with French locale on compact1, 2: expected:janvier but was:January
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 conformance tests and are redundant with testing of the US Locale above Reviewed-by: alanb ! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 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 incorrectly if the answer is otherwise equal to EVEN + 1/2 ULP. EVEN + 1/2 ULP rounds to EVEN, EVEN + 1/2 ULP + 1 rounds to EVEN + 1. Whoops, no, you don't do that. But I'd call that another bug, and not one worth getting terribly excited about. Strictly speaking, if your input is decimal_rep_of_half_ulp + a billion zeroes + 1, then the answer is 1 ulp (2^-1074), if the trailing one is missing, then the answer is zero (which is even in the mantissa). David On 2013-09-12, at 10:37 AM, David Chase david.r.ch...@oracle.com wrote: 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 12, 2013 at 3:57 PM, David Chase david.r.ch...@oracle.comwrote: 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 Yes, but you are adding them. It is as if you took two lengths, 1075 feet and 17 yards, added them, rounded up, and said that 1100 yards will be adequate (which is entirely true, though perhaps overconservative). Overconservative is okay. 2^-1075 is the binary ulp, give or take a fencepost, not the decimal ulp. David
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
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 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, Christian Thalinger christian.thalin...@oracle.com wrote: + // err.initCause(ex); Why is this commented? -- Chris
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 correctness. because decimal ulp may be larger than 10^(-1075) for some inputs. For example, for decimal string 1. binary half-ulp is 2^(-53) and decimal ulp 10^(-53) is enough . On Thu, Sep 12, 2013 at 6:32 PM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: 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 around)? I expected to see something like The value below is chosen as the conservative threshold. We can demonstrate (link) that decimal ulp should be less than 10^(-1075) to guarantee correctness; we also compensate for binary mantissa which takes 53 binary digits, or 17 decimal ones. Hence, 1075+17 =~ 1100. -Aleksey.
Re: RFR: 8014659: NPG: performance counters for compressed klass space
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 added the output of the compressed class space performance counters next to the metaspace output. I've also updated the jstat and jstatd tests to take the new output into account. Webrev: http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/ Testing: - jdk/test/sun/tools/jstat - jdk/test/sun/tools/jstatd Thanks, Erik [0]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 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 correctness === We can demonstrate (link) that decimal ulp less than 10^(-1075) is enough to guarantee correctness. because decimal ulp may be larger than 10^(-1075) for some inputs. For example, for decimal string 1. binary half-ulp is 2^(-53) and decimal ulp 10^(-53) is enough .
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
+ // 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 thrown in call of methodhandle to private method fix: detect special case of IllegalAccessException, convert to IllegalAccessError testing: verified that the test would pass with modified library verified that the test would fail with old library verified that the test would fail if the class substitution (for some reason) did not occur jtreg of jdk/test/java/lang/invoke -- note that the new exception thrown is a subtype of the old one, so this is unlikely to create a new surprise ___ mlvm-dev mailing list mlvm-...@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
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, Christian Thalinger christian.thalin...@oracle.com wrote: + // 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 thrown in call of methodhandle to private method fix: detect special case of IllegalAccessException, convert to IllegalAccessError testing: verified that the test would pass with modified library verified that the test would fail with old library verified that the test would fail if the class substitution (for some reason) did not occur jtreg of jdk/test/java/lang/invoke -- note that the new exception thrown is a subtype of the old one, so this is unlikely to create a new surprise ___ mlvm-dev mailing list mlvm-...@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 correctness === We can demonstrate (link) that decimal ulp less than 10^(-1075) is enough to guarantee correctness. because decimal ulp may be larger than 10^(-1075) for some inputs. For example, for decimal string 1. binary half-ulp is 2^(-53) and decimal ulp 10^(-53) is enough .
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
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 the wrong one. The new test checks the exception in both the reflective-invocation and plain-invocation cases, and also checks both a method handle call (which threw the wrong exception) and a plain call (which threw, and throws, the right exception). The test also uses a tweaked classloader to substitute the borked bytecodes necessary to get the error, so it is not only shell-free, it can also be run outside jtreg. On 2013-09-12, at 2:34 PM, Christian Thalinger christian.thalin...@oracle.com wrote: 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 be good if John could also have a quick look (just be to be sure). -- Chris 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 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, Christian Thalinger christian.thalin...@oracle.com wrote: + // err.initCause(ex); Why is this commented? -- Chris
Re: static vs. default interface methods and inheritance VM/javac issues
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:
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() {
System.out.println(A.m() called);
}
}
public interface B {
static void m() {
System.out.println(B.m() called);
}
}
public interface C extends A, B {
}
public static void main(String[] args) throws Exception {
C c = new C() {};
c.m();
}
}
...compiles, but gives a runtime error:
Exception in thread main java.lang.AbstractMethodError: Conflicting default
methods: DefaultVsStaticInterfaceMethodTest$A.m
DefaultVsStaticInterfaceMethodTest$B.m
at
DefaultVsStaticInterfaceMethodTest$1.m(DefaultVsStaticInterfaceMethodTest.java)
at
DefaultVsStaticInterfaceMethodTest.main(DefaultVsStaticInterfaceMethodTest.java:28)
A slightly modified program: C extends A, B replaced with C extends B, A:
http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/DefaultVsStaticInterfaceMethodTest.java
...also compiles, but crashes the VM when run:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7fd4d5020bf9, pid=9964, tid=140552419804928
#
# JRE version: OpenJDK Runtime Environment (8.0) (build
1.8.0-internal-peter_2013_09_12_16_29-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b48 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# j DefaultVsStaticInterfaceMethodTest.main([Ljava/lang/String;)V+9
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try ulimit -c unlimited before starting Java again
#
# An error report file with more information is saved as:
# /home/peter/work/git/jdk8-tl/out/production/test/hs_err_pid9964.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
Aborted (core dumped)
Here's the hs_err_pid file:
http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/hs_err_pid9964.log
Regards, Peter
hg: jdk8/tl/jdk: 8015340: remove erroneous @since tag
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
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
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 be good if John could also have a quick look (just be to be sure). -- Chris 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 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, Christian Thalinger christian.thalin...@oracle.com wrote: + // err.initCause(ex); Why is this commented? -- Chris
hg: jdk8/tl/jdk: 8011916: Spec update for java.util.stream; ...
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: brian.go...@oracle.com ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/function/package-info.java ! src/share/classes/java/util/stream/BaseStream.java ! src/share/classes/java/util/stream/Collector.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/package-info.java
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 refers to the decimal representation that has had leading zeroes between decimal point and mantissa trimmed. An exact case is the decimal representation of the sum of 2^-1022 + 2^-1075 This has a decimal point, then 307 zeroes, non-zeroes at 308 (2) and 1075 (5) (and usually non-zeroes between) for a span of 768 decimal digits between the leading and trailing zeroes. (There are other screw cases. Here, 2^-1022 is the minimum normalized-rep double, and 2^-1075 is 1/2 ulp for doubles with binary exponent -1022, which is represented as 1 in IEEE format.) Appending any trailing non-zero on this decimal representation rounds up; nothing trailing rounds down. If the final digit 5 is instead a 6, it always rounds up, if it is a 4 it always rounds down no matter what is appended. There are other screw cases, but they always involve 2^-1075 because that requires the maximum number of decimal digits for its representation. David
Re: RFR: 8024009 : Remove jdk.map.useRandomSeed system property
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 this for me? I can send you a changeset... -Brent
hg: jdk8/tl/langtools: 8013846: javac fails to reject semantically equivalent generic method declarations
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 elements to be equal regardless of order. Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/neg/OrderedIntersections.java + test/tools/javac/generics/neg/OrderedIntersections.out
JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions
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 crucible. The ID is CR-JDK8TL-182. Thanks, Eric
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
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. Please add that step to the comments more explicitly, or if possible
to the code (so bogusMethodSupplier is a clean copy of the od output). I
suppose you could ask sed to change the byte for you. That will make this test
a better example for future tests, and make it easier to maintain if javac
output changes. The high road to use would be asm, although for a single byte
tweak od works OK.
Also, this bug has two twins. The same thing will happen with NoSuchMethodE*
and NoSuchFieldE*. Can you please make fixes for those guys also?
FTR, see MemberName.makeAccessException() for logic which maps the other way,
from *Error to *Exception. I don't see a direct way to avoid the double
mapping (Error=Exception=Error) when it occurs.
For the initCause bit we should do this:
} catch (IllegalAccessException ex) {
Error err = new IllegalAccessError(ex.getMessage());
err.initCause(ex.getCause()); // reuse underlying cause of ex
throw err;
} ... and for NSME and NSFE...
That way users can avoid the duplicate exception but can see any underlying
causes that the JVM may include.
Thanks for untangling this!
— John
On Sep 12, 2013, at 12:17 PM, David Chase david.r.ch...@oracle.com wrote:
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 the wrong one.
The new test checks the exception in both the reflective-invocation and
plain-invocation cases,
and also checks both a method handle call (which threw the wrong exception)
and a plain
call (which threw, and throws, the right exception).
The test also uses a tweaked classloader to substitute the borked bytecodes
necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.
On 2013-09-12, at 2:34 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
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 be good if John could also have a quick look (just be to be
sure).
-- Chris
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 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, Christian Thalinger
christian.thalin...@oracle.com wrote:
+ // err.initCause(ex);
Why is this commented?
-- Chris
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: jdk8/tl/jdk: 8010430: Math.round has surprising behavior for odd values of ulp 1
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 including the implicit 1-bit. Reviewed-by: bpb, darcy, gls Contributed-by: Dmitry Nadezhin dmitry.nadez...@oracle.com ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! test/java/lang/Math/RoundTests.java
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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, David Chase wrote: 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.
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 helpful to mention in the proof/comment, that 768 refers to the decimal representation that has had leading zeroes between decimal point and mantissa trimmed. 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/ If there is any more tweaking of comments which needs to be effected prior to an approval request being posted to 7u-dev, please let me know. Thanks, Brian
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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
hg: jdk8/tl/langtools: 8023558: Javac creates invalid bootstrap methods for complex lambda/methodref case
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: maurizio.cimadam...@oracle.com, vicente.rom...@oracle.com ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/lambda/8023558/T8023558a.java + test/tools/javac/lambda/8023558/T8023558b.java + test/tools/javac/lambda/8023558/T8023558c.java
Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]
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 (/Users/nick/Library/Containers/my.app/Data/Documents), will show the standard Mac file selection dialog with the standard ~/Documents directory selected. If you then select a file there, say 'selected-file.txt', click OK, the dialog will return the path ~/Documents/selected-file.txt. Since I have the com.apple.security.files.user-selected.read-write entitlement in my application, I can subsequently write to this path, and the file is written in ~/Documents/selected-file.txt, not in the Container's Documents directory. So this clears up my questions about this patch. Thanks for helping me through it. Cheers, Nick On Thu, Sep 12, 2013 at 12:11 AM, David DeHaven david.deha...@oracle.com wrote: The bottom line is, if what you have now allows you to write to ~/Documents and you're sandboxed then this change should not affect your application at all, except maybe in the UI if you're displaying that path to the user. The user won't notice the difference otherwise. My users *will* notice because I display this path in the export dialog, along with the other export options they can use. If the path displayed is coming from the selected file, then it will continue to show the correct path. I don't think I was clear on that comment... if you're building the path from say System.getProperty(user.home) + /Documents/blah and showing it to the user, then that's a problem. If you're showing paths returned by the open/save panels then you're fine, the user will never see the container path. -DrD-
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 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 refers to the decimal representation that has had leading zeroes between decimal point and mantissa trimmed. 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/ If there is any more tweaking of comments which needs to be effected prior to an approval request being posted to 7u-dev, please let me know. Thanks, Brian
RFR (S) 8019417: JSR 292 javadoc should clarify method handle arity limits
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 changes. Thanks, — John
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
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 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. Please add that step to the comments more explicitly, or if
possible to the code (so bogusMethodSupplier is a clean copy of the od
output). I suppose you could ask sed to change the byte for you. That will
make this test a better example for future tests, and make it easier to
maintain if javac output changes. The high road to use would be asm,
although for a single byte tweak od works OK.
Also, this bug has two twins. The same thing will happen with NoSuchMethodE*
and NoSuchFieldE*. Can you please make fixes for those guys also?
FTR, see MemberName.makeAccessException() for logic which maps the other way,
from *Error to *Exception. I don't see a direct way to avoid the double
mapping (Error=Exception=Error) when it occurs.
For the initCause bit we should do this:
} catch (IllegalAccessException ex) {
Error err = new IllegalAccessError(ex.getMessage());
err.initCause(ex.getCause()); // reuse underlying cause of ex
throw err;
} ... and for NSME and NSFE...
That way users can avoid the duplicate exception but can see any underlying
causes that the JVM may include.
Thanks for untangling this!
— John
On Sep 12, 2013, at 12:17 PM, David Chase david.r.ch...@oracle.com wrote:
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 the wrong one.
The new test checks the exception in both the reflective-invocation and
plain-invocation cases,
and also checks both a method handle call (which threw the wrong exception)
and a plain
call (which threw, and throws, the right exception).
The test also uses a tweaked classloader to substitute the borked bytecodes
necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.
On 2013-09-12, at 2:34 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
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 be good if John could also have a quick look (just be to be
sure).
-- Chris
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 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, Christian Thalinger
christian.thalin...@oracle.com wrote:
+ // err.initCause(ex);
Why is this commented?
-- Chris
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (S) 8019417: JSR 292 javadoc should clarify method handle arity limits
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 APIs. Since the RI is already correct, there are no implementation code changes. This looks good. The only thing that sounds odd is very large arity: + * a href=MethodHandle.html#maxarityvery large arity/a, -- Chris Thanks, — John ___ mlvm-dev mailing list mlvm-...@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
RFR (S) 8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException
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 just IAE. Thanks, — John
RFR (S) 8001108: an attempt to use init as a method name should elicit NoSuchMethodException
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 APIs. In the RI, there is an explicit error check. Thanks, — John P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev. Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
RFR (S) 8024599: JSR 292 direct method handles need to respect initialization rules for static members
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, documenting and testing some corner cases of JSR 292 APIs. Bug Description: When using lookupStatic to create a direct method handle for a static method, class initialization needs to be specified to align with the underly bytecode behavior of the invokestatic instruction. The JDK8 and 7u40 implementations do this, but the specification claims that the call to lookupStatic itself performs class initialization. Although this may have been the behavior of early versions of JDK 7, it is an error. Detail: The javadoc headers to Lookup and MethodHandle state that method handles emulate bytecode behaviors. The most precise specification of this emulation is in the JVMS, 5.4.3.5: Calling this method handle on a valid set of arguments has exactly the same effect and returns the same result (if any) as the corresponding bytecode behavior. Also the doc for the invokevirtual instruction says: ...if the method handle to be invoked has bytecode behavior, the Java Virtual Machine invokes the method handle as if by execution of the bytecode behavior associated with the method handle's kind. And the doc for the invokestatic instruction describes the placement of the lazy class initialization: On successful resolution of the method, the class that declared the resolved method is initialized (§5.5) if that class has not already been initialized. This puts the class initialization action near the border between resolution (link time) and execution (run time). The JDK 7 behavior acts as if the initialization action were part of resolution (link time), in that it claims to perform class initialization before the method handle is returned from findStatic (etc.). But on a closer reading of the JVMS, that is wrong. Note that errors (and presumably side effects) from class initialization are classified as runtime effects, not linktime effects: Run-time Exceptions Otherwise, if execution of this invokestatic instruction causes initialization of the referenced class, invokestatic may throw an Error as detailed in §5.5. In other words, the original JDK 7 specification of eager initalization poorly aligns with (poorly emulates) the bytecode behavior, contrary to the overall pronouncements of the JSR 292 specification. Compatibility risk for better alignment is small, since most users of JSR 292 create method handles lazily during BSM (i.e., invokedynamic bootstrap method) execution. It will not matter to them (except to reduce surprise due to semantic mislignment) if the initialization action is moved from the BSM to the first execution of the MH produced by the BSM. It appears that the at least one other implementation, the JSR 292 Backport, performs static member class initialization on first execution of bytecode behavior, because it uses reflection and weaving of *static instructions. This is no accident: The coherence and usefulness of JSR 292 relies on close alignment of member access semantics among the various modes, direct bytecode execution and various old and new reflective APIs. Besides spec. coherence, a key problem with the eager class initialization (in findStatic) is usability. Eager class initialization is impossible to undo. It is also difficult to predict and avoid. Users who want it and don't have it can call Class.forName with an argument of 'true'. Users who don't want it and get it (in early JDK 7 and perhaps other systems) are out of luck. Thanks, — John P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev. Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
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 and testing some corner
cases of JSR 292 APIs.
Bug Description: Currently, a method handle can be transformed so that
multiple arguments are collected and passed to the original method handle.
However, the two routes to doing this are both limited to special purposes.
(They are asCollector, which collects only trailing arguments, and only into an
array; and foldArguments, which collects only leading arguments into filter
function, and passes both the filtered result *and* the original arguments to
the original.)
MethodHandles.collectArguments(mh, pos, collector) should produce a method
handle which acts like lambda(a*, b*, c*) { x = collector(b*); return mh(a*, x,
c*) }, where the span of arguments b* is located by pos and the arity of the
collector.
There is internal machinery in any JSR 292 implementation to do this. It should
be made available to users.
This is a missing part of the JSR 292 spec.
Thanks,
— John
P.S. Since this is a change which oriented toward JSR 292 functionality, the
review request is to mlvm-dev and core-libs-dev.
Changes which are oriented toward performance will go to mlvm-dev and
hotspot-compiler-dev.
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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 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 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 refers to the decimal representation that has had leading zeroes between decimal point and mantissa trimmed. 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/ If there is any more tweaking of comments which needs to be effected prior to an approval request being posted to 7u-dev, please let me know. Thanks, Brian
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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), 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 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 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 refers to the decimal representation that has had leading zeroes between decimal point and mantissa trimmed. 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/ If there is any more tweaking of comments which needs to be effected prior to an approval request being posted to 7u-dev, please let me know. Thanks, Brian -- - DML
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
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. The case of no such field does not have a direct cause from
lambda expressions AFAIK, but it can occur with raw CONSTANT_MethodHandles.
(It would be reasonable for javac to emit CONSTANT_MH's for fields in some very
limited circumstances, but I'll bet it doesn't.)
2) DO attach the underlying cause
Yes. Read the javadoc for ExceptionInInitializerError for an example of why
users want the underlying cause for linkage errors.
(Golly, I wonder what happens if resolution of a CONSTANT_MethodHandle tries to
touch a class with a booby-trapped clinit. I hope it's the case that the
ExceptionInInitializerError just passes straight up the stack. But if it were
to get wrapped in a ROE of some sort, it would probably bubble up as an IAE.
Could be a charming exploration. Actually, no, I don't want to go in there.
Getting all possible linkage errors correct is fine, but we have more important
things to do.)
— John
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 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. Please add that step to the comments more explicitly, or if
possible to the code (so bogusMethodSupplier is a clean copy of the od
output). I suppose you could ask sed to change the byte for you. That will
make this test a better example for future tests, and make it easier to
maintain if javac output changes. The high road to use would be asm,
although for a single byte tweak od works OK.
Also, this bug has two twins. The same thing will happen with
NoSuchMethodE* and NoSuchFieldE*. Can you please make fixes for those guys
also?
FTR, see MemberName.makeAccessException() for logic which maps the other
way, from *Error to *Exception. I don't see a direct way to avoid the
double mapping (Error=Exception=Error) when it occurs.
For the initCause bit we should do this:
} catch (IllegalAccessException ex) {
Error err = new IllegalAccessError(ex.getMessage());
err.initCause(ex.getCause()); // reuse underlying cause of ex
throw err;
} ... and for NSME and NSFE...
That way users can avoid the duplicate exception but can see any underlying
causes that the JVM may include.
Thanks for untangling this!
— John
On Sep 12, 2013, at 12:17 PM, David Chase david.r.ch...@oracle.com wrote:
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 the wrong one.
The new test checks the exception in both the reflective-invocation and
plain-invocation cases,
and also checks both a method handle call (which threw the wrong exception)
and a plain
call (which threw, and throws, the right exception).
The test also uses a tweaked classloader to substitute the borked bytecodes
necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.
On 2013-09-12, at 2:34 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
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 be good if John could also have a quick look (just be to be
sure).
-- Chris
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 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, Christian Thalinger
christian.thalin...@oracle.com wrote:
+ // err.initCause(ex);
Why is this commented?
-- Chris
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
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, 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), 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 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 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 refers to the decimal representation that has had leading zeroes between decimal point and mantissa trimmed. 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/http://cr.openjdk.java.net/~bpb/8024356/ If there is any more tweaking of comments which needs to be effected prior to an approval request being posted to 7u-dev, please let me know. Thanks, Brian -- - DML
additional JSR 292 review resources
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 http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/3-specdiff-meth-spr-8001109 http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/4-specdiff-meth-nsme-8001108 http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/5-specdiff-meth-clinit-8024599 http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/6-specdiff-meth-coll-8001110 http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/7-specdiff-meth-mr-8024438 (The code changes for the last one, 8024438, are not yet ready to review.)
