Hi Andrew, Aleksey, Rémi,
Thanks for looking at the patch. Could one or more of you add yourselves as
reviewers on the corresponding CSR?
https://bugs.openjdk.java.net/browse/JDK-8215025
Thanks,
s'marks
On 12/7/18 5:55 AM, Andrew Dinn wrote:
On 07/12/2018 10:31, Remi Forax wrote:
what about adding "tries to" to the @implSpec section
As much as is reasonably practical, the {@code hashCode} method defined
by class {@code Object} tries to return distinct integers for distinct objects.
An alg
On 12/7/18 4:51 AM, Claes Redestad wrote:
One possible improvement would to wrap coder() == aString.coder() in a
method isSameCoder(String):
private boolean isSameCoder(String other) {
return COMPACT_STRINGS ? coder == other.coder : true;
}
.. one less method call, but still perfectly opti
On 12/6/18 6:31 PM, Joseph D. Darcy wrote:
With the start of JDK 13 around the corner, please review the core libs
portions of:
JDK-8205626: Start of release updates for JDK 13
http://cr.openjdk.java.net/~darcy/jdk13-fork.2
Those changes include (but are not necessarily limited to) upd
On 12/6/18 2:42 PM, Claes Redestad wrote:
I filed this bug after seeing it in startup profiles, where isEmpty() avoids an
instanceof and four(!) method calls, so getting rid of a few of these has a
measurable impact on startup. It seemed prudent to just replace it all while
we're at it.
Inter
Hi all,
Please review this small update to the Object.hashCode spec to remove mention of
memory addresses. This also moves the statement about the implementation of
hashCode in the Object class into an @implSpec section.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8199394
Patch app
Hi Rémi,
I can sponsor this for you. Can you file a bug report?
Thanks,
s'marks
On 11/25/18 12:10 PM, Remi Forax wrote:
ping !
Rémi
- Mail original -
De: "Remi Forax"
À: "core-libs-dev"
Envoyé: Mardi 13 Novembre 2018 15:47:54
Objet: Both Collector.of() are not correctly typed
Hi Vinnie,
Roger Riggs wrote:
The 'forEachOrdered' should not be necessary and may raise questions about why.
if there's no good reason, use 'forEach’.
Using forEachOrdered() is necessary. The dumpAsStream() method produces a
stream; presumably it has a defined order that's the same as its in
Hi all,
Please review this small fix to correct some broken links in
serialized-form.html. Patch appended below.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8211882
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 1544056617 28800
# Wed Dec 05 16:36:57 2018 -0800
#
On 12/4/18 12:32 AM, Claes Redestad wrote:
These non-standard and tool/library specific names appear in the manifest of a
great many jar files, for example on maven central, and including the most
common non-standard manifest attributes significantly reduce allocation churn
reading such mani
Hi everybody,
I've finally caught up with all of this. I see that several people are surprised
by the way this has turned out. As the first-named reviewer on this changeset, I
felt I should try to figure out what happened.
While this API point stands on its own, this is really part of Jim's R
I believe it makes sense to override CopiesList.equals()
Also: contains(), iterator(), listIterator()
equals(): sure
contains() is already overridden. Not sure there's much benefit to overriding
the iterators.
s'marks
The general rule for JDK core classes (including collections, even private
implementations) is that we try to preserve backward *and* forward serialization
compatibility. This doesn't apply to all classes in the JDK, though. For
example, javax.swing.JComponent is serializable, but it includes a
On 11/30/18 8:34 PM, Zheka Kozlov wrote:
I think we should choose Tagir's version so you don't need my OCA.
OK, thanks. Let me know if you need any assistance with the OCA, should you
decide to proceed with it.
s'marks
On 11/30/18 8:52 AM, Martin Buchholz wrote:
On Thu, Nov 29, 2018 at 8:02 PM, Tagir Valeev wrote:
I can file an issue and create a webrev, but I still need a sponsor
and review for such change. Martin, can you help with this?
As usual, I'm only half paying attention, but I can be your shep
On 11/1/18 8:12 PM, Kishor Gollapalliwar wrote:
Thank you for providing this opportunity. I'm up for this challenge and I'd
love to take this task. The only huddle would be, how to proceed, ie planning
things step by step, as this is my first time. If you can help me with the
planning, I'll do th
Hi all,
https://bugs.openjdk.java.net/browse/JDK-8214460
Please review this small fix to correct broken macOS build caused by the fix for
JDK-8214014. Patch appended below.
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 1543457799 28800
# Wed Nov 28 18:16:39 2018 -0800
# N
On 10/19/18 11:26 AM, Joe Wang wrote:
Current version:
http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/
Hi Joe,
Thanks for updating the tests per my comments. Everything looks good now!
s'marks
Hi Kishor,
This is indeed an issue with the documentation. The root of the issue is that
the implementations of the SortedSet and SortMap interfaces do not use the
equals() method to determine set or map membership. Instead they use a
comparison method (a Comparator, if provided, or the object
Hi Joe,
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/
I concur with Roger's comments on the test file generation. It would be good to
find some way to reduce the redundancy. He had some suggestions that might work.
You might also want to play around with variations to
On 10/17/18 1:08 PM, Roger Riggs wrote:
I think the @bug line should be empty, this is not a test for a bug.
I don't think you need or use the testng group= functionality; if you don't have
a need for it omit it.
I think it would be helpful to have the bug ID in the test's @bug line. If in
th
Hi Tagir,
Thanks for doing this! This looks like a good optimization. I can sponsor it for
you.
The preliminary patch looks fine. Too bad there's some code duplication. If this
weren't HashMap, I'd suggest refactoring it and using a lambda expression.
However, HashMap is used early in JDK st
On 10/1/18 10:46 AM, Martin Buchholz wrote:
This is one example of a change that should leave zero
impact on the generated bytecode, and that should be testable, if only by
comparing the .class files for identical size.
This is a good point. I did something similar when I did the "diamond"
emory is, in my opinion, always going to be "unsafe" from the standpoint
of coordination. It's not only the mark/position/limit/ByteOrder that is
not multithreaded-friendly about ByteBuffer API, but the underlying memory
too. It would be nice if mark/position/limit/Byt
On 9/28/18 12:21 AM, Peter Levart wrote:
I mostly agree with your assessment about the suitability of the ByteBuffer API
for nice multithreaded use. What would such API look like? I think pretty much
like ByteBuffer but without things that mutate mark/position/limit/ByteOrder. A
stripped-dow
On 9/28/18 2:16 AM, Andrew Dinn wrote:
Thanks for clarifying that point. I have already added a note to that
effect to the JEP. I take your other point that these limitations make
this JEP a less useful addition than it could be. However, it's hard to
see what else might usefully be provided t
Hi Andrew,
Let me first stay that this issue of "ByteBuffer might not be the right answer"
is something of a digression from the JEP discussion. I think the JEP should
proceed forward using MBB with the API that you and Alan had discussed
previously. At most, the discussion of the "right thing
Hi, I just wanted to mention that I pushed the changeset for this bug:
http://hg.openjdk.java.net/jdk/jdk/rev/2ee7e1b7ba66
Thanks for your contribution to OpenJDK!
s'marks
Hi Andrew,
I've been starting to look at some of the buffer-related issues and I've been
discussing this issue with Alan.
On 9/25/18 2:01 AM, Andrew Haley wrote:
On 09/24/2018 09:14 AM, Alan Bateman wrote:
I'm not questioning the need to support NVM, instead I'm trying to
see whether Mapped
of-argument folks might observe that
"tee" also has bilateral symmetry, but I don't think you could
reasonably argue that a four-way "tee" is not less of an arity abuse
than a four-way "duplex", and the plumbing industry would agree:
https://www.amazon.com/Way-Tee-PVC-
On 9/20/18 7:01 PM, Jaikiran Pai wrote:
Since you mentioned it I'll proceed with "Jaikiran Pai
" since that looks a bit more "official".
Sounds fine to me and yes it indeed is a bit more official one. Thank you.
OK, CSR request posted:
https://bugs.openjdk.java.net/browse/JDK-8210991
Ca
On 9/19/18 11:48 AM, Joe Wang wrote:
After much discussion and 10 iterations of reviews, this proposal has evolved
from what was the original isSameContent method to a mismatch method. API-wise,
a compare method was also considered as it looked like just a short step forward
from mismatch, h
On 9/19/18 7:46 PM, Jaikiran Pai wrote:
Thank you. More of a FYI and if it matters from a process point of view
- in a couple of my earlier contributions, the sponsors have used the
"Contributed-by" line to be "Jaikiran Pai " like
here http://hg.openjdk.java.net/jdk/jdk/rev/6c394ed56b07. I don
e a
CSR to be filed.
From Stuart Marks:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html
Whether this requires a CSR depends on whether any normative text of the
specification is changed. A simple clarification ("API note") can be added
without a CSR. As th
On 9/18/18 10:51 AM, Jim Laskey wrote:
Please review the code for String::unescape. Used to translate escape sequences
in a string, typically in a raw string literal, into characters represented by
those escapes.
webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
jbs: htt
s method is not
*
* unmodifiable
*
* @param the class of the objects in the array
* @param a the array by which the list will be backed
* @return a list view of the specified array
* @throws NullPointerException if the passed array is {@code null}
*/
On
e name of this collector. But I
think it's a more descriptive term and it reads more smoothly.
Turning to the issues mentioned by Tomasz:
1) Brian Goetz' suggestion of changing "? extends R" into "R":
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2018
I'd guess that security-dev would have reviewers for the change to
default.policy. Cc'd.
s'marks
On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
Hello.
Please review fix for jdk12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
CSR:
On 9/11/18 10:36 PM, Michael Rasmussen wrote:
Can a language syntax/feature be deprecated to produce a warning in javac?
Perhaps this one should.
We haven't reached the point of formally deprecating language features, but
certain features like this one (and others) are certainly frowned upo
com/help/idea/running-inspection-by-name.html
It will fix all such C-style array declarations for you automatically.
--
Regards,
Tomasz Linkowski
From: Stuart Marks mailto:stuart.ma...@oracle.com>>
To: "ullenb...@gmail.com <mailto:ullenb...@gmail.com>"
mailto:ulle
Hi Roger,
110 * Returns a list of path strings parsed from a string with empty
paths removed.
The Unix shell and the Java launcher's -classpath processing treat an empty path
entry as the current working directory. (I don't know what happens on Windows.)
Removing empty paths thus woul
2. even if, it should not be byte b[] but byte[] b
Yeah we need to clean occurrences of this anachronistic array declaration from
the JDK. I noticed a few others nearby. It's startling that a new occurrence has
crept it. (Or maybe not, perhaps it was done to conform to the nearby code.)
Any
On 9/10/18 5:13 PM, Weijun Wang wrote:
On Sep 11, 2018, at 3:29 AM, Langer, Christoph wrote:
Ok, maybe it should be named "priviledgedGetOverridable" then.
Ah yes. My mistake.
Small spelling nit: there's no "d" before "g", so this should likely be
privilegedGetOverridable
s'mark
Hi Jaikiran,
Terribly sorry about this. I completely missed the review request you posted on
this a couple weeks ago now.
Comments below.
Returns a fixed-size list backed by the specified array.
OK. Same as the original. :-)
The passed array is held as a reference in the returned list.
Yes, the fix itself looks fine. Quite subtle, good catch.
But should this have a regression test? I can imagine somebody coming along
later and "simplifying" (!(... > ...)) to (... <= ...) which would reintroduce
the bug.
s'marks
On 9/2/18 11:14 AM, Xueming Shen wrote:
+1
On 8/31/18, 5:17
On 8/21/18 12:04 AM, Peter Levart wrote:
- UNORDERED: should the returned collector be UNORDERED if *either* of the
provided collectors is UNORDERED? (Current draft says *both*.)
I think *both* is the right behavior. If you are collecting:
teeingAndThen(
Collectors.toList(),
Hi Tagir,
Thanks for working on this. This looks really cool! And thanks Peter for
agreeing to sponsor it.
I can help out with the CSR. My first bit of advice about the CSR process is to
hold off until the specification is complete. :-)
I think the intent of the API is fine, but I think som
On 8/16/18 1:38 AM, Jaikiran Pai wrote:
[1] https://bugs.openjdk.java.net/browse/JDK-7033681
Is this JIRA/change, something that I can contribute? If so, what would
be the typical process for that? I have signed and approved OCA, but I
don't know what's involved in submitting changes which i
Thanks, Patrick! This is very helpful.
Alex, others,
(Meta: I've been at JVMLS and the OpenJDK Committers' Workshop all week, and I'm
on vacation next week, so I don't have much time to discuss this right now.
However, I am interested in moving this forward.)
OK, so the API in this webrev es
Hi,
Here's my current proposal: https://pastebin.com/EABgwLYS
<https://pastebin.com/EABgwLYS>
Alex
----
*From:* Stuart Marks
*Sent:* July 28, 2018 8:11 PM
*To:* Martin Buchholz; Alex Foster
*Cc:* Dou
Hi, I finally got some time to get my head around this.
Conceptually, I like the idea of a List that's stored in a circular array, like
ArrayDeque. The best way to manifest this in the API isn't obvious though. I
filed the bug as "retrofit ArrayDeque to implement List" but of course it
doesn't
On 7/19/18 11:55 PM, Alan Bateman wrote:
On 19/07/2018 22:22, Stuart Marks wrote:
Please review this fix for some failing RMI activation tests. Some reflective
code needed adjustment to take nestmates into account. This also removes the
failing tests from the problem list.
Webrev:
http
Hi all,
Please review this fix for some failing RMI activation tests. Some reflective
code needed adjustment to take nestmates into account. This also removes the
failing tests from the problem list.
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/8206865/webrev.0/
Bug:
h
On 6/26/18 9:57 AM, Ivan Gerasimov wrote:
On the first place, I'd like to understand why it is bad, if
List.of().iterator() in fact returns ListIterator?
What kind of problems it may cause?
Basically it leaks information. Somebody might get an iterator, partially
advance it, and hand it off t
Hi Peter,
Sorry for the delay again. I got pulled into a P1 escalation.
I don't think I'll have time to look at this in any detail until after JDK 11
ramp-down.
s'marks
On 6/22/18 9:51 AM, Peter Levart wrote:
Hi Stuart,
Do you still fear that "single-threaded-object" idiom is not safe?
I
Hi all,
Please review this small fix for a broken link.
Patch appended below.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8201610
Thanks,
s'marks
diff -r 8b98dcf37891 -r 3da3bcc7b28b
src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java
--- a/src/java.rmi/share/classe
Hi all,
Please review this small changeset that ensures that calling iterator() on an
unmodifiable List (from List.of, et. al.) returns an instance that cannot be
downcast to ListIterator and used as such.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8203670
Webrev:
http://cr.open
Hi all,
Please review this small changeset that restores copy semantics to List.copyOf()
when applied to a sublist of an unmodifiable list.
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/8203184/webrev.0/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8203184
Thanks,
s'marks
On 6/17/18 4:23 PM, Peter Levart wrote:
My attempt to optimize the Map.copyOf() was also using just public APIs (with
the addition of an internal class).
Well, it does speed-up Map.copyOf() by 30%. But I agree there are other
approaches that could go even further. In particular when all int
On 6/18/18 7:25 AM, Roger Riggs wrote:
In regard to new SharedSecret interfaces, one option is move shared (but
private) implementation classes
to a jdk.internal.xx package (not exported). This only works well if they are
not tightly coupled to other
package private classes.
SpinedBuffer m
On 6/17/18 1:50 AM, Peter Levart wrote:
It's a little strange that the generator function is used to construct an
empty array (at least in the default method, but overrides will likely do the
same if they want to avoid pre-zeroing overhead) in order to just extract the
array's type from it. So
Tagir Valeev wrote:
If you are going to create long-living array which is likely to be empty,
it's good to deduplicate them to spare the heap space. This can be easily
done via existing toArray method like
collection.toArray(MyClass.EMPTY_ARRAY) assuming we have an empty array
constant. We us
Hi Rémi,
On 6/15/18 12:26 AM, Remi Forax wrote:
The overrides I had previously provided in specific implementation classes like
ArrayList actually are slower, because the allocation of the array is done
separately from filling it. This necessitates the extra zero-filling step. Thus,
I've removed
Hi Peter,
Finally getting back to this.
I think there's clearly room for improvement in the creation of the unmodifiable
collections. Right now the creation paths (mostly) use only public APIs, which
can result in unnecessary allocation and copying. Certainly Map.copyOf does
this, but there a
Hi all,
I wanted to restart review of the changeset for bug JDK-8060192 [1]. The latest
webrev is here: [2].
The previous review was from December 2017: [3]. The only difference between the
current changeset and the previous one is the removal of the overriding
implementations (see explanati
e:
Stuart,
Thank you for explanation!
I'm Okay with the fix it is now.
Thanks,
Serguei
On 6/6/18 14:02, Stuart Marks wrote:
On 6/6/18 10:58 AM, serguei.spit...@oracle.com wrote:
But the fix below is not clear to me:
http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.1/src/hots
ris Clark wrote:
Hi, Stuart.
I think you need to make changes to this file too:
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html
Thanks,
iris
-Original Message-
From: Alan Bateman
Sent: Wednesday, June 6, 2018 3:40
is a subtle shift in the meaning, and I think the meaning is clear after (1) has
been removed.
But I can remove the "similar to Thread.stop" bit if you prefer.
s'marks
Thanks,
Serguei
On 6/5/18 17:05, Stuart Marks wrote:
[adding serviceability-dev]
Hi serviceability folks,
I
[adding serviceability-dev]
Hi serviceability folks,
I'm in the process of removing Thread.destroy() and Thread.stop(Throwable) from
the Java SE API. Alan and David have pointed out that there are some
cross-references to Thread.stop(Throwable) in the JDWP and JVMTI specs, as well
as in the J
On 6/4/18 6:32 AM, Roger Riggs wrote:
Please review a change to make the values of java.home, user.home, user.dir, and
user.name
effectively read-only for internal use. The values are cached during
initialization and the
cached values are used.
Webrev:
http://cr.openjdk.java.net/~rriggs
On 6/3/18 8:55 AM, Alan Bateman wrote:
On 03/06/2018 13:11, David Holmes wrote:
Any suggestions as to how to do that in a practical and effective way?
"As if done by the highly-dangerous, long-deprecated and finally removed
Thread.stop(Throwable)"
? ;-)
In all seriousness I hate to do a
On 6/1/18 5:15 PM, David Holmes wrote:
I would expect the CSR that marked them as deprecated for removal, also serves
for the actual removal. Certainly for VM flags we don't do a separate CSR for
each phase (deprecation, obsoletion, expiration).
Hm. Well, this hasn't been tested for Java SE AP
On 6/1/18 4:40 PM, David Holmes wrote:
Hi Stuart!
Nooo!
Just kidding!
Yaay
:-)
Actual removal looks fine but what about the corresponding JDI code:
./jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java
it still has a stop(Throwable) function (it doesn't have the no-arg one
On 6/1/18 2:37 PM, Lance Andersen wrote:
The changes look fine. Is there a CSR or a release note that also needs to be
reviewed?
Thanks. No CSR yet. I usually do those after the code review. Good point about a
release note, though; I'll add the label and subtask for one.
s'marks
Hi all,
Please review this changeset to remove the Thread.destroy() and
Thread.stop(Throwable) methods. Both of these methods have been deprecated for a
long time, and they were deprecated for removal in Java SE 9.
Thread.destroy() was never implemented, and has always thrown NoSuchMethodErro
On 5/22/18 2:58 PM, Stuart Marks wrote:
On 5/22/18 8:50 AM, Martin Buchholz wrote:
We seem to have enough consensus to change the modCount behavior of
replaceAll.
Sorry, I don't agree that there is such consensus. There are about half a dozen
different issues all at play, spread a
On 5/24/18 2:20 AM, Peter Levart wrote:
The test looks good, but the way you write keys from unmodifiable map composed
of WORDS:
84 Arrays.stream(WORDS)
85 .collect(toUnmodifiableMap(word -> word, word -> ""))
86 .keySet()
87
Hi all,
Please review this new test for testing the randomized iteration order of
unmodifiable Set and Map implementations.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8201518
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/8201518/webrev.0/
Thanks,
s'marks
Hi Martin,
On 5/22/18 8:50 AM, Martin Buchholz wrote:
We seem to have enough consensus to change the modCount behavior of
replaceAll.
Sorry, I don't agree that there is such consensus. There are about half a dozen
different issues all at play, spread across several messages throughout the
th
I owe all of you replies on this, but I don't have time to continue the
discussion, and I suspect you all want to get on with things.
Let me have a quick chat with Paul tomorrow and then I'll propose a path
forward.
s'marks
On 5/15/18 8:02 PM, Martin Buchholz wrote:
How many times the lock is acquired is an implementation detail, a non-obvious
tradeoff even.
vector.replaceAll holds the lock throughout, but vector.subList(0,
size).replaceAll holds the lock for each element (sigh ... racily (really a bug!)).
In
On 5/15/18 7:37 PM, David Holmes wrote:
I'm still with Martin on this. It makes no sense to me to allow replacing one
element to not cause CME, but replacing more than one does cause CME. This is
inconsistent and confusing and the end result is the programmer won't know what
to expect when or
(TL;DR - replaceAll incrementing modCount is a bug.)
I acknowledge that statement is the one in dispute.
Hmmm ... my previous convincing arguments have failed to convince ?!
Your argument above applies to List.set just as much as List.repladeAll, because
the latter is nothing more semantical
I mentally revised the history when doing the collections/stream API work since
we added more bulk operations, since this is on a “best effort” basis and if
it’s cheap to do then there is no real harm in it and it might help.
Spec says:
"""protected transient int modCount
The number of tim
A typical way to refer to a particular Unicode character by code point hex value
is U+ (with more x's if necessary). For example,
2602 * Returns a string whose value is this string, with all leading
2603 * and trailing space removed, where space is defined
2604 * as any charac
On 4/18/18 8:20 AM, Claes Redestad wrote:
please review this change that moves the use of SALT to iterator creation, which
would allow for certain startup
optimizations in the future.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201650
Webrev: http://cr.openjdk.java.net/~redestad/8201650/op
OK, looks good! +1 from me.
s'marks
On 4/17/18 10:34 PM, Vivek Theeyarath wrote:
Hi Stuart,
Done with the changes
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.05/ .
Regards
Vivek
-Original Message-
From: Stuart Marks
Sent: Wednesday, April 18, 2018 8:56 AM
To:
riginal Message-
From: Stuart Marks
Sent: Tuesday, April 17, 2018 5:11 AM
To: Vivek Theeyarath
Cc: core-libs-dev ; Paul Sandoz
Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty
Hi Vivek,
Please add "@since 11" tags to the doc comments of the four Optional*.isEmpty()
methods.
Reg
Hi Vivek,
Please add "@since 11" tags to the doc comments of the four Optional*.isEmpty()
methods.
Regarding the tests, I don't think the various newly added testIsEmpty() tests
are useful. The setup in those test files already generates a fairly
comprehensive set of Optional values from a v
On 4/3/18 5:43 PM, Stuart Marks wrote:
Adding a method to create a Predicate that has match() semantics would be a fine
task to consider separately.
I notice I had already filed a bug for this:
https://bugs.openjdk.java.net/browse/JDK-8184692
Feel free to pick it up.
s'marks
Hi Vivek,
Thanks for taking on this task.
In case it wasn't clear from Paul's mail, what I think you should do is continue
with this fix as a doc-only (and test-only) change, and not modify the behavior
of this method. Doing that would be an incompatible change.
Uwe's point is a reasonable o
cleaned up at once. I'll leave it in for now.
s'marks
On 3/30/18 10:35 AM, Paul Sandoz wrote:
Very nice +1.
You can probably remove the "groups = “unit”" from the @Test declarations.
Paul.
On Mar 29, 2018, at 6:12 PM, Stuart Marks wrote:
Hi all,
Please review this
Hi all,
Please review this changeset, which reorganizes (basically rewrites) the tests
for Optional and Optional{Double,Int,Long}. The new arrangement clusters all the
assertions together into check* methods. These are then called on the results of
the various factories and other monadic opera
On 3/22/18 11:50 PM, Zheka Kozlov wrote:
I noticed that List.copyOf() allocates an array twice. The first allocation is
coll.toArray(), the second one is in ListN constructor. Can we do something with it?
Yeah, I still need to fix that. The various fixed-args List.of() factory methods
also do
lists of an arbitrary AbstractImmutableList, not AbstractList.
Other than this, I think you're good to go!
Thanks,
s'marks
On 3/22/18 8:42 AM, Claes Redestad wrote:
Hi Stuart,
On 2018-03-22 01:51, Stuart Marks wrote:
Hi Claes,
I'm finally finally getting back to this. I review
Hi Claes,
I'm finally finally getting back to this. I reviewed the current state of the
patch located here:
http://cr.openjdk.java.net/~redestad/8193128/open.06/
I think this is mostly fine as it is. There are some things about it that could
be adjusted, but none of them stand in the way
On 3/21/18 1:27 PM, Brian Burkhalter wrote:
On Mar 21, 2018, at 1:23 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote:
Perhaps instead the verbiage just needs to be changed to, e.g.,
“The implementation in this class simply invokes {@link
#write(byte[],int,int) write(b, 0,
On 3/21/18 1:01 PM, Brian Burkhalter wrote:
On Mar 21, 2018, at 12:34 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote:
Having this as an @implSpec sounds as if the implementation of this method in
BAOS is *required* to call write(b, 0, b.length). It happens to do that in
th
On 3/21/18 11:27 AM, Brian Burkhalter wrote:
--- a/src/java.base/share/classes/java/io/ByteArrayOutputStream.java
+++ b/src/java.base/share/classes/java/io/ByteArrayOutputStream.java
@@ -158,15 +158,16 @@
count += len;
}
/**
* Writes the complete contents of the
Hi Jim,
Some comments (really, mainly just quibbles) about string trimming. First,
* String.trim trims characters <= \u0020 from each end of a string. I agree that
String.trim should be preserved unchanged for compatibility purposes.
* The trimLeft, trimRight, and trimWhitespace (which trims
501 - 600 of 1414 matches
Mail list logo
