Thank you, Daniel
Regards,
Chris
> On 14 Sep 2018, at 6:19 PM, Daniel Fuchs wrote:
>
> Hi Chris,
>
> > http://cr.openjdk.java.net/~xyin/8210695/webrev.01/
>
> Looks good to me.
>
> > Yep, fixed as you suggested. My original though is that the stack trace
> > maybe too verbose if most of run
Hi Martin,
- Mail original -
> De: "Martin Desruisseaux"
> À: "core-libs-dev"
> Envoyé: Samedi 15 Septembre 2018 20:16:45
> Objet: Thought on multiplicity of properties in Java
> I’m deriving Java interfaces from the UML of ISO 19111 international
> standard, and a though come to my min
I agree with Tagir that supporting more than two Collectors sounds risky. I
especially agree that well-typed and well-named accessors are important.
I use the quoted library (jOOL), but I:
- either avoid all those tuple-based functions,
- or I use only Tuple2/Tuple3 and I map the tuple to a dedica
On 14/09/2018 20:16, Peter Levart wrote:
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
Hello, Brian!
Regarding more than two collectors. Some libraries definitely have
analogs (e.g. [1]) which combine more than two collectors. To my
opinion combining two collectors this way is an upper limit for
readable code. Especially if you are going to collect to the list, you
will have a list
On 14/09/2018 20:34, Johannes Kuhn wrote:
:
1. Use Case:
The most obvious use case is to to "implement" default methods in
instances created by j.l.r.Proxy. An implementation of
j.l.r.InvocationHandler that handles default methods could look like this:
public Object invoke(Object proxy, M
On 15/09/2018 22:00, Philip Race wrote:
It was exported in the past .. and it was publicly documented ..
http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html
.. so I think Sergey was correct in his "JDK" scope.
Implementation would be for something entirely internal.
I
Hi
Please help review the change for JDK-8034802.
issue: https://bugs.openjdk.java.net/browse/JDK-8034802
webrev: http://cr.openjdk.java.net/~sherman/8034802/webrev
One of the reasons that the implementation works this way is that I
didn't have a
complete SeekableByteChannel support (mainly th
