On 2016-04-01 16:57, Mandy Chung wrote:
On Apr 1, 2016, at 5:32 AM, Claes Redestad wrote:
http://cr.openjdk.java.net/~redestad/8152641/webrev.06/
Looks good except the new test with 2015 copyright start year.
Fixed. Thanks Mandy!
/Claes
> On Apr 1, 2016, at 5:32 AM, Claes Redestad wrote:
>
> http://cr.openjdk.java.net/~redestad/8152641/webrev.06/
>
Looks good except the new test with 2015 copyright start year.
>
> [1] Mandy filed https://bugs.openjdk.java.net/browse/JDK-8153238 to improve
> this
Hi Mandy et al,
On 2016-04-01 01:10, Mandy Chung wrote:
GenerateBMHClassesPlugin::configure
The plugin should validate of the input argument and throw an exception if
it’s invalid. The plugin API is still being revised and JDK-8152800 is related
to the exception case. The existing
> On Mar 31, 2016, at 4:10 PM, Mandy Chung wrote:
>
>
>> On Mar 30, 2016, at 9:17 AM, Claes Redestad
>> wrote:
>>
>> Hi Peter,
>>
>> something like this, then:
>>
>> http://cr.openjdk.java.net/~redestad/8152641/webrev.05/
>>
>
>
> On Mar 30, 2016, at 9:17 AM, Claes Redestad wrote:
>
> Hi Peter,
>
> something like this, then:
>
> http://cr.openjdk.java.net/~redestad/8152641/webrev.05/
>
BoundMethodHandle::generateConcreteBMHClassBytes
It only allows “LIJFD” characters. But the default
> On Mar 29, 2016, at 4:03 PM, Claes Redestad wrote:
>
> Mandy: I've not found any test (under jdk/test/tools/jlink or elsewhere) which
> has to be updated when adding a plugin like this.
jdk/test/tools/jlink/JLinkTest.java
This is the one I recalled. This is in
I like it too. Reviewed.
A couple of comments:
The default list of species in the plugin (List.of("LL", "L3", … "I", "LLILL"))
should
be commented with information for maintainers to reproduce the procedure you
used to generate that list. Otherwise the list is just magic, and
unmaintainable.
Hi Peter,
something like this, then:
http://cr.openjdk.java.net/~redestad/8152641/webrev.05/
- Added a method only used by the plugin which validates input; added a
comment about the dependency
- Invalid types are logged but otherwise ignored now (I bet someone
might suggest a better way to
Hi Claes,
webrev.04 looks good now.
Maybe just one nit. For production quality, plugin input could be
verified that after expansion it is composed of just the following
characters: "LIJFD". Otherwise ClassWriter might generate an unusable
class without complaining (for example if someone
On 2016-03-30 14:21, Peter Levart wrote:
Hi Claes,
On 03/30/2016 12:53 PM, Claes Redestad wrote:
Hi,
I think Class.forName(Module, String) seemed like a nice
efficiency/simplicity compromise, but there is some usage of
lambdas/method-refs in the Module lookup code, especially for
Hi Claes,
On 03/30/2016 12:53 PM, Claes Redestad wrote:
Hi,
I think Class.forName(Module, String) seemed like a nice
efficiency/simplicity compromise, but there is some usage of
lambdas/method-refs in the Module lookup code, especially for exploded
modules (which get exercised during JDK
Hi,
On 2016-03-30 13:11, Remi Forax wrote:
Hi Claes,
Did you considere to use
return c.asSubclass(BoundMethodHandle.class);
instead of
return (Class)c;
to avoid the @SupressWarnings, like in generateConcreteBMHClass ?
no, but it's a good cleanup. :-)
Updated in-place:
> À: "Peter Levart" <peter.lev...@gmail.com>, "Mandy Chung"
> <mandy.ch...@oracle.com>
> Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>, "core-libs-dev"
> <core-libs-...@openjdk.java.net>
> Envoyé: Mercredi 30 Mars 2016 12:53:
Hi,
I think Class.forName(Module, String) seemed like a nice
efficiency/simplicity compromise, but there is some usage of
lambdas/method-refs in the Module lookup code, especially for exploded
modules (which get exercised during JDK build). Depending on a lambda
from code in java.lang.invoke
Hi Claes,
Sorry, I found a flaw in the benchmark (the regex pattern to split
comma-separated string into substrings was wrong). What the benchmark
did was compare the overheads of a single lookup of a longer class name
containing commas. Here's the corrected result of overheads of 5
Hi Claes,
On 03/30/2016 01:03 AM, Claes Redestad wrote:
Hi Peter, Mandy,
On 2016-03-26 12:47, Peter Levart wrote:
Comparing this with proposed code from webrev:
493 try {
494 return (ClassBoundMethodHandle>)
495
Hi Peter, Mandy,
On 2016-03-26 12:47, Peter Levart wrote:
Comparing this with proposed code from webrev:
493 try {
494 return (ClassBoundMethodHandle>)
495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" +
Hi Claes, Mandy,
On 03/25/2016 03:58 PM, Claes Redestad wrote:
Hi,
On 2016-03-25 11:11, Peter Levart wrote:
Hi Claes, Mandy,
On 03/25/2016 02:51 AM, Mandy Chung wrote:
Hi Claes,
This is a good interesting work to generate
BoundMethodHandle$Species_* classes at link time. This will save
> On Mar 25, 2016, at 7:58 AM, Claes Redestad wrote:
>
> Hi,
>
> On 2016-03-25 11:11, Peter Levart wrote:
>> Hi Claes, Mandy,
>>
>> On 03/25/2016 02:51 AM, Mandy Chung wrote:
>>> Hi Claes,
>>>
>>> This is a good interesting work to generate
Hi,
On 2016-03-25 11:11, Peter Levart wrote:
Hi Claes, Mandy,
On 03/25/2016 02:51 AM, Mandy Chung wrote:
Hi Claes,
This is a good interesting work to generate
BoundMethodHandle$Species_* classes at link time. This will save the
class generation time. Instead of Class.forName, you may
Hi Claes, Mandy,
On 03/25/2016 02:51 AM, Mandy Chung wrote:
Hi Claes,
This is a good interesting work to generate BoundMethodHandle$Species_* classes at
link time. This will save the class generation time. Instead of Class.forName, you
may want to have a class (similar to SystemModules
Hi,
please review this patch which add an enabled-by-default plugin to
generate a
configurable list of BoundMethodHandle$Species_*-classes using jlink.
Bug: https://bugs.openjdk.java.net/browse/JDK-8152641
Webrev: http://cr.openjdk.java.net/~redestad/8152641/webrev.01/
This plugin adds the
22 matches
Mail list logo