Hi Martin,
On 05/17/2016 05:19 AM, Martin Buchholz wrote:
I have some evidence that an object's finalize method can run while a
weak reference pointing to it is not yet cleared, which surprised me.
E.g.
class F { protected void finalize() { assert wref.get() != this; } }
static WeakReference w
Hi Bhanu,
I think you should add a test case comparing the return value of getFrom()
( Not an official reviewer)
Regards,
Nadeesh
On 5/16/2016 11:46 AM, Bhanu Gopularam wrote:
Hi all,
Could you please review fix for following issue.
Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718
I have some evidence that an object's finalize method can run while a
weak reference pointing to it is not yet cleared, which surprised me.
E.g.
class F { protected void finalize() { assert wref.get() != this; } }
static WeakReference wref = new WeakReference(new F());
If this is a bug, I can try
Hi,
Please review the changes to
test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java:
1. The test is skipped by JTREG due to incorrect module name in jtreg
@modules tag: javax.xml.bind -> java.xml.bind
2. The compilation of XJC generated classes now requires "-addmods
java.xml.bind" argume
Hi,
Please, help to review XjcOptionalPropertyTest test modification bug [1].
The list of applied changes:
1. Test files are now generated in jtreg work directory (scratch),
instead of test source folder.
2. Shell script was replaced with java code: xjc tool is now invoked via
jdk.testlibrary.J
Hi all,
Please review this changeset that adds specifications of the serialized forms
(really, a single serialization proxy class) for the immutable collections
implementation. There are no code changes in this changeset, just documentation.
It's somewhat odd, but the class doc for the serial
On 05/16/2016 11:53 AM, Martin Buchholz wrote:
Hi Xueming,
https://bugs.openjdk.java.net/browse/JDK-8157069
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-assortment/
Hopefully other improvements later.
looks fine.
yes, someone will have to deal with a > byte[] cen table, some
Hi Xueming,
https://bugs.openjdk.java.net/browse/JDK-8157069
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-assortment/
Hopefully other improvements later.
BTW, I notice that the CEN is stored in a byte[], and someday someone
will create a zip file with a CEN that won't fit!
- Mail original -
> De: "Iris Clark"
> À: "Remi Forax"
> Cc: "Java Core Libs" ,
> compiler-...@openjdk.java.net, verona-...@openjdk.java.net
> Envoyé: Lundi 16 Mai 2016 19:52:33
> Objet: RE: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
>
> Hi, Remi.
Hi Iris,
>
> Thanks
Hi, Remi.
Thanks for taking the time to review this change.
> java.lang.Runtime.Version is used during the boot process
I don’t think that Runtime.Version is used during boot because
I'm not seeing it loaded with a small test program invoked with
"java -verbose:class Hi". In fact, I'm not seein
Hi Martin,
As I have been studying the CleanerTest too recently, let me comment on
some questions...
On 05/09/2016 06:34 PM, Martin Buchholz wrote:
---
Assert.assertEquals(map.get(k2), data, "value should be found
in the map");
key = null;
System.gc();
Ass
On 16/05/2016 14:45, Seán Coffey wrote:
On 16/05/16 13:51, Alan Bateman wrote:
On 16/05/2016 13:44, Seán Coffey wrote:
Some extra capturing of context in exception handling. I've re-based
the original suggested patch and added some minor edits.
https://bugs.openjdk.java.net/browse/JDK-8151
Hi,
what do you thing about adding helper methods for this kind of VarHandle?
It would be nice to have something like
Long.getFrom[LE/BE](byte[] arr, int index) // LE/BE -> endianity
Long.setTo[LE/BE](long val, byte[] arr, int index)
or
Arrays.getLongFrom[LE/BE](byte[] arr, int index)
On 16/05/16 13:51, Alan Bateman wrote:
On 16/05/2016 13:44, Seán Coffey wrote:
Some extra capturing of context in exception handling. I've re-based
the original suggested patch and added some minor edits.
https://bugs.openjdk.java.net/browse/JDK-8151832
webrev :
http://cr.openjdk.java.net/~c
On 16/05/2016 13:44, Seán Coffey wrote:
Some extra capturing of context in exception handling. I've re-based
the original suggested patch and added some minor edits.
https://bugs.openjdk.java.net/browse/JDK-8151832
webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html
Some extra capturing of context in exception handling. I've re-based the
original suggested patch and added some minor edits.
https://bugs.openjdk.java.net/browse/JDK-8151832
webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html
--
Regards,
Sean.
Hi Peter,
I for one think this looks like a very nice cleanup.
The patch drops 5 classes from a minimal VM startup test, which is a
welcome improvement.
/Claes
On 2016-05-16 00:08, Peter Levart wrote:
Hi Roger and others,
When the new Cleaner API was created the implementation of
Cleanabl
Looks good.
Best regards,
Vladimir Ivanov
PS: regarding naming, makeVarHandleMethodInvoker is shorter and as
informative. Since there are only 2 flavors of invokers for VarHandles
(for MHs there are also basic invokers), there's no need to explicitly
mention the modes in method names.
On 5/
Hey Peter,
Thanks for your answer. Actually you’re right, makes perfect sense. Somehow it
still feels wrong to implement the same pattern (inside lots of classes) over
and over again. Inheritance, on the other hand, is not always possible.
Chris
> On 16 May 2016, at 12:57, Peter Levart wrote
Correction in line...
On 05/16/2016 12:54 PM, Peter Levart wrote:
Hi Christoph,
On 05/16/2016 10:37 AM, Christoph Engelbert wrote:
Hey Peter,
First of all, I really love this Cleanup API!
Anyhow I think it would make sense to have Cleanable extend
AutoCloseable for exactly the use case you
Hi Christoph,
On 05/16/2016 10:37 AM, Christoph Engelbert wrote:
Hey Peter,
First of all, I really love this Cleanup API!
Anyhow I think it would make sense to have Cleanable extend AutoCloseable for
exactly the use case you rendered in your JavaDoc of the Cleaner class.
Made up example:
pub
Looks good.
Best regards,
Vladimir Ivanov
PS: I noticed you missed ACC_PRIVATE flag on the invoker class, but then
erroneously put it on the method. Please, move it to class flags before
pushing. No need to send updated webrev.
+ cw.visit(52, ACC_PRIVATE | ACC_SUPER, "InjectedInv
Peter,
Just as a quick correction of the previous example, obviously
Buffer::deallocate wouldn’t work, but I guess you get the point.
Chris
> On 16 May 2016, at 10:37, Christoph Engelbert wrote:
>
> Hey Peter,
>
> First of all, I really love this Cleanup API!
> Anyhow I think it would make s
Hey Peter,
First of all, I really love this Cleanup API!
Anyhow I think it would make sense to have Cleanable extend AutoCloseable for
exactly the use case you rendered in your JavaDoc of the Cleaner class.
Made up example:
public T execute(BufferAction bufferAction) {
Buffer buffer = allocat
java/io/pathNames/GeneralWin32.java
has been seen to fail with high frequency on windows. Until JDK-8156595
is addressed, the test should be problem listed.
bug: https://bugs.openjdk.java.net/browse/JDK-8157006
tools/pack200/TestNormal.java
has been seen to fail with some frequency on windows.
25 matches
Mail list logo