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

+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 P

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

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.open

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

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 th

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

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 J

Re: How can I trigger a @Serial warning?

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 se

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

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

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

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

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

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 a

Re: SourceVersion::feature

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 mode

Re: SourceVersion::feature

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

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

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 t

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

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

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

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

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

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 flag

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

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 1

Re: Java float, double, StrictMath correction?

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

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

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 publi

Re: Java Floating Points.

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 use

Re: Why does we still need StrictMath?

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 rep

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

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 recen

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

Vote: yes -Joe

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

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 pl

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

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

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

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:

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

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

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

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 +25

Re: Miscellaneous improvements to "jar".

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

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

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 cor

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

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 sep

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

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 "LinkageExc

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

; 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:[email protected]>> wrote: Hello. Please review the patch below to fix 6857789: (reflect) Create common

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

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 jus

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

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 th

Re: Spec update for Class#getDeclaredMethods()

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

Re: Spec update for Class#getDeclaredMethods()

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 expe

Re: execvpe and glibc 2.10

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 thes

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

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

Re: execvpe and glibc 2.10

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,

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

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

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

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 ann

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

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 Annota

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

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.java

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

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

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

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! L

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

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

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

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 reg

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

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 compa

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

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

Re: New Methods/Features in JDK7

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.ja

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

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 d

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

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 w

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

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 method

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

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-argume

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

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;

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

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

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

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 yo

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

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 o

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

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 st

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

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 dete

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

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

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

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 i

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

, + * 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

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

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 @@

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

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)

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

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

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

on than this change deserves! -Joe -Neal On Fri, Oct 9, 2009 at 4:13 PM, Joe Darcy <mailto:[email protected]>> wrote: Neal Gafter wrote: Do EnumSet and EnumMap exist on all platform profiles? They exist on JDK 7 where this change is intended. -Joe

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

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

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

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, Jos

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

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

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

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 i

java.util.Objects, round two

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

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

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. T

Re: java.util.Objects, round two

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 Array

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

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.

Re: BigInteger.bitLength() can return negative result

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.magSerialized

Re: BigInteger.bitLength() can return negative result

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

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

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

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

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

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

l 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

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

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

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

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^I

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

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/

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

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

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 o

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

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

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

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 yo

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

unwanted changes to the meaning of source code. -Joe On Mon, Oct 26, 2009 at 9:29 AM, David Holmes <mailto:[email protected]>> wrote: Joseph D. Darcy wrote: Stephen Colebourne wrote: Joe, would you be prepared to sponsor a Strings class, and se

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

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

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

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/mat

Re: Adding constant for line.separator and friends

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 <= 4

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

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

Re: hg: jdk7/tl/jdk: 6907177: Update jdk tests to remove unncessary -source and -target options

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

Re: package javax.lang missing in OpenJDK sources

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 re

Re: Need reviewers, jdk7 testing changes

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 i

Re: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags"

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/

Re: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags"

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

Code review request to fix more javadoc build warnings, 6909563: Javadoc build warnings in rmi, security, management

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 200

[email protected]

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 f

[email protected]

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

[email protected]

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 t

  1   2   3   4   >