Re: RFR: [XS, doc] JDK-8225077: fix references to broken link in java.compiler module

[Joseph D. Darcy]

+1

Thanks Jon,

-Joe

On 5/30/2019 1:32 PM, Jonathan Gibbons wrote:
Please review a one line change to fix a 404 link in 
javax/annotation/processing/Filer.java

With this fix, DocCheck finds no errors in the java.compiler module.

JBS: https://bugs.openjdk.java.net/browse/JDK-8225077

-- Jon


Patch inline:

$ hg diff -R open
diff -r a0d4e61acb6b 
src/java.compiler/share/classes/javax/annotation/processing/Filer.java
--- 
a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
Thu May 30 12:45:02 2019 -0700
+++ 
b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
Thu May 30 13:27:15 2019 -0700

@@ -60,7 +60,7 @@
  * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path
  * segments.  A valid relative name must match the
  * "path-rootless" rule of http://www.ietf.org/html/rfc3986.txt";>RFC 3986, section
+ * href="http://www.ietf.org/rfc/rfc3986.txt";>RFC 3986, section
  * 3.3.
  *
  * The file creation methods take a variable number of arguments to

Re: RFR: XS,docs JDK-8225314 broken links in java.base

[Joseph D. Darcy]

Looks good; thanks Jon,

-Joe

On 6/4/2019 3:28 PM, Jonathan Gibbons wrote:

Please review a small fix for a couple of broken links in java.base.

Both look like the same copy/paste error, trying to refer to a target 
id in another package.


No webrev: patch below.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8225314


$ hg diff -R open
diff -r 64fe51ee940e src/java.base/share/classes/java/lang/Enum.java
--- a/src/java.base/share/classes/java/lang/Enum.java   Tue Jun 04 
14:47:25 2019 -0700
+++ b/src/java.base/share/classes/java/lang/Enum.java   Tue Jun 04 
15:17:48 2019 -0700

@@ -283,7 +283,7 @@
 }

 /**
- * A nominal 
descriptor for an
+ * A href="{@docRoot}/java.base/java/lang/constant/package-summary.html#nominal">nominal 
descriptor for an

  * {@code enum} constant.
  *
  * @param  the type of the enum constant
diff -r 64fe51ee940e 
src/java.base/share/classes/java/lang/invoke/VarHandle.java
--- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java Tue 
Jun 04 14:47:25 2019 -0700
+++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java Tue 
Jun 04 15:17:48 2019 -0700

@@ -2118,7 +2118,7 @@
 }

 /**
- * A nominal 
descriptor for a
+ * A href="{@docRoot}/java.base/java/lang/constant/package-summary.html#nominal">nominal 
descriptor for a

  * {@link VarHandle} constant.
  *
  * @since 12

Re: RFR(xs): 8225315 test java/util/ArrayDeque/WhiteBox.java isn't part of the jdk_collections test group

[Joseph D. Darcy]

Looks okay.

Should the test be removed from the catch-all group as part of this change?

-Joe

On 6/4/2019 5:53 PM, Stuart Marks wrote:

Hi all,

This test was added some time ago, but it wasn't added to the 
jdk_collections test group. Please review the patch appended below, 
which adds it to the right group. (The test was still run as part of 
the catch-all jdk_util_other group though.)


Bug link: https://bugs.openjdk.java.net/browse/JDK-8225315

s'marks


diff -r ef23ea332077 test/jdk/TEST.groups
--- a/test/jdk/TEST.groupsTue Jun 04 11:55:51 2019 -0700
+++ b/test/jdk/TEST.groupsTue Jun 04 17:52:11 2019 -0700
@@ -137,6 +137,7 @@
 java/util/AbstractList \
 java/util/AbstractMap \
 java/util/AbstractSequentialList \
+java/util/ArrayDeque \
 java/util/ArrayList \
 java/util/Arrays \
 java/util/BitSet \

Re: RFR (XS) 8224716 : Javadoc of Int/Long/DoubleSummaryStatistics should mention possible overflow of count

[Joseph D. Darcy]

Hello,

Please file a CSR for this change; thanks,

-Joe

On 6/25/2019 11:30 AM, Brent Christian wrote:
I was musing about this myself.  If the changes are within the 
@implNote(s), then perhaps not?


-Brent

On 6/25/19 11:15 AM, Brian Burkhalter wrote:
>

Is a CSR in order?

Thanks,

Brian

On Jun 25, 2019, at 5:49 AM, Ivan Gerasimov 
 wrote:


Hello!

Would someone volunteer to review this extra-small doc-only fix?

Thanks in advance!

With kind regards,
Ivan


On 5/29/19 2:39 PM, Ivan Gerasimov wrote:

Hello!

In the implNote section of the javadoc for xxxSummaryStatistics 
classes it is mentioned that the sum is not checked for overflow.
It would be more accurate to add that neither does the 
implementation check the count for overflow.


Would you please help review this doc-only change?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224716
WEBREV: http://cr.openjdk.java.net/~igerasim/8224716/00/webrev/



--
With kind regards,
Ivan Gerasimov

Re: How can I trigger a @Serial warning?

[Joseph D. Darcy]

Hi Cay,

The enhancements to javac's serial lint checking have not been 
implemented as of yet. For now, @Serial is just documentation.


HTH,

-Joe

On 9/8/2021 10:43 PM, Cay Horstmann wrote:
I am trying to give an example of the utility of the @Serial 
annotation. But the JDK 17 javac doesn't seem to do anything with it. 
I tried:


@Serial private void readObject(java.io.ObjectInputStream stream, int 
shouldNotHaveThisParam) throws IOException, ClassNotFoundException

@Serial private static final String serialVersionUID = "Fred";
@Serial public String getName() { ... }

Is there some flag that I need to use? I tried -Xlint:serial, but it 
didn't make a difference.


Thanks,

Cay

Re: Confusing javadoc on a method java.lang.StringBuilder#readObject

[Joseph D. Darcy]

On 9/8/2021 1:28 PM, Andrey Turbanov wrote:

Hello.
I found a confusing javadoc of the method java.lang.StringBuilder#readObject:

"readObject is called to restore the state of the StringBuffer from a stream."

I believe there should be "StringBuilder" instead of "StringBuffer".


Agreed; filed

    JDK-8274031: Typo in StringBuilder.readObject

Thanks,

-Joe

Re: RFR: 8231640: (prop) Canonical property storage [v21]

[Joseph D. Darcy]

Hello Jaikiran,

The CSR is in Draft state. As discussed in the CSR wiki 
(https://wiki.openjdk.java.net/display/csr/Main), the request needs to 
be moved by the assignee to either Finalized or Proposed state to 
request the CSR review the request.


HTH,

-Joe

On 9/20/2021 8:46 PM, Jaikiran Pai wrote:

On Sat, 18 Sep 2021 03:52:17 GMT, Jaikiran Pai  wrote:


The commit in this PR implements the proposal for enhancement that was 
discussed in the core-libs-dev mailing list recently[1], for 
https://bugs.openjdk.java.net/browse/JDK-8231640

At a high level - the `store()` APIs in `Properties` have been modified to now look for 
the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then 
instead of writing out the current date time as a date comment, the `store()` APIs 
instead will use the value set for this env variable to parse it to a `Date` and write 
out the string form of such a date. The implementation here uses the `d MMM  HH:mm:ss 
'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should 
provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, 
intentionally, no changes in the date format of the "current date" have been 
done.

These  modified `store()` APIs work in the presence of the `SecurityManager` too. The 
caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment 
variable. If the caller doesn't have that permission, then the implementation of these 
`store()` APIs will write out the "current date" and will ignore any value that 
has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward 
compatibility of existing applications, where, when they run under a `SecurityManager` 
and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` 
shouldn't impact their calls to the `store()` APIs.

The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that  
cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the 
"current date" and ignore the value set for this environment variable. No 
exceptions will be thrown for such invalid values. This is an additional backward 
compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking 
applications.

An additional change in the implementation of these `store()` APIs and 
unrelated to the date comment, is that these APIs will now write out the 
property keys in a deterministic order. The keys will be written out in the 
natural ordering as specified by `java.lang.String#compareTo()` API.

The combination of the ordering of the property keys when written out and the 
usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment 
should together allow for reproducibility of the output generated by these 
`store()` APIs.

New jtreg test classes have been introduced to verify these changes. The 
primary focus of `PropertiesStoreTest` is the ordering aspects of the property 
keys that are written out. On the other hand `StoreReproducibilityTest` focuses 
on the reproducibility of the output generated by these APIs.  The 
`StoreReproducibilityTest` runs these tests both in the presence and absence of 
`SecurityManager`. Plus, in the presence of SecurityManager, it tests both the 
scenarios where the caller is granted the requisite permission and in other 
case not granted that permission.

These new tests and existing tests under `test/jdk/java/util/Properties/` pass 
with these changes.

[1] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html
[2] https://reproducible-builds.org/specs/source-date-epoch/

Jaikiran Pai has updated the pull request incrementally with one additional 
commit since the last revision:

   Roger's suggestion to reword the implSpec text

What would be the next step to move the CSR forward? Should I be changing it's 
status or do something else?

-

PR: https://git.openjdk.java.net/jdk/pull/5372

Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

[Joseph D. Darcy]

On 9/22/2021 4:53 PM, Claes Redestad wrote:

On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов 
 wrote:


Currently the method is implemented like

public List> parameterList() {
   return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
}

This seems to be excessive, as three objects are allocated here. Instead we can 
use `List.of(ptypes)` which doesn't allocate anything for empty array and for 
one of length 1 and 2 it allocates lightweight objects with 2 fields, still 
copying longer arrays. This is likely to be fruitful as most of methods have 
0-2 parameters.

Also there is a couple of cases when `MethodType.parameterLis()` is called to 
get its size, which is excessive either as we can use 
`MethodType.parameterCount()` instead.

I think it's OK and even expected to file a CSRs retroactively when you realize 
post integration that there's a behavior change. I recall doing so at least 
once in the past.


This scenario is discussed in the CSR FAQ:


Q: Timing wise, when do I need to file a CSR request?
A: A CSR request needs to be filed and approved /before/ the 
corresponding change is pushed to a JDK release line of development. 
In exceptional circumstances, the need for a CSR review may be 
recognized only after a push has already occurred. In such cases, a 
retroactive CSR review can be conducted. The results of such a 
retroactive review may require updates to the change, up to and 
including complete removal of the change.

https://wiki.openjdk.java.net/display/csr/CSR+FAQs

For the change in question, are there any interactions with class file 
redefinition effects?


-Joe

Re: SourceVersion::feature

[Joseph D. Darcy]

On 10/14/2021 10:23 AM, Michael Bien wrote:

is this the right mailing list for javax.lang.model.* discussions?



The compiler-dev list would be appropriate as well, but core-libs will work.

First, I understand the desire for a method like this. One of the 
potential issues is SourceVersion models language versions and while, to 
date, there has been a simple linear progression, that is not guaranteed 
to be case arbitrarily far into the future, even though it is the most 
likely outcome.


Since java.lang.Runtime.Version is in the platform now, I think this 
request would be better satisfied via a


    public static SourceVersion valueOf(Runtime.Version version)

method on SourceVersion. That way the modeling of SourceVersion can 
absorb any non-linearity in versioning and presumably provide sufficient 
information for a  Runtime.Version -> SourceVersion mapping to query.


I've filed the RFE

    JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion

Cheers,

-Joe




if yes:

instead of adding
    /**
 * Returns the version as int representing the feature release.
 * @see Runtime.Version#feature()
 */
    public int feature() {
    return this.ordinal();
    }
to SourceVersion.

a note could be added to the doc that the ordinal can be used as 
feature version. Since this statement would apply to the past too, the 
note could be backported to all maintained JDKs. This comes with the 
usual downside of not being able to add enums for in-between versions 
in future.


(doing both would be an option too of course)


To not use the ordinal, client code has to go through some enum init 
rituals to be able to do version comparisons:


   final static SOURCE_VERSION_RELEASE_18;
   static {
SourceVersion tmp18;
    try {
    tmp18 = SourceVersion.valueOf("RELEASE_18");
    } catch (IllegalArgumentException ex) {
tmp18 = null;
    }
    SOURCE_VERSION_RELEASE_18 = tmp18;
    //... more versions
   }
just to be able to

    if (SOURCE_VERSION_RELEASE_18 != null && 
version.compareTo(SOURCE_VERSION_RELEASE_18) >= 0) {}


or

    if 
(Integer.parseInt(version.name().substring(version.name().indexOf('_')+1)) 
>= 18) {}


which is shorter but not a good solution either.

what the client code actually wants is:

    if (SourceVersion.latest().feature() >= 18) {}


it was a wise decision for java.lang.Runtime.Version to not use enums :)

best regards,
michael



On 09.10.21 20:58, Michael Bien wrote:

Hello,

could javax.lang.model.SourceVersion receive a feature() method 
returning the version as an int, analog to java.lang.Runtime.Version?


if (SourceVersion.latest().feature() >= 18) {}

is simpler than comparing enums which may or may not exist dependent 
on the deployed java version and cleaner than ordinal() tricks.


best regards,

michael

Re: SourceVersion::feature

[Joseph D. Darcy]

PS See https://github.com/openjdk/jdk/pull/5973

-Joe

On 10/14/2021 1:53 PM, Joseph D. Darcy wrote:

On 10/14/2021 10:23 AM, Michael Bien wrote:

is this the right mailing list for javax.lang.model.* discussions?



The compiler-dev list would be appropriate as well, but core-libs will 
work.


First, I understand the desire for a method like this. One of the 
potential issues is SourceVersion models language versions and while, 
to date, there has been a simple linear progression, that is not 
guaranteed to be case arbitrarily far into the future, even though it 
is the most likely outcome.


Since java.lang.Runtime.Version is in the platform now, I think this 
request would be better satisfied via a


    public static SourceVersion valueOf(Runtime.Version version)

method on SourceVersion. That way the modeling of SourceVersion can 
absorb any non-linearity in versioning and presumably provide 
sufficient information for a  Runtime.Version -> SourceVersion mapping 
to query.


I've filed the RFE

    JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion

Cheers,

-Joe




if yes:

instead of adding
    /**
 * Returns the version as int representing the feature release.
 * @see Runtime.Version#feature()
 */
    public int feature() {
    return this.ordinal();
    }
to SourceVersion.

a note could be added to the doc that the ordinal can be used as 
feature version. Since this statement would apply to the past too, 
the note could be backported to all maintained JDKs. This comes with 
the usual downside of not being able to add enums for in-between 
versions in future.


(doing both would be an option too of course)


To not use the ordinal, client code has to go through some enum init 
rituals to be able to do version comparisons:


   final static SOURCE_VERSION_RELEASE_18;
   static {
SourceVersion tmp18;
    try {
    tmp18 = SourceVersion.valueOf("RELEASE_18");
    } catch (IllegalArgumentException ex) {
tmp18 = null;
    }
    SOURCE_VERSION_RELEASE_18 = tmp18;
    //... more versions
   }
just to be able to

    if (SOURCE_VERSION_RELEASE_18 != null && 
version.compareTo(SOURCE_VERSION_RELEASE_18) >= 0) {}


or

    if 
(Integer.parseInt(version.name().substring(version.name().indexOf('_')+1)) 
>= 18) {}


which is shorter but not a good solution either.

what the client code actually wants is:

    if (SourceVersion.latest().feature() >= 18) {}


it was a wise decision for java.lang.Runtime.Version to not use enums :)

best regards,
michael



On 09.10.21 20:58, Michael Bien wrote:

Hello,

could javax.lang.model.SourceVersion receive a feature() method 
returning the version as an int, analog to java.lang.Runtime.Version?


if (SourceVersion.latest().feature() >= 18) {}

is simpler than comparing enums which may or may not exist dependent 
on the deployed java version and cleaner than ordinal() tricks.


best regards,

michael

Re: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec

[Joseph D. Darcy]

It is a non-goal to replicate all of the JCK test coverage in the 
regression test suite.


-Joe

On 10/25/2021 7:17 PM, Sergey Bylokhov wrote:

On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов  wrote:


It looks like we cannot use `Long.hashCode(long)` for 
`java.rmi.server.ObjID.hashCode()` due to specification: 
https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode().

I think this one was missed due to the absence of the coverage in the jtreg 
test suite, and some people have no access to the jck to run it in advance.

-

PR: https://git.openjdk.java.net/jdk/pull/5963

Re: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap

[Joseph D. Darcy]

On 12/4/2021 4:31 PM, liach wrote:

On Wed, 24 Nov 2021 05:16:40 GMT, liach  wrote:


Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` 
would throw CME if the functions modified the map itself, and there are 
corresponding specification changes.

Since I don't have an account on the JBS, I will post the CSR markdown draft 
here and hope someone can create one for me.



Created CSR https://bugs.openjdk.java.net/browse/JDK-8278313.

-Joe

Re: RFR: 8279508: Auto-vectorize Math.round API [v2]

[Joseph D. Darcy]

On 2/12/2022 6:55 PM, Jatin Bhateja wrote:

On Fri, 21 Jan 2022 00:49:04 GMT, Sandhya Viswanathan 
 wrote:


The JVM currently initializes the x86 mxcsr to round to nearest even, see below 
in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, 
exceptions masked StubRoutines::x86::_mxcsr_std = 0x1F80; The above works for 
Math.rint which is specified to be round to nearest even. Please see: 
https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
 : section 4.8.4

The rounding mode needed for Math.round is round to positive infinity which 
needs a different x86 mxcsr initialization(0x5F80).

Hi @sviswa7 ,
As per JLS 17 section 15.4 Java follows round to nearest rounding policy for 
all floating point operations except conversion to integer and remainder where 
it uses round toward zero.



That is a true background condition, but I will note that the Math.round 
method does independently define the semantics of its operation and 
rounding behavior, which has changed (slightly) over the lifetime of the 
platform.


-Joe

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v6]

[Joseph D. Darcy]

On 2/17/2022 8:34 AM, Roger Riggs wrote:

On Thu, 17 Feb 2022 01:38:42 GMT, Joe Darcy  wrote:


This is an early review of changes to better model JVM access flags, that is 
"modifiers" like public, protected, etc. but explicitly at a VM level.

Language level modifiers and JVM level access flags are closely related, but 
distinct. There are concepts that overlap in the two domains (public, private, 
etc.), others that only have a language-level modifier (sealed), and still 
others that only have an access flag (synthetic).

The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, 
the bit positions used by access flags on different kinds of elements overlap (such as 
"volatile" for fields and "bridge" for methods. Just having a raw integer does 
not provide sufficient context to decode the corresponding language-level string. Methods like 
Modifier.methodModifiers() were introduced to cope with this situation.

With additional modifiers and flags on the horizon with projects like Valhalla, 
addressing the existent modeling deficiency now ahead of time is reasonable 
before further strain is introduced.

This PR in its current form is meant to give the overall shape of the API. It 
is missing implementations to map from, say, method modifiers to access flags, 
taking into account overlaps in bit positions.

The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once 
the API is further along.

Joe Darcy has updated the pull request with a new target base due to a merge or 
a rebase. The incremental webrev excludes the unrelated changes brought in by 
the merge/rebase. The pull request contains ten additional commits since the 
last revision:

  - Update JVMS references.
  - Merge branch 'master' into JDK-8266670
  - Reorder constants by mask value per review feedback.
  - Merge branch 'master' into JDK-8266670
  - Respond to more review feedback.
  - Respond to review feedback explicitly stating returned sets are immutable.
  - Fix typo from review feedback.
  - Merge branch 'master' into JDK-8266670
  - JDK-8266670: Better modeling of modifiers in core reflection

The jvms also has `access_flags` for parameters.
[4.7.24. The MethodParameters 
Attribute](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.24)


I'll augment/edit the spec describing where the flags come from to 
mention method parameters.




Even if java.lang.reflect.Parameter is not a "Member", it would be useful for 
Parameter to have an `accessFlags()` method and loosen up the spec for AccessFlag to 
allow its use in Parameter.
Its access flags have the same underlying bit patterns and definitions.


An accessFlags method on Parameter has been part of this proposal since 
the first push:


https://openjdk.github.io/cr/?repo=jdk&pr=7445&range=00#udiff-5-src/java.base/share/classes/java/lang/reflect/Parameter.java

-Joe

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath

[Joseph D. Darcy]

Hi Raffaello,

With changing TAU to be set to 2.0 * PI, I'll file a follow-up bug to 
use the least-precision decimal values that will get rounded to PI and 
E, respectively, in Math and StrictMath. (Per the general base 
conversion properties for the double format, there will be between 15 
and 17 decimal digits rather than 21.)


Thanks,

-Joe

On 3/14/2022 2:32 PM, Raffaello Giulietti wrote:

Hello,

I find it a bit disturbing that PI is specified with 21 digits whereas 
TAU has 16.

I think that specifying PI as
    public static final double PI = 3.141592653589793;
doesn't harm anybody and makes it visually more consistent with TAU-


Greetings
Raffaello



On 3/14/22 22:13, Brian Burkhalter wrote:

On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy  wrote:

Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is 
a very common value in mathematical formulas, it is helpful to give 
it a distinct constant.


Please also review the CSR 
https://bugs.openjdk.java.net/browse/JDK-8283136


Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: Java float, double, StrictMath correction?

[Joseph D. Darcy]

On 3/15/2022 6:11 PM, A Z wrote:
[snip]



Raffaello has said:

'Exact representation of 0.1 using base 2 is mathematically impossible,

no matter the language (it is a periodic number in base 2).'


Consideration of the article:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf


Which is admittedly older, but still accurate, indicates otherwise.


As the co-author of the article in question, I am familiar with its contents 
and the article does not question 1/10 being a repeating fraction in binary.

For comments on both the technical floating-point matters raised and style of 
discourse, I refer interested readers to a previous email on core-libs-dev:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051952.html

-Joe

FYI, candidate list of classes to be updated to sealed in JDK-8283414: Update java.base to use sealed classes (umbrella)

[Joseph D. Darcy]

Hello,

With a number of efforts to update various class hierarchies in the JDK 
to sealed classes, I wrote an annotation processor to find candidates to 
be changed to sealed. The candidates for this analysis are non-final 
public classes with at least one package access constructor and no 
public constructors. That is, the candidate class cannot be generally 
subclassable.


Several dozen candidates were identified and listed in JDK-8283414, 
including two cases where changing the classes in question to sealed was 
already out for review (JDK-8282536 and JDK-8283237).


I've created subtasks for a number of other cases in core-libs; the 
cases in security libs could also be reviewed.


-Joe

Re: Java Floating Points.

[Joseph D. Darcy]

In the spirit of repeating previous messages, I again refer interested 
readers to my 2018 email to core-libs-dev which addresses many of the 
technical points being (re)raised here:


http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051952.html

Appeal to authority is a commonly used rhetorical technique. A worse 
variant of appeal to authority is when the work being cited does not in 
fact support the argument being put forward. Case point, the document


    "How Java’s Floating-Point Hurts Everyone Everywhere"
    https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

originally authored by Prof. Kahan and myself in 1998, does not advocate 
decimal-only computation. The word "decimal" appears exactly zero times 
in the July 30, 2004 version of the document (Prof. Kahan often revises 
and reposts his documents).


In brief, the thesis of the "JavaHURT" paper is that the Java platform 
commits sins of omission by requiring IEEE 754 arithmetic while 
forbidding certain mandatory feature of the IEEE 754 standard and by 
precluding support for the 80-bit floating-point format found on 
contemporary x86 processors. Moral conclusions aside, it is correct that 
the Java platform then, as now, does not natively support those 
mandatory features of IEEE 754 (rounding modes, floating-point exception 
handling) for the built-in floating-point types float and double. No 
other widely used and available programming platform I know of supports 
those features either. In the intervening years, the 80-bit format 
originating with the x87 co-processor has been effectively deprecated by 
both Intel and AMD.


While IEEE 754 is commonly thought of as a hardware standard, the 
designers of the standard intended it to provide a programming platform. 
More recent revisions of IEEE 754 have tried to make this intention clearer.


Without researching the exact JDK where SSE support was first included, 
it was would have been at least 15 years ago, probably more.


The SSE instructions do *not* support decimal floating-point 
computation; they are primarily, but not exclusively, about 32-bit and 
64-bit binary floating-point operations:


    https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

The POWER6 chip is one of the few that does have hardware support for 
decimal floating-point, a feature added in the 2008 revision of IEEE 754:


    https://en.wikipedia.org/wiki/Decimal_floating_point

Rather than re-asking core-libs-dev every few days if the the platform 
stewards have suddenly decided to undertake this large, but poorly 
defined effort, I suggest trying you organize like minded parties, 
perhaps including A Z poweruserm at live.com.au, to yourselves build a 
library/environment/platform with the features you envision to 
concretely demonstrate its benefits.


-Joe

On 4/21/2022 11:55 PM, sminervini.prism wrote:

mailto:core-libs-...@openjdk.net
To core-libs, OpenJDK, JCP, and all

For the sake of the consequences of the real issues it raises,
I include the rebuttal to Andrew Haley's earlier comments,
and I reiterate that the real need is to improve the Java software
at its roots level, more so.

Andrew Haley said, and we reply:

1) Firstly, it is not possible to change Java's core floating-point
arithmetic in a compatible way. We certainly will not adopt decimal
floating-point for Java's core arithmetic.

While I don't like re-submitting this article, certainly not on this forum,
there has always been this article:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

The age of this article does not matter. It is as bearing to action in 2022
as it was then.

-Even without recombiling floating point or StrictMath code, of course it could
be changed, and compatibly. Runtime or compile time switches could be 
introduced.
Key words could be introduced that may apply at many different levels. Maybe
even annotations could be used for the compiler, which can already apply at
any point that floating point arithmetic and StrictMath methods and fields
may occur. Whevever there is a code space, there could be an annotation
or a keyword. At the class or interface or static block level. At the
variable, data, field and method level. Even at the main method,
Thread level, Runnable or Future level, or even further.

2) Secondly, Java should not be your focus. We will not change Java's
arithmetic in a way that is incompatible with other languages or
which makes Java slower on existing hardware.

-There could be dual mode floating point correction, implemented inside
Java at any level you could like. Dual mode couldn't be incompatible
with anything.

3) You must read and fully understand this before you go any further. It
will require a lot of study:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html


May the Java Community Process reconsider the present floating point
operations and method calls situation, based on an imperfect
standard and improper workaround, and provide corrected, defaulting

Re: Why does we still need StrictMath?

[Joseph D. Darcy]

On 5/8/2022 4:10 AM, Martin Desruisseaux wrote:

Le 08/05/2022 à 10:56, Andrew Haley a écrit :

Some targets (x86, in particular) have intrinsics (log, trig) that 
are faster than StrictMath and also more accurate. StrictMath is not 
about accuracy, but cross-architecture down-to-the-last bit 
reproducibility. Whether we still need that reproducibility is, I 
suppose, something for debate.


In production code, maybe not. But in test code (e.g. using JUnit), 
when the program does a lot of trigonometric operations (e.g. map 
projections), I have meet cases where a test was successful on a 
machine but failed on another machine. The systematic use of 
StrictMath in all JUnit test code ensure that the difference in 
behavior is not in the test code, so we can focus our debugging effort 
on the main code.


JEP 306 was concerned with changing the definitions of the 
language-level floating-point operations and JVM-level floating-point 
instructions to be consistently strict, the original language and VM 
semantics from the mid-1990's.


The strictfp-ness, or not, of arithmetic operations is a separate matter 
from the semantics of the methods in java.lang.Math and 
java.lang.StrictMath. For example, even when strictfp and default-fp 
were both present, it is was *not* always necessary to declare a method 
in StrictMath to be strictfp (since the difference between strictfp and 
default-fp is only visible when overflow or underflow occurs).


As noted elsewhere in this thread, several platform have faster versions 
of some methods (log, sin, cos, tan, etc.) and in other situations it is 
more expedient to just use the reproducible methods in StrictMath. So to 
meet the reproducibility goals of the platform, StrictMath is still 
needed IMO while Math provides an alternative for users to opt-into 
possible greater speed.


(If Strictmath were being added to the platform today, its specification 
would most likely say the methods need to be correctly rounded, but that 
was less tractable a choice when StrictMath was added in JDK 1.3.)


-Joe

Re: CVF: new Core Libraries Group member: Naoto Sato

[Joseph D. Darcy]

Vote: yes

-joe

On 6/6/2022 5:52 PM, Stuart Marks wrote:
I hereby nominate Naoto Sato [1] to membership in the Core Libraries 
Group [2].


Naoto Sato has been on the Core Libraries team for over a decade and 
has contributed hundreds of changes to the JDK project [3]. His most 
significant recent contribution is JEP 400: UTF-8 by Default [4]. 
Naoto is also lead of the Internationalization Group [5] and a 
Reviewer on the JDK project.


Votes are due by June 20, 2022, 23:59 PDT.

Only current members of the Core Libraries Group [6] are eligible to 
vote on this nomination. Votes must be cast in the open by replying to 
this mailing list, as described here [7]. Results are determined by 
lazy consensus [8].


s'marks


[1] https://openjdk.java.net/census#naoto
[2] https://openjdk.java.net/groups/core-libs/
[3] 
https://github.com/openjdk/jdk/search?q=author-name%3Anaoto&type=commits

[4] https://openjdk.java.net/jeps/400
[5] https://openjdk.java.net/groups/i18n/
[6] https://openjdk.java.net/census#core-libs
[7] https://openjdk.java.net/groups/#member-vote
[8] https://openjdk.java.net/bylaws#lazy-consensus

Re: CFV: new Core Libraries Group member: Roger Riggs

[Joseph D. Darcy]

Vote: yes

-Joe

Re: Request for approval: fix 4428022, System.out.println(0.001) outputs 0.0010

[Joseph D. Darcy]

Alan Bateman wrote:

Andrew Haley wrote:

:
OK, here it is.  I put the test in java/lang/Double/ToString.java
rather than sun/misc/FloatingDecimal because the bug manifested
itself in Double.toString although the fix was in
FloatingDecimal.dtoa.
  
I agree that test/java/lang/Double is the best place for this. All 
looks good to me (except minor nit, "String argv[]" -> "String[] 
args").  Joe, are you okay with this?


-Alan.


Yes; the changes look fine for both releases.

Thanks,

-Joe

Re: Request for approval: fix 4428022, System.out.println(0.001) outputs 0.0010

[Joseph D. Darcy]

Andrew Haley wrote:

Joseph D. Darcy wrote:
  

Alan Bateman wrote:


Andrew Haley wrote:
  

:
OK, here it is.  I put the test in java/lang/Double/ToString.java
rather than sun/misc/FloatingDecimal because the bug manifested
itself in Double.toString although the fix was in
FloatingDecimal.dtoa.
  


I agree that test/java/lang/Double is the best place for this. All
looks good to me (except minor nit, "String argv[]" -> "String[]
args").  Joe, are you okay with this?

-Alan.
  

Yes; the changes look fine for both releases.



To which openjdk7 repo do you want me to push this?
My best guess is jdk7/jdk7-gate/jdk.
  


Please push this through TL (tools and libraries): 
ssh://hg.openjdk.java.net/jdk7/tl-gate/jdk


-Joe

Re: Review request for 6857803 Missing links to exceptions in javadoc for Class.getGeneric{Superclass, Interfaces}

[Joseph D. Darcy]

Christopher Hegarty -Sun Microsystems Ireland wrote:

Hi Joe,

The changes look good, but could I ask you to make the same change to 
the throws param for getTypeParameters. It looks like it has the same 
issue.


Good catch; I'll fix that too.

Thanks,

-Joe



Thanks,
-Chris.

Joe Darcy wrote:

Hello.

Below is a simple patch for JDK 7 to fix a minor javadoc problem in 
java.lang.Clas.  The javadoc for methods getGenericSuperclass and 
getGenericInterfaces make @throws reference to two exceptions in the 
java.lang.reflect package; these exceptions don't get rendered as 
links in the HTML output because they are in a different package.  
The fix is to add the package qualification; importing the exceptions 
would have worked too, but the imports are not needed by the code in 
java.lang.Class.


Thanks,

-Joe

--- old/src/share/classes/java/lang/Class.java2009-07-06 
21:31:15.0 -0700
+++ new/src/share/classes/java/lang/Class.java2009-07-06 
21:31:15.0 -0700

@@ -673,12 +673,12 @@
* {...@code Class} object representing the {...@code Object} class is
* returned.
*
- * @throws GenericSignatureFormatError if the generic
+ * @throws java.lang.reflect.GenericSignatureFormatError if the 
generic
* class signature does not conform to the format specified in 
the

* Java Virtual Machine Specification, 3rd edition
* @throws TypeNotPresentException if the generic superclass
* refers to a non-existent type declaration
- * @throws MalformedParameterizedTypeException if the
+ * @throws java.lang.reflect.MalformedParameterizedTypeException 
if the
* generic superclass refers to a parameterized type that 
cannot be

* instantiated  for any reason
* @return the superclass of the class represented by this object
@@ -795,14 +795,14 @@
* If this object represents a primitive type or void, the
* method returns an array of length 0.
*
- * @throws GenericSignatureFormatError
+ * @throws java.lang.reflect.GenericSignatureFormatError
* if the generic class signature does not conform to the format
* specified in the Java Virtual Machine Specification, 3rd 
edition

* @throws TypeNotPresentException if any of the generic
* superinterfaces refers to a non-existent type declaration
- * @throws MalformedParameterizedTypeException if any of the
- * generic superinterfaces refer to a parameterized type 
that cannot

- * be instantiated  for any reason
+ * @throws java.lang.reflect.MalformedParameterizedTypeException
+ * if any of the generic superinterfaces refer to a 
parameterized

+ * type that cannot be instantiated for any reason
* @return an array of interfaces implemented by this class
* @since 1.5
*/

Code review request for 6628737: Specification of wrapper class valueOf static factories should require caching

[Joseph D. Darcy]

Hello.

Since JDK 5, to implement autoboxing, javac has relied on various static 
factory methods in the wrapper classes to perform the caching in the 
required range.  While the factories said they could cache, they did not 
state they would definitely cache in the required range given in JLSv3 
section 5.1.7:

http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7

Please review the patch below of my specification changes to mandate the 
caching.  The Boolean factory already mandates caching.  (For those 
interested in such things, tn parallel a ccc request has been filed to 
track the specification change.)


-Joe

--- old/src/share/classes/java/lang/Byte.java2009-07-08 
18:38:11.0 -0700
+++ new/src/share/classes/java/lang/Byte.java2009-07-08 
18:38:11.0 -0700

@@ -90,8 +90,8 @@
 * If a new {...@code Byte} instance is not required, this method
 * should generally be used in preference to the constructor
 * {...@link #Byte(byte)}, as this method is likely to yield
- * significantly better space and time performance by caching
- * frequently requested values.
+ * significantly better space and time performance since
+ * all byte values are cached.
 *
 * @param  b a byte value.
 * @return a {...@code Byte} instance representing {...@code b}.
--- old/src/share/classes/java/lang/Character.java2009-07-08 
18:38:13.0 -0700
+++ new/src/share/classes/java/lang/Character.java2009-07-08 
18:38:13.0 -0700

@@ -2571,6 +2571,10 @@
 * significantly better space and time performance by caching
 * frequently requested values.
 *
+ * This method will always cache values in the range '\u'
+ * to '\u007f'", inclusive, and may cache other values outside
+ * of this range.
+ *
 * @param  c a char value.
 * @return a Character instance representing c.
 * @since  1.5
--- old/src/share/classes/java/lang/Integer.java2009-07-08 
18:38:14.0 -0700
+++ new/src/share/classes/java/lang/Integer.java2009-07-08 
18:38:14.0 -0700

@@ -638,6 +638,9 @@
 * to yield significantly better space and time performance by
 * caching frequently requested values.
 *
+ * This method will always cache values in the range -128 to 127,
+ * inclusive, and may cache other values outside of this range.
+ *
 * @param  i an {...@code int} value.
 * @return an {...@code Integer} instance representing {...@code i}.
 * @since  1.5
--- old/src/share/classes/java/lang/Long.java2009-07-08 
18:38:16.0 -0700
+++ new/src/share/classes/java/lang/Long.java2009-07-08 
18:38:16.0 -0700

@@ -560,6 +560,11 @@
 * significantly better space and time performance by caching
 * frequently requested values.
 *
+ * Note that unlike the {...@linkplain Integer#valueOf(int)
+ * corresponding method} in the {...@code Integer} class, this method
+ * is not required to cache values within a particular
+ * range.
+ *
 * @param  l a long value.
 * @return a {...@code Long} instance representing {...@code l}.
 * @since  1.5
--- old/src/share/classes/java/lang/Short.java2009-07-08 
18:38:17.0 -0700
+++ new/src/share/classes/java/lang/Short.java2009-07-08 
18:38:17.0 -0700

@@ -219,6 +219,9 @@
 * significantly better space and time performance by caching
 * frequently requested values.
 *
+ * This method will always cache values in the range -128 to 127,
+ * inclusive, and may cache other values outside of this range.
+ *
 * @param  s a short value.
 * @return a {...@code Short} instance representing {...@code s}.
 * @since  1.5

Re: Code review request for 6628737: Specification of wrapper class valueOf static factories should require caching

[Joseph D. Darcy]

Mark Reinhold wrote:

Looks fine to me.

Minor formatting nit in each delta except the first:

  

...

--- old/src/share/classes/java/lang/Character.java2009-07-08
18:38:13.0 -0700
+++ new/src/share/classes/java/lang/Character.java2009-07-08
18:38:13.0 -0700
@@ -2571,6 +2571,10 @@
  * significantly better space and time performance by caching
  * frequently requested values.
  *
+ * This method will always cache values in the range '\u'
+ * to '\u007f'", inclusive, and may cache other values outside
+ * of this range.
+ *
  * @param  c a char value.
  * @return a Character instance representing c.
  * @since  1.5



I'm guessing, from the blank lines around this paragraph, that you want
it to be displayed as a separate paragraph.  If that's the case then you
need to wrap it in  ... .

  


Actually the extra blanks lines in only the javadoc were intentional; I 
sometimes like to insert extra lines in the javadoc to make it easier to 
read and secondarily to reduce the creation of spurious diffs from 
javadoc reformatting.


Thanks for the review,

-Joe

Re: Miscellaneous improvements to "jar".

[Joseph D. Darcy]

Thanks Martin!

-Joe


Martin Buchholz wrote:

Alright, I am all done with "jar" improvements.
(although the jar command is still far from perfect)
All the fixes (in particular, to make "jar" faster)
are in openjdk7 and openjdk6.

Martin

On Mon, Jul 6, 2009 at 13:58, Martin Buchholz > wrote:


I will atone for my use of nio2
by providing the backport to openjdk6.

6854795: Miscellaneous improvements to "jar"
6834805: Improve jar -C performance
6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream
6496274: jar seems to use more CPU than it should
Summary: backport jdk7 jar command (remove use of nio2)

Assuming darcy and sherman agree,
I will commit this to openjdk6.

http://cr.openjdk.java.net/~martin/webrevs/openjdk6/jar-misc-6/


Martin

On Sun, Jun 28, 2009 at 22:47, Xueming Shenmailto:xueming.s...@sun.com>> wrote:
> (2)nio2 APIs are good, but now I can't not just copy/paste the
jar Main to
> 6.x:-)

Code review request for 6857789: (reflect) Create common superclass of reflective exceptions

[Joseph D. Darcy]

Hello.

Please review the patch below to fix

   6857789:  (reflect) Create common superclass of reflective exceptions

Half a dozen checked exceptions thrown by methods in core reflection 
don't have a superclass more specific than Exception, requiring multiple 
catch blocks around code using core reflection operations.The fix is 
to change the direct superclass of the checked exceptions in question to 
a new shared checked exception, java.lang.ReflectiveOperationException.  
This is useful whether or not multi-catch is added as a language change 
in JDK 7.


Inserting a new level into the superclass hierarchy is a binary 
compatible change (JLSv3 Chapter 13); the change should be transparent 
other than to reflective operations that specifically queried the 
superclass.   All the exception classes in question already have 
explicit serialVersionUID fields so changing the superclass will be 
compatible from a serialization perspective too.


(A ccc request for this change is in progress too.)

Thanks,

-Joe


--- old/src/share/classes/java/lang/ClassNotFoundException.java
2009-07-09 14:38:05.0 -0700
+++ new/src/share/classes/java/lang/ClassNotFoundException.java
2009-07-09 14:38:05.0 -0700

@@ -50,7 +50,7 @@
 * @see java.lang.ClassLoader#loadClass(java.lang.String, boolean)
 * @since   JDK1.0
 */
-public class ClassNotFoundException extends Exception {
+public class ClassNotFoundException extends ReflectiveOperationException {
/**
 * use serialVersionUID from JDK 1.1.X for interoperability
 */
--- old/src/share/classes/java/lang/IllegalAccessException.java
2009-07-09 14:38:06.0 -0700
+++ new/src/share/classes/java/lang/IllegalAccessException.java
2009-07-09 14:38:06.0 -0700

@@ -56,7 +56,7 @@
 * @see java.lang.reflect.Constructor#newInstance(Object[])
 * @since   JDK1.0
 */
-public class IllegalAccessException extends Exception {
+public class IllegalAccessException extends ReflectiveOperationException {
private static final long serialVersionUID = 6616958222490762034L;

/**
--- old/src/share/classes/java/lang/InstantiationException.java
2009-07-09 14:38:06.0 -0700
+++ new/src/share/classes/java/lang/InstantiationException.java
2009-07-09 14:38:06.0 -0700

@@ -43,7 +43,7 @@
 * @since   JDK1.0
 */
public
-class InstantiationException extends Exception {
+class InstantiationException extends ReflectiveOperationException {
private static final long serialVersionUID = -8441929162975509110L;

/**
--- old/src/share/classes/java/lang/NoSuchFieldException.java
2009-07-09 14:38:07.0 -0700
+++ new/src/share/classes/java/lang/NoSuchFieldException.java
2009-07-09 14:38:07.0 -0700

@@ -31,7 +31,7 @@
 * @author  unascribed
 * @since   JDK1.1
 */
-public class NoSuchFieldException extends Exception {
+public class NoSuchFieldException extends ReflectiveOperationException {
private static final long serialVersionUID = -6143714805279938260L;

/**
--- old/src/share/classes/java/lang/NoSuchMethodException.java
2009-07-09 14:38:08.0 -0700
+++ new/src/share/classes/java/lang/NoSuchMethodException.java
2009-07-09 14:38:07.0 -0700

@@ -32,7 +32,7 @@
 * @since  JDK1.0
 */
public
-class NoSuchMethodException extends Exception {
+class NoSuchMethodException extends ReflectiveOperationException {
private static final long serialVersionUID = 5034388446362600923L;

/**
--- 
old/src/share/classes/java/lang/reflect/InvocationTargetException.java
2009-07-09 14:38:08.0 -0700
+++ 
new/src/share/classes/java/lang/reflect/InvocationTargetException.java
2009-07-09 14:38:08.0 -0700

@@ -39,7 +39,7 @@
 * @see Method
 * @see Constructor
 */
-public class InvocationTargetException extends Exception {
+public class InvocationTargetException extends 
ReflectiveOperationException {

/**
 * Use serialVersionUID from JDK 1.1.X for interoperability
 */
--- /dev/null2009-07-06 20:02:10.0 -0700
+++ new/src/share/classes/java/lang/ReflectiveOperationException.java
2009-07-09 14:38:09.0 -0700

@@ -0,0 +1,88 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * 

Re: Code review request for 6857789: (reflect) Create common superclass of reflective exceptions

[Joseph D. Darcy]

Rémi Forax wrote:

This request seems dangerous,
InvocationTargetException should not be retrofitted because
usually its catch block is different from the others.
As is, this patch will introduce more burden than it tries to revolve.


If needed InvocationTargetException can continue to have a separate 
catch block; if you happen to put a catch for  
ReflectiveOperationException ahead of InvocationTargetException, the 
compiler will emit an error.


-Joe

Re: Code review request for 6857789: (reflect) Create common superclass of reflective exceptions

[Joseph D. Darcy]

Jason Mehrens wrote:

Joe,
 
Wouldn't LinkageException be a better fit than 
ReflectiveOperationException?  Shorter name and it would mimic the 
LinkageError inheritance tree introduced in JDK1.0.  I.E. LinkageError 
-> NoClassDefFoundError, LinkageException -> ClassNotFoundException


"LinkageException" is a shorter name, but these conditions do not 
indicate there is a problem with linkage.  If there were a linkage 
program, you wouldn't have the reflective object to work with.


-Joe

Re: Code review request for 6857789: (reflect) Create common superclass of reflective exceptions

[Joseph D. Darcy]

Martin Buchholz wrote:

Thanks for this; I had a chance to use it in the past week,
if it had been there.

-
typo

+ * Conqstructs a new exception with {...@code null} as its detail


I caught this, but neglected to recreate the patch before sending the 
email.  I've spellchecked all the other comments.




-
Start paragraphs on new lines.

+ * and cause.  Note that the detail message associated with
-


Yes, I started by copying over the constructor's text from 
java.lang.Exception, but there is no reason to not follow the current 
conventions for new code; I'll fix this before it goes back.



Otherwise, looks good!


Thanks for the review,

-Joe



Martin

On Thu, Jul 9, 2009 at 15:47, Joseph D. Darcy <mailto:joe.da...@sun.com>> wrote:


Hello.

Please review the patch below to fix

  6857789:  (reflect) Create common superclass of reflective
exceptions

Half a dozen checked exceptions thrown by methods in core
reflection don't have a superclass more specific than Exception,
requiring multiple catch blocks around code using core reflection
operations.The fix is to change the direct superclass of the
checked exceptions in question to a new shared checked exception,
java.lang.ReflectiveOperationException.  This is useful whether or
not multi-catch is added as a language change in JDK 7.

Inserting a new level into the superclass hierarchy is a binary
compatible change (JLSv3 Chapter 13); the change should be
transparent other than to reflective operations that specifically
queried the superclass.   All the exception classes in question
already have explicit serialVersionUID fields so changing the
superclass will be compatible from a serialization perspective too.

(A ccc request for this change is in progress too.)

Thanks,

-Joe


--- old/src/share/classes/java/lang/ClassNotFoundException.java  
 2009-07-09 14:38:05.0 -0700
+++ new/src/share/classes/java/lang/ClassNotFoundException.java  
 2009-07-09 14:38:05.0 -0700

@@ -50,7 +50,7 @@
 * @see java.lang.ClassLoader#loadClass(java.lang.String, boolean)
 * @since   JDK1.0
 */
-public class ClassNotFoundException extends Exception {
+public class ClassNotFoundException extends
ReflectiveOperationException {
   /**
* use serialVersionUID from JDK 1.1.X for interoperability
*/
--- old/src/share/classes/java/lang/IllegalAccessException.java  
 2009-07-09 14:38:06.0 -0700
+++ new/src/share/classes/java/lang/IllegalAccessException.java  
 2009-07-09 14:38:06.0 -0700

@@ -56,7 +56,7 @@
 * @see java.lang.reflect.Constructor#newInstance(Object[])
 * @since   JDK1.0
 */
-public class IllegalAccessException extends Exception {
+public class IllegalAccessException extends
ReflectiveOperationException {
   private static final long serialVersionUID = 6616958222490762034L;

   /**
--- old/src/share/classes/java/lang/InstantiationException.java  
 2009-07-09 14:38:06.0 -0700
+++ new/src/share/classes/java/lang/InstantiationException.java  
 2009-07-09 14:38:06.0 -0700

@@ -43,7 +43,7 @@
 * @since   JDK1.0
 */
public
-class InstantiationException extends Exception {
+class InstantiationException extends ReflectiveOperationException {
   private static final long serialVersionUID = -8441929162975509110L;

   /**
--- old/src/share/classes/java/lang/NoSuchFieldException.java  
 2009-07-09 14:38:07.0 -0700
+++ new/src/share/classes/java/lang/NoSuchFieldException.java  
 2009-07-09 14:38:07.0 -0700

@@ -31,7 +31,7 @@
 * @author  unascribed
 * @since   JDK1.1
 */
-public class NoSuchFieldException extends Exception {
+public class NoSuchFieldException extends
ReflectiveOperationException {
   private static final long serialVersionUID = -6143714805279938260L;

   /**
--- old/src/share/classes/java/lang/NoSuchMethodException.java  
 2009-07-09 14:38:08.0 -0700
+++ new/src/share/classes/java/lang/NoSuchMethodException.java  
 2009-07-09 14:38:07.0 -0700

@@ -32,7 +32,7 @@
 * @since  JDK1.0
 */
public
-class NoSuchMethodException extends Exception {
+class NoSuchMethodException extends ReflectiveOperationException {
   private static final long serialVersionUID = 5034388446362600923L;

   /**
---
old/src/share/classes/java/lang/reflect/InvocationTargetException.java
   2009-07-09 14:38:08.0 -0700
+++
new/src/share/classes/java/lang/reflect/InvocationTargetException.java
   2009-07-09 14:38:08.0 -0700
@@ -39,7 +39,7 @@
 * @see Method
 * @see Constructor
 */
-public class InvocationTargetException extends Exception {
+public class Invo

Code review request for 6463998: Undocumented NullPointerExeption from Float.parseFloat and Double.parseDouble

[Joseph D. Darcy]

Hello.

Please review this simple patch below to document the long-standing 
behavior of parseFloat and parseDouble regarding null inputs.  (Yes, the 
various string -> value methods have inconsistent behavior with respect 
to null inputs; however, at this point the safest course of action is 
just to document the present behavior.)


Thanks,

-Joe

--- old/src/share/classes/java/lang/Double.java2009-07-15 
13:28:38.0 -0700
+++ new/src/share/classes/java/lang/Double.java2009-07-15 
13:28:38.0 -0700

@@ -529,6 +529,7 @@
 * @param  s   the string to be parsed.
 * @return the {...@code double} value represented by the string
 * argument.
+ * @throws  NullPointerException if the argument string is null
 * @throws NumberFormatException if the string does not contain
 * a parsable {...@code double}.
 * @seejava.lang.Double#valueOf(String)
--- old/src/share/classes/java/lang/Float.java2009-07-15 
13:28:39.0 -0700
+++ new/src/share/classes/java/lang/Float.java2009-07-15 
13:28:39.0 -0700

@@ -441,6 +441,7 @@
 * @param  s   the string to be parsed.
 * @return the {...@code float} value represented by the string
 * argument.
+ * @throws  NullPointerException if the argument string is null
 * @throws  NumberFormatException  if the string does not contain a
 *   parsable {...@code float}.
 * @seejava.lang.Float#valueOf(String)

Re: Code review request for 6463998: Undocumented NullPointerExeption from Float.parseFloat and Double.parseDouble

[Joseph D. Darcy]

Hello.

In response to a suggestion from Iris, I'll change the patch to use the 
phrase "the string" for both exceptions @throws descriptions.


Thanks for the quick reviews,

-Joe

Lance J. Andersen wrote:

Looks good Joe

-Lance

Joseph D. Darcy wrote:

Hello.

Please review this simple patch below to document the long-standing 
behavior of parseFloat and parseDouble regarding null inputs.  (Yes, 
the various string -> value methods have inconsistent behavior with 
respect to null inputs; however, at this point the safest course of 
action is just to document the present behavior.)


Thanks,

-Joe

--- old/src/share/classes/java/lang/Double.java2009-07-15 
13:28:38.0 -0700
+++ new/src/share/classes/java/lang/Double.java2009-07-15 
13:28:38.0 -0700

@@ -529,6 +529,7 @@
 * @param  s   the string to be parsed.
 * @return the {...@code double} value represented by the string
 * argument.
+ * @throws  NullPointerException if the argument string is null
 * @throws NumberFormatException if the string does not contain
 * a parsable {...@code double}.
 * @seejava.lang.Double#valueOf(String)
--- old/src/share/classes/java/lang/Float.java2009-07-15 
13:28:39.0 -0700
+++ new/src/share/classes/java/lang/Float.java2009-07-15 
13:28:39.0 -0700

@@ -441,6 +441,7 @@
 * @param  s   the string to be parsed.
 * @return the {...@code float} value represented by the string
 * argument.
+ * @throws  NullPointerException if the argument string is null
 * @throws  NumberFormatException  if the string does not contain a
 *   parsable {...@code float}.
 * @seejava.lang.Float#valueOf(String)

Re: Spec update for Class#getDeclaredMethods()

[Joseph D. Darcy]

Florian Weimer wrote:

* Rémi Forax:

  

The solution is to not rely on reflection and to parse the bytecode
using by example ASM :
see http://asm.ow2.org/



I think you'd still need to sort based on line numbers, which requires
debugging information which is not always available.

The only reliable way I know is to use a JSR 269 compiler plugin.
Members are guaranteed to be in source order over there.  (But this
still suffers from poor IDE support, AFAICS.)
  


The source ordering from JSR 269 is only guaranteed if the information 
is coming from a source file; from javax.lang.model.element.TypeElement:


"Each method of this interface that returns a list of elements will 
return them in the order that is natural for the underlying source of 
program information. For example, if the underlying source of 
information is Java source code, then the elements will be returned in 
source code order."

http://java.sun.com/javase/6/docs/api/javax/lang/model/element/TypeElement.html

If the information is coming from a class file, elements will be 
returned in the same order as they were in the class file.


Note that in the case of core reflection, which actually mostly present 
a JVM model of the world rather than a Java source model, there are more 
cases where non-source artifacts can crop up, including but not limited 
to implicit no-arg constructors and bridge methods.


-Joe

Re: Spec update for Class#getDeclaredMethods()

[Joseph D. Darcy]

Rémi Forax wrote:

Florian Weimer a écrit :

* Eamonn McManus:

 

The proposed change could be made, but it is not just a spec
change. All JVMs that don't currently conform to the spec would need
to change, as Rémi Forax notes, and that includes the JDK and its
derivatives. I'm not a HotSpot expert but my guess is that there's
some pretty sensitive code involved that the HotSpot team might be
reluctant to go poking around in.



*hmpf* There's some code out there which relies on source code order
of members (it's not just Preon).  Hotspot appears close enough to
guaranteeing it that programmers make this assumption
The solution is to not rely on reflection and to parse the bytecode 
using by example ASM :

see http://asm.ow2.org/

Rémi




One can also impose an ordering on the program elements.  Due to a 
mis-design in the original apt API we had to write such a comparator in 
com.sun.mirror.util.SourceOrderDeclScanner:


http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/7e0056ded28c/src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java

-Joe

Re: execvpe and glibc 2.10

[Joseph D. Darcy]

Martin Buchholz wrote:

Of course, it's all my fault.
First, for having used a symbol that libc implementers are likely to add.
Second, for actually asking glibc implementers to add that very symbol.
Third, for forgetting that this is an issue in openjdk6 as well.

Anyways, I intend to commit these patches to their respective forests:

http://cr.openjdk.java.net/~martin/webrevs/openjdk6/rename-execvpe/
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/

As ever, we need a Sun bug (could Michael or Joe file it?):

Synopsis: Rename execvpe to avoid symbol clash with glibc 2.10.
Description:
glibc 2.10 added the long-awaited "missing link" function execvpe
(thank you!  No really!)
But the JDK already has a function of that name, which needs renaming,
to avoid a compile time failure in UNIXProcess_md.c
Evaluation: Yup

Thanks,
  


I've filed bug 6866719 and I approve the fix going back into 7 and 
OpenJDK 6.


Cheers,

-Joe


Martin

On Wed, Jul 29, 2009 at 08:24, Andrew John
Hughes wrote:
  

2009/7/28 Martin Buchholz :


On Tue, Jul 28, 2009 at 06:08, Michael McMahon wrote:
  

Andrew John Hughes wrote:


2009/7/28 Michael McMahon :

  

Andrew John Hughes wrote:



2009/7/9 Martin Buchholz :


  

rename-execvpe is the one I'm particularly concerned about.  It's a
trivial patch, but without it, OpenJDK builds are going to start
failing as distros move to the new glibc (e.g. Fedora 12).  It's
already an issue for users of Fedora rawhide.

  

Ok. Maybe we can push rename-execvpe and RESTARTABLE first.


RESTARTABLE depends on vfork-exec, and I would not like to do
the work to reorder them.

Changes to fork-exec are always high-risk,
and I would like to see some more testing on these
before committing to openjdk proper.
That could be done by having icedtea7 import them,
and by having Michael or another Sun person run them
through Sun testing.

There are more changes to fork-exec to come,
although they will probably not affect the average Linux user's
experience.

Michael and I have been doing other things the past few weeks.

Martin

  

Sure, we can do some testing with IcedTea7 after the release for M4,
which should be sometime in the next week or so.

In the meantime, can you or me push the execvpe cleanup to the 6 and 7
forests (tl presumably for 7)?  Or is there a further issue there?
You've not mentioned it in either reply.

Joe, I assume this is okay for 6?  Without it the build is broken on
newer distributions.

Thanks,
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: Review request #0: 6863566 (Java should support the freedesktop.org startup notification specification)

[Joseph D. Darcy]

Oleg Sukhodolsky wrote:

Hi,

just a short question:
do we really have to change the launcher?  Why we can not add the
changes to AWT's native code (somewhere near LoadLibrary())?

  


Yes, it would be preferable if the launcher did not change for this.

-Joe


Oleg.

On Wed, Jul 29, 2009 at 3:13 PM, Anthony Petrov wrote:
  

Hello,

Please review the fix contributed by Damjan Jovanovic:

RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094

webrev: http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.0/

Since the patch includes changes to the src/solaris/bin/java_md.c, I'm
CC'ing Kumar and Core Libs alias to review the changes in that file.


Damjan, have you by the way tested the fix with a GUI Java application that
does not display a top-level window, but rather creates a tray icon only?
Does the notification get correctly removed from the task bar in that case?

--
best regards,
Anthony

Re: execvpe and glibc 2.10

[Joseph D. Darcy]

Martin Buchholz wrote:

Joe, thanks for the review.
  


Thanks for the fixes :-)

-Joe


I've pushed fixes for this problem to openjdk6 and openjdk7/tl

Martin

On Wed, Jul 29, 2009 at 21:22, Joseph D. Darcy wrote:
  

Martin Buchholz wrote:


Of course, it's all my fault.
First, for having used a symbol that libc implementers are likely to add.
Second, for actually asking glibc implementers to add that very symbol.
Third, for forgetting that this is an issue in openjdk6 as well.

Anyways, I intend to commit these patches to their respective forests:

http://cr.openjdk.java.net/~martin/webrevs/openjdk6/rename-execvpe/
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/

As ever, we need a Sun bug (could Michael or Joe file it?):

Synopsis: Rename execvpe to avoid symbol clash with glibc 2.10.
Description:
glibc 2.10 added the long-awaited "missing link" function execvpe
(thank you!  No really!)
But the JDK already has a function of that name, which needs renaming,
to avoid a compile time failure in UNIXProcess_md.c
Evaluation: Yup

Thanks,

  

I've filed bug 6866719 and I approve the fix going back into 7 and OpenJDK
6.

Cheers,

-Joe



Martin

On Wed, Jul 29, 2009 at 08:24, Andrew John
Hughes wrote:

  

2009/7/28 Martin Buchholz :



On Tue, Jul 28, 2009 at 06:08, Michael McMahon
wrote:

  

Andrew John Hughes wrote:



2009/7/28 Michael McMahon :


  

Andrew John Hughes wrote:




2009/7/9 Martin Buchholz :



  

rename-execvpe is the one I'm particularly concerned about.  It's a
trivial patch, but without it, OpenJDK builds are going to start
failing as distros move to the new glibc (e.g. Fedora 12).  It's
already an issue for users of Fedora rawhide.


  

Ok. Maybe we can push rename-execvpe and RESTARTABLE first.



RESTARTABLE depends on vfork-exec, and I would not like to do
the work to reorder them.

Changes to fork-exec are always high-risk,
and I would like to see some more testing on these
before committing to openjdk proper.
That could be done by having icedtea7 import them,
and by having Michael or another Sun person run them
through Sun testing.

There are more changes to fork-exec to come,
although they will probably not affect the average Linux user's
experience.

Michael and I have been doing other things the past few weeks.

Martin


  

Sure, we can do some testing with IcedTea7 after the release for M4,
which should be sometime in the next week or so.

In the meantime, can you or me push the execvpe cleanup to the 6 and 7
forests (tl presumably for 7)?  Or is there a further issue there?
You've not mentioned it in either reply.

Joe, I assume this is okay for 6?  Without it the build is broken on
newer distributions.

Thanks,
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from FILES_java.gmk

[Joseph D. Darcy]

Andrew John Hughes wrote:

When java.lang.ReflectiveOperationException was added in:

http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e

it wasn't added to make/java/java/FILES_java.gmk.  Although it still
seems to end up in rt.jar when building with IcedTea as the bootstrap
JDK, it fails when using gcj+ecj (which we use in a full bootstrap).

Is there any reason not to explicitly add the file like the others,
rather than relying on the compiler to do so (or not as the case may
be)?

There's a webrev here:
http://cr.openjdk.java.net/~andrew/roe/webrev.01/ with the 1 line fix.
  


Hmm, curious.  Yes, it does seem the file belongs be on the list in 
FILES_java.gmk; the new class is a superclass of some of the exception 
classes on the list so it gets pulled in, at least by javac.


However, I'm a bit surprised at the use of such a list in the current build.

Kelly, I thought specifying files was generally done at a 
package/directory level now?  What kind of files need to go into 
FILES_java.gmk?


-Joe

Core review request for 6378701 "(enum) Unclear purpose of EnumConstantNotPresentException "

[Joseph D. Darcy]

Hello.

Please review the patch below is clarify the use of certain exception 
types to address bug 6378701 "(enum) Unclear purpose of 
EnumConstantNotPresentException."  Five exceptions/errors can be thrown 
by the methods of the AnnotatedElement interface; those methods are used 
to retrieve annotations reflectively.  I've added cross references 
between the AnnotatedElement intefaces and the throwables it may throw.


-Joe

--- 
old/src/share/classes/java/lang/EnumConstantNotPresentException.java
2009-08-21 00:43:31.0 -0700
+++ 
new/src/share/classes/java/lang/EnumConstantNotPresentException.java
2009-08-21 00:43:30.0 -0700

@@ -28,8 +28,12 @@
/**
 * Thrown when an application tries to access an enum constant by name
 * and the enum type contains no constant with the specified name.
+ * This exception can be thrown by the {...@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
 *
 * @author  Josh Bloch
+ * @see java.lang.reflect.AnnotatedElement
 * @since   1.5
 */
public class EnumConstantNotPresentException extends RuntimeException {
--- old/src/share/classes/java/lang/TypeNotPresentException.java
2009-08-21 00:43:32.0 -0700
+++ new/src/share/classes/java/lang/TypeNotPresentException.java
2009-08-21 00:43:31.0 -0700

@@ -35,8 +35,12 @@
 * Note that this exception may be used when undefined type variables
 * are accessed as well as when types (e.g., classes, interfaces or
 * annotation types) are loaded.
+ * In particular, this exception can be thrown by the {...@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
 *
 * @author  Josh Bloch
+ * @see java.lang.reflect.AnnotatedElement
 * @since 1.5
 */
public class TypeNotPresentException extends RuntimeException {
--- 
old/src/share/classes/java/lang/annotation/AnnotationFormatError.java
2009-08-21 00:43:32.0 -0700
+++ 
new/src/share/classes/java/lang/annotation/AnnotationFormatError.java
2009-08-21 00:43:32.0 -0700

@@ -28,8 +28,12 @@
/**
 * Thrown when the annotation parser attempts to read an annotation
 * from a class file and determines that the annotation is malformed.
+ * This error can be thrown by the {...@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
 *
 * @author  Josh Bloch
+ * @see java.lang.reflect.AnnotatedElement
 * @since   1.5
 */
public class AnnotationFormatError extends Error {
--- 
old/src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
2009-08-21 00:43:33.0 -0700
+++ 
new/src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
2009-08-21 00:43:33.0 -0700

@@ -30,8 +30,12 @@
 * Thrown to indicate that a program has attempted to access an element of
 * an annotation whose type has changed after the annotation was compiled
 * (or serialized).
+ * This exception can be thrown by the {...@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
 *
 * @author  Josh Bloch
+ * @see java.lang.reflect.AnnotatedElement
 * @since 1.5
 */
public class AnnotationTypeMismatchException extends RuntimeException {
--- 
old/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
2009-08-21 00:43:34.0 -0700
+++ 
new/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
2009-08-21 00:43:33.0 -0700

@@ -30,8 +30,12 @@
 * an annotation type that was added to the annotation type definition 
after

 * the annotation was compiled (or serialized).  This exception will not be
 * thrown if the new element has a default value.
+ * This exception can be thrown by the {...@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
 *
 * @author  Josh Bloch
+ * @see java.lang.reflect.AnnotatedElement
 * @since 1.5
 */
public class IncompleteAnnotationException extends RuntimeException {
--- old/src/share/classes/java/lang/reflect/AnnotatedElement.java
2009-08-21 00:43:34.0 -0700
+++ new/src/share/classes/java/lang/reflect/AnnotatedElement.java
2009-08-21 00:43:34.0 -0700

@@ -50,6 +50,11 @@
 * java.lang.annotation.AnnotationTypeMismatchException} or an
 * {...@link java.lang.annotation.IncompleteAnnotationException}.
 *
+ * @see java.lang.EnumConstantNotPresentException
+ * @see java.lang.TypeNotPresentException
+ * @see java.lang.annotation.AnnotationFormatError
+ * @see java.lang.annotation.AnnotationTypeMismatchException
+ * @see java.lang.annotation.IncompleteAnnotationException
 * @since 1.5
 * @author Josh Bloch
 */

Re: Core review request for 6378701 "(enum) Unclear purpose of EnumConstantNotPresentException "

[Joseph D. Darcy]

Alan Bateman wrote:

Joseph D. Darcy wrote:

Hello.

Please review the patch below is clarify the use of certain exception 
types to address bug 6378701 "(enum) Unclear purpose of 
EnumConstantNotPresentException."  Five exceptions/errors can be 
thrown by the methods of the AnnotatedElement interface; those 
methods are used to retrieve annotations reflectively.  I've added 
cross references between the AnnotatedElement intefaces and the 
throwables it may throw.


-Joe
Looks okay to me (although maybe you don't need two links to 
j.l.reflect.AnnotatedElement from each of the exceptions?).




I think calling out the connection in the "See also" area makes things 
clearer since the "See also" section stands apart from the text.


Thanks,

-Joe

Code review request to remove javadoc build warnings from javax.sql.rowset.BaseRowSet.java

[Joseph D. Darcy]

Hello.

More cleanup of docs build warnings; this time from 
javax.sql.rowset.BaseRowSet.java where non-existent getter methods are 
repeatedly referenced.  Assuming someone approves the change, I'll file 
a bug and commit the fix.


-Joe

--- old/src/share/classes/javax/sql/rowset/BaseRowSet.java2009-08-27 
18:04:08.0 -0700
+++ new/src/share/classes/javax/sql/rowset/BaseRowSet.java2009-08-27 
18:04:08.0 -0700

@@ -168,8 +168,8 @@
 * The majority of methods for setting placeholder parameters take two 
parameters,

 *  with the first parameter
 * indicating which placeholder parameter is to be set, and the second 
parameter

- * giving the value to be set.  Methods such as getInt,
- * getString, getBoolean, and 
getLong fall into

+ * giving the value to be set.  Methods such as setInt,
+ * setString, setBoolean, and 
setLong fall into
 * this category.  After these methods have been called, a call to the 
method
 * getParams will return an array with the values that 
have been set. Each

 * element in the array is an Object instance representing the
@@ -3259,7 +3259,6 @@
* @param x the parameter value
* @exception SQLException if a database access error occurs or
* this method is called on a closed CallableStatement
-* @see #getBoolean
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
* @since 1.4
@@ -3281,7 +3280,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getByte
* @since 1.4
*/
   public void setByte(String parameterName, byte x) throws SQLException{
@@ -3301,7 +3299,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getShort
* @since 1.4
*/
   public void setShort(String parameterName, short x) throws SQLException{
@@ -3320,7 +3317,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getInt
* @since 1.4
*/
   public void setInt(String parameterName, int x) throws SQLException{
@@ -3339,7 +3335,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getLong
* @since 1.4
*/
   public void setLong(String parameterName, long x) throws SQLException{
@@ -3358,7 +3353,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getFloat
* @since 1.4
*/
   public void setFloat(String parameterName, float x) throws SQLException{
@@ -3377,7 +3371,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getDouble
* @since 1.4
*/
   public void setDouble(String parameterName, double x) throws 
SQLException{

@@ -3398,7 +3391,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getBigDecimal
* @since 1.4
*/
   public void setBigDecimal(String parameterName, BigDecimal x) throws 
SQLException{

@@ -3421,7 +3413,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getString
* @since 1.4
*/
   public void setString(String parameterName, String x) throws 
SQLException{

@@ -3443,7 +3434,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getBytes
* @since 1.4
*/
   public void setBytes(String parameterName, byte x[]) throws 
SQLException{

@@ -3464,7 +3454,6 @@
* this method is called on a closed CallableStatement
* @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support

* this method
-* @see #getTimestamp
* @since 1.4
*/
   public void setTimestamp(String parameterName, java.sql.Timestamp x)
@@ -3712,7 +3701,6 @@
* or  STRUCT data type and the JDBC driver does not 
support

* this data type
* @see Types
-* @see #getObject
* @since 1.4
*/
   public void setObject(String parameterName, Object x, int 
targetSqlType, int scale)

@@ -3740,7 +3728,6 @@
*  REF, ROWID, SQLXML
* or  STRUCT data type and the JDBC driver does not 
support

* this data type
-* @see #getObject
* @since 1.4
*/
   public void setObject(String parameterName, O

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

[Joseph D. Darcy]

Hello.

Martin Buchholz wrote:

Joe, here's a fix for the stray double quote.
  


Mea culpa!


I've used {...@code with \u005C with the hope of making Ulf happy.

As usual, we'll need bug filed, etc...
  


I've filed bug 6879368 "Remove stray quote in Character javadoc" for 
this issue.



diff --git a/src/share/classes/java/lang/Character.java
b/src/share/classes/java/lang/Character.java
--- a/src/share/classes/java/lang/Character.java
+++ b/src/share/classes/java/lang/Character.java
@@ -2587,9 +2587,9 @@
  * significantly better space and time performance by caching
  * frequently requested values.
  *
- * This method will always cache values in the range '\u'
- * to '\u007f'", inclusive, and may cache other values outside
- * of this range.
+ * This method will always cache values in the range {...@code
+ * '\u005Cu'} to {...@code '\u005Cu007f'}, inclusive, and may
+ * cache other values outside of this range.
  *
  * @param  c a char value.
  * @return a Character instance representing c.
  



I approve this going back.

Thanks,

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Mike Morris wrote:

Joe Darcy wrote:

For JDK 7, I think it is high-time the platform included a class like 
java.util.Objects to hold commonly-written utility methods.  For 

...
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Ah! Let's just go back to coding in C, then. I cannot see any 
justification for everything and the kitchen-sink being glommed into 
the Java APIs. If people want these sort of static methods, they're 
pretty-much all available in other libraries (Apache Commons, etc.)


The methods being discussed are generaly short and while easy to write, 
all of them aren't so easy to write that they cannot have bugs.  To me, 
the existence of these methods in multiple other libraries argues for 
putting robust version of them in the JDK since it is not worthwhile 
adding a library dependency just to get a static two argument equals method.


-Joe

Re: PATCH: Tired of waiting for rt.jar to build?

[Joseph D. Darcy]

Martin Buchholz wrote:

On Thu, Sep 10, 2009 at 08:25, Andrew Haley wrote:
  

Andrew John Hughes wrote:



FWIW, I'm pretty sure I'm not alone in saying I'd much prefer to
receive these 'uninteresting' mails.
  

This particular back-port mail would have been very interesting to
us, since it has a huge impact on build times on some architectures.



The mercurial history of openjdk6 is sadly incomplete,
even when compared to openjdk7.
  


Due to efforts by Kelly, OpenJDK 6 has Mercurial history since it 
branched off from OpenJDK 7.  Given the original use of teamware, there 
is not fully accurate changeset-level reconstruction from the beginning, 
but there is at least build-level information for all OpenJDK 6 builds.


-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Joe Darcy wrote:

Martin Buchholz wrote:

On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:

Martin Buchholz wrote:

On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:


On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly tightened:


Right you are.  Webrev regenerated.

Martin

One typo inherited from my earlier suggestion (mea culpa!): as the 
Character

class is not a java.lang.Number, it does not have an intValue method.
 Character does have a charValue method and referring to that method 
in the

specification of hashCode should suffice.

I approve this change going back with the correction to the 
Character class.


Oops!  so many little mistakes. Webrev regenerated.


Looks good.

-Joe



Martin,

Just to be clear, I approve this change of tightening the hashCode 
specifications for Byte, Short, and Character going back into JDK 7.


Thanks,

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Joe Darcy wrote:

Martin Buchholz wrote:

On Wed, Sep 9, 2009 at 17:34, Joe Darcy wrote:
 

Martin Buchholz wrote:
   

Google would like to contribute implementations of the methods below.
Here's a webrev:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/

  

Wherever these compare methods go, into the N wrapper classes or into
java.util.Compare,



Given the precedent of Double.compare(double,double) and
Float.compare(float,float), I think the compare methods need
to go into the primitive wrapper classes.

 I think the instance method compareTo should be rewritten
 

in terms of the new static compare.  In particular,

422 public int compareTo(Short anotherShort) {
423 return this.value - anotherShort.value;
424 }

should get replaced with

422 public int compareTo(Short anotherShort) {
423 return compare(this.value, anotherShort.value);
424 }



As you wish.

Webrev updated.
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/
  


I approve these changes in an engineering sense; they are a fix for bug

6582946 Add suite of compare(T, T) methods for ints, longs etc


This consolidates the comparison logic in a single method per type and
reuses the existing implementation tests.




 
(Later in JDK 7, a set of "unsignedCompare" methods are possible 
additions

to the platform too.)

   
We have tests (not yet included) but they would need to be 
jtreg-ified.

Is there any junit support yet for jtreg?

  

No.

Once the home of the new methods is determined, I'll file a ccc 
request so

these changes can go back after any additional testing is settled.



There's not a whole lot of testing work here, but we will provide it if
it CCC is approved.

  

I've created a ccc for this and will let you know when it is approved.

-Joe



Martin,

The paperwork has been handled; I approve your set of compare methods 
going back.


Thanks,

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Jason Mehrens wrote:

Joe,

 > * null safe toString(Object), returning "null" for a null argument
 
Doesn't String.valueOf do the same thing?
http://java.sun.com/javase/6/docs/api/java/lang/String.html#valueOf(java.lang.Object 
)


Indeed it does!  I'll replace the implementation with a call to 
String.valueOf and update the javadoc accordingly.  Thanks for spotting 
this.


What about a toIdentityString(Object) instead?  Some of the nice 
properties of an identity string is that it is safe to


By toIdentityString, do you mean the String that would be returned by 
toString if toString is not overridden?


-Joe

call from multiple threads even on objects that are not thread safe 
(JComponent), won't deadlock if toString is synchronized (observed in 
logging), and won't build run away strings (nCopies(Integer.MAX_VALUE, 
"lookout").toString()).
 
Jason



Hotmail® has ever-growing storage! Don’t worry about storage limits. 
Check it out. 

Re: New Methods/Features in JDK7

[Joseph D. Darcy]

Quintin Beukes wrote:

Hey,

Are there any current listings of new language features/broad API
changes so far in OpenJDK7. I understand they might not be permanent,
and could change in a wink, though I'm curious to see what could
possibly be in the next Java.

Quintin Beukes
  


http://openjdk.java.net/projects/jdk7/features/

-Joe

Core review request for 5062288 "(reflect) Core reflection uses raw types when it could be using wildcards"

[Joseph D. Darcy]

Hello.

Please review my changes to address:

5062288 "(reflect) Core reflection uses raw types when it could be using 
wildcards"

http://cr.openjdk.java.net/~darcy/5062288.0/

This changeset removes most of the raw types warnings in core 
reflection, java.lang.Class and java.lang.reflect.*.  I did not attempt 
to remove uses of raw types from ClassLoader and I did not attempt to 
make serious changes to Proxy.  This changeset does not affect "exported 
public" API signatures, only local variables and less than public 
exported method signatures and fields.


Thanks,

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

David Holmes - Sun Microsystems wrote:

Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do 
something is part of the JDK. 


While the JDK is far from a model example of providing "one way" to do 
something, that doesn't mean we should gratuitously add superfluous 
and redundant functionality. 


The JDK has a long history of providing convenience methods.  For 
example, we have PrintStream.format and PrintStream.printf which are 
just two names for the same functionality.



Type.valueOf is an established pattern for converting types.

The JDK is already severely bloated - new APIs should pay their own way.


Getting rid of more than half a dozen implementations of equals(Object, 
Object) should just in the JDK should more than pay the for the entire 
Objects class ;-)


-Joe

Code review request: bugs 6480728 and 6655735 in the wrapper classes

[Joseph D. Darcy]

Hello.

Please review these simple cleanup fixes in the wrapper classes:

6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String)
6655735: Integer.toString() and String.valueOf(int) contain slow delegations

The fix for the first bug is for the valueOf(String) and decode methods 
in Byte and Short to return objects after going through the cache.  This 
behavior is already present in Integer and Long.


The second fix changes method calls in various wrapper classes and  in 
String to go to the Foo -> String method most directly implementing the 
desired conversion


Patch is below; webrev at
http://cr.openjdk.java.net/~darcy/6480728.0/

-Joe

--- old/src/share/classes/java/lang/Byte.java2009-10-07 
12:18:04.0 -0700
+++ new/src/share/classes/java/lang/Byte.java2009-10-07 
12:18:03.0 -0700

@@ -201,7 +201,7 @@
 */
public static Byte valueOf(String s, int radix)
throws NumberFormatException {
-return new Byte(parseByte(s, radix));
+return valueOf(parseByte(s, radix));
}

/**
@@ -277,7 +277,7 @@
if (i < MIN_VALUE || i > MAX_VALUE)
throw new NumberFormatException(
"Value " + i + " out of range from input " + nm);
-return (byte)i;
+return valueOf((byte)i);
}

/**
@@ -374,7 +374,7 @@
 *  base 10.
 */
public String toString() {
-return String.valueOf((int)value);
+return Integer.toString((int)value);
}

/**
--- old/src/share/classes/java/lang/Double.java2009-10-07 
12:18:04.0 -0700
+++ new/src/share/classes/java/lang/Double.java2009-10-07 
12:18:04.0 -0700

@@ -629,7 +629,7 @@
 * @see java.lang.Double#toString(double)
 */
public String toString() {
-return String.valueOf(value);
+return toString(value);
}

/**
--- old/src/share/classes/java/lang/Float.java2009-10-07 
12:18:05.0 -0700
+++ new/src/share/classes/java/lang/Float.java2009-10-07 
12:18:05.0 -0700

@@ -551,7 +551,7 @@
 * @see java.lang.Float#toString(float)
 */
public String toString() {
-return String.valueOf(value);
+return Float.toString(value);
}

/**
--- old/src/share/classes/java/lang/Integer.java2009-10-07 
12:18:06.0 -0700
+++ new/src/share/classes/java/lang/Integer.java2009-10-07 
12:18:06.0 -0700

@@ -746,7 +746,7 @@
 *  base 10.
 */
public String toString() {
-return String.valueOf(value);
+return toString(value);
}

/**
--- old/src/share/classes/java/lang/Long.java2009-10-07 
12:18:07.0 -0700
+++ new/src/share/classes/java/lang/Long.java2009-10-07 
12:18:07.0 -0700

@@ -761,7 +761,7 @@
 *  base 10.
 */
public String toString() {
-return String.valueOf(value);
+return toString(value);
}

/**
--- old/src/share/classes/java/lang/Short.java2009-10-07 
12:18:08.0 -0700
+++ new/src/share/classes/java/lang/Short.java2009-10-07 
12:18:07.0 -0700

@@ -170,7 +170,7 @@
 */
public static Short valueOf(String s, int radix)
throws NumberFormatException {
-return new Short(parseShort(s, radix));
+return valueOf(parseShort(s, radix));
}

/**
@@ -282,7 +282,7 @@
if (i < MIN_VALUE || i > MAX_VALUE)
throw new NumberFormatException(
"Value " + i + " out of range from input " + nm);
-return (short)i;
+return valueOf((short)i);
}

/**
@@ -379,7 +379,7 @@
 *  base 10.
 */
public String toString() {
-return String.valueOf((int)value);
+return Integer.toString((int)value);
}

/**
--- old/src/share/classes/java/lang/String.java2009-10-07 
12:18:08.0 -0700
+++ new/src/share/classes/java/lang/String.java2009-10-07 
12:18:08.0 -0700

@@ -2995,7 +2995,7 @@
 * @see java.lang.Integer#toString(int, int)
 */
public static String valueOf(int i) {
-return Integer.toString(i, 10);
+return Integer.toString(i);
}

/**
@@ -3009,7 +3009,7 @@
 * @see java.lang.Long#toString(long)
 */
public static String valueOf(long l) {
-return Long.toString(l, 10);
+return Long.toString(l);
}

/**

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Joseph D. Darcy]

Jason Mehrens wrote:
+1, return empty string for the one arg and add the two arg 
variant.  The j.u.Properties.getProperty(String, String) could use it 
first.  Just curious, what does project jigsaw think of j.u.Objects?


I'm preparing the first round of java.util.Objects with the 
single-argument static toString method return "null" for null for final 
review.  I'll send out a few follow-up emails, including one for 
additional toStrings methods.  I'm sympathetic to the two-argument 
toString method with a default.


Project Jigsaw is about modularity so I don't see what connection there 
is between Jigsaw and j.u.Objects.


-Joe

 
Jason


 
> Date: Thu, 8 Oct 2009 11:47:49 +0100
> Subject: Objects.toString [Re: What methods should go into a 
java.util.Objects class in JDK 7?]

> From: scolebou...@joda.org
> To: core-libs-dev@openjdk.java.net
>
> A number of us are proposing that Objects.toString(obj) should return
> "" when the object is null. I'm strongly in favour of this, and it
> removes any discussion of duplicated API (as it does something
> different and more useful).
>
> In favour/against +1/-1 ?
>
> Stephen
 




Hotmail: Powerful Free email with security by Microsoft. Get it now. 

First round of java.util.Objects for code review (bug 6797535)

[Joseph D. Darcy]

rosystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+/*
+ * @test
+ * @bug 6797535
+ * @summary Basic tests for methods in java.util.Objects
+ * @author  Joseph D. Darcy
+ */
+
+import java.util.*;
+
+public class BasicObjectsTest {
+public static void main(String... args) {
+int errors = 0;
+errors += testEquals();
+errors += testHashCode();
+errors += testToString();
+errors += testCompare();
+if (errors > 0 )
+throw new RuntimeException();
+}
+
+private static int testEquals() {
+int errors = 0;
+Object[] values = {null, "42", 42};
+for(int i = 0; i < values.length; i++)
+for(int j = 0; j < values.length; j++) {
+boolean expected = (i == j);
+Object a = values[i];
+Object b = values[j];
+boolean result = Objects.equals(a, b);
+if (result != expected) {
+errors++;
+System.err.printf("When equating %s to %s, got %b intead of 
%b%n.",
+  a, b, result, expected);
+}
+}
+return errors;
+}
+
+private static int testHashCode() {
+int errors = 0;
+errors += (Objects.hashCode(null) == 0 ) ? 0 : 1;
+String s = "42";
+errors += (Objects.hashCode(s) == s.hashCode() ) ? 0 : 1;
+return errors;
+}
+
+private static int testToString() {
+int errors = 0;
+errors += ("null".equals(Objects.toString(null)) ) ? 0 : 1;
+String s = "Some string";
+errors += (s.equals(Objects.toString(s)) ) ? 0 : 1;
+return errors;
+}
+
+private static int testCompare() {
+int errors = 0;
+String[] values = {"e. e. cummings", "zzz"};
+String[] VALUES = {"E. E. Cummings", "ZZZ"};
+errors += compareTest(null, null, 0);
+for(int i = 0; i < values.length; i++) {
+String a = values[i];
+errors += compareTest(a, a, 0);
+for(int j = 0; j < VALUES.length; j++) {
+int expected = Integer.compare(i, j);
+String b = VALUES[j];
+errors += compareTest(a, b, expected);
+}
+}
+return errors;
+}
+
+private static int compareTest(String a, String b, int expected) {
+int errors = 0;
+int result = Objects.compare(a, b, String.CASE_INSENSITIVE_ORDER);
+if (Integer.signum(result) != Integer.signum(expected)) {
+errors++;
+System.err.printf("When comaping %s to %s, got %d intead of %d%n.",
+  a, b, result, expected);
+}
+return errors;
+}
+}

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Joseph D. Darcy]

Paul Benedict wrote:

Joe,

  

I'm preparing the first round of java.util.Objects with the
single-argument static toString method return "null" for null for final
review.



Why would you choose to return "null" for any null object? 


Because that is how the platform has always treated null in string 
concatenation.



Everyone
who has opined did disagree with replicating String.valueOf()
behavior. 


The people who disagreed with the replication disagreed with the 
replication.  Others disagreed with the behavior.


-Joe

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Joseph D. Darcy]

Paul Benedict wrote:

Why would you choose to return "null" for any null object?
  

Because that is how the platform has always treated null in string
concatenation.



If you were defining new operations for String, StringBuilder, or
StringBuffer, I would agree with your choice. Since you are now
defining a global utility method for all objects, I think having
"null" being the de-facto string representation of null is simply
taking it too far.
  


System.out.println("" + referenceOfAnyType);

will print "null" if referenceOfAnyType is null.

This is what the platform has done since the beginning.

-Joe

j.ul.Objects follow-up: methods for var-argification?

[Joseph D. Darcy]

Hello.

In the discussion about java.util.Objects, a few existing JDK methods 
were mentioned for possible var-argification:


java.util.Arrays.hashCode(Object[] a)
java.util.Arrays.deepHashCode(Object[] a)
java.util.Arrays.toString(Object[] a)

Also of possible general interest are some methods on String (bug 
6762452 API change proposal: Enhance String constructor for varargs)


java.lang.String.copyValueOf(char[] data)
java.lang.String.valueOf(char[] data)
java.lang.String(char[] value)

Var-argification is fully binary compatible and is generally source 
compatible, although new conversions are allowed of course and 
overloadings may change.


-Joe

j.u.Objects follow-up: variations on Object -> String methods

[Joseph D. Darcy]

Hello.

During the vigorous discussion of what Objects.toString(Object) should 
be defined to do, a number of alternatives were suggested:


public static toString(Object a, String default) // return default if (a 
== null) else a.toString()
public static toDefaultString(Object a) // return the string 
Object.toString returns if not overriden, what about null?
public static toDebugString(Object a) // reflectively return an 
informative representation of the argument


I can accept the utility of toString(Object a, String default) and will 
include it in the next round of j.u.Objects updates.


The functionality of toDefaultString is included in Apache commons under 
the name of "identityToString," returning null for a null argument.  
From a quick Google code search, this methods doesn't seem to be widely 
called and I'm not yet convinced it's worthwhile to add this method to 
Objects.


I think I could be convinced that a reflection-based toDebugString was 
useful enough to include in the platform.  However, someone would have 
to contribute the specification and a robust implementation.


-Joe

j.u.Objects follow-up: deepEquals(Object, Object)?

[Joseph D. Darcy]

Another piece of functionality requested in the j.u.Objects thread was a 
deepEquals(Object a, Object b.) method that "did the right thing" if the 
arguments happened to dynamically be arrays.


I've been thinking a bit how this might be implemented.

The array-ness of a and b would need to be determined, after any 
up-front null-checks


boolean aIsArray = a.getClass().isArray();
boolean bIsArray = b.getClass().isArray();

followed various case-analyses.

if (aIsArray && bIsArray) {
Class aComponentType = a.getClass().getComponentType();
Class bComponentType = b.getClass().getComponentType();
   if (aComponentType == bComponentType) {
   // long case analysis to cast and call Arrays.deepEquals if 
ComponentType is a reference type
   // or the matching Arrays.equals(primitiveComponent[], 
primitiveComponent[]) method if

   // aComponentType.isPrimitive().
   } else
   return false;
} else
   return a.equals(b);

Certainly a bit messy internally.

What are scenarios where this method would be used?

-Joe

Re: j.ul.Objects follow-up: methods for var-argification?

[Joseph D. Darcy]

Ulf Zibis wrote:

Am 08.10.2009 20:34, Joseph D. Darcy schrieb:

Hello.

In the discussion about java.util.Objects, a few existing JDK methods 
were mentioned for possible var-argification:


java.util.Arrays.hashCode(Object[] a)
java.util.Arrays.deepHashCode(Object[] a)
java.util.Arrays.toString(Object[] a)

Also of possible general interest are some methods on String (bug 
6762452 API change proposal: Enhance String constructor for varargs)


java.lang.String.copyValueOf(char[] data)
java.lang.String.valueOf(char[] data)
java.lang.String(char[] value)

Var-argification is fully binary compatible and is generally source 
compatible, although new conversions are allowed of course and 
overloadings may change.




As String is final, there are no changed overloadings.
As the Arrays methods are static, there are too no changed overloadings.


Being final and static alone are not enough to guarantee no new 
overloadings; although the overloading resolution rules are carefully 
crafted to try to select the same method if var-args is added to a class.




OK, correct me, if I'm wrong.



FYI, here is a var-argification which breaks source compatibility:

Consider in final class C

Before:
static void foo(int..)
static void foo(Integer[])

After:
static void foo(int...)
static void foo(Integer...)

Call site:

C.foo(42);

In the after scenario, both versions of foo *could* now be called and 
there is an ambiguity whereas before only the int... method could have 
been called.


For some interesting discussion of overloading, see
http://gbracha.blogspot.com/2009/09/systemic-overload.html

-Joe

Re: j.u.Objects follow-up: deepEquals(Object, Object)?

[Joseph D. Darcy]

Eamonn McManus wrote:

Joseph D. Darcy wrote:
> What are scenarios where this method would be used?

I use a similar method fairly often in unit tests.  JUnit's 
assertEquals doesn't
do the right thing if its arguments happen to be arrays, so I use the 
following

simple if inefficient implementation:

static void deepEquals(Object x, Object y) {
return Arrays.deepEquals(new Object[] {x}, new Object[] {y});
}

What that shows of course is that the messy logic you mention is 
already present in

Arrays.deepEquals so you could factor it out.


Yes, the logic inside the for loop in deepEquals could be factored out 
into just the right package-private helper method.


Thanks for the pointer!

-Joe

Code review request for 6648344: (reflect spec) State default of isAccessible for reflective objects

[Joseph D. Darcy]

Hello.

Please review this simple specification clarification (with accompanying 
test) for

6648344: (reflect spec) State default of isAccessible for reflective objects

-Joe

--- old/src/share/classes/java/lang/reflect/AccessibleObject.java
2009-10-09 14:48:35.0 -0700
+++ new/src/share/classes/java/lang/reflect/AccessibleObject.java
2009-10-09 14:48:35.0 -0700

@@ -44,6 +44,8 @@
 * as Java Object Serialization or other persistence mechanisms, to
 * manipulate objects in a manner that would normally be prohibited.
 *
+ * By default, a reflected object is not accessible.
+ *
 * @see Field
 * @see Method
 * @see Constructor
--- /dev/null2009-07-06 20:02:10.0 -0700
+++ new/test/java/lang/reflect/DefaultAccessibility.java2009-10-09 
14:48:36.0 -0700

@@ -0,0 +1,69 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version

+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+/*
+ * @test
+ * @bug 6648344
+ * @summary Test that default accessibility is false
+ * @author Joseph D. Darcy
+ */
+
+import java.lang.reflect.*;
+
+public class DefaultAccessibility {
+private DefaultAccessibility() {
+super();
+}
+
+private static int f = 42;
+
+public static void main(String... args) throws Exception {
+Class daClass = (new DefaultAccessibility()).getClass();
+
+int elementCount = 0;
+for(Constructor ctor : daClass.getDeclaredConstructors()) {
+elementCount++;
+if (ctor.isAccessible())
+throw new RuntimeException("Unexpected accessibility 
for constructor " +

+   ctor);
+}
+
+for(Method method : daClass.getDeclaredMethods()) {
+elementCount++;
+if (method.isAccessible())
+throw new RuntimeException("Unexpected accessibility 
for method " +

+   method);
+}
+
+for(Field field : daClass.getDeclaredFields()) {
+elementCount++;
+if (field.isAccessible())
+throw new RuntimeException("Unexpected accessibility 
for field " +

+   field);
+}
+
+if (elementCount < 3)
+throw new RuntimeException("Expected at least three 
members; only found " +

+   elementCount);
+}
+}

Quick code review request for 634992 (enum) Include links from java.lang.Enum to EnumSet and EnumMap

[Joseph D. Darcy]

Please review this tiny doc fix to make EnumSet and EnumMap just a bit 
easier to find; patch below


-Joe

--- old/src/share/classes/java/lang/Enum.java2009-10-09 
11:41:23.0 -0700
+++ new/src/share/classes/java/lang/Enum.java2009-10-09 
11:41:23.0 -0700

@@ -44,6 +44,8 @@
 * @author  Josh Bloch
 * @author  Neal Gafter
 * @see Class#getEnumConstants()
+ * @see java.util.EnumSet
+ * @see java.util.EnumMap
 * @since   1.5
 */
public abstract class Enum>

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Joseph D. Darcy]

Eamonn McManus wrote:

David Holmes - Sun Microsystems wrote:
> So to me: String toString(Object o, String useIfNull) is the only 
method

> that provides true utility in this case.

I agree with that, and would just suggest to the person specifying the 
method
to add a @see String#valueOf(Object).  I find that the behaviour of 
that method


Agreed, that @see, amongst others, has been in the patch for this change

http://cr.openjdk.java.net/~darcy/6797535.1/

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Paul Benedict wrote:

Joe,

I think java.util.Objects could benefit from the "final" modifier.
Since its constructor always fails, there is no reason to subclass it
(i.e., super constructor always fails). I believe Josh's "Effective
Java" book makes such a point about static utility classes.

Paul
  


Hello.

Classes with only private constructors, like j.u.Objects, are 
effectively final.  Adding final is harmless but unnecessary in these 
cases.  The platform is a bit inconsistent here; j.u.Collections is 
*not* marked final while j.l.Math is.  In practice, it doesn't matter 
very much; I'll consider final-izing j.u.Objects on the next round of edits.


-Joe

Re: Quick code review request for 634992 (enum) Include links from java.lang.Enum to EnumSet and EnumMap

[Joseph D. Darcy]

Neal Gafter wrote:
Generally speaking, lower levels in the system shouldn't refer to 
higher levels.  In this case it's just a comment, but it isn't clear 
that every profile that includes Enum will include the collections 
framework.  I'm thinking, for example, about ME profiles.


A few comments on this.

Yes, in general it is true that lower levels shouldn't depend on higher 
levels.  That was the primary reason we decided to have the new 
reflection methods in JDK 5 return arrays rather than generic 
collections.  However, than are many nuances here.


First, there is a difference between an API level dependency, like a 
type used in a signature, and an implementation dependency, something 
that only appears in a method body.  A further distinction is between a 
compile-time implementation dependency and a runtime-only one, such as 
when a class is looked up reflectively.  Additionally, if collections 
and java.lang.Enum are in the same grouping, there is no problem in 
having the dependency.


Second, the underlying model for creating platform javadoc is "compile 
the world" so the presence of absence of particular edges in the 
dependency graph don't really affect what needs to happen.


Finally, the onus for subsetting the API documentation for platform 
subsets ultimately falls on those doing the subsetting.  The javadoc 
build warnings will be there to guide them.


In short, IMO this is an entirely innocuous change that will help those 
learning Java find the enum-optimized set and map implementations.  I 
would even consider adding "Note that when using enums in sets or as 
keys in a map, optimized set and map implementations are available."


Which is probably about an order of magnitude more consideration than 
this change deserves!


-Joe



-Neal

On Fri, Oct 9, 2009 at 4:13 PM, Joe Darcy <mailto:joe.da...@sun.com>> wrote:


Neal Gafter wrote:

Do EnumSet and EnumMap exist on all platform profiles?


They exist on JDK 7 where this change is intended.

    -Joe


On Fri, Oct 9, 2009 at 11:43 AM, Joseph D. Darcy
mailto:joe.da...@sun.com>> wrote:

Please review this tiny doc fix to make EnumSet and
EnumMap just a bit
easier to find; patch below

-Joe

--- old/src/share/classes/java/lang/Enum.java2009-10-09
11:41:23.0 -0700
+++ new/src/share/classes/java/lang/Enum.java2009-10-09
11:41:23.0 -0700
@@ -44,6 +44,8 @@
 * @author  Josh Bloch
 * @author  Neal Gafter
 * @see Class#getEnumConstants()
+ * @see java.util.EnumSet
+ * @see java.util.EnumMap
 * @since   1.5
 */
public abstract class Enum>

Re: j.ul.Objects follow-up: methods for var-argification?

[Joseph D. Darcy]

Joshua Bloch wrote:

Joe,

I'm not sure I like this idea.  My one experience with forcing an 
array method to do double duty as varargs method was a disaster.  The 
method was Arrays.asList, and the result was Puzzler # 7 from "The 
Continuing Adventures of Java™Puzzlers: Tiger Traps."  Here it is:


*7. “Fib O’Nacci”*

public class Fibonacci {
private static final int LENGTH = 7;
public static void main(String[] args) {
int[] fib = new int[LENGTH];
fib[0] = fib[1] = 1; // First 2 Fibonacci numbers
for (inti = 2; i < LENGTH; i++)
fib[i] = fib[i -2] + fib[i -1];
System.out.println(Arrays.asList(fib));
}
}

The main moral of the puzzle was:

Use varargssparingly in your APIs
•It can hide errors and cause confusion
•This program wouldn't compile under 1.4

Arrays.hashCode, equals, and toString are already overloaded out the 
wazoo; adding varargs to the mix could be deadly.  Also, Arrays is not 
the place where people would go looking for what is essentially a 
hashing utility.  So I'm not in favor of varargifying the existing 
methods in Arrays, but I am in favor of adding a convenience method 
like this somewhere:


 /**
 * Generates a hash code for a sequence of input values. The hash 
code is
 * generated as if all the input values were placed into an array, 
and that

 * array were hashed by calling {...@link Arrays#hashCode(Object[])}.
 * 
 * This method is useful for implementing {...@link 
Object#hashCode()} on
 * objects containing multiple fields. For example, if an object 
that has
 * three  fields, {...@code x}, {...@code y}, and {...@code z}, one could 
write:

 * 
 * @Override public int hashCode() {
 * return Objects.hashCode(x, y, z);
 * }
 * 
 * Warning: When a single object reference is supplied, the 
returned
 * value does not equal the hash code of that object 
reference. This

 * value can be computed by calling {...@link #hashCode(Object)}.
 */
public static int hash(Object... components) {
return Arrays.hashCode(components);
}

Viewed in isolation, it's simple, straightforward, and will help 
people write high quality hashCode methods.  I don't think Objects is 
a bad place for it, but you could put it is a "hash utility" class if 
we wrote such a thing.




Okay; unless and until a hash utility is added somewhere, this 
hash(Object ...) can live in Objects.


-Joe

Re: First round of java.util.Objects for code review (bug 6797535)

[Joseph D. Darcy]

Joshua Bloch wrote:

Joe,

Hi.  I've attached a file containing the methods and a JTReg "basic 
test" for inclusion in your BasicObjectTests.  I adhered to your 
style, for easy integration. If you could take it from here, I'd be 
ever so grateful.


Will do.

Cheers,

-Joe



Thanks,

Josh

On Thu, Oct 8, 2009 at 6:21 PM, Joe Darcy > wrote:



I strongly suggest that you do add these two methods:

   /**
* Checks that the specified object reference is not {...@code
null}. This
* method is designed primarily for doing parameter
validation in methods
* and constructors, as demonstrated below:
* 
* public Foo(Bar bar) {
* this.bar = Objects.nonNull(bar);
* }
* 
*
* @param obj the object reference to check for nullity
* @return {...@code obj} if not {...@code null}
* @throws NullPointerException if {...@code obj} is {...@code null}
*/
   public static  T nonNull(T obj) {
   if (obj == null)
   throw new NullPointerException();
   return obj;
   }

   /**
* Checks that the specified object reference is not {...@code
null} and
* throws a customized {...@link NullPointerException} if it
is. This method
* is designed primarily for doing parameter validation in
methods and
* constructors with multiple parameters, as demonstrated
below:
* 
* public Foo(Bar bar, Baz baz) {
* this.bar = Objects.nonNull(bar, "bar must not be null");
* this.baz = Objects.nonNull(baz, "baz must not be null");
* }
* 
*
* @param obj the object reference to check for nullity
* @param message detail message to be used in the event
that a {...@code
*NullPointerException} is thrown
* @return {...@code obj} if not {...@code null}
* @throws NullPointerException if {...@code obj} is {...@code null}
*/
   public static  T nonNull(T obj, String message) {
   if (obj == null)
   throw new NullPointerException(message);
   return obj;
   }

They do a great job reducing the verbiage in validity-checking
of arguments that must not be null.


I've filed bug 6889858 "Add nonNull methods to java.util.Objects" for
these last two methods.  If you want to finish off the engineering
need for a changeset, some light tests, etc., I'll file the
Sun-internal paperwork for these.

Re: j.ul.Objects follow-up: methods for var-argification?

[Joseph D. Darcy]

Rémi Forax wrote:

Le 12/10/2009 19:25, Joseph D. Darcy a écrit :

Joshua Bloch wrote:

Joe,

I'm not sure I like this idea.  My one experience with forcing an 
array method to do double duty as varargs method was a disaster.  
The method was Arrays.asList, and the result was Puzzler # 7 from 
"The Continuing Adventures of Java™Puzzlers: Tiger Traps."  Here it is:


*7. “Fib O’Nacci”*

public class Fibonacci {
private static final int LENGTH = 7;
public static void main(String[] args) {
int[] fib = new int[LENGTH];
fib[0] = fib[1] = 1; // First 2 Fibonacci numbers
for (inti = 2; i < LENGTH; i++)
fib[i] = fib[i -2] + fib[i -1];
System.out.println(Arrays.asList(fib));
}
}

The main moral of the puzzle was:

Use varargssparingly in your APIs
•It can hide errors and cause confusion
•This program wouldn't compile under 1.4

Arrays.hashCode, equals, and toString are already overloaded out the 
wazoo; adding varargs to the mix could be deadly.  Also, Arrays is 
not the place where people would go looking for what is essentially 
a hashing utility.  So I'm not in favor of varargifying the existing 
methods in Arrays, but I am in favor of adding a convenience method 
like this somewhere:


 /**
 * Generates a hash code for a sequence of input values. The 
hash code is
 * generated as if all the input values were placed into an 
array, and that

 * array were hashed by calling {...@link Arrays#hashCode(Object[])}.
 * 
 * This method is useful for implementing {...@link 
Object#hashCode()} on
 * objects containing multiple fields. For example, if an object 
that has
 * three  fields, {...@code x}, {...@code y}, and {...@code z}, one could 
write:

 * 
 * @Override public int hashCode() {
 * return Objects.hashCode(x, y, z);
 * }
 * 
 * Warning: When a single object reference is supplied, the 
returned
 * value does not equal the hash code of that object 
reference. This

 * value can be computed by calling {...@link #hashCode(Object)}.
 */
public static int hash(Object... components) {
return Arrays.hashCode(components);
}

Viewed in isolation, it's simple, straightforward, and will help 
people write high quality hashCode methods.  I don't think Objects 
is a bad place for it, but you could put it is a "hash utility" 
class if we wrote such a thing.




Okay; unless and until a hash utility is added somewhere, this 
hash(Object ...) can live in Objects.


-Joe


In that case, we can also add some methods hash that avoid create an 
array

for let say 2 to 5 arguments:
hash(Object, Object), hash-Object, Object, Object), 
hash(Object,Object,Object,Object)

and hash(Object,Object,Object,Object,Object).



I don't think such methods are justified at present.

-Joe

Re: j.u.Objects follow-up: deepEquals(Object, Object)?

[Joseph D. Darcy]

Joshua Bloch wrote:
I don't think method really pays for itself.  If it belongs anywhere, 
it belongs in java.util.Arrays.


  Josh


I think there is room in the platform for this functionality.  Even if 
this is mostly used in tests, code used in tests is code too :-)


I think Objects is a better home for deepEquals(Object, Object) than 
Arrays since the arguments are not arrays and since it is a sibling 
method to equals(Object, Object).


-Joe

java.util.Objects, round two

[Joseph D. Darcy]

Hello.

After recent discussions on the list, the following methods will be 
included in round two of the evolution of java.util.Objects:


Under bug 6889858: Add nonNull methods to java.util.Objects:

 /**
* Checks that the specified object reference is not {...@code null}. This
* method is designed primarily for doing parameter validation in 
methods

* and constructors, as demonstrated below:
* 
* public Foo(Bar bar) {
* this.bar = Objects.nonNull(bar);
* }
* 
*
* @param obj the object reference to check for nullity
* @return {...@code obj} if not {...@code null}
* @throws NullPointerException if {...@code obj} is {...@code null}
*/
   public static  T nonNull(T obj);

   /**
* Checks that the specified object reference is not {...@code null} and
* throws a customized {...@link NullPointerException} if it is. This 
method

* is designed primarily for doing parameter validation in methods and
* constructors with multiple parameters, as demonstrated below:
* 
* public Foo(Bar bar, Baz baz) {
* this.bar = Objects.nonNull(bar, "bar must not be null");
* this.baz = Objects.nonNull(baz, "baz must not be null");
* }
* 
*
* @param obj the object reference to check for nullity
* @param message detail message to be used in the event that a {...@code
*NullPointerException} is thrown
* @return {...@code obj} if not {...@code null}
* @throws NullPointerException if {...@code obj} is {...@code null}
*/
   public static  T nonNull(T obj, String message);

Under bug 6891113:  More methods for java.util.Objects: deepEquals, 
hash, toString with default

   /**
* Returns {...@code true} if the arguments are deeply equal to each other
* and {...@code false} otherwise.
*
* Two {...@code null} values are deeply equal.  If both arguments are
* arrays, the algorithm in {...@link Arrays.deepEquals(Object[],
* Object[]) Arrays.deepEquals) is used to determine equality.
* Otherwise, equality is determined by using the {...@link Object#equals
* equals} method of the first argument.
*
* @return {...@code true} if the arguments are deeply equal to each other
* and {...@code false} otherwise
* @see Arrays#deepEquals(Object[], Object[])
* @see Objects#equals(Object, Object)
*/
   public static deepEquals(Object a, Object b);
  
   /**

* Returns the result of calling {...@code toString} on the first
* argument if the first argument is not {...@code null} and returns
* the second argument otherwise.
*
* @return the result of calling {...@code toString} on the first
* argument if it is not {...@code null} and the second argument
* otherwise.
* @see Objects#toString(Object)
*/
   public static toString(Object a, String nullDefault);

   /**
* Generates a hash code for a sequence of input values. The hash 
code is
* generated as if all the input values were placed into an array, 
and that

* array were hashed by calling {...@link Arrays#hashCode(Object[])}.
*
* This method is useful for implementing {...@link 
Object#hashCode()} on
* objects containing multiple fields. For example, if an object 
that has

* three  fields, {...@code x}, {...@code y}, and {...@code z}, one could 
write:
* 
* @Override public int hashCode() {
* return Objects.hashCode(x, y, z);
* }
* 
* Warning: When a single object reference is supplied, the returned
* value does not equal the hash code of that object reference. This
* value can be computed by calling {...@link #hashCode(Object)}.
*
* @return a hash value of the sequence of input values
* @see Arrays#hashCode
*/
   public static int hash(Object... components);

In addition, the Objects class will be explicitly marked as "final" to 
indicate its already implicit status as a non-instantiable, 
non-extendable class.


I've closed as "will not fix" the bug requesting to var-argify various 
constructors in String.


I'm open having being convinced that "toDefaultString(Object)" is a 
worthwhile addition to j.u.Objects as well.


Likewise, for "toDebugString(Object)", although someone else would have 
to specify, implement, and test that method.


-Joe

Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

[Joseph D. Darcy]

Hello.

Following up from threads earlier this year,

http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html

I'm willing and interested to sponsor getting String.join functionality 
into JDK 7.


To address this particular bug, I think there should be new "join" 
methods on String as opposed to a general "joiner" class.  A more 
general class could be added later.


Remi, please point to a current draft of the specification and 
implementation for your change.


Kevin, I'm interested in hearing your comments on the API design.

Thanks,

-Joe

Re: java.util.Objects, round two

[Joseph D. Darcy]

Paul Benedict wrote:

Joe,

I am confused over this warning:
  

* Warning: When a single object reference is supplied, the returned
* value does not equal the hash code of that object reference. This
* value can be computed by calling {...@link #hashCode(Object)}.



I first looked into Arrays#deepHashCode and did not see any companion
warning there; therefore I am presuming this is new functionality. 


No, the behavior is the same.  Objects.hash is just a var-arg wrapper 
around Arrays.hashCode(Object[]).  The semantic difference is that for 
Object.hash, one is passing a number of objects, which happen to get 
bundled into an array, whereas in Arrays.hashCode an array is being 
explicitly passed.



Two
questions remain based on looking at the javadoc alone and not knowing
its implementation:

For when a single object reference is supplied:
1) Why is the hash code not the hash code of the single object? Is
there harm in doing so?
  


As implied by the chain of javadocs, for a single object, hashcode + 31 
is returned via the List.hashCode algorithm on a single element list.


-Joe

Re: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]

[Joseph D. Darcy]

Jesús Viñuales wrote:

I agree with Stephen. There are a slew of validation methods that
would be beneficial, and if you really want to drive the JDK towards
standard validation, refactor them out into a Validation class. Look
at what Spring has written for themselves:

http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/ut


il/Assert.html
  

Paul



Fully agree with you both, Stephan and Paul. A Validation class  with a
broad perspective makes much more sense to me.
--Jesus

  


If such a validation class is added to the platform, the nonNull methods 
can be moved there.  Until then, they can live in Objects.


-Joe

Re: BigInteger.bitLength() can return negative result

[Joseph D. Darcy]

Dmitry Nadezhin wrote:
BigInteger is a class implementing arbitrary-precision integers. Of 
course, it is an idealization. Let's look at implementation limits of 
this type.


The bits are stored in "int[] mag" array. This sets the maximum bit 
length 32*(2^31 - 1).


The "BigInteger.magSerializedForm()" converts bits to "byte[]" array. 
Serialization of BigInteger will throw an exception on values with bit 
length larger than 8*(2^31 - 1).


The methods "BigInteger.bitLength()", "BigInteger.bitCount()", 
"BigInteger.getLowestSetBit()" return result as "int".
So they may wrap around when bit length is larger than "2^31 - 1". The 
method "BigInteger.toByteArray()" can fail on such values because it 
uses "bitLength()".


In fact, the output of this program
public static void main(String[] args) {
BigInteger x = BigInteger.ONE.shiftLeft(Integer.MAX_VALUE); // x = 
2^Integer.MAX_VALUE;

System.out.println("bitLength="+x.bitLength());
try {
byte[] bytes = x.toByteArray();
} catch (Exception e) {
e.printStackTrace(System.out);
}
}
is:
bitLength=-2147483648
java.lang.NegativeArraySizeException
at java_math.BigInteger.toByteArray(BigInteger.java:2689)


Yes, the internal bookkeeping of BigInteger is not robust when extremely 
large values are used.


Shouldn't BigInteger.bitLength()" conform its specification on all 
possible values of BigInteger ?

This can be achieved in different ways:
a) Don't change code but write about the wrap around in the 
specification of "bitLength()" and other methods ;

b) Change the return type of "bitLength()" from "int" to "long";


Should we break binary compatibility of a commonly used class by 
changing the return type to fix this problem?  Obviously not.


c) "bitLength()" throws an exception when bit length is larger than 
2^31 - 1;
d) All BigInteger constructors ensure that the bit length is no larger 
than 2^31 - 1;


d) is arguably the most correct approach to address the problem.  
However, I think the practical consequences of this flaw are low.


-Joe

Re: BigInteger.bitLength() can return negative result

[Joseph D. Darcy]

Dmitry Nadezhin wrote:


d) All BigInteger constructors ensure that the bit length is no 
larger than 2^31 - 1;


d) is arguably the most correct approach to address the problem.  
However, I think the practical consequences of this flaw are low.
Nevertheless, may I use this unimportant flaw as a lesson of Java bug 
fixing ?




No fix for the bug has yet been offered.

You're independently rediscovered a bug that has been in the platform 
for about 12 years.


-Joe

Re: JDK7 b74: Where is j.u.Objects?

[Joseph D. Darcy]

Paul Benedict wrote:

I saw in the release notes the tickets regarding j.u.Objects, but I
don't see the class in the javadoc:
http://download.java.net/jdk7/docs/api/java/util/package-summary.html

Thoughts?

Paul
  


I believe there was a problem in either generating or posting the b74 
docs and the currently posted docs are from b73.


-Joe

Re: JDK7 b74: Where is j.u.Objects?

[Joseph D. Darcy]

Upon further inspection, j.u.Objects is in the TL staging repository but 
has not yet hit the master.  j.u.Objects will be included in the next 
build TL integrates into.


-Joe

Paul Benedict wrote:

All the labels and titles on the API doc say its b74, so it must be
some generation problem.

On Fri, Oct 16, 2009 at 4:14 PM, Joseph D. Darcy  wrote:
  

Paul Benedict wrote:


I saw in the release notes the tickets regarding j.u.Objects, but I
don't see the class in the javadoc:
http://download.java.net/jdk7/docs/api/java/util/package-summary.html

Thoughts?

Paul

  

I believe there was a problem in either generating or posting the b74 docs
and the currently posted docs are from b73.

-Joe

Code review request for 6371401: java.math.BigInteger.shift(Integer.MIN_VALUE) throws StackOverflowError

[Joseph D. Darcy]

Hello.

Please review this simple improvement in handling an exceptional 
condition in BigInteger.  A stack overflow on an argument of 
BigInteger.shitf{Left, Right}(Integer.MIN_VALUE) is handled as an 
explicit ArithmeticException, the same exception used throughout 
BigInteger for other invalid inputs.


Patch below; webrev at
http://cr.openjdk.java.net/~darcy/6371401.0/

Thanks,

-Joe

--- old/src/share/classes/java/math/BigInteger.java2009-10-19 
17:37:36.0 -0700
+++ new/src/share/classes/java/math/BigInteger.java2009-10-19 
17:37:35.0 -0700

@@ -2051,6 +2051,8 @@
 *
 * @param  n shift distance, in bits.
 * @return {...@code this << n}
+ * @throws ArithmeticException if the shift distance is {...@code
+ * Integer.MIN_VALUE}.
 * @see #shiftRight
 */
public BigInteger shiftLeft(int n) {
@@ -2058,8 +2060,13 @@
return ZERO;
if (n==0)
return this;
-if (n<0)
-return shiftRight(-n);
+if (n<0) {
+if (n == Integer.MIN_VALUE) {
+throw new ArithmeticException("Shift distance of 
Integer.MIN_VALUE not supported.");

+} else {
+return shiftRight(-n);
+}
+}

int nInts = n >>> 5;
int nBits = n & 0x1f;
@@ -2097,13 +2104,20 @@
 *
 * @param  n shift distance, in bits.
 * @return {...@code this >> n}
+ * @throws ArithmeticException if the shift distance is {...@code
+ * Integer.MIN_VALUE}.
 * @see #shiftLeft
 */
public BigInteger shiftRight(int n) {
if (n==0)
return this;
-if (n<0)
-return shiftLeft(-n);
+if (n<0) {
+if (n == Integer.MIN_VALUE) {
+throw new ArithmeticException("Shift distance of 
Integer.MIN_VALUE not supported.");

+} else {
+return shiftLeft(-n);
+}
+}

int nInts = n >>> 5;
int nBits = n & 0x1f;
--- /dev/null2009-07-06 20:02:10.0 -0700
+++ new/test/java/math/BigInteger/ExtremeShiftingTests.java
2009-10-19 17:37:36.0 -0700

@@ -0,0 +1,49 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version

+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+/*
+ * @test
+ * @bug 6371401
+ * @summary Tests of shiftLeft and shiftRight on Integer.MIN_VALUE
+ * @author Joseph D. Darcy
+ */
+import java.math.*;
+import static java.math.BigInteger.*;
+
+public class ExtremeShiftingTests {
+public static void main(String... args) {
+try {
+ONE.shiftLeft(Integer.MIN_VALUE);
+throw new RuntimeException("Should not reach here.");
+} catch (ArithmeticException ae) {
+; // Expected
+}
+
+try {
+ONE.shiftRight(Integer.MIN_VALUE);
+throw new RuntimeException("Should not reach here.");
+} catch (ArithmeticException ae) {
+; // Expected
+}
+}
+}

Re: Code review request for 6371401: java.math.BigInteger.shift(Integer.MIN_VALUE) throws StackOverflowError

[Joseph D. Darcy]

Alan Bateman wrote:

Joseph D. Darcy wrote:

Hello.

Please review this simple improvement in handling an exceptional 
condition in BigInteger.  A stack overflow on an argument of 
BigInteger.shitf{Left, Right}(Integer.MIN_VALUE) is handled as an 
explicit ArithmeticException, the same exception used throughout 
BigInteger for other invalid inputs.


Patch below; webrev at
http://cr.openjdk.java.net/~darcy/6371401.0/

Thanks,

-Joe
This looks okay to me. Minor comment is that ExtremeShiftingTests 
probably doesn't need to import java.math.




Import removed; thanks,

-Joe

Re: Code review request for 6371401: java.math.BigInteger.shift(Integer.MIN_VALUE) throws StackOverflowError

[Joseph D. Darcy]

Dmitry Nadezhin wrote:

I want to make comments to this change from point of view of the post
"BigInteger.bitLength() can return negative results".

Suppose that the range of valid BigInteger is restiricted either to
[-2^Integer.MAX_VALUE , 2^Integer.MAX_VALUE-1]
or to
[-2^Integer.MAX_VALUE+1, 2^Integer.MAX_VALUE-1].


Which is not the case today because BigInteger allows the creation of 
partially overflowed values, values so large that various internal 
counters in the class overflow or otherwise misbehave.



In this case the exact result of x.shiftRight(Integer.MIN_VALUE)
will be 0 for x==0;
will be out of BigInteger range for any x != 0.

The exact result of x.shiftLeft(Integer.MIN_VALUE)
will be 0 for any valid x >= 0;
and will be -1 for any valid x < 0.

So it seems to me that x.shiftLeft(Integer.MIN_VALUE) should never 
throw ArithmeticException



and x.shiftRight(Integer.MIN_VALUE) should throw ArithmeticException 
only when x is nonzero.


That is arguably more correct, but in my estimation screening out 
MIN_VALUE as an unsupported value is reasonable.


If an when BigInteger is made robust in the face of huge values, these 
decisions and be reexamined.


-Joe

Code review request for 6560935: BigInteger.modPow() throws ArithmeticException for negative exponent

[Joseph D. Darcy]

Hello.

Please review this small doc clarification; modPow is not defined for 
negative exponents unless the BigInteger being operated on is relatively 
prime to the modulus.  There are a few stylistic javadoc cleanups in the 
patch below too.


Webrev:
http://cr.openjdk.java.net/~darcy/6560935.0/

Thanks,

-Joe

--- old/src/share/classes/java/math/BigInteger.java2009-10-20 
14:40:35.0 -0700
+++ new/src/share/classes/java/math/BigInteger.java2009-10-20 
14:40:35.0 -0700

@@ -478,7 +478,7 @@

/**
 * Constructs a randomly generated BigInteger, uniformly 
distributed over

- * the range {...@code 0} to (2{...@code numBits} - 1), 
inclusive.
+ * the range 0 to (2{...@code numBits} - 1), inclusive.
 * The uniformity of the distribution assumes that a fair source of 
random

 * bits is provided in {...@code rnd}.  Note that this constructor always
 * constructs a non-negative BigInteger.
@@ -1332,7 +1332,7 @@
 *
 * @param  val value by which this BigInteger is to be divided.
 * @return {...@code this / val}
- * @throws ArithmeticException {...@code val==0}
+ * @throws ArithmeticException if {...@code val} is zero.
 */
public BigInteger divide(BigInteger val) {
MutableBigInteger q = new MutableBigInteger(),
@@ -1352,7 +1352,7 @@
 * @return an array of two BigIntegers: the quotient {...@code (this / 
val)}
 * is the initial element, and the remainder {...@code (this % 
val)}

 * is the final element.
- * @throws ArithmeticException {...@code val==0}
+ * @throws ArithmeticException if {...@code val} is zero.
 */
public BigInteger[] divideAndRemainder(BigInteger val) {
BigInteger[] result = new BigInteger[2];
@@ -1371,7 +1371,7 @@
 * @param  val value by which this BigInteger is to be divided, and the
 * remainder computed.
 * @return {...@code this % val}
- * @throws ArithmeticException {...@code val==0}
+ * @throws ArithmeticException if {...@code val} is zero.
 */
public BigInteger remainder(BigInteger val) {
MutableBigInteger q = new MutableBigInteger(),
@@ -1547,7 +1547,7 @@
 *
 * @param  m the modulus.
 * @return {...@code this mod m}
- * @throws ArithmeticException {...@code m <= 0}
+ * @throws ArithmeticException {...@code m} ≤ 0
 * @see#remainder
 */
public BigInteger mod(BigInteger m) {
@@ -1566,7 +1566,9 @@
 * @param  exponent the exponent.
 * @param  m the modulus.
 * @return thisexponent mod m
- * @throws ArithmeticException {...@code m <= 0}
+ * @throws ArithmeticException {...@code m} ≤ 0 or the exponent is
+ * negative and this BigInteger is not relatively
+ * prime to m.
 * @see#modInverse
 */
public BigInteger modPow(BigInteger exponent, BigInteger m) {
@@ -2015,7 +2017,7 @@
 *
 * @param  m the modulus.
 * @return {...@code this}-1 {...@code mod m}.
- * @throws ArithmeticException {...@code  m <= 0}, or this BigInteger
+ * @throws ArithmeticException {...@code  m} ≤ 0, or this BigInteger
 * has no multiplicative inverse mod m (that is, this 
BigInteger

 * is not relatively prime to m).
 */
@@ -2449,7 +2451,7 @@
/**
 * Returns {...@code true} if this BigInteger is probably prime,
 * {...@code false} if it's definitely composite.  If
- * {...@code certainty} is {...@code  <= 0}, {...@code true} is
+ * {...@code certainty} is ≤ 0, {...@code true} is
 * returned.
 *
 * @param  certainty a measure of the uncertainty that the caller is

Code review request for 6891113: More methods for java.util.Objects: deepEquals, hash, toString with default

[Joseph D. Darcy]

Hello.

Please review this webrev to add deepEquals(Object, Object), 
hash(Object...) and toString(Object, String) to j.u.Objects:


6891113 More methods for java.util.Objects: deepEquals, hash, toString 
with default

http://cr.openjdk.java.net/~darcy/6891113.0/

Thanks,

-Joe

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

[Joseph D. Darcy]

Yes, to my aesthetics the static call

   join(" ", "A", "call", "to");

is more sensible looking than

   " ".join("A", "call", "to");

Especially when a call like

   " ".join("Foo")

will not have " " in the returned String.  However, the platform would 
certainly be improved with any version of String.join compared to not 
having it.


-Joe

Joe Kearney wrote:

Hi,

From the peanut gallery, it seems to me that there is a genuine reason 
to leave join as a static method (if we're not going after the 
google-collections approach of a Joiner class 
) 
in that split acts on one existing String, whereas join creates one 
from others. On which object would you call the join method? The 
separator? I know this was covered on this list before, but it still 
strikes me as looking a little wierd.


",".join("a", "b", "c")

versus

Joiner.on(",").join("a", "b", "c")


Thanks,
Joe

2009/10/23 Mark Reinhold mailto:m...@sun.com>>

> Date: Fri, 23 Oct 2009 10:10:35 +0200
> From: Rémi Forax mailto:fo...@univ-mlv.fr>>

> Le 23/10/2009 03:53, Joe Darcy a écrit :
>> Following up on this, what is the exact revised proposal?
>>
>> In java.lang.String:
>>
>>public static String join(String separator, Iterable
objects);
>>public static String join(String separator, Object[] objects);
>>public static String join(String separator, Object first,
Object... rest);
>>
>> with analogous methods in StringBuffer and StringBuilder return
that type,
>> respectively, instead of String?
>
> I don't know. In my opinion, the main problem with join
specified using
> static methods is that split is not currently specified as a static
> method.  Because join is the dual of split, one could find the
usage of
> static methods weird.

I agree.  The join methods should be instance methods, not static
methods.

- Mark

Re: Code review request for 6891113: More methods for java.util.Objects: deepEquals, hash, toString with default

[Joseph D. Darcy]

Joe Darcy wrote:

Neal Gafter wrote:
There should be a shortcut in Arrays.deepEquals0 when e1==e2.  


That shortcut is in Objects.deepEquals(Object a, Object b) and 
Arrays.deepEquals on lines 3947 and 3948.  The nested call in 
deepEquals0 is to deepEquals rather than deepEquals0 so the shortcut 
is used on all levels.


Also, the code will throw an assertion error if e1!=null and e2==null 
(which can occur when called from Arrays.deepEquals).


Good catch!  Yes, my mistake; only e1 != null is guaranteed when being 
called from Arrays.deepEquals.


The simplest way to fix these is to move the if statements from 
Objects.deepEquals into Arrays.deepEquals0.  Alternately, change the 
call of Arrays.deepEquals0 in Arrays.deepEquals to a call to 
Objects.deepEquals.  If you do the latter, you might as well move all 
the code of deepEquals0 into the body of Object.deepEquals.


For correctness, I think removing the assertion that e2 != null in 
deepEquals0 is sufficient.


Thanks,

-Joe



The code with both asserts failed the Arrays regression tests with when 
run with system assertions enabled.  When the second assertion was 
removed, the tests passed with system assertions enabled and I've push 
that version.


Thanks,

-Joe

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

[Joseph D. Darcy]

Stephen Colebourne wrote:

Not wishing to confuse the debate, but perhaps the correct place for
this is a static Strings class, that parallels Objects.

We all know that there are lots of possible methods for such a class,
but even if JDK7 had just a few, that would be a good start.

Joe, would you be prepared to sponsor a Strings class, and see join on
there instead of String?
  


No.

While I believe a "StringUtils" class would have been appropriate early 
in the platform's life to host more advanced string manipulation 
facilities, I don't think adding such a class now is the right design.


IMO, the join method, whether it is an instance method or a static one, 
should live in java.lang.String.


-Joe


Stephen


2009/10/23 Kevin Bourrillion :
  

FYI,
While I certainly love my "Joiner" baby, and while y'all have blanket
permission to make use of any of our code you want, I think it's entirely
appropriate for the JDK to just hit the 80% case with a static method
directly on String.
(And yes, the fact that split() is an instance method is a false parallel.)


On Fri, Oct 23, 2009 at 8:58 AM, Joe Kearney 
wrote:


Hi,

From the peanut gallery, it seems to me that there is a genuine reason to
leave join as a static method (if we're not going after the
google-collections approach of a Joiner class) in that split acts on one
existing String, whereas join creates one from others. On which object would
you call the join method? The separator? I know this was covered on this
list before, but it still strikes me as looking a little wierd.

  

",".join("a", "b", "c")


versus
  

Joiner.on(",").join("a", "b", "c")


Thanks,
Joe

2009/10/23 Mark Reinhold 
  

Date: Fri, 23 Oct 2009 10:10:35 +0200
From: Rémi Forax 
  
Le 23/10/2009 03:53, Joe Darcy a écrit :
  

Following up on this, what is the exact revised proposal?

In java.lang.String:

   public static String join(String separator, Iterable objects);
   public static String join(String separator, Object[] objects);
   public static String join(String separator, Object first, Object...
rest);

with analogous methods in StringBuffer and StringBuilder return that
type,
respectively, instead of String?


I don't know. In my opinion, the main problem with join specified using
static methods is that split is not currently specified as a static
method.  Because join is the dual of split, one could find the usage of
static methods weird.
  

I agree.  The join methods should be instance methods, not static
methods.

- Mark



--
Kevin Bourrillion @ Google
internal:  http://go/javalibraries
external: guava-libraries.googlecode.com

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

[Joseph D. Darcy]

Neal Gafter wrote:
You can hardly add any methods to Object, event static methods, 
without breaking compatibility, because they get added to every the 
overload set if the name is used for methods in existing code.


Indeed, which is why these methods were added in a new class to prevent 
unwanted changes to the meaning of source code.


-Joe



On Mon, Oct 26, 2009 at 9:29 AM, David Holmes <mailto:david.hol...@sun.com>> wrote:


    Joseph D. Darcy wrote:

Stephen Colebourne wrote:

Joe, would you be prepared to sponsor a Strings class, and
see join on
there instead of String?
 



No.


+1.

It was necessary to introduce Arrays and Collections for utility
methods because there was no place else to locate the static
methods. But for String these should simply be static String methods.

But that also means I'd prefer to see additional static methods in
Object, rather than the added Objects class.

Personally I think a java.util.Utilities class containing nested
static classes for Objects, Arrays, Collections, Strings, Maps
etc, might have been a better way to organize such things. But
it's probably too late now as the duplication would be very ugly.

David

Re: Code review request for 6897550 BigInteger constructor should use local cached String length

[Joseph D. Darcy]

Andrew John Hughes wrote:

2009/11/3 Joseph D. Darcy :
  

Hello.

Please review this simple change to replace several calls to val.length()
with an already cached copy of val.length(); patch below.

6897550 BigInteger constructor should use local cached String length
http://cr.openjdk.java.net/~darcy/6897550.0/

-Joe

--- old/src/share/classes/java/math/BigInteger.java2009-11-03
13:57:31.0 -0800
+++ new/src/share/classes/java/math/BigInteger.java2009-11-03
13:57:31.0 -0800
@@ -292,7 +292,7 @@

   if (radix < Character.MIN_RADIX || radix > Character.MAX_RADIX)
   throw new NumberFormatException("Radix out of range");
-if (val.length() == 0)
+if (len == 0)
   throw new NumberFormatException("Zero length BigInteger");

   // Check for at most one leading sign
@@ -303,7 +303,7 @@
   // No leading sign character or at most one leading sign
character
   if (index1 == 0 || index2 == 0) {
   cursor = 1;
-if (val.length() == 1)
+if (len == 1)
   throw new NumberFormatException("Zero length
BigInteger");
   }
   if (index1 == 0)
@@ -342,7 +342,7 @@
   // Process remaining digit groups
   int superRadix = intRadix[radix];
   int groupVal = 0;
-while (cursor < val.length()) {
+while (cursor < len) {
   group = val.substring(cursor, cursor += digitsPerInt[radix]);
   groupVal = Integer.parseInt(group, radix);
   if (groupVal < 0)





Looks good to me.  This is all in one method, and len doesn't change
its value (maybe make it final?)
  


Correct on the nature of len; will add final before I push.

Thanks,

-Joe

Code review request for 6897550 BigInteger constructor should use local cached String length

[Joseph D. Darcy]

Hello.

Please review this simple change to replace several calls to 
val.length() with an already cached copy of val.length(); patch below.


6897550 BigInteger constructor should use local cached String length
http://cr.openjdk.java.net/~darcy/6897550.0/

-Joe

--- old/src/share/classes/java/math/BigInteger.java2009-11-03 
13:57:31.0 -0800
+++ new/src/share/classes/java/math/BigInteger.java2009-11-03 
13:57:31.0 -0800

@@ -292,7 +292,7 @@

if (radix < Character.MIN_RADIX || radix > Character.MAX_RADIX)
throw new NumberFormatException("Radix out of range");
-if (val.length() == 0)
+if (len == 0)
throw new NumberFormatException("Zero length BigInteger");

// Check for at most one leading sign
@@ -303,7 +303,7 @@
// No leading sign character or at most one leading sign 
character

if (index1 == 0 || index2 == 0) {
cursor = 1;
-if (val.length() == 1)
+if (len == 1)
throw new NumberFormatException("Zero length 
BigInteger");

}
if (index1 == 0)
@@ -342,7 +342,7 @@
// Process remaining digit groups
int superRadix = intRadix[radix];
int groupVal = 0;
-while (cursor < val.length()) {
+while (cursor < len) {
group = val.substring(cursor, cursor += digitsPerInt[radix]);
groupVal = Integer.parseInt(group, radix);
if (groupVal < 0)

Re: Adding constant for line.separator and friends

[Joseph D. Darcy]

Mark Reinhold wrote:

Date: Mon, 09 Nov 2009 23:07:05 -0800
From: Martin Buchholz 



  

On Mon, Nov 9, 2009 at 21:54, Mark Reinhold  wrote:


...
Yet ... how much of a problem is this outside of the JDK itself and,
more generally, for new code rather than old?

If there are n (for n <= 43) problematic uses in the JDK then we could
just fix those without defining any new public API.  For new code we
should encourage people to use String.format("...%n...") rather than
access the line.separator property explicitly.
  

Hacking on Formatter is how I got here.

String.format("%n")" is both at risk of throwing SecurityException
(because Formatter does not use doPrivileged;
my proposal here is a step to fixing that)
and is rather slow.
Too slow for performance-sensitive uses.



Okay, fair enough.

  


Martin,

If we're settled on a method in System, please send a revised spec and 
I'll file the ccc paperwork.


-Joe

Re: Request for sponsor: 4421494 infinite loop while parsing double literal

[Joseph D. Darcy]

Dmitry Nadezhin wrote:

Hello Joe,

Thank you for the sponsorship of the bug 4421494.

I can also prepare a fix for another related bug 4396272
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272

The bug 4396272 is blinking because it occurs only when HotSpot 
chooses double value set and it doesn't occur

with double-extended-exponent value set.
The suggested fix will be in FloatingDecimal too, though in other line.

What is more convenient to you
a) if I combine both fixes of 4421494 and 4396272 in a single 
changeset now;
b) if I postpone submitting of the fix 4396272 until 4421494 is in the 
JDK

?


If the first fix is just a one-liner, combining the two fixes is easier 
overall.


Cheers,

-Joe


 -Dima

Dmitry Nadezhin wrote:

http://bugs.sun.com/view_bug.do?bug_id=4421494
https://bugs.openjdk.java.net/show_bug.cgi?id=100119

Summary: This old bug report says that Double.parseDouble(s) hangs 
for decimal strings
in range (Double.MIN_NORMAL-0.5*Double.MIN_VALUE,Double.MIN), and 
returns
incorrect result for decimal string 
Double.MIN_NORMAL-0.5*Double.MIN_VALUE.


This is because current code in FloatingDecimal.doubleValue() 
incorrectly
defines the condition when nextDown(dValue) - dValue == 
-0.5*ulp(dValue). The
current code considers that these are all numbers 2^n which are 
represented as
normal doubles, and nexDown(dValue) - dValue == -1.0*ulp(dValue) for 
other

doubles (subnormal or not 2-powers).
However, this is not correct for dValue == Double.MIN_VALUE, because
nextDown(Double.MIN_NORMAL) - Double.MIN_NORMAL == 
-1.0*ulp(Double.MIN_NORMAL).


The suggested change
-if ( (bigIntNBits == 1) && (bigIntExp > 
-expBias) ){
+if ( (bigIntNBits == 1) && (bigIntExp > 
-expBias+1) ){
redefines the condition so that dValue == Double.MIN_NORMAL doesn't 
satisfy it.


-Dima


Hello.

Thank you for the proposed fix; that certainly sounds like a 
plausible cause of the problem.


I'm a bit swamped now, but I'll try to look at verifying the fix and 
sponsoring getting it back into the JDK within the next few weeks.


-Joe

Re: hg: jdk7/tl/jdk: 6907177: Update jdk tests to remove unncessary -source and -target options

[Joseph D. Darcy]

Jonathan Gibbons wrote:

Andrew John Hughes wrote:

2009/12/4  :
  

Changeset: 1755493c5774
Author:darcy
Date:  2009-12-03 18:19 -0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1755493c5774

6907177: Update jdk tests to remove unncessary -source and -target options
Reviewed-by: ohair

! test/demo/jvmti/hprof/CpuOldTest.java

  


[snip]


! test/sun/tools/jconsole/ResourceCheckTest.sh





Was this really necessary? The options, as far as I can see, were
doing no harm but this change means that a compiler that defaults to a
version < 1.5 (e.g. ecj) will now fail to compile the tests.
  
This is a JDK test suite and there is no guarantee that any other 
compiler can be used. All sorts of JDK-specific options may be passed 
to the compiler, runtime and other tools in these tests.




Yes, these tests are part of the JDK 7 regression test suite.  
Interoperability with other compilers, even other compilers from related 
code bases like OpenJDK 6, is a non-goal.


Having the old -source options in the tests was at least in a small way 
reducing the effectiveness of the test suite since the default -source 
setting is now 7.  Using of new language features in tests, even tests 
not targeting those language features is certainly encouraged.


As explained in my code review request on corelib-dev, many of the 
-source directives dated to back in JDK 5 before the default sourced was 
upped from 1.4 to 5.  Tests written later in JDK 5 that use JDK 5 
language features didn't have explicit -source settings.


While the build environment for most programs should explicitly set 
source, target, and encoding,

   "Build Advice: Set Source, Target, and Encoding"
   http://blogs.sun.com/darcy/entry/build_advice_set_source_target
the regressions tests of the JDK itself are (usually) an exception.

-Joe

Re: package javax.lang missing in OpenJDK sources

[Joseph D. Darcy]

Ulf Zibis wrote:

Hi,

in class java.lang.Character in javadoc of method 
isJavaIdentifierStart(char ch) I find reference:

@seejavax.lang.model.SourceVersion#isIdentifier(CharSequence)

But there is no package javax.lang in OpenJDK sources. =-O


Yes there is, but is lives in the langtools repository rather than the 
jdk repo.


-Joe

Re: Need reviewers, jdk7 testing changes

[Joseph D. Darcy]

Kelly O'Hair wrote:


Need reviewer for JDK7 testing changes, e.g. testing via:
  cd jdk/make && gmake all images && cd ../test && gmake jdk_all

6906210: Fix another minor typo in test/Makefile
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-test-changes4/webrev/

Dan had pointed out my typo in the jdk/test/Makefile ($->$$)
but when I started running and re-running the tests I ran into
more unstable tests. This webrev includes fixes to 3 tests
and unfortuntately more additions to the ProblemList file.

Tests added to the ProblemList:


A few comments on problem list membership:

366 # Need to be marked othervm, or changed to be samevm safe
367 java/lang/annotation/ParameterAnnotations.java  
generic-all


This test uses a security manager.

499 # Problems with rounding add failures on solaris-sparcv9 and -server
500 java/math/BigDecimal/AddTests.java solaris-sparcv9

If this test is failing on a particular platform, that is indicative of 
a HotSpot bug on that platform.


502 # Problems on windows with samevm, missing inputstream close()?
503 # Also times out on solaris-sparcv9 -server
504 java/math/BigInteger/BigIntegerTest.java generic-all

Some uses of input/output are not guarded by the try-finally {close 
resource} structure. I've filed 6908541 "Bad resource management in 
java/math/BigInteger/BigIntegerTest.java" for this.


505
506 # Should be samevm? But seems problematic with samevm on windows
507 java/math/BigInteger/ModPow65537.java

From a quick look, the test uses some security infrastructure, but 
there is nothing that would seem problematic for samevm operation.

Re: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags"

[Joseph D. Darcy]

Andrew John Hughes wrote:

2009/12/10 Joe Darcy :
  

Hello.

While doing a coredocs build, I noticed once again some javadoc warnings
coming out of the javax.accessibility package and I decided to fix them; the
patch is below and the full webrev is at

http://cr.openjdk.java.net/~darcy/4891262.0/




Again, good to see these being fixed.  What do you think to the idea
of backporting these fixes to OpenJDK6 for the next release (b19)?
It's not a major issue, but would improve the documentation packages
being installed by GNU/Linux distros.
  


Andrew, if you wish, you have my approval to apply the fix for 4891262 
(just pushed into JDK 7 TL) and also


6909070 "Missing package statements in java.text.Bidi @see links"

to OpenJDK 6 build 18, the current build.

-Joe

Re: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags"

[Joseph D. Darcy]

Andrew John Hughes wrote:

2009/12/10 Joseph D. Darcy :
  

Andrew John Hughes wrote:


2009/12/10 Joe Darcy :

  

Hello.

While doing a coredocs build, I noticed once again some javadoc warnings
coming out of the javax.accessibility package and I decided to fix them;
the
patch is below and the full webrev is at

http://cr.openjdk.java.net/~darcy/4891262.0/




Again, good to see these being fixed.  What do you think to the idea
of backporting these fixes to OpenJDK6 for the next release (b19)?
It's not a major issue, but would improve the documentation packages
being installed by GNU/Linux distros.

  

Andrew, if you wish, you have my approval to apply the fix for 4891262 (just
pushed into JDK 7 TL) and also

6909070 "Missing package statements in java.text.Bidi @see links"

to OpenJDK 6 build 18, the current build.

-Joe




Thanks.  I'll do that once I get the current timezone patch off my
stack.  I suggest we leave a full blitz of such warnings until b19
though, otherwise b18 has the potential to go on for ever :)
  


Build 19 would be fine too, but at least for now there will be at most 
one or two more doc warnings patches from me in the near future :-)


-Joe

Code review request to fix more javadoc build warnings, 6909563: Javadoc build warnings in rmi, security, management

[Joseph D. Darcy]

Hello.

Another round of javadoc build warnings fixes for review; this time 
mostly in rmi, but one in security and another in management.


Patch below; webrev at
http://cr.openjdk.java.net/~darcy/6909563.0/

-Joe

--- 
old/src/share/classes/java/lang/management/PlatformManagedObject.java
2009-12-10 21:30:19.0 -0800
+++ 
new/src/share/classes/java/lang/management/PlatformManagedObject.java
2009-12-10 21:30:19.0 -0800

@@ -32,7 +32,7 @@
 * for monitoring and managing a component in the Java platform.
 * Each platform managed object has a unique
 * object name
- * for the {...@linkplain ManagementFactory.getPlatformMBeanServer
+ * for the {...@linkplain ManagementFactory#getPlatformMBeanServer
 * platform MBeanServer} access.
 * All platform MXBeans will implement this interface.
 *
--- old/src/share/classes/java/rmi/activation/Activatable.java
2009-12-10 21:30:20.0 -0800
+++ new/src/share/classes/java/rmi/activation/Activatable.java
2009-12-10 21:30:20.0 -0800

@@ -73,7 +73,7 @@
 * can be handled properly.
 *
 * This method invokes the {...@link
- * exportObject(Remote,String,MarshalledObject,boolean,port)
+ * #exportObject(Remote,String,MarshalledObject,boolean,int)
 * exportObject} method with this object, and the specified location,
 * data, restart mode, and port.  Subsequent calls to {...@link #getID}
 * will return the activation identifier returned from the call to
@@ -120,7 +120,7 @@
 * can be handled properly.
 *
 * This method invokes the {...@link
- * 
exportObject(Remote,String,MarshalledObject,boolean,port,RMIClientSocketFactory,RMIServerSocketFactory)
+ * 
#exportObject(Remote,String,MarshalledObject,boolean,int,RMIClientSocketFactory,RMIServerSocketFactory)

 * exportObject} method with this object, and the specified location,
 * data, restart mode, port, and client and server socket factories.
 * Subsequent calls to {...@link #getID} will return the activation
@@ -312,7 +312,7 @@
 * separately, so that exceptions can be handled properly.
 *
 * This method invokes the {...@link
- * 
exportObject(Remote,String,MarshalledObject,boolean,port,RMIClientSocketFactory,RMIServerSocketFactory)
+ * 
#exportObject(Remote,String,MarshalledObject,boolean,int,RMIClientSocketFactory,RMIServerSocketFactory)

 * exportObject} method with the specified object, location, data,
 * restart mode, and port, and null for both client and
 * server socket factories, and then returns the resulting activation
--- old/src/share/classes/java/rmi/registry/LocateRegistry.java
2009-12-10 21:30:21.0 -0800
+++ new/src/share/classes/java/rmi/registry/LocateRegistry.java
2009-12-10 21:30:21.0 -0800

@@ -187,7 +187,7 @@
 * host that accepts requests on the specified port.
 *
 * The Registry instance is exported as if the static
- * {...@link UnicastRemoteObject.exportObject(Remote,int)
+ * {...@link UnicastRemoteObject#exportObject(Remote,int)
 * UnicastRemoteObject.exportObject} method is invoked, passing the
 * Registry instance and the specified 
port as

 * arguments, except that the Registry instance is
@@ -213,7 +213,7 @@
 *
 * The Registry instance is exported as if
 * the static {...@link
- * 
UnicastRemoteObject.exportObject(Remote,int,RMIClientSocketFactory,RMIServerSocketFactory)
+ * 
UnicastRemoteObject#exportObject(Remote,int,RMIClientSocketFactory,RMIServerSocketFactory)

 * UnicastRemoteObject.exportObject} method is invoked, passing the
 * Registry instance, the specified port, the
 * specified RMIClientSocketFactory, and the specified
--- 
old/src/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java
2009-12-10 21:30:22.0 -0800
+++ 
new/src/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java
2009-12-10 21:30:22.0 -0800

@@ -138,7 +138,6 @@
 * instance
 * @throws  Throwable the exception to throw from the method invocation
 * on the proxy instance
- * @see
 **/
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable
--- 
old/src/share/classes/java/security/cert/CertPathValidatorException.java
2009-12-10 21:30:23.0 -0800
+++ 
new/src/share/classes/java/security/cert/CertPathValidatorException.java
2009-12-10 21:30:22.0 -0800

@@ -216,7 +216,7 @@
/**
 * Returns the reason that the validation failed. The reason is
 * associated with the index of the certificate returned by
- * {...@link getIndex}.
+ * {...@link #getIndex}.
 *
 * @return the reason that the validation failed, or
 *BasicReason.UNSPECIFIED if a reason has not been

core-libs-dev@openjdk.java.net

[Joseph D. Darcy]

Hello.

Please review my fix for

6908131 Pure Java implementations of StrictMath.floor(double) 
&StrictMath.ceil(double)

http://cr.openjdk.java.net/~darcy/6908131.0/

I've asked Doug Priest, one of Sun's numerical experts, to review the 
floor/ceil algorithm and testing.  I've incorporated his feedback and he 
has approved those aspects of the changes.  The JDK integration has not 
yet been looked over.


Thanks,

-Joe

core-libs-dev@openjdk.java.net

[Joseph D. Darcy]

Christian Thalinger wrote:

On Mon, 2009-12-14 at 01:31 -0800, Joseph D. Darcy wrote:
  

Hello.

Please review my fix for

6908131 Pure Java implementations of StrictMath.floor(double) 
&StrictMath.ceil(double)

http://cr.openjdk.java.net/~darcy/6908131.0/

I've asked Doug Priest, one of Sun's numerical experts, to review the 
floor/ceil algorithm and testing.  I've incorporated his feedback and he 
has approved those aspects of the changes.  The JDK integration has not 
yet been looked over.



Not a review, but did you think about implementing the whole FDLIBM in
Java, as done here:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001970.html
  


Yes, porting FDLIBM to Java has been an oft-delayed "nice to have" 
project of mine.  It is not obvious from looking at my ceil/floor code, 
but it started with the FDLIBM versions of those algorithms.  The tests 
are new and greatly outnumber the code changes, as it typical in this 
line of work :-)  I think getting an all-java StrictMath library would 
be best done as a series of small batches so floor/ceil could be a start.


-Joe

core-libs-dev@openjdk.java.net

[Joseph D. Darcy]

Alan Bateman wrote:

Joseph D. Darcy wrote:

Hello.

Please review my fix for

6908131 Pure Java implementations of StrictMath.floor(double) 
&StrictMath.ceil(double)

http://cr.openjdk.java.net/~darcy/6908131.0/

I've asked Doug Priest, one of Sun's numerical experts, to review the 
floor/ceil algorithm and testing.  I've incorporated his feedback and 
he has approved those aspects of the changes.  The JDK integration 
has not yet been looked over.


Thanks,

-Joe
For the JDK integration you'll need to remove the symbols from 
make/java/java/mapfile-vers. Also, there are probably references in 
the reorder-* files that can be removed (although they aren't 
maintained now).




Webrev so updated:
http://cr.openjdk.java.net/~darcy/6908131.1

Thanks,

-Joe