and the resulting non-lambda classes moved here for review.
There will be a separate change and review for the StringJoiner changes
in lamda-dev.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
of failing
tests.
http://cr.openjdk.java.net/~ksrini/7189944/webrev.0/
Thanks
Kumar
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
that, the code and the changes are actually pretty simple.
s'marks
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
) {
+ return contentEquals((AbstractStringBuilder)cs);
+}
+} else {
+return contentEquals((AbstractStringBuilder)cs);
}
-return true;
}
// Argument is a String
if (cs.equals(this))
--
Jim Gish
OK. With that in mind, here's an update where I leave contentEquals(
StringBuffer ) in place (adding a clarifying spec), and defer the
synchronization as I had it to the contentEquals( CharSequence ) method:
diff --git a/src/share/classes/java/lang/String.java
Hopefully, this will address most, if not all of the suggestions made to
date.
Jim
diff -r f37afaa214e9 src/share/classes/java/lang/StringBuffer.java
--- a/src/share/classes/java/lang/StringBuffer.javaMon Jun 25
14:22:42 2012 -0400
+++ b/src/share/classes/java/lang/StringBuffer.java
, contained in the string buffer, does not exceed
Missing comma at 2 locations of:
* object but does not synchronize on the source ({@code sb}).
* object, but does not synchronize on the source ({@code sb}).
-Ulf
Am 25.06.2012 21:32, schrieb Jim Gish:
Hopefully, this will address most
sequence contained in the string buffer does not exceed
* the capacity, it is not necessary to allocate a new internal
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
that StringBuffer.add/insert has a
Jim,
You may want to replace add with append if you are intending to
reference the actual method name and not the generic operation.
Additionally, you may want to use {@code ...} to show this context.
Thanks,
Dave
--
Jim Gish | Consulting Member of Technical Staff
be satisfied
Mike
On Jun 21 2012, at 11:10 , Jim Gish wrote:
Taking all the previous comments into consideration, here's an update:
diff -r fc575c78f5d3 src/share/classes/java/lang/StringBuffer.java
--- a/src/share/classes/java/lang/StringBuffer.javaSun Jun 10 10:29:27 2012
+0100
+++ b/src/share
On 06/12/2012 01:40 AM, David Holmes wrote:
Hi Jim,
On 12/06/2012 7:59 AM, Jim Gish wrote:
While triaging outstanding String bugs, I was looking at 4247235, (spec
str) StringBuffer.insert(int, char[]) specification is inconsistent
Although the description is out of date w.r.t. the current
I'm triaging all outstanding String bugs/RFEs.
In light of Mike's recent changes to hashing, I'm seeking opinions on
what should be done with bug # 6932858 -- (str) Tune hashCode() of
String. Although we can't change the specification for
String.hashCode(), we would certainly be willing to
places) and
tell the user straight off the effect of passing null.
Cheers
Jim Gish
On 05/25/2012 09:48 AM, Mike Duigou wrote:
A non-material comment is that there are a couple of style changes that I found
annoying. Everyone is an expert on such matters, I'm not, but the one that
bugged me a bit was adding the space after the cast, eg:
(toffset (long) value.length - len)
I
I'm just now reading State of the Lambda and beginning to get a handle
on this discussion, which makes sense to me today (and didn't yesterday
morning). (All this stuff about reduce is definitely taking me back
to my APL days. s - ./list -- a concat/reduce operation (sans the
delimiter of
.
Thanks,
Jim Gish
.
David
On 19/04/2012 5:47 AM, Jim Gish wrote:
I've updated the copyrights to just have first and current year.
Jim
On 04/18/2012 03:33 PM, Jim Gish wrote:
Description:
Another trivial javadoc update - fixed existing @see ref and added a
few more representative of the exception usage
Patch
Description: just a trivial change to add in Iterator#next() as a @see
reference
(Alan and I discussed the possibilities here of completeness vs brevity,
and we opted for brevity. There are actually other uses, particularly
in Deque , and Queue but thought it best to keep it simple)
java.lang.Float#Float(String)
+ * @see java.lang.Integer#parseInt(String)
* @since JDK1.0
*/
public
Thanks,
Jim Gish
I've updated the copyrights to just have first and current year.
Jim
On 04/18/2012 03:15 PM, Jim Gish wrote:
Description: just a trivial change to add in Iterator#next() as a
@see reference
(Alan and I discussed the possibilities here of completeness vs
brevity, and we opted for brevity
I've updated the copyrights to just have first and current year.
Jim
On 04/18/2012 03:33 PM, Jim Gish wrote:
Description:
Another trivial javadoc update - fixed existing @see ref and added a
few more representative of the exception usage
Patch:
diff -r 00f5665ee0ea
src/share/classes/java
good.
Just some background on this one. Jim Gish just recently moved into
the JDK team in Oracle (he was in WebLogic land). I suggested a few
bugs to get used to building the JDK, running the tests, learning the
processes etc. Now that you've clean-ed up this test it means I need
to go find
101 - 122 of 122 matches
Mail list logo
