On 25.05.2016 22:32, Mandy Chung wrote:
On May 25, 2016, at 1:12 PM, Jochen Theodorou wrote:
Dynamic proxies and invocation handlers won't do the job, as they do not
provide an implementation of the interface I can call the default method
on.
Is this a general limitation of j.l.r.Proxy? At
Looks fine Amy; thanks,
-Joe
On 5/25/2016 10:10 PM, Amy Lu wrote:
tools/jimage/JImageTest.java
This test is in ProblemList.txt with related bugid JDK-8150975.
JDK-8150975 has been closed since previously reported image recreate
issue now is not an issue anymore because the support for jimag
tools/jimage/JImageTest.java
This test is in ProblemList.txt with related bugid JDK-8150975.
JDK-8150975 has been closed since previously reported image recreate
issue now is not an issue anymore because the support for jimage
recreate has been removed in JDK-8154090, in which test also update
> On May 25, 2016, at 3:38 PM, Kevin Rushforth
> wrote:
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8131888
> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
>
> This adds support for the javafx.embed.swt package back into the JDK, which
> will be delive
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8131888
http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
This adds support for the javafx.embed.swt package back into the JDK,
which will be delivered as an automatic module in
$JAVA_HOME/lib/javafx-swt.jar (final location
> On May 25, 2016, at 2:40 AM, Alan Bateman wrote:
>
> This is minor mismatch between javadoc + implementation when
> getResourceAsStream is called on a module in a custom Layer and access is
> denied by the security manager. It's a one line fix, this is mostly just a
> new test:
> http://c
> On May 25, 2016, at 1:12 PM, Jochen Theodorou wrote:
>
>>> Dynamic proxies and invocation handlers won't do the job, as they do not
>>> provide an implementation of the interface I can call the default method
>>> on.
>>
>> Is this a general limitation of j.l.r.Proxy? At first glance it doesn'
On 25.05.2016 20:08, Alex Buckley wrote:
On 5/25/2016 12:22 AM, Jochen Theodorou wrote:
so in earlier mails to this list I described a bit the problems I got
into with the way Groovy produces proxies and handles default methods
for those.
Pointer? The most relevant thread I could find was "Gro
On 25/05/2016 13:48, Chris Hegarty wrote:
:
I think this is fine. Does the @implSpec on release(ByteBuffer) need
to be updated too?
Fair point, it would be clearer if it said that it doesn't do anything
except check for null.
-Alan
On 5/25/2016 12:22 AM, Jochen Theodorou wrote:
so in earlier mails to this list I described a bit the problems I got
into with the way Groovy produces proxies and handles default methods
for those.
Pointer? The most relevant thread I could find was "Groovy with Jigsaw"
from September 2015 but
> On May 25, 2016, at 4:49 AM, Alan Bateman wrote:
>
>
> Another trivial patch, this time it's the ModuleReader for the system modules
> is missing a null check so that it doesn't throw the expected NPE. The patch
> is to mostly just expand test coverage.
> http://cr.openjdk.java.net/~alanb/
> On May 25, 2016, at 4:09 AM, Alan Bateman wrote:
>
>
> This is another small fix where the Layer javadoc doesn't make it clear that
> there can only be one "java.base" module in the VM. The enforcement has been
> there but it wasn't specified and there weren't tests for this scenario.
>
> On 25 May 2016, at 12:09, Alan Bateman wrote:
>
> This is another small fix where the Layer javadoc doesn't make it clear that
> there can only be one "java.base" module in the VM. The enforcement has been
> there but it wasn't specified and there weren't tests for this scenario.
>http:/
> On 25 May 2016, at 12:49, Alan Bateman wrote:
>
>
> Another trivial patch, this time it's the ModuleReader for the system modules
> is missing a null check so that it doesn't throw the expected NPE. The patch
> is to mostly just expand test coverage.
> http://cr.openjdk.java.net/~alanb/815
Looks good
-Sundar
On 5/25/2016 5:19 PM, Alan Bateman wrote:
>
> Another trivial patch, this time it's the ModuleReader for the system
> modules is missing a null check so that it doesn't throw the expected
> NPE. The patch is to mostly just expand test coverage.
> http://cr.openjdk.java.net/~
Another trivial patch, this time it's the ModuleReader for the system
modules is missing a null check so that it doesn't throw the expected
NPE. The patch is to mostly just expand test coverage.
http://cr.openjdk.java.net/~alanb/8156142/webrev/
Thanks,
Alan
This is another small fix where the Layer javadoc doesn't make it clear
that there can only be one "java.base" module in the VM. The enforcement
has been there but it wasn't specified and there weren't tests for this
scenario.
http://cr.openjdk.java.net/~alanb/8150668/webrev/
Thanks,
Ala
This is minor mismatch between javadoc + implementation when
getResourceAsStream is called on a module in a custom Layer and access
is denied by the security manager. It's a one line fix, this is mostly
just a new test:
http://cr.openjdk.java.net/~alanb/8156143/webrev/
Thanks,
-Alan
> On 25 May 2016, at 07:44, John Jiang wrote:
>
> Hi,
> Please review this patch on fixing module dependencies for /javax/* and
> /jdk/* tests.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8157783
> Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/
The changes to the non-ja
Hi Stuart,
thanks for the comments.
On 2016/5/21 7:52, Stuart Marks wrote:
On 5/16/16 1:18 AM, Felix Yang wrote:
please review the updated webrev, which remove not-suggested
filesystem
modification and codebase stuff:
http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/
Hi Felix,
OK, I'll update issue JDK-8157783 and its webrev to focus on /jdk/* only.
Thanks!
John Jiang
On 2016/5/25 15:07, Felix Yang wrote:
Hi John,
I think changes for javax/* tests are not needed. Please have a
look at the bug below. We are waiting for the next jtreg promotion to
push the cha
Hi all,
so in earlier mails to this list I described a bit the problems I got
into with the way Groovy produces proxies and handles default methods
for those.
I would like to see how the correct solution to this is supposed to be
so we have code like m.sortReversed{a,b -> a.value <=> b.v
Hi John,
I think changes for javax/* tests are not needed. Please have a
look at the bug below. We are waiting for the next jtreg promotion to
push the change, otherwise those tests will be skipped silently.
https://bugs.openjdk.java.net/browse/JDK-8157135
-Felix
On 2016/5/25 14:44, Joh
23 matches
Mail list logo
