On 5/4/16 1:38 AM, Remi Forax wrote:
nice work !
Spoken like a true university professor: "nice work" followed by 100 lines of
criticism. :-)
first, all classes should be final otherwise, they are not truly immutable and
all arrays should be marked as @Stable.
OK, I'll make the classes f
Hi Stephen,
On 5/4/16 8:25 AM, Stephen Colebourne wrote:
A new instance is being created each time for size-zero
lists/sets/maps. This should return a singleton.
Yes, this is a fairly obvious optimization. It's been on my personal to-do list,
but I've moved this to a sub-task in JIRA: JDK-815
On 5/4/16 6:22 AM, Alan Bateman wrote:
This looks very good, but I just wonder about the iteration order varying from
run to run in the Set/Map implementations. I recall the section added to the
javadoc where it made it very clear that the iteration order is unspecified and
subject to change and
Hi Daniel,
On 5/4/16 3:08 AM, Daniel Fuchs wrote:
I wonder about serial interoperability with earlier
versions of the JDK. For instance it will not be possible to
send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM.
I wonder if there is any good solution to that.
You could of course use w
Hi Peter,
Great comments and questions. Responses below
On 5/4/16 12:20 AM, Peter Levart wrote:
- What's the point of 11 overloaded List.of() methods for 0 ... 10-arity if you
then invoke the var-args ListN(E...input) constructor that does the array
cloning with 8 of them? The same for Set.
Hello,
Please review two small patches for jdk and hotspot repos which add
array bound checks to functions which return a length of bytecode
instruction.
Please see details in https://bugs.openjdk.java.net/browse/JDK-8152207
http://cr.openjdk.java.net/~asmotrak/8152207/jdk/webrev.00/
http://
Thanks, Vladimir.
BTW, automated build+test has revealed that my test's simple array of
expected values doesn't cut it in the face of other [endian|bit]ness-es.
For now, I need to skip checking of a couple of locals until something
more robust can be added.
Thanks,
-Brent
jdk/test/java/lan
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8130679
Patch: http://cr.openjdk.java.net/~bpb/8130679/webrev.00/
Summary: Add “@throws IndexOutOfBoundsException […]” to all write() methods
which accept an index parameter and for which no such throws tag is a
- Mail original -
> De: "Peter Levart"
> À: "Stephen Colebourne" , "core-libs-dev"
>
> Envoyé: Mercredi 4 Mai 2016 23:58:13
> Objet: Re: RFR(m): 8139233 add initial compact immutable collection
> implementations
>
>
>
> On 05/04/2016 05:25 PM, Stephen Colebourne wrote:
> > I disagr
On 05/04/2016 05:25 PM, Stephen Colebourne wrote:
I disagree with altering the iteration order. Guava's ImmutableSet and
ImmutableMap have reliable iteration specified to match creation
order. This aspect of the design is very useful.
Stephen
Are they also O(1) on lookup at the same time?
A
For the record, I reviewed the jvm changes and they look good.
thanks,
Karen
> On May 4, 2016, at 3:29 PM, Mandy Chung wrote:
>
> The default implementation of ObjectInputStream::resolveClass and
> resolveProxyClass finds the user-defined class loader on the stack and
> assumes that only syst
The new test looks good, Mandy.
Thanks,
-Brent
On 05/04/2016 12:36 PM, Mandy Chung wrote:
This version includes a new test:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.02/
Daniel - StackFrameInfo class is package-private class In the future this may
become a final class
Thanks Claes! fixed and webrev has been updated.
http://cr.openjdk.java.net/~sherman/8150496/webrev
sherman
On 05/04/2016 12:38 PM, Claes Redestad wrote:
Hi Sherman,
On 2016-05-04 21:14, Xueming Shen wrote:
http://cr.openjdk.java.net/~sherman/8150496/webrev
this looks good to me!
Pre-exi
Hi Sherman,
On 2016-05-04 21:14, Xueming Shen wrote:
http://cr.openjdk.java.net/~sherman/8150496/webrev
this looks good to me!
Pre-existing typo 'bofore' -> 'before' in
src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java
/Claes
This version includes a new test:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.02/
Daniel - StackFrameInfo class is package-private class In the future this may
become a final class once we decide what to do with locals and operands in a
future release. I don’t worry about
The default implementation of ObjectInputStream::resolveClass and
resolveProxyClass finds the user-defined class loader on the stack and assumes
that only system classes are loaded by null loader. As JDK modules are
deprivileged, classes on the stack defined by the platform class loader.
These
On 05/04/2016 10:14 PM, Xueming Shen wrote:
> http://cr.openjdk.java.net/~sherman/8150496/webrev
Okay, good.
> yes, the performance gains still hold.
>
> Benchmark Mode Cnt Score Error Units
> ---new--
Hi Aleksey,
The webrev has been updated accordingly.
http://cr.openjdk.java.net/~sherman/8150496/webrev
---
*) Parentheses to nail down eval order:
if (w&& zfs.isReadOnly() || x) {
...to:
if ((w&& zfs.isReadOnly()) |
PS: I wonder whether the MH cache in VarHandle
(VarHandle.typesAndInvokers.methodHandle_table) should be idempotent or not.
I am guessing you mean in terms of the MH ref identity?
Yes, but I think it matters only if bytecode spinning happens (it does
for LambdaForms). What matters for the
> On 4 May 2016, at 09:19, Vladimir Ivanov wrote:
>
> Looks good.
>
> I'm fine with pushing it directly into jdk9/dev, since the change just
> relaxes the assert and the risk of a merge conflict is very small.
>
Thanks!
> Best regards,
> Vladimir Ivanov
>
> PS: I wonder whether the MH cac
Looks good.
I'm fine with pushing it directly into jdk9/dev, since the change just
relaxes the assert and the risk of a merge conflict is very small.
Best regards,
Vladimir Ivanov
PS: I wonder whether the MH cache in VarHandle
(VarHandle.typesAndInvokers.methodHandle_table) should be idempot
This makes sense - I will move the tests into a subduer, put the dependencies
into a TEST.properties file.
jdk.zipfs has the code needed for access jars - the tests are failing without
that dependency.
Shura
> On May 4, 2016, at 8:30 AM, Chris Hegarty wrote:
>
> On 4 May 2016, at 14:32, Alan
Hi Alan,
On 2016/5/4 22:45, Alan Bateman wrote:
On 04/05/2016 15:39, Felix Yang wrote:
Hi Alan,
please review the updated webrev. Reverted changes for those
tests with "-addmods".
http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/
For the javax.transaction test then don't you al
On 04/05/2016 15:53, Andrew Dinn wrote:
:
Just to dispel any idea that this has been plucked out of thin air by
the JacORB implementors I'll note that there appears to be both a
standard for and more than one implementation of ssliop.
Regarding implementations, OpenORB and TAO also implemented
On 4 May 2016, at 14:32, Alan Bateman wrote:
>
> On 04/05/2016 11:24, Chris Hegarty wrote:
>> :
>> The tests cause compilation of test library classes, but only some tests
>> actually use the methods that provoke compilation. Similar to above, tests
>> that don’t actually compile anything could d
A new instance is being created each time for size-zero
lists/sets/maps. This should return a singleton.
The serialization proxy is reminiscent of those in JSR-310 but less
space efficient. Once per stream, the proxy will write
"java.util.ImmutableCollections.SerialProxy", whereas the JSR-310 one
Looks good.
Best regards,
Vladimir Ivanov
On 5/3/16 1:37 AM, Paul Sandoz wrote:
Hi,
Please review:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev
On 04/05/16 15:36, Tomasz Adamski wrote:
> I'm proposing this extension from practical reasons as it would
> enable configuration of fully secured iiop invocations - the feature
> that was present in ORB implementation that we used previously
> (JacORB). ORB specification allows adding new corbaloc
Hi Sherman,
On 05/03/2016 11:19 PM, Xueming Shen wrote:
> Again, thanks for the review. The webrev has been updated accordingly,
> as well as the MyBenchmark.java (to use Blackhole, as suggested)
>
> http://cr.openjdk.java.net/~sherman/8150496/webrev/
Further nits, sorry for not catching them ea
On 05/04/2016 10:50 AM, Peter Levart wrote:
> On 05/03/2016 02:39 PM, Aleksey Shipilev wrote:
>> *) There is ever-so-subtle difference in doing either:
>>
>> 171 byte[] tmp = new byte[path.length + 1];
>> 172 System.arraycopy(path, 0, tmp, 1, path.length);
>> 173
On 04/05/2016 15:39, Felix Yang wrote:
Hi Alan,
please review the updated webrev. Reverted changes for those tests
with "-addmods".
http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/
For the javax.transaction test then don't you also add
"java.transaction" in the @modules value? T
Hi Roger,
Ok. Thanks.
Regards,
Nadeesh
On 5/4/2016 7:58 PM, Roger Riggs wrote:
Hi Nadeesh,
java/time/format/DateTimeFormatterBuilder.java: 1836-1839
Correct as is, but could collapse both count ==2 and count ==3 into a
single appendValue call:
appendValue(field, count, 3, SignStyle.NOT_NE
Hi Alan,
please review the updated webrev. Reverted changes for those tests
with "-addmods".
http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/
Thanks,
Felix
On 2016/4/29 15:25, Alan Bateman wrote:
On 29/04/2016 03:16, Felix Yang wrote:
Hi there,
please review the changes to e
+1
Roger
On 5/4/2016 6:00 AM, Stephen Colebourne wrote:
Fine by me.
thanks
Stephen
On 4 May 2016 at 08:13, nadeesh tv wrote:
Hi,
Updated the webrev http://cr.openjdk.java.net/~ntv/8148949/webrev.03/
Thanks and Regards,
Nadeesh
On 5/3/2016 8:37 PM, Stephen Colebourne wrote:
The current be
I'm proposing this extension from practical reasons as it would enable
configuration of fully secured iiop invocations - the feature that was present
in ORB implementation that we used previously (JacORB). ORB specification
allows adding new corbaloc protocols if necessary:
"This specification
Hi Nadeesh,
java/time/format/DateTimeFormatterBuilder.java: 1836-1839
Correct as is, but could collapse both count ==2 and count ==3 into a
single appendValue call:
appendValue(field, count, 3, SignStyle.NOT_NEGATIVE); Reviewed.
Roger
On 5/4/2016 3:15 AM, nadeesh tv wrote:
Hi,
Updated the
On Wed, May 4, 2016 at 3:29 PM, Jan Lahoda wrote:
> On 3.5.2016 14:58, Florent Guillaume wrote:
>> http://www.x.org/docs/xterm/ctlseqs.pdf is probably a more canonical
>> reference.
>
> It seems that this version of the document unfortunately does not specify
> the codes the terminal sends for the
On 04/05/2016 11:24, Chris Hegarty wrote:
:
The tests cause compilation of test library classes, but only some tests
actually use the methods that provoke compilation. Similar to above, tests
that don’t actually compile anything could depend on just java.compiler.
This is all to fragile and ma
On 3.5.2016 14:58, Florent Guillaume wrote:
Hi,
http://www.x.org/docs/xterm/ctlseqs.pdf is probably a more canonical reference.
It seems that this version of the document unfortunately does not
specify the codes the terminal sends for the function keys?
Jan
Florent
On Mon, May 2, 2016
On 04/05/2016 05:55, Stuart Marks wrote:
Hi all,
This is a reimplementation of collections created by the JEP 269
convenience factory methods. These implementations are overall quite a
bit smaller than their conventional collections counterparts,
particularly at small sizes. Lookup performan
On 03/05/2016 21:16, Mandy Chung wrote:
I originally asked Sherman to identify the permissions for jdk.charsets as a
follow up issue. I took another look and define the list:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155513/webrev.01/
This looks okay to me.
-Alan.
On 4 May 2016, at 11:07, Alan Bateman wrote:
> On 04/05/2016 09:40, Chris Hegarty wrote:
>> On 3 May 2016, at 16:10, Chris Hegarty wrote:
>>
> Can you please take a look on:
> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/
>> Taking another look over this before sponsoring….
On 04/05/2016 09:40, Chris Hegarty wrote:
On 3 May 2016, at 16:10, Chris Hegarty wrote:
Can you please take a look on:
http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/
Taking another look over this before sponsoring….
The test library dependency seems to be on java.compiler, and n
Hi Stuart,
It will be good to have really immutable collections!
But I have one comment:
I wonder about serial interoperability with earlier
versions of the JDK. For instance it will not be possible to
send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM.
I wonder if there is any good sol
Fine by me.
thanks
Stephen
On 4 May 2016 at 08:13, nadeesh tv wrote:
> Hi,
>
> Updated the webrev http://cr.openjdk.java.net/~ntv/8148949/webrev.03/
>
> Thanks and Regards,
> Nadeesh
>
> On 5/3/2016 8:37 PM, Stephen Colebourne wrote:
>>
>> The current behaviour is to use NORMAL for "A" and NOT_NE
On 3 May 2016, at 16:10, Chris Hegarty wrote:
>>>
>>> Can you please take a look on:
>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/
Taking another look over this before sponsoring….
The test library dependency seems to be on java.compiler, and not jdk.compiler,
right ? Also, I
Hi Stuart,
nice work !
first, all classes should be final otherwise, they are not truly immutable and
all arrays should be marked as @Stable.
List0, List1,
why not using Collections.emptyList(), Collections.singletonList() here ?
ListN:
- i don't think that extending AbstractList is a go
Looks good.
Best regards,
Vladimir Ivanov
On 5/3/16 10:00 PM, Brent Christian wrote:
Hi,
Please review this change which fixes buggy behavior (including SEGV) in
the experimental LiveStackFrame feature of StackWalker.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8147039
Webrev:
http://cr.ope
Hi Aleksey,
On 05/03/2016 02:39 PM, Aleksey Shipilev wrote:
*) There is ever-so-subtle difference in doing either:
171 byte[] tmp = new byte[path.length + 1];
172 System.arraycopy(path, 0, tmp, 1, path.length);
173 tmp[0] = '/';
...or:
1083
Hi Stuart,
Good to see these implementations finally appear. I have a few comments:
- What's the point of 11 overloaded List.of() methods for 0 ... 10-arity
if you then invoke the var-args ListN(E...input) constructor that does
the array cloning with 8 of them? The same for Set.of()... I sugg
Hi,
Updated the webev http://cr.openjdk.java.net/~ntv/8079628/webrev.04/
Regards,
Nadeesh
On 5/3/2016 8:45 PM, Stephen Colebourne wrote:
Letters "Q", "q", "M", "L", "d", "D", "F", "h", "H", "k", "K", "m",
"s" and no doubt others use NORMAL via
appendValue(field);
Changing these to use NOT_NEG
Hi,
Updated the webrev http://cr.openjdk.java.net/~ntv/8148949/webrev.03/
Thanks and Regards,
Nadeesh
On 5/3/2016 8:37 PM, Stephen Colebourne wrote:
The current behaviour is to use NORMAL for "A" and NOT_NEGATIVE for
"AA", "AAA" and so on. The sensible behaviour going forward is to use
NOT_NEGA
52 matches
Mail list logo
