ble implements IterableOnce or do direct multiple
iteration on the passed-in Iterable if it doesnt.
Regards, Peter
On 3/6/19 4:50 PM, Peter Levart wrote:
Hi Stuart,
According to Liskov substitution principle:
Subtype Requirement: Let ϕ ( x ) be a property provable about
objects
Hi Stuart,
According to Liskov substitution principle:
Subtype Requirement: Let ϕ ( x ) be a property provable about
objects x of type T. Then ϕ ( y ) should be true for objects y of type S
where S is a subtype of T.
Let ϕ ( x ) for objects x of type Iterable be: "x.iterator() may be
denmaier, Goetz wrote:
Hi Roger,
Maybe 10 years ago, when native was the only solution.
Now there are tools to analyze bytecode in java.
I'm working on a Java implementation.
Peter Levart proposed to initialize the message with a sentinel instead.
I'll implement this as a proposal.
That's a
...just one thing if you go that route. Make sure to initialize the
NPE_MESSAGE_PENDING to a new String("something") or else you may be
sharing this constant reference with somebody else via string
interning...
2019-02-08 16:01 GMT+01.00, Peter Levart :
> Hi Goetz,
>
&
Hi Goetz,
In NPE:
97 String extendedMessage = getExtendedNPEMessage(super.getMessage());
...do you expect super.getMessage() to return anything else than null?
Wouldn't that only occur when there was a data race between two
threads observing that lazyComputeMessage is strill true in
Hi Alan,
On 1/26/19 8:38 PM, Alan Snyder wrote:
My usage of GetStringUTFChars was to pass a String as a parameter to a system
call that takes a NUL-terminated UTF-8 string (a file path). Obviously, the
system call does not accept strings containing NUL. I suspect this is a common
case.
On 1/29/19 9:52 PM, Brian Goetz wrote:
How is this different from Collectors.collectingAndThen?
Hi Brian,
It is exactly the same!
I'm sorry, I haven discovered that method when I needed it. Perhaps I
was looking for another name?
Regards, Peter
On 1/29/2019 3:30 PM, Peter Levart
Hi,
I wonder if there's any interest in adding a convenience factory method
for a Collector to the standard repertoire which would look like the
following:
/**
* Convert given {@link Collector} so that it applies an additional
finisher function that
* converts the result of
On 1/18/19 3:11 PM, Peter Levart wrote:
You meant package-private constructor, right? Protected constructor
would allow subclassing MapMode by arbitrary user class which is not
what would be desirable.
...unless you actually want users to construct their own MapMode(s),
like you mentioned
Hi Alan,
On 1/18/19 2:32 PM, Alan Bateman wrote:
On 17/01/2019 14:27, Andrew Dinn wrote:
:
Vladimir and I have reviewed the JEP, it will need an area lead to
endorse, I think it can be Brian or Mikael in this case.
Ok, thanks for the above answers. Looking forward to hearing further
from
Mobex: 279990 Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groe...@uk.ibm.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, H
Hi Steve,
What you have observed is an artifact of how Java the language is
compiled into bytecode contained in .class files and the fact that Java
reflection API returns information about the compiled .class files. The
quoted sample code:
package x.y;
class A {
public void m() {
}
}
Hi Brian,
This is really highly unlikely (1 in 2^800). In fact, it was not
possible for this particular test to produce zero BigInteger. That's
because the test uses a pseudo-random generator with deterministic
algorithm and it uses a constant seed to initialize it before generating
the next
Hi Brian,
I don't quite understand this reasoning. I need some explanation...
You are talking about the distribution of BigInteger values (not the bit
lengths of the values), obtained with constructor BigInteger(int,
java.util.Random) for which the javadoc says:
* Constructs a randomly
Hi Rob,
On 12/10/18 11:11 PM, Rob Griffin (rgriffin) wrote:
Hi Remi,
There are certainly places where we could do this when we are simply iterating
over the results but that is not always the case. However I was disappointed to
find that the enhanced for loop can't iterate over a stream so
Hi Claes,
Haven't checked all changes yet, although it looks like a
straightforward swap of Properties for HashMap for intermediary result,
but I noticed the following in SystemProps:
265 var cmdProps = new HashMapString>((vmProps.length / 2) + Raw.FIXED_LENGTH);
The
Ah, I see your point. Haven't read this part of your message below
before. You don't know in the MultiMap code whether the key is already
in the HashMap or not (so you can't choose .get() vs.
.computeIfAbsent()), but the user of the MultiMap might expect that
when the MultiMap has been
Hi Michael,
If in your code you "know" that a particular key must be present, then
why aren't you using .get(key) in that place instead of
.computeIfAbsent() and trying to rely on it being a non-modifying operation?
Note that in some Map implementations (WeakHashMap for example) event
On 9/21/18 12:22 PM, Alan Bateman wrote:
On 18/09/2018 18:52, Jim Laskey wrote:
Please review the code for String::transform. The goal is to provide
a String instance method to allow function application of custom
transformations applied to an instance of String.
webrev:
Hi Joe,
On 10/17/2018 09:16 PM, joe darcy wrote:
PS In response to some off-list feedback, an updated webrev uses a
stream-ier implementation:
http://cr.openjdk.java.net/~darcy/6304578.1/
I suggest further niceing:
- if you make typeVarBounds() static, you could use it in Stream.map()
Hi Mandy,
On 10/04/2018 07:45 PM, Alan Bateman wrote:
On 03/10/2018 18:28, Mandy Chung wrote:
:
On 10/3/18 9:30 AM, Peter Levart wrote:
Hi Mandy,
I don't know if this matters though, but should
Reflection.getCallerClass() ever return null, previous behavior was
to throw NPE (from
Hi Mandy,
I don't know if this matters though, but should
Reflection.getCallerClass() ever return null, previous behavior was to
throw NPE (from Reflection.verifyMemberAccess(...)), now the checks are
skipped. This should only be observable if [Class,
Constructor].newInstance() was called
te
bulk ops not respect the limit, but that seems inconsistent.)
OK, let's adopt an approach similar to what was described by Peter
Levart a couple messages upthread, where a) there is an initialization
step where various things including the limit are set properly; b) the
buffer is published
Hi Andrew,
On 09/27/2018 11:23 AM, Andrew Dinn wrote:
On 26/09/18 17:00, Alan Bateman wrote:
The reason that we've mentioned it a few times is because it's a
significant issue. If you have a byte buffer then you can't have
different threads accessing different parts of the buffer at the same
Hi Alan,
Just a few comments about implementation.
In Reflection:
292 boolean shouldSkip = false;
293 for (String filteredName : filteredNames) {
294 if (member.getName() == filteredName) {
295 shouldSkip = true;
296
uot; to the
different collectors. Since we're doing this with two collectors, how about
"duplex"? (I note that Jacob Glickman also had suggested "duplex".)
s'marks
On 8/20/18 1:48 AM, Tagir Valeev wrote:
Hello!
A CSR is created:
https://bugs.openjdk.java.net/browse/JDK-8
Hi Jaikiran,
Forwarding to compiler-dev as the core of source file launcher feature
is produced there...
The check for main class is performed after compilation (which actually
produces the main class name).
I think it would be possible to check for all classes compiled from the
source
On 09/12/2018 04:30 PM, Roger Riggs wrote:
Hi Stuart,
The implementation retains the previous handling of empty path
elements for URLClassPath
in the implementation. The spec for the new methods is explicit about
dropping empty elements.
For a library API, it is inadvisable to support
Hi Stephen,
On 08/28/2018 11:21 PM, Stephen Colebourne wrote:
So is there a way to achieve what you want for your test with existing API?
Probably. I could have a separate maven module creating a separate
modular jar file with the testing resource in it, and run the test
using both the
Hi Stephen,
On 08/28/2018 11:21 PM, Stephen Colebourne wrote:
On Tue, 28 Aug 2018 at 20:43, Peter Levart wrote:
Do you think this functionality is really needed in programs? It seems useful
just for testing.
Why do people add classes at runtime? Might they not reasonably want
to also add
On 08/28/2018 06:38 PM, Stephen Colebourne wrote:
On 28 August 2018 at 08:17, Alan Bateman wrote:
On 28/08/2018 07:55, Peter Levart wrote:
Right, and any class injected with Lookup.defineClass can be located with
methods such as Class.forName or Lookup.findClass. There is no equivalent
On 08/28/2018 08:55 AM, Peter Levart wrote:
MethodHandles.Lookup.defineClass() allows a class to be pushed into an
existing ClassLoader & Module, but I'm unaware of an equivalent for
resources, and that seems like a gap, regardless of use case.
ClassLoader (the Java part of it at l
Hi Stephen,
On 08/27/2018 11:51 PM, Stephen Colebourne wrote:
The specific code was written in Java 8 world to create a ClassLoader
containing the resource with a suitable parent (as a test case). The
resource was accessed using ClassLoader.getResources() from a shared
library. Under Java 9
On 08/27/2018 04:47 PM, David Lloyd wrote:
On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman wrote:
On 24/08/2018 18:27, David Lloyd wrote:
Why not go ahead and implement getResource as well? It's not *that*
big of a deal to add a URL handler, and it would be a fairly trivial
one.
Right, it
ng objects in
native code...
Regards, Peter
Here is a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/
Best regards
Christoph
-Original Message-----
From: Peter Levart
Sent: Freitag, 24. August 2018 13:06
To: Remi Forax ; Langer, Christoph
Cc: core-libs-dev ; Baesken
On 08/24/2018 12:09 PM, Remi Forax wrote:
Hi Christoph,
getWidth() and getHeight() should be instance methods and not static methods,
providing the weight or the height if there is no console seems weird.
Also, they should be named width() and height() given the rest of the methods of
I just note that sometimes naming is hard. Not because there would be no
suitable name to choose from but because there are too many. In such
situations it becomes apparent that every individual's brain works
slightly differently. That said, I must admit that teeingAndThen is not
my favorite
Hi Stuart,
On 08/21/2018 07:43 AM, Stuart Marks wrote:
2. Characteristics
- 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:
Hi Claes,
That's ok. You could also add @see tag to WeakEntry.equals pointing to
MethodType.equals. The other way around is not possible, but you could
spell-out the same: "See also WeakEntry.equals()"
Regards, Peter
On 08/20/2018 12:56 PM, Claes Redestad wrote:
Yes, perhaps just pointers
Hi Tagir,
I think this looks very good. It just needs a CSR. Will you file it?
Regards, Peter
On 08/19/2018 11:24 AM, Tagir Valeev wrote:
Hello, Brian!
Of the three phases, teeing is the most important and least obvious, so
I think something that includes that in the name is going to be
Hi Mandy,
On 08/17/2018 05:20 PM, mandy chung wrote:
Hi Peter, Jason, Joe,
Thanks for the pointers. I have missed the use of
serialPersistentFields (thanks to Peter for calling this out). I read
the javadoc and serialization spec but that didn't come clearly to me.
It'd be good to include an
On 08/17/2018 04:32 PM, Claes Redestad wrote:
Hi Peter,
On 2018-08-17 16:04, Peter Levart wrote:
Hi Claes,
Nice trick.
thanks!
You made MethodType(s) and WeakEntry(s) holding them equal,
respecting the equals()/hashCode() contract. When WeakEntry looses
the referent it is left equal
Hi Claes,
Nice trick. You made MethodType(s) and WeakEntry(s) holding them equal,
respecting the equals()/hashCode() contract. When WeakEntry looses the
referent it is left equal to itself only, which is enough for expunging
it from map.
Regards, Peter
On 08/17/2018 12:56 PM, Claes
On 08/17/2018 01:54 AM, mandy chung wrote:
On 8/16/18 4:48 PM, joe darcy wrote:
Just a question. Why does "private Throwable exception" field in
ExceptionInInitializerError exist? Was it there before there was a
"cause" in Throwable and later still remained there because of
serialization
Hi Mandy,
Just a question. Why does "private Throwable exception" field in
ExceptionInInitializerError exist? Was it there before there was a
"cause" in Throwable and later still remained there because of
serialization format? Would it be possible to "simulate" its effect for
serialization
The javadoc comments in public API are a requirement in OpenJDK and can
not be removed. This is the OpenJDK project policy. If you want to
extend OpenJDK you have to add the comments. And not only comments. New
public API may be added to OpenJDK only after passing the special
process called
On 08/15/2018 07:16 PM, Peter Levart wrote:
On 08/15/2018 05:49 PM, dalibor topic wrote:
On 06.08.2018 20:21, mr rupplin wrote:
Three problems that I run into when running the 'make jdk' after
minor work on the System.java class for JNI and custom JDK:
java/lang/memory
On 08/15/2018 05:49 PM, dalibor topic wrote:
On 06.08.2018 20:21, mr rupplin wrote:
Three problems that I run into when running the 'make jdk' after
minor work on the System.java class for JNI and custom JDK:
java/lang/memory/GroupListener.java:111:
Can we get explanations for each of
On 08/09/2018 06:28 PM, Claes Redestad wrote:
On 2018-08-09 17:41, Peter Levart wrote:
There's danger when you overwrite a non-null @Stable field with
another value that this new value will not be seen. Or is
code an exception where @Stable is not honored yet...
Typically
On 08/09/2018 05:32 PM, Peter Levart wrote:
Hi Claes,
When is this archived cache created? Is it possible to create archived
cache with java.lang.Integer.IntegerCache.high system property set to
> 127 ? Wouldn't then at runtime, when cache is initialized from such
oversized arch
Hi Claes,
When is this archived cache created? Is it possible to create archived
cache with java.lang.Integer.IntegerCache.high system property set to >
127 ? Wouldn't then at runtime, when cache is initialized from such
oversized archive and no java.lang.Integer.IntegerCache.high system
partitioningBy, which is not the case)
tee or teeing - by Brian Goetz (IIUC from the T shape, it's assymmetrical
operation, while our collector is symmetrical)
duplex(ing) - by Jacob Glickman (well, probably ok?)
bifurcate - by James Laskey (or bifurcating?)
replicator - by James Laskey (as in DNA)
re
Hi all,
On 08/04/2018 01:51 AM, Stuart Marks wrote:
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
On 07/16/2018 05:13 PM, Adam Farley8 wrote:
As for the JDK9+
issue, I believe that has already been solved. See the line at the end of
the Module-Module-String-Locale-Control getBundleImpl, where it says:
Reference.reachabilityFence(module);
You're right, Adam. I missed that.
Regards,
Hi,
On 07/16/2018 02:10 PM, Alan Bateman wrote:
On 11/07/2018 14:27, Adam Farley8 wrote:
Hi All,
-- Summary:
When calling "ResourceBundle.getBundle(String, Locale, ClassLoader)" on
JDK8, the ClassLoader can get GC'd before we're finished with it.
This can result in us getting the wrong
Sorry Paul for hijacking the thread, just answering to Remi ...
On 07/11/2018 05:31 PM, Remi Forax wrote:
- Mail original -
De: "Peter Levart"
À: "Paul Sandoz" , "core-libs-dev"
Envoyé: Mercredi 11 Juillet 2018 17:15:09
Objet: Re: RFR 8206955 MethodHan
Hi Paul,
The patch looks ok. I hope IMPL_LOOKUP has access to all methods (even
if located in package-private interfaces and/or in concealed packages of
modules)?
Just a thought... Would it be possible to implement this API in terms of
LambdaMetafactory ?
Regards, Peter
On 07/11/2018
Hi Mandy,
On 07/10/2018 12:18 AM, mandy chung wrote:
On 7/9/18 12:59 PM, Per Liden wrote:
On 2018-07-09 20:49, mandy chung wrote:
On 7/9/18 11:31 AM, Zheka Kozlov wrote:
It is possible to create a
WeakReference/SoftReference/PhantomReference
with a null value in which case the Reference
Hi David,
On 07/09/2018 09:33 AM, David Holmes wrote:
On 9/07/2018 5:22 PM, Peter Levart wrote:
Hi David,
On 07/09/2018 03:37 AM, David Holmes wrote:
Hi Peter,
On 7/07/2018 2:10 AM, Peter Levart wrote:
Hi,
On 07/05/2018 01:01 AM, David Holmes wrote:
I dispute "they will under
Hi David,
On 07/09/2018 03:37 AM, David Holmes wrote:
Hi Peter,
On 7/07/2018 2:10 AM, Peter Levart wrote:
Hi,
On 07/05/2018 01:01 AM, David Holmes wrote:
I dispute "they will understand this might have happened in another
thread".
What if the stack trace was like the followin
Hi,
On 07/05/2018 01:01 AM, David Holmes wrote:
I dispute "they will understand this might have happened in another
thread".
What if the stack trace was like the following...
Before patch:
1st attempt [ForkJoinPool.commonPool-worker-3]:
java.lang.ExceptionInInitializerError
at
Hi Volker,
It occurred to me that getting rid of backtrace-s of cause(s)/suppressed
exception(s) might not be enough to prevent ClassLoader leaks...
On 07/04/2018 10:21 AM, Lindenmaier, Goetz wrote:
dealing with backtrace and stackTrace. I have to wonder why nothing in
Throwable clears the
Hi Volker,
I fully support this change, although I'm not qualified to review it as
I'm not so acquainted with VM internals. The code looks reasonable to me
though. This change will greatly help track down class initializiation
bugs. I don't think that attaching a cause which is not directly
On 06/26/2018 08:11 AM, Zheka Kozlov wrote:
I agree with Ivan. Isn't it better to create a standalone implementation of
Iterator and return its instance in iterator()? Implementing of Iterator
for ImmutableList doesn't look like a big problem.
Also, performance would be better if it was a
Please review the following tiny change that delays
TerminatingThreadLocal class initialization until the 1st thread that
actually uses thread locals, exits:
http://cr.openjdk.java.net/~plevart/jdk-dev/8205540_TerminatingThreadLocal.opt/webrev.01/
Since JDK-8202788 has been pushed, a
Hi Stuart,
Do you still fear that "single-threaded-object" idiom is not safe?
I would just like to comment on the last approach...
On 06/19/2018 07:01 PM, Peter Levart wrote:
Here's another attempt that uses the same technique but relaxes the
possible concurrent source map scena
On 06/22/2018 11:50 AM, Alan Bateman wrote:
On 21/06/2018 18:29, Peter Levart wrote:
On 06/21/2018 07:01 PM, Tony Printezis wrote:
I’m trying exactly that. :-)
Sorry, I didn't know. Here's my attempt:
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.07/
I also added
nd can run anywhere.
Regards, Peter
Tony
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
<mailto:tprinte...@twitter.com>
On June 21, 2018 at 1:29:38 PM, Peter Levart (peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>) wrote:
On 06/21/2018 07:01 PM, Tony
| @TonyPrintezis | tprinte...@twitter.com
<mailto:tprinte...@twitter.com>
On June 21, 2018 at 12:59:58 PM, Peter Levart (peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>) wrote:
On 06/21/2018 06:17 PM, Tony Printezis wrote:
I was saying: I looked at TestMaxCach
On 06/21/2018 06:17 PM, Tony Printezis wrote:
I was saying: I looked at TestMaxCachedBufferSize and, unfortunately,
I don’t think the test makes a lot of sense right now as it checks the
number / size of direct buffers after all the threads terminate and,
with this change, that should
On 06/21/2018 05:53 PM, Peter Levart wrote:
Hi,
On 06/21/2018 09:42 AM, Alan Bateman wrote:
On 20/06/2018 15:08, Peter Levart wrote:
Like the following?
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/
Yes, I think this looks good.
Do we need a test which
Hi,
On 06/21/2018 09:42 AM, Alan Bateman wrote:
On 20/06/2018 15:08, Peter Levart wrote:
Like the following?
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/
Yes, I think this looks good.
Do we need a test which proves that cached direct buffers are
released
| tprinte...@twitter.com
<mailto:tprinte...@twitter.com>
On June 20, 2018 at 10:08:48 AM, Peter Levart (peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>) wrote:
On 06/18/2018 05:41 PM, Alan Bateman wrote:
>
>
> On 17/06/2018 22:20, Peter Levart wrote:
>
On 06/18/2018 05:41 PM, Alan Bateman wrote:
On 17/06/2018 22:20, Peter Levart wrote:
Update: the discussion on concurrent-interest about possible future
addition of public ThreadLocal.getIfPresent() or
ThreadLocal.isPresent() has died out, but it nevertheless reached a
point where
Hi Stuart,
On 06/19/2018 04:09 AM, Stuart Marks wrote:
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
On 06/18/2018 06:53 PM, Claes Redestad wrote:
Plain write that follows in program a volatile write, can in theory
float before the volatile write. So if you publish a Properties
instance via data race (via plain write), the observer may still see
uninitialized 'map' and 'defaults' fields.
On 06/19/2018 12:21 AM, Brian Goetz wrote:
distributing?
More "replicating" than "distributing" (thinking of replicated vs.
distributed caches for example).
Peter
On 06/19/18 09:43, Peter Levart wrote:
We already have some toXxx() methods (toList, toSet, toCollection,
toMap, ...), so toBoth seems to me as a natural extension of that
naming principle:
Well, on a second thought, toList, toSet, etc... they all name a type
that is a result
On 06/19/18 02:38, John Rose wrote:
unzipping(
Function f1, // defaults to identity
Collector c1,
Function f2, // defaults to identity
Collector c2,
BiFunction finisher) {
return toBoth(mapping(f1,
On 06/18/2018 04:47 PM, Claes Redestad wrote:
On 2018-06-18 16:23, Peter Levart wrote:
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http
Unsafe directly for that since VarHandle could
cause bootstrap issues.
Regards, Peter
/Claes
On 2018-06-18 15:27, Claes Redestad wrote:
On 2018-06-18 13:06, Peter Levart wrote:
Adding a volatile read on every read through Properties is likely
to have some performance impact,
On non-Intel
Hi Claes,
On 06/18/2018 12:02 PM, Claes Redestad wrote:
On 2018-06-18 05:45, David Holmes wrote:
Making it "final" to fix unsafe publication only works with actual
publication after construction. You're making it "final" but then not
setting it at construction time and instead using
method for example)
it is delegated to iteration over entrySet.
I'll benchmark it tomorrow when I get back to the computer other
benchmarks were run on so the results can be compared.
So what do you think of this one?
Regards, Peter
s'marks
On 6/11/18 3:57 AM, Peter Levart wrote:
Hi
be OK?
Regards, Peter
On 06/06/18 20:55, Peter Levart wrote:
Ok, here's next webrev:
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.03/
The changes from webrev.02 are:
- renamed JdkThreadLocal -> TerminatingThreadLocal
- instead of overriding initialVa
Hi Brent,
If 'map' field could be observed as null (which I think is only
possible, if Properties object is unsafely published), then so can
'defaults' field. You could make it final as well if it was not protected.
So I'm thinking what kind of memory fences would make those fields
behave
Hi Tagir,
I don't know if this is important, but in your approach the particular
functions of the sub-collectors are retrieved eagerly even if they are
later not used. This should typically not present a problem as
Collector(s) should be prepared to be used in any scenario (parallel or
On 06/17/18 10:50, Peter Levart wrote:
The argument about using (and re-using) a method so that its method
reference can be passed to the toArray method without any unchecked
casts is equally true for any of the 3 alternatives shown - the method
itself might need unchecked casts, but its
, Jun 11, 2018 at 7:40 PM Peter Levart <mailto:peter.lev...@gmail.com>> wrote:
Hi,
Have you ever wanted to perform a collection of the same Stream
into two
different targets using two Collectors? Say you wanted to collect
Map.Entry elements into two parallel lists
Hi Stuart,
On 06/15/18 03:02, Stuart Marks wrote:
Comparing this to the type token alternatives, for simple tasks like
converting Collection to String[], things are about equal:
toArray(String[]::new)
toArray(String.class)
toArray(String[].class)
However, things are hairier if
easibility of its inclusion in the JDK (Paul rules
here :-)), I note that BiStream would obviously allow this
functionality to be exposed in a more user friendly way.
Cheers
Maurizio
On 11/06/18 13:39, Peter Levart wrote:
Hi,
Have you ever wanted to perform a collection of the same Stream
r have you
prototyped a combined strategy in BiStream?
Regards, Peter
FWIW i would call it a “splitting” or “bisecting" collector e.g.
“s.collect(bisecting(…))”
Paul.
On Jun 11, 2018, at 5:39 AM, Peter Levart wrote:
Hi,
Have you ever wanted to perform a collection of the same
tor), at the loss of sharp types for the results.)
*Yes, I'm sure one can find precedent of this being done; this has no
effect on whether it's bad.
On 6/11/2018 8:39 AM, Peter Levart wrote:
> Hi,
>
> Have you ever wanted to perform a collection of the same Stream
i
Hi,
On 06/12/2018 11:34 AM, Vivek Theeyarath wrote:
Hi All,
Please review fix for
https://bugs.openjdk.java.net/browse/JDK-8202216
Webrev: http://cr.openjdk.java.net/~vtheeyarath/8202216/webrev.00/
CSR : https://bugs.openjdk.java.net/browse/JDK-8204852
Regards
dunno how this might turn out in the future and if your BiCollector fits
nicely into such a future model.
What are you thoughts on this?
FWIW i would call it a “splitting” or “bisecting" collector e.g.
“s.collect(bisecting(…))”
Paul.
On Jun 11, 2018, at 5:39 AM, Peter Levart wrote:
Hi,
Hi,
Have you ever wanted to perform a collection of the same Stream into two
different targets using two Collectors? Say you wanted to collect
Map.Entry elements into two parallel lists, each of them containing keys
and values respectively. Or you wanted to collect elements into groups
by
Hi,
Those two methods were added in JDK 10 and they are not very optimal.
Map.copyOf(Map map) 1st dumps the source map into an array of
Map.Entry(s) (map.entrySet().toArray(new Entry[0])), which typically
creates new Map.Entry objects, then passes the array to
Map.ofEntries(Map.Entry[]
Hi Tony,
Thanks for taking a look. Just a couple of comments inline...
On 06/06/18 22:38, Tony Printezis wrote:
- instead of overriding initialValue(), ThreadLocal.setInitialValue()
calls TerminatingThreadLocal.register() at the right moment
Thanks. I much prefer not having to introduce
be further
simplified.
Regards, Peter
On 06/06/18 18:58, Peter Levart wrote:
On 06/06/18 17:41, Tony Printezis wrote:
Peter,
You’re totally right re: JdkThreadLocal::initialValue being final and
cannot be overridden (I had completely missed the final keyword when
I first looked a
com>
On June 6, 2018 at 11:12:44 AM, Peter Levart (peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>) wrote:
Hi Tony, Alan,
On 06/06/2018 04:37 PM, Tony Printezis wrote:
Alan,
Thanks for your thoughts!
Peter,
Any chance of taking the two suggestions I made in an ea
| @TonyPrintezis | tprinte...@twitter.com
<mailto:tprinte...@twitter.com>
On June 6, 2018 at 9:38:05 AM, Alan Bateman (alan.bate...@oracle.com
<mailto:alan.bate...@oracle.com>) wrote:
On 30/05/2018 22:16, Peter Levart wrote:
> I thought there would be some hint from Alan about w
401 - 500 of 2148 matches
Mail list logo
