Hello!
> My view is that it's preferable for collections implementations to be
> strict. If I'm handing out an unmodifiable List, it should always be illegal
> for the callee to attempt to sort it, even if it has zero or one elements.
Thank you, this totally makes sence.
> While this isn't guara
On 11/14/17 7:52 PM, Tagir Valeev wrote:
According to `List.sort` specification [1] "This list must be modifiable".
According to `Collections.emptyList` specification [2] "Returns an
empty list (immutable)."
So I assume that `List.sort` cannot be called on
`Collections.emptyList` result. Howev
Thanks, Lance. Corrected as suggested.
http://cr.openjdk.java.net/~naoto/8191349/specdiff.02/overview-summary.html
Also, I inserted "@since 10."
Naoto
On 11/15/17 3:06 PM, Lance Andersen wrote:
Hi Naoto
localizedBy, i would suggest changing:
- “If the new locale contains “ca”…” to “if th
Hi Naoto
localizedBy, i would suggest changing:
- “If the new locale contains “ca”…” to “if the new locale contains the
“ca”…”
- “Unlike withLocale method” to Unlike the withLocale method”
Best
Lance
> On Nov 15, 2017, at 5:36 PM, Naoto Sato wrote:
>
> http://cr.openjdk.java.net/~naoto/819
Thanks, Roger. Updated the specdiff as suggested:
http://cr.openjdk.java.net/~naoto/8191349/specdiff.01/overview-summary.html
Naoto
On 11/15/17 2:06 PM, Roger Riggs wrote:
Hi Naoto,
- The word "designated" is unnecessary and inconsistent with the rest of
the java.time API doc.
"designat
Hi Naoto,
- The word "designated" is unnecessary and inconsistent with the rest of
the java.time API doc.
"designated locale" -> "locale"
I would have written: "Unicode extensions in the locale are ignored."
- localizedBy(Locale):
The first sentence should be more specific.
" Retur
Here is the proposed spec changes:
http://cr.openjdk.java.net/~naoto/8191349/specdiff.00/overview-summary.html
Naoto
On 11/15/17 10:06 AM, Naoto Sato wrote:
On 11/14/17 4:44 PM, Stephen Colebourne wrote:
On 14 November 2017 at 23:58, Naoto Sato wrote:
So even with the new suggested method,
Just to see if I picked up the Discussion so far. The discussion is
about that original sentence
from: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03
"Depending on which class implements the appendable, there may be a
limit of data
that can written to which in turn could lead to a
On 15/11/17 18:38, Vitaly Davidovich wrote:
> On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley wrote:
>> On 15/11/17 15:38, Alan Bateman wrote:
>>> Moving the nativeOrder out of the loop make sense but I'm curious about
>>> the context for improving this implementation.
>>
>> I wonder about lifting
On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley wrote:
> On 15/11/17 15:38, Alan Bateman wrote:
>> Moving the nativeOrder out of the loop make sense but I'm curious about
>> the context for improving this implementation.
>
> I wonder about lifting ByteOrder.nativeOrder(). Maybe it fails to
> inlin
On Nov 15, 2017, at 3:22 AM, Alan Bateman wrote:
> "If the destination is capacity bounded and has insufficient capacity to
> append all characters read from the source then the exception may be thrown
> after transferring some characters to the destination".
Could “is capacity-bounded and” be
On 11/14/17 4:44 PM, Stephen Colebourne wrote:
On 14 November 2017 at 23:58, Naoto Sato wrote:
So even with the new suggested method,
formatter.withZone(locale).withLocalization(locale)
formatter.withLocalization(locale).withZone(locale)
would produce different formatters. Would it be OK, ass
On 15/11/17 15:38, Alan Bateman wrote:
> Moving the nativeOrder out of the loop make sense but I'm curious about
> the context for improving this implementation.
I wonder about lifting ByteOrder.nativeOrder(). Maybe it fails to
inline because the method is too large: if that happens, we really
l
> On 14 Nov 2017, at 20:48, stanislav lukyanov
> wrote:
>
> On 15.11.2017 6:19, Paul Sandoz wrote:
>>> On 10 Nov 2017, at 01:36, stanislav lukyanov
>>> wrote:
>>>
>>> On 10.11.2017 0:13, Paul Sandoz wrote:
<...>
I would prefer to follow up later on with more non-normative explanat
On 11/15/2017 06:38 PM, Alan Bateman wrote:
On 15/11/2017 15:27, Dmitry Chuyko wrote:
Hello,
Please review a performance enhancement for java.util.CRC32C pure
Java implementation.
Moving the nativeOrder out of the loop make sense but I'm curious
about the context for improving this implemen
On 15/11/2017 15:27, Dmitry Chuyko wrote:
Hello,
Please review a performance enhancement for java.util.CRC32C pure Java
implementation.
Moving the nativeOrder out of the loop make sense but I'm curious about
the context for improving this implementation. You mentioned it helps
-Xcomp but th
Looks fine.
Nothing more from me, Roger
On 11/8/2017 6:52 PM, mandy chung wrote:
Hi Roger,
Updated version:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.02/index.html
On 11/8/17 11:37 AM, Roger Riggs wrote:
Hi Mandy,
A few editorial suggestions:
MethodHandle.java:
8
Hello,
Please review a performance enhancement for java.util.CRC32C pure Java
implementation.
rfe: https://bugs.openjdk.java.net/browse/JDK-8191328
webrev: http://cr.openjdk.java.net/~dchuyko/8191328/webrev.00/
some results:
https://bugs.openjdk.java.net/browse/JDK-8191328?focusedCommentId=14
On úterý 14. listopadu 2017 21:34:45 CET mandy chung wrote:
> I am wondering this ACE comes from Graal accessing jdk.vm.ci.services
> from JVMCI which is defined to the boot loader versus Graal is defined
> to the platform class loader.
>
> java.security.AccessControlException: access denied
> (
On 14/11/2017 16:59, Patrick Reinhart wrote:
:
And what should it be then here? I’m a bit confused now…
Sorry, there was a typo in my mail that Brian picked up on. I think we
are converging on:
"If the destination is capacity bounded and has insufficient capacity to
append all characters
On Wed, Nov 15, 2017 at 5:21 AM Andrej Golovnin
wrote:
> > On 15/11/17 10:03, Andrej Golovnin wrote:
> >> I think we would need to write ugly code in any case as Java 9 has now
> >> two empty list implementations: Collections.emptyList() and List.of().
> >>
> >> Collections.emptyList().sort() doe
On 15/11/2017 10:03, Andrej Golovnin wrote:
Hi Bernd,
On Wed, Nov 15, 2017 at 7:04 AM, Bernd Eckenfels wrote:
I would however vote for allowing an empty list to be sorted. This is such a
common case to return a replacement empty list that it will not only introduce
changed behavior but also
> On 15/11/17 10:03, Andrej Golovnin wrote:
>> I think we would need to write ugly code in any case as Java 9 has now
>> two empty list implementations: Collections.emptyList() and List.of().
>>
>> Collections.emptyList().sort() does not throw an exception.
>>
>> List.of().sort() throws an exceptio
On 15/11/17 10:03, Andrej Golovnin wrote:
> I think we would need to write ugly code in any case as Java 9 has now
> two empty list implementations: Collections.emptyList() and List.of().
>
> Collections.emptyList().sort() does not throw an exception.
>
> List.of().sort() throws an exception.
We
Hi Bernd,
On Wed, Nov 15, 2017 at 7:04 AM, Bernd Eckenfels wrote:
> I would however vote for allowing an empty list to be sorted. This is such a
> common case to return a replacement empty list that it will not only
> introduce changed behavior but also forces ugly code.
I think we would need
Hi David,
On 11/14/2017 10:28 PM, David Holmes wrote:
Hi Peter,
On 15/11/2017 1:02 AM, Peter Levart wrote:
Hi David,
On 11/11/2017 07:51 AM, David Holmes wrote:
AFAICS SimpleTimeZone is simply not thread-safe. It has state that
can be modified concurrently without synchronization and with fi
26 matches
Mail list logo
