Hi, Stuart
On 11/6/13 5:31 PM, Stuart Marks wrote:
In several places the specs mention returning new strings. This is
overspecified; it's sufficient to return a string that satisfies the
required properties. In some cases the current implementation doesn't
create a new string -- for example,
I'm curious about why this was done:
*** 4452,4462
public final boolean removeAll(Collection? c) {
! Objects.requireNonNull(c);
boolean modified = false;
--- 4495,4505
public final boolean removeAll(Collection? c) {
! if (c ==
On 12/11/13 9:24 PM, Mike Duigou wrote:
Hello all;
In the review for JDK-8029795 Paul Sandoz noted that HashMap.computeIfAbsent
would generate a spurious access event for keys mapped to null when the
function returned null. This patch corrects that behaviour.
Hi,
I would like to backport this fix from 8 to 7u.
https://bugs.openjdk.java.net/browse/JDK-7199674
The source code changes apply cleanly to 7u from the 8 changeset,
however the makefile changes needed to be tweaked.
makefiles/CompileNativeLibraries.gmk did not exist in 7, so equivalent
(forgot to include macosx-port-...@openjdk.java.net)
Hi,
I would like to backport this fix from 8 to 7u.
https://bugs.openjdk.java.net/browse/JDK-7199674
The source code changes apply cleanly to 7u from the 8 changeset,
however the makefile changes needed to be tweaked.
Please review my changes for:
https://bugs.openjdk.java.net/browse/JDK-8027640
The webrev is here:
http://cr.openjdk.java.net/~bchristi/8027640/webrev.00/
This is a small cleanup to reconcile the String[last]indexOf() spec with
longstanding behavior. There are no changes to executable code.
On 2/25/14 4:41 AM, Paul Sandoz wrote:
On Feb 25, 2014, at 12:52 AM, Brent Christian brent.christ...@oracle.com
wrote:
Please review my changes for:
https://bugs.openjdk.java.net/browse/JDK-8027640
The webrev is here:
http://cr.openjdk.java.net/~bchristi/8027640/webrev.00
File under chipping away at test stabilization issues.
https://bugs.openjdk.java.net/browse/JDK-6835233
I've done some repeated runs of this test on my Linux machine. The test
fails every time with 6u3. It fails intermittently on 7 (after 145
iterations for 7u45, and 62 iterations for
On 2/28/14 9:27 AM, Stuart Marks wrote:
I guess there is some risk of adding new intermittent failures, but
tackling @ignore'd tests is important too.
Right - the main risk is that we will see this test fail again at some
point in the future. I'll be keeping an eye out for that.
Thanks
Hi, Ivan
This sounds like an issue we saw in FX a while ago with imprecise timers
on Windows. If it is, you might check out:
https://bugs.openjdk.java.net/browse/JDK-6435126
It describes a workaround to enable higher-precision timing on Windows
(using a long-sleeping daemon thread). That
Please review the fix for JDK-8049373. It applies only to 8u.
The JBS issue is not public, but the general problem is that some closed
changes related to JDK-8044473 incorrectly ended up being added to the
compact 1 profile. The changes in question depend on the management
APIs, which are
Please review my fix for:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8034032
Webrev:
http://cr.openjdk.java.net/~bchristi/8034032/webrev.0/
Within jdk/src/macosx/native/java/util/prefs/MacOSXPreferencesFile.m,
there is a pattern of making blocks of toCF() calls, where
later toCF() calls are
Thanks, Chris!
On 8/7/14 9:24 AM, Chris Hegarty wrote:
This looks ok to me Brent, and I agree with your conservative approach.
-Chris.
On 6 Aug 2014, at 22:45, Brent Christian brent.christ...@oracle.com wrote:
Please review my fix for:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8034032
Hi, Claes
I've looked over the latest changes, and they look good to me. I can
sponsor this. Note that we need approval from a Reviewer.
One small nitpick from me:
2914:
If the text is left-justified, then aren't we padding on the right? I
would call this padRight.
Thanks,
-Brent
On
I can push this change, Claes.
-Brent
I had to make an update to satisfy jcheck, and neglected to specify the
user when re-committing, so I'm listed as the author. Sorry!
-Brent
On 9/24/14 2:16 PM, Brent Christian wrote:
I can push this change, Claes.
-Brent
At present, the JDK port for OS X gets its value for os.name from a JRS
function exported by the Apple Java Runtime Support framework.
Historically this has either been Mac OS X, or Mac OS X Server, but
there have been reports that this could change at any time, e.g.
to just OS X. This would
/hotspot-rt/hotspot/test/closed/rev/40505e5a55e8
Note that official documentation from apple suggest: contains(OS X)
https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html
14.11.2012 2:50, Brent Christian wrote:
At present, the JDK port for OS X gets its value for os.name from
Any more comments on this?
-Brent
On 11/14/12 1:23 PM, Brent Christian wrote:
Thanks, Sergey.
It's good that we standardized on the recommended usage within the JDK
in order to stay ahead of a possible change to the value of ProductName
in /System/Library/CoreServices/SystemVersion.plist
Hi,
I've prepared a JDK 8 fix for 8003228 [1]. The webrev is here:
http://cr.openjdk.java.net/~bchristi/8003228/webrev.00/
JPRT passes on all platforms (with the exception of two known bugs[2]).
There was some recent discussion related to this - see [3].
Thanks,
-Brent
[1]
Forgot a regtest - now included w/ v.01:
http://cr.openjdk.java.net/~bchristi/8003228/webrev.01/
Thanks,
-Brent
On 12/20/12 10:52 AM, Brent Christian wrote:
Hi,
I've prepared a JDK 8 fix for 8003228 [1]. The webrev is here:
http://cr.openjdk.java.net/~bchristi/8003228/webrev.00/
JPRT
On 12/21/12 7:33 AM, Alan Bateman wrote:
I also think it's important that the folks on macosx-port-dev that have
been complaining about this help us test it out, particularly folks that
work in Asian locales. I don't know how many of them build the jdk so
you might need to send a reminder once
Thanks, Naoto.
If there are no other comments, I'll need someone to push this for me.
Thanks,
-Brent
On 12/21/12 3:09 PM, Naoto Sato wrote:
Hi Brent,
The change looks good to me. Sorry for the delay, as I was taking a half
day off.
Naoto
On 12/20/12 2:20 PM, Brent Christian wrote:
Forgot
thought that webrev would effectively extract the diffs even when
files were moved around.
Naoto
On 1/10/13 9:49 AM, Brent Christian wrote:
Hi,
The test case for 8003228 fails in certain environments. Also the
version that was pushed was missing a couple small changes.
The code changes to fix
11:13 AM, Brent Christian wrote:
Thanks, Naoto.
AFAICT, in a case like this there where a file is moved *and* changes
are made
to it, webrev shows that the new file is renamed from the old file,
but doesn't
provide cdiffs/sdiffs/etc for the code changes.
'hg diff' behaves the same way WRT the code
, but if you list the new and
old file
names at the same line in the list file, the webrev should generate
the diff for
you.
-Sherman
On 1/10/13 11:13 AM, Brent Christian wrote:
Thanks, Naoto.
AFAICT, in a case like this there where a file is moved *and* changes
are made to it, webrev shows
On 1/11/13 9:54 AM, Chris Hegarty wrote:
On 11/01/2013 17:50, Brent Christian wrote:
I did an 'hg mv' of the directory containing the (two) test files. But I
then had to 'hg export' to send the changeset for pushing. I'm guessing
Yes, I noticed this before. 'hg export' and 'hg mv
Hi,
This test started failing after 8003228 [1] was putback (setting
sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch a
.jar stored in a directory named with two-byte characters.
The code comments in the test case state that (on Unix) it expects
LC_ALL to be set (to
On 2/21/13 7:33 PM, Kumar Srinivasan wrote:
A nit
- LC_ALL + LC_ALL + \n +
+ LC_ALL= + LC_ALL + \n +
Done, thanks.
If Mac is the only system affected by this, should we make the checks for
LC* and LANG specific to Macs since other platforms don't have this issue ?
I am concerned this
(and LC_ALL= output
change) is here:
http://cr.openjdk.java.net/~bchristi/8006039/webrev.01/
Thanks,
-Brent
On 2/21/13 4:34 PM, Brent Christian wrote:
Hi,
This test started failing after 8003228 [1] was putback (setting
sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch a
.jar
On 2/25/13 10:53 AM, Brent Christian wrote:
On 2/22/13 10:22 AM, Naoto Sato wrote:
check not only C but also other locales that do not use UTF-8
encoding.
I would like to make the test more robust (per 8008761), though my focus
at the moment is to avoid a test failure on our automated test
A couple small things:
HashMap:
It might be nice to have a comment or two on the new, dual-purpose of
'threshold': perhaps in the comments for inflateTable(), and/or at the
field declaration.
ArrayList:
Is there an extra set of ()'s around (minCapacity DEFAULT_CAPACITY) ?
Thanks,
-Brent
Hi,
Please review my changes for 8005698 : Handle Frequent HashMap
Collisions with Balanced Trees.
For HashMap and LinkedHashMap, we would like to duplicate the technique
(and some of the code) that the latest ConcurrentHashMap[1] uses for
handling hash collisions: use of balanced trees to
needed anyway, due to the recent jtreg update)
The new webrev is here:
http://cr.openjdk.java.net/~bchristi/8005698/webrev.01/
Thanks,
-Brent
On 5/13/13 9:48 AM, Brent Christian wrote:
Hi,
Please review my changes for 8005698 : Handle Frequent HashMap
Collisions with Balanced Trees.
For HashMap
contortions. In the end, the extra complexity wasn't worth it, so it's
not included.
The whole thought
of doing this though is suspect (so I'm happy to see it
not being done)
Glad to hear that taking it out was the right move. :)
Thanks,
-Brent
On 05/22/13 16:50, Brent Christian wrote:
I have
On 5/28/13 3:09 AM, Doug Lea wrote:
To better enable and simplify future improvements, could you
do this -- nest the tree classes within HashMap?
Done.
Also, a note on spliterators: I had added these in the
least disruptive way (knowing that major changes were coming)
by checking exact
more stuff here.
Indeed. I don't know the answer.
InPlaceOpsCollisions::
- The @run directives run the wrong class (an error I have made
myself...).
Dang! Thanks - fixed.
-Brent
On May 28 2013, at 13:03 , Brent Christian wrote:
On 5/28/13 3:09 AM, Doug Lea wrote:
To better enable
, initialized in constructor,
UNSAFE restored and used in readObject().
Thanks,
-Brent
On 5/29/13 11:39 AM, Brent Christian wrote:
On 5/28/13 9:13 PM, Mike Duigou wrote:
Hashtable/WeakHashMap::
- I assume that the JVM falls over dead if the security manager
doesn't allow access to the property
On 5/31/13 7:10 AM, Alan Bateman wrote:
I've read through the latest webrev, overall very good work.
I had to read splitTreeBin a few times to convince myself as to how the
keys re-hash. I wonder if would be helpful to beef up the comment on
this method.
I think that's a good idea:
---
On 6/1/13 9:59 AM, Doug Lea wrote:
On cross-checking with ConcurrentHashMap, all looks OK except that
it should include a fix for a problem introduced once when changing
comparison orders and not picked up until recently retesting CHM. (sorry.)
Here's a diff against webrev 0.3
Thank you. I
Hi, Paul
If a HashMap is created via serialization or clone(), we don't check if
the table needs resizing when adding entries, but still need to check if
a bin should be converted to a TreeBin. In this case, putForCreate()
calls createEntry() directly, instead of addEntry().
Thanks,
-Brent
Thanks for the reviews, everyone. I will change the nits mentioned.
And I need a sponsor.
Thanks,
-Brent
On 6/12/13 9:10 AM, Mike Duigou wrote:
Looks good to me.
Mike
On Jun 11 2013, at 13:32 , Brent Christian wrote:
Hi,
Please review my fix for 8010325. Some background
from the
make/java/java/FILES_java.gmk file? I suspect it could break builds for
people still using the old build system on jdk8.
regards,
Sean.
On 12/06/13 17:30, Brent Christian wrote:
Thanks for the reviews, everyone. I will change the nits mentioned.
And I need a sponsor.
Thanks,
-Brent
On 6/12/13 7:55 PM, David Holmes wrote:
Something of an aside but ...
On 13/06/2013 3:45 AM, Martin Buchholz wrote:
Hi Brent,
Thanks for doing this.
Your webrev does not include mercurial changeset information, which I
think
is supported by recent webrevs.
Given the changeset has to be
FWIW, the HashMap/LinkedHashMap/Hashtable/WeakHashMap changes look good
to me.
-Brent
On 6/17/13 9:43 PM, Mike Duigou wrote:
Now updated again with additional tests and, as these things go, fixes. I was
able to use LockStep to exercise the checkedNavigable{Set/Map} and
Please review my fix for 8011194 : Apps launched via double-clicked
.jars have file.encoding value of US-ASCII on Mac OS X
http://bugs.sun.com/view_bug.do?bug_id=8011194
In most cases of launching a Java app on Mac (from the cmdline, or from
a native .app bundle), reading and displaying UTF-8
On 7/28/13 10:13 PM, David Holmes wrote:
On 27/07/2013 3:53 AM, Brent Christian wrote:
Please review my fix for 8011194 : Apps launched via double-clicked
.jars have file.encoding value of US-ASCII on Mac OS X
http://bugs.sun.com/view_bug.do?bug_id=8011194
In most cases of launching a Java
reported
by the OS is likely to cause a different set of problems.
Scott
On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi,
On Tue, 30 Jul 2013, David Holmes wrote:
On 30/07/2013 5:54 AM, Brent Christian wrote:
On 7/28/13 10:13 PM, David Holmes wrote
On 7/30/13 4:28 PM, Naoto Sato wrote:
On 7/30/13 4:06 PM, David DeHaven wrote:
I was about to chime in that UTF-8 has been the preferred encoding for
(stored) text on Mac OS X as long as I've been hacking on it (think
Rhapsody), so why is this even an issue?
Judging from the docs, nl_langinfo
Looks fine to me, though I'm not a Reviewer (but I think I contributed
a fair number of those warnings O:).
One question: why was enext added?:
1249 EntryK,V enext = (EntryK,V) newTable[i];
1250 e.next = enext;
Thanks,
-Brent
On 8/6/13 2:11 PM, Dan Smith wrote:
Please review this warnings
Hi,
I did a before/after run with the changes using Doug Lea's MapCheck
microbenchmark [1]. I tested java.util.HashMap with Object, String, and
Integer types.
It should be mentioned this was a quick check for any major performance
changes: 2 iterations, run by hand on my own (relatively
Hi, Doug
I like this approach.
The subclassing used for nodes/entries and trees looks good, given the
constraints. The before/after references that HashMap.TreeNode inherits
from LinkedHashMap.Entry are superfluous when trees are used by a
HashMap, but IMO we can live with that as trees in
On 8/12/13 8:41 AM, Alan Bateman wrote:
On 12/08/2013 14:26, harold seigel wrote:
The change to the MakeClasslist tool to use TraceClassLoadingPreorder
was made prior to my changes. The following code has been in
MakeClasslist.java for a long time. I was unable to determine who had
made this
On 8/14/13 3:34 AM, Paul Sandoz wrote:
If no one else volunteers i can try and sort this out and sync up
stuff from the current HashMap/LinkedHashMap (e.g. forEachRem. as
reported by Remi) and the lint warnings in one go, and submit for
review.
That would be great, Paul.
One thing on my
On 8/22/13 5:01 AM, Paul Sandoz wrote:
On Aug 21, 2013, at 6:47 PM, Paul Sandoz paul.san...@oracle.com wrote:
I updated the webrev and replaced TreeBinSplitBackToEntries.java with:
Please review my changes for 7199674
(http://bugs.sun.com/view_bug.do?bug_id=7199674).
This improves how Java .app bundles work when they've been signed for
the Mac App Sandbox. Specifically, it changes how the user.home system
property is set.
For apps signed for the App Sandbox, user.home
Hi, Nick. Thanks for your feedback. I'm glad to hear from someone who
has experience with App Store deployment.
On 9/6/13 2:17 PM, Nicholas Rahn wrote:
If you're saying that NSHomeDirectory is the correct behaviour for the Java
user.home property, then I have to disagree. On every other
Adding a little to what Dave said, based on my understanding...
On 9/10/13 3:36 PM, David DeHaven wrote:
Nicholas Rahn wrote:
In my app, the user selects where he wants to export individual
files, such as CSVs and PDFs. These are files he'll use outside of
my app.
If user.home points to the
On 9/11/13 11:09 AM, Nicholas Rahn wrote:
On David DeHaven wrote:
In my app, I have an export dialog where the user can select the
file to export as well as choose some other export options. In
that dialog, after the user has selected the file to export (via
the file selection dialog), I
Please review my fix to remove the jdk.map.useRandomSeed system property
added earlier in jdk8.
Some history is in the bug report,
http://bugs.sun.com/view_bug.do?bug_id=8024009
HashMap and LinkedHashMap stopped using the random hash seed as of
8023463. This change removes the code to read
On 9/12/13 1:09 AM, Alan Bateman wrote:
On 12/09/2013 01:13, Brent Christian wrote:
Please review my fix to remove the jdk.map.useRandomSeed system
property added earlier in jdk8.
It's good to see this going away, the changes (and clean-up) look good
to me too.
Thanks guys.
Can someone push
Replying to Alan and Mike...
On 9/6/13 2:27 AM, Alan Bateman wrote:
On 05/09/2013 22:30, Brent Christian wrote:
I don't know Cocoa memory management but from a quick look at the
NSAutoreleasePool docs then what you seems to be right. Folks on
macosx-port-dev would be better to comment
Please review this change for 8025173, HashMap.put() replacing an
existing key can trigger a resize().
A description of the problem can be found in the bug report:
http://bugs.sun.com/view_bug.do?bug_id=8025173
Thanks to Doug Lea for sending in the diff for HashMap.java.
Webrev is here:
On 9/26/13 6:11 AM, Alan Bateman wrote:
On 25/09/2013 15:19, Brent Christian wrote:
The fix looks right to me.
Thanks.
One comment on the test is that testItr is
using raw types, is there any reason for thaht?
Pure laziness! Here, this one's nicer:
http://cr.openjdk.java.net/~bchristi
On 9/25/13 4:03 PM, Martin Buchholz wrote:
Looks good.
I would only suggest the stylistic improvement of using proper /**
javadoc comments even for private test methods instead of /*
The comments were meant as internal documentation and not real
javadoc. After dabbling with some doclint
/13 1:51 AM, Paul Sandoz wrote:
On Oct 4, 2013, at 7:28 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 03/10/2013 16:31, Brent Christian wrote:
Please review my fix for 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses
iterator position
There are two possible code paths
On 10/9/13 3:12 AM, Alan Bateman wrote:
On 08/10/2013 20:55, Brent Christian wrote:
I've beefed up the test case
Thanks for the update and expanding the test. I skimmed over the new
test cases and they looks good.
Thanks.
There are a few commented out cases and
it's not clear why
Hi,
Please review this draft JEP for:
More memory-efficient internal representation for Strings
https://bugs.openjdk.java.net/browse/JDK-8054307
Thanks,
Brent
Hi,
The
java/lang/ClassLoader/deadlock/GetResource.java
test has started causing problems for Hotspot nightly testing. A real
fix is being worked on under [1], but in the meantime, this test should
be added to the ProblemList.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8068347
The
Thanks, Chris.
On 12/30/14 12:52 AM, Chris Hegarty wrote:
I’m ok with this Brent.
-Chris.
On 29 Dec 2014, at 21:43, Brent Christian brent.christ...@oracle.com wrote:
Hi,
The
java/lang/ClassLoader/deadlock/GetResource.java
test has started causing problems for Hotspot nightly testing
/15 4:01 PM, Brent Christian wrote:
The code in bug 8071667 [1] passes a mappingFunction to
computeIfAbsent() which itself put()s a sufficient number of
additional entries into the HashMap to cause a resize/rehash. As
a result, computeIfAbsent() doesn't add the new entry at the
proper place
On 2/5/15 12:46 AM, Paul Sandoz wrote:
On Feb 5, 2015, at 1:36 AM, Brent Christian
brent.christ...@oracle.com wrote:
I prefer this approach of discouraging/preventing side-effects via
CME, rather than allowing them.
...
Regarding the default methods:
Would we be able to make a best-effort
Hi,
The code in bug 8071667 [1] passes a mappingFunction to
computeIfAbsent() which itself put()s a sufficient number of additional
entries into the HashMap to cause a resize/rehash. As a result,
computeIfAbsent() doesn't add the new entry at the proper place in the
HashMap.
While one
)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:745)
On 1/23/15 4:15 PM, Brent Christian wrote:
Hi,
Please review this test case update.
Bug:
https
Hi,
Please review this test case update.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8068578
Webrev:
http://cr.openjdk.java.net/~bchristi/8068578/webrev.0/
The test relies on creating a new URLClassLoader and using it to load a
subclass of ObjectOutputStream. The system classloader is cast
Hi, Bernd
The initial discussion of the change that set TREEIFY_THRESHOLD to 8 (it
was initially 16) can be read here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018685.html
...continuing here...
Hi,
Please review my changes for 8071667 : HashMap.computeIfAbsent() adds
entry that HashMap.get() does not find
Bug:
https://bugs.openjdk.java.net/browse/JDK-8071667
Webrev+specdiff:
http://cr.openjdk.java.net/~bchristi/8071667/webrev.2/
The fix is to detect structural changes made by the
out the
larger test into the smaller tests. Meaning we test all combinations regardless
of which fail, and each will be reported so there is no need to print out test
info. If you need help with that i can provide an example.
Thanks,
Paul.
On Mar 18, 2015, at 6:46 PM, Brent Christian brent.christ
On 3/20/15 4:40 AM, Chris Hegarty wrote:
Yes, the spec changes look good.
Thanks.
Brent, would you mind if I assign 8062841 [1] to you, so you can
bring in the CHM implementation changes? Also maybe CHM could be
added to the test?
I've assigned it to myself.
-Brent
Here's the latest:
http://cr.openjdk.java.net/~bchristi/8071667/webrev.4/
That should have everything.
Thanks again,
-Brent
On 3/20/15 2:52 AM, Paul Sandoz wrote:
On Mar 19, 2015, at 11:31 PM, Brent Christian
brent.christ...@oracle.com wrote:
Hi, Paul
Thank you for the suggested doc
that modifying the list from the lambda will
result in a CME. It's not clearly spelled out, but then, modifying the
collection this way falls outside the intended usage of these methods.
Thanks for any additional feedback.
-Brent
On 2/6/15 1:12 PM, Brent Christian wrote:
diff -r 330dcd651f3b
Hi, Paul
On 3/10/15 8:29 AM, Paul Sandoz wrote:
On the Map.compute* methods.
Perhaps we can reuse similar language to that we added for Matcher:
* The mapping function should not modify this map during computation.
* This method will, on a best-effort basis, throw a
* ConcurrentModification
/HashMap.html#computeIfAbsent-K-java.util.function.Function-
On 3/11/15 2:05 AM, Paul Sandoz wrote:
On Mar 11, 2015, at 12:34 AM, Brent Christian brent.christ...@oracle.com
wrote:
Hi, Paul
On 3/10/15 8:29 AM, Paul Sandoz wrote:
On the Map.compute* methods.
Perhaps we can reuse similar
On 3/21/15 6:43 AM, Paul Sandoz wrote:
On Mar 20, 2015, at 10:23 PM, Brent Christian brent.christ...@oracle.com
wrote:
Here's the latest:
http://cr.openjdk.java.net/~bchristi/8071667/webrev.4/
That should have everything.
Looks good (i assumed all but the test code has remained unchanged
Hello,
Please review this small javadoc change.
It was discovered that some codePoint-related methods in StringBuffer
are missing documentation for throwing IndexOutOfBoundsException. The
methods are:
codePointAt(int)
codePointBefore(int)
codePointCount(int,int)
of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037
Oracle Java Engineering
1 Network Drive x-apple-data-detectors://34/0
Burlington, MA 01803 x-apple-data-detectors://34/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPad
On Apr 13, 2015, at 6:49 PM, Brent Christian
Hi,
Please review this fix, courtesy of Peter Levart (thanks!), that I would
like to get in.
https://bugs.openjdk.java.net/browse/JDK-8029891
http://cr.openjdk.java.net/~bchristi/8029891/webrev.0/
There is some discussion of it in the bug report, starting at 2014-12-31.
The problem, as
Hi, Mandy. Thanks for having a look.
On 5/11/15 12:09 PM, Mandy Chung wrote:
~/WORK/8029891/plevartI'd like Daniel's suggestion to have the load*
method to putAll entries in one go after the input reader/stream/xml
file is loaded and parsed rather than adding one entry at a time.
I also like
an Enumeration which is also an
Iterator which supports removal of elements, that might have
unintended side effects WRT to concurrency subclassing.
best regards,
-- daniel
On 15/05/15 21:09, Brent Christian wrote:
On 5/13/15 8:53 AM, Mandy Chung wrote:
On May 12, 2015, at 2:26 PM, Peter Levart
On 5/13/15 8:53 AM, Mandy Chung wrote:
On May 12, 2015, at 2:26 PM, Peter Levart peter.lev...@gmail.com
wrote:
On 05/12/2015 10:49 PM, Mandy Chung wrote:
But I think it should be pretty safe to make the
java.util.Properties object override all Hashtable methods and
delegate to internal CMH so
On 4/14/15 12:10 AM, Alan Bateman wrote:
On 13/04/2015 23:49, Brent Christian wrote:
Hello,
Please review this small javadoc change.
It was discovered that some codePoint-related methods in StringBuffer
are missing documentation for throwing IndexOutOfBoundsException. The
methods
Hi,
Please review my change for:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8064956
Webrev:
http://cr.openjdk.java.net/~bchristi/8064956/
After clearing some internal dependencies following the removal of the
extension mechanism from JDK 9[1], we can now remove 4 extension-related
classes
Looks reasonable to me.
-Brent
On 7/28/15 9:14 AM, Steve Drach wrote:
Please review the following simple fix for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8062849
https://bugs.openjdk.java.net/browse/JDK-8062849.
-
# HG changeset patch
# User sdrach
#
Hi,
Please review my doc/spec change (no code) for 8138824.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138824
Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/
Specdiff:
http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html
This change addresses a
can be
omitted.
It puts the link where the reader sees the reference and is just as
informative.
Otherwise, looks good.
Roger
On 10/7/2015 7:30 PM, Brent Christian wrote:
Hi,
Please review my doc/spec change (no code) for 8138824.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138824
Webrev
Sure, I'll write something. -B
On 10/08/2015 08:57 AM, Naoto Sato wrote:
Hi Brent,
I wonder whether we should add a negative test case, in which
lowercasing/uppercasing on the originals would differ but
String.equalsIgnoreCase() returns true.
Naoto
On 10/7/15 4:30 PM, Brent Christian wrote
wo strings?
The current implementation returns true if str2.startsWith(str1) is true.
Yes, it also seems to me that true should only be returned if the
Strings' lengths match.
Fixes will be in the pushed version.
Thanks, Naoto.
-Brent
On 10/12/15 2:44 PM, Brent Christian wrote:
FYI: up
FYI: updated webrev & specdiff with test case, and Roger's suggestion
for using @link:
http://cr.openjdk.java.net/~bchristi/8138824/webrev.1/
http://cr.openjdk.java.net/~bchristi/8138824/specdiff.1/overview-summary.html
Thanks,
-Brent
On 10/8/15 10:22 AM, Brent Christian wrote:
Sure,
Hi, Mandy
I looked through the jdk code. I think it's looking quite good. I just
noticed some small details to consider fixing up before pushing.
Docs:
StackWalker.StackFrame.getClassName():
the "binary name" link seems to be broken
(StackWalker.java line 100)
StackWalker.getInstance(Set
Hi,
Please review my change for
8144552 : java/lang/StackWalker/LocalsAndOperands.java fails with
java.lang.NullPointerException
Bug:
https://bugs.openjdk.java.net/browse/JDK-8144552
Webrev:
http://cr.openjdk.java.net/~bchristi/8144552/webrev.0/
It's possible for the
1 - 100 of 497 matches
Mail list logo
