Please review a minor patch to correct typo in test/jdk/ProblemList.txt.
Change "Hashmap" to "HashMap".
diff -r 4a35a00eb001 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Wed Nov 01 16:45:28 2017 +0100
+++ b/test/jdk/ProblemList.txt Wed Nov 01 23:34:44 2017 -0400
@@ -320,7 +320,7
If it's not too late, I'd lake to take part in this feast :)
Here's a handful of some more word duplicates:
http://cr.openjdk.java.net/~igerasim/double-trouble-2/00/webrev/
With kind regards,
Ivan
On 10/30/17 6:16 PM, Stuart Marks wrote:
No, Roger checked in the "the the" patch before Christ
On 2/11/2017 3:46 AM, Peter Levart wrote:
On 11/01/17 13:34, David Holmes wrote:
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Rig
On 2/11/2017 5:07 AM, Stuart Marks wrote:
On 10/31/17 6:58 PM, David Holmes wrote:
I'm not sure why you say this isn't helpful. It's clearly not helpful
to *clients* of TPE; but since finalize() is protected, the warning
is clearly directed at subclasses, and it provides information about
migr
Good catch! Thanks, I'll fix it.
s'marks
On 11/1/17 4:01 PM, Stefan Zobel wrote:
Hi Stuart,
only a minor nit. In Map.java, the class-level
Javadoc anchor id="immutable" doesn't match the
href="#unmodifiable" used in the methods.
+ * Unmodifiable Maps
vs.
+ * See Unmodifiable Maps for detail
On 11/1/17 1:50 PM, Roger Riggs wrote:
Collection.java: Lines 110, 133, 166
The bold labels probably want to be on their own lines and not terminated by
"." to look like headings
(or be headings if the CSS supports them)
I'll change these to be actual headings.
List.java: Consistency of mar
On 11/1/17 10:45 AM, Tagir Valeev wrote:
Set.of:
+if (coll instanceof ImmutableCollections.AbstractImmutableSet) {
+return (Set)coll;
+} else {
+return (Set)Set.of(coll.stream().distinct().toArray());
I think that good old Set.of(new HashSet<>(coll).toA
Hi Stuart,
only a minor nit. In Map.java, the class-level
Javadoc anchor id="immutable" doesn't match the
href="#unmodifiable" used in the methods.
+ * Unmodifiable Maps
vs.
+ * See Unmodifiable Maps for details.
Regards,
Stefan
2017-11-01 0:49 GMT+01:00 Stuart Marks :
> Updated webrev, bas
Hi Stuart,
A few editorial comments:
Collection.java: Lines 110, 133, 166
The bold labels probably want to be on their own lines and not
terminated by "." to look like headings
(or be headings if the CSS supports them)
List.java: Consistency of markup references to unmodifiable List|Set|Map.
In this case I would prefer a non static copyOf() method on the list to create
a unmodifiable list/set/map, where the optimal factory method can be called.
This would also solve the problem of a concurrent implementation.
-Patrick
> Am 01.11.2017 um 21:05 schrieb Louis Wasserman :
>
> I disag
I disagree, actually. Collections with size zero and one are significantly
more common than bigger collections.
In Guava's immutable collection factories (ImmutableList.of(...) etc.), we
observed a roughly exponential decline in the number of users of factory
methods of each size: if N people cre
On 10/27/17 1:56 PM, Chris Dennis wrote:
I’m very confused about what was intended with the ‘UNORDERED’ Collector
characteristic. My logical inference was that unordered as a Collector
characteristic meant that the result of this collector applied to any stream
was independent of the order of
> Am 01.11.2017 um 20:25 schrieb Stuart Marks :
>
> On 10/31/17 5:52 PM, Bernd Eckenfels wrote:
>> Having a List.of(List) copy constructor would save an additional array copy
>> in the collector Which uses (List)List.of(list.toArray())
>
> The quickest way to get all the elements from the sour
On 10/31/17 5:52 PM, Bernd Eckenfels wrote:
Having a List.of(List) copy constructor would save an additional array copy in the
collector Which uses (List)List.of(list.toArray())
The quickest way to get all the elements from the source collection is to call
toArray() on it. Some copy construc
Hi Peter,
I like the idea of moving get/releaseInflter() into CleanableResource,
though I doubt
how much it can really help the GC it should be a good thing to do to
remove the strong
reference of ZipFile from stream's cleaner, and the code appears a
little cleaner as well.
I was debating wi
On 10/31/17 6:58 PM, David Holmes wrote:
I'm not sure why you say this isn't helpful. It's clearly not helpful to
*clients* of TPE; but since finalize() is protected, the warning is clearly
directed at subclasses, and it provides information about migrating away from
finalization. Should say so
On 11/01/17 13:34, David Holmes wrote:
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources t
Hello!
Set.of:
+if (coll instanceof ImmutableCollections.AbstractImmutableSet) {
+return (Set)coll;
+} else {
+return (Set)Set.of(coll.stream().distinct().toArray());
I think that good old Set.of(new HashSet<>(coll).toArray()) would
produce less garbage. d
> On 31 Oct 2017, at 16:46, joe darcy wrote:
>>>
>> In that case we need to double (sorry) down on the NaNs and include sum as
>> well:
>>
>> * {@code (min <= max && !isNaN(sum)) || (isNaN(min) && isNaN(max) &&
>> isNaN(sum))}
>
> A more complete test for the numerical consistency conditio
Paul,
Thank you!
-Dmitry
On 31.10.2017 20:32, Paul Sandoz wrote:
>
>> On 31 Oct 2017, at 05:58, Dmitry Samersoff
>> wrote:
>>
>> Paul and Frederic,
>>
>> Thank you.
>>
>> One more question. Do we need to call verify_oop below?
>>
>> 509 { // Check for the null sentinel.
>> ...
>> 517
I tried to put that in my latest proposal:
/**
* Reads all characters from this readable and writes the characters to
* the given appendable in the order that they are read. On return, this
* readable will be at end its data.
*
* This method may block indefinitely reading from the readable,
Hi Peter,
The Supplier/Consumer allocator/deallocator version is useful and
interesting encapsulation.
We should be able to do better than exposing raw native pointers for
other resources.
They should have better more complete encapsulation including their cleanup.
For example, the recent wo
On 16/12/2014 22:54, Pavel Rappo wrote:
Hi Patrick, nice to hear from you again! I agree we should consider adding this
method. Unfortunately, from the spec point of view I suppose this one will
require a lot more chewing. For instance there's nothing that can be closed
either in Readable or Appe
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc
cycle need any kind
of cleanup. I would w
Hi Sherman,
On 11/01/17 00:25, Xueming Shen wrote:
Hi Peter,
After tried couple implementations it seems the most reasonable
approach is to
use the coding pattern you suggested to move all pieces into ZSStream
Ref. Given
we are already using the internal API CleanerFactory it is attractive
t
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc cycle
need any kind
of cleanup. I would work toward a model that encapsulates the
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc cycle
need any kind
of cleanup. I would work toward a model that encapsulates the
reference to a native resource
with a cor
28 matches
Mail list logo
