Here's an updated webrev. I also renamed APP_CLASSNAME to
APP_SLASH_CLASSNAME just to make it a bit more clear which format is
being used.
http://cr.openjdk.java.net/~cjplummer/8242142/webrev.01
thanks,
Chris
On 4/3/20 6:13 PM, Chris Plummer wrote:
Ok, I'll make those changes. Thanks for th
Ok, I'll make those changes. Thanks for the review.
Chris
On 4/3/20 5:44 PM, Alex Menkov wrote:
Hi Chris,
The fix looks good.
Couple minor notes about the test:
41 static final String APP_CLASSNAME =
"jdk/test/lib/apps/LingeredApp";
42 static final String APP_DOT_CLASSNAME =
APP_
Hi Chris,
The fix looks good.
Couple minor notes about the test:
41 static final String APP_CLASSNAME =
"jdk/test/lib/apps/LingeredApp";
42 static final String APP_DOT_CLASSNAME =
APP_CLASSNAME.replace('/', '.');
I'd make this
static final String APP_DOT_CLASSNAME = LingeredApp.cl
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8242142
http://cr.openjdk.java.net/~cjplummer/8242142/webrev.00/
See the CR for details. Note the output for the "class" command looks like:
jdk/test/lib/apps/LingeredApp @0x000800bcb040
The output for "class
Hi Peter,
I added a JBS comment [1] to describe this special case trying to put
the story together (let me know if it needs more explanation). More
comment inline below.
On 4/3/20 4:40 AM, Peter Levart wrote:
Ok, I think I found one such use-case. In the following example:
package test;
pub
Looks good
Leonid
> On Apr 2, 2020, at 4:20 PM, Alex Menkov wrote:
>
> Hi all,
>
> please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8237572
> webrev:
> http://cr.openjdk.java.net/~amenkov/jdk15/jpsLingeredApp/webrev/
>
> verified all test which use LangeredApp pass.
>
> --
Looks good.
thanks,
Chris
On 4/2/20 4:20 PM, Alex Menkov wrote:
Hi all,
please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8237572
webrev:
http://cr.openjdk.java.net/~amenkov/jdk15/jpsLingeredApp/webrev/
verified all test which use LangeredApp pass.
--alex
Hi Egor,
The changes look fine. Please update the copyrights before pushing.
thanks,
Chris
On 4/3/20 2:16 AM, Egor Ushakov wrote:
Hi all, please review the fix
The com.sun.tools.jdi.ClassLoaderReferenceImpl#findType may be slow
because ClassLoaderReferenceImpl#visibleClasses does not popula
Thanks Alex and Yasumasa!
Chris
On 4/2/20 5:35 PM, Alex Menkov wrote:
+1
--alex
On 04/02/2020 17:17, Yasumasa Suenaga wrote:
Hi Chris,
Looks good!
Yasumasa
On 2020/04/03 5:46, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8240989
ht
Thank you, Serguei and Alex, for reviewing this change.
Best regards,
Daniil
On 4/1/20, 2:19 PM, "serguei.spit...@oracle.com"
wrote:
Hi Daniil,
LGTM++
Thanks,
Serguei
On 3/30/20 13:06, Alex Menkov wrote:
> Looks good.
>
> --alex
>
>
Ok, I think I found one such use-case. In the following example:
package test;
public class LambdaTest {
protected void m() {
}
}
package test.sub;
public class LambdaTestSub extends test.LambdaTest {
public void test() {
Runnable r = this::m;
r.run();
}
}
...whe
Hi all, please review the fix
The com.sun.tools.jdi.ClassLoaderReferenceImpl#findType may be slow
because ClassLoaderReferenceImpl#visibleClasses does not populate
signature and we check it for every class in the loop just after, so
requesting all unavailable signatures one by one.
The fix add
Hi Mandy,
Good work.
I'm trying to find out which language use-case is covered by the
InnerClassLambdaMetafactory needing to inject method handle into the
generated proxy class to be invoked instead of proxy class directly
invoking the method:
useImplMethodHandle =
!implClass.getPa
13 matches
Mail list logo
