On 2/5/16 4:54 PM, David Holmes wrote:
Regardless of whether I agree with this API or not, it does, as Stuart points
out, require a JEP and to go through the normal rigorous process of determining
whether an API is suitable for inclusion in the Java platform.
Note, it was Thomas Stüfe who sug
On 07/02/2016 22:20, Peter Levart wrote:
:
If the decision to remove sun.misc.Cleaner was partly influenced by
the desire to maintain just 2 instead of 3 Cleaner(s), then my
proposal to migrate JDK code to the public API might enable Oracle to
reconsider keeping sun.misc.Cleaner.
The main
On 6/02/2016 8:21 AM, Mikael Vidstedt wrote:
I fully agree that moving the arguments checking up to Java makes more
sense, and I've prepared new webrevs which do exactly that, including
changes to address the other feedback from David, John and others:
Shouldn't the lowest-level do_conjoint_sw
Hi Peter,
as discussed before in the other thread about move to jdk.internal: this looks
fine to Apache Lucene. We have a separate issue to fix this for Java 9:
https://issues.apache.org/jira/browse/LUCENE-6989
Currently the patch on the Lucene issue tries to cast the jdk.internal.Cleaner
to R
Looks good to me.
Masayoshi
On 2/4/2016 5:55 PM, Ramanand Patil wrote:
Hi Masayoshi/all,
Please review the updated Webrev at:
http://cr.openjdk.java.net/~rpatil/8148446/webrev.01/
Regards,
Ramanand.
-Original Message-
From: Masayoshi Okutsu
Sent: Thursday, February 04, 2016 12:17 PM
On 02/07/2016 11:20 PM, Peter Levart wrote:
On 02/07/2016 08:01 PM, Jeremy Manson wrote:
Hadoop seems to use sun.misc.Cleaner:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hadoop/hadoop-common/2.7.1/org/apache/hadoop/crypto/CryptoStreamUtils.java
So you may want to keep it ar
Hi,
I 1st thought that my version of jtreg did not want to parse the new JDK
9 version strings as it kept saying:
Error: cannot determine version for JDK:
build/linux-x86_64-normal-server-release/images/jdk
...but the fact was that the patched JDK did not even want to boot-up.
So in order
On 02/07/2016 08:01 PM, Jeremy Manson wrote:
Hadoop seems to use sun.misc.Cleaner:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hadoop/hadoop-common/2.7.1/org/apache/hadoop/crypto/CryptoStreamUtils.java
So you may want to keep it around transitionally (a la Unsafe).
JEP 260 [1
Hi,
sun.misc.Cleaner has been moved to internal package jdk.internal.ref
recently [1] to clean-up sun.misc namespace. But now that:
- we have comparable public API (java.lang.ref.Cleaner & Cleanable) [2]
- we have an internal shared java.lang.ref.Cleaner instance
(jdk.internal.ref.CleanerFact
Thanks Peter & David,
That's good to know.
I've altered the SecurityManager to perform a permission check prior to
becoming the security manager, this ensures the cache has been created,
to avoid any recursive deadlock prone calls.
The class that both threads are attempting to load and init is
Hello!
Currently the isParallel() spec says [1]:
> Calling this method after invoking an terminal stream operation
> method may yield unpredictable results.
The spliterator() spec says [2]:
> This is a terminal operation.
As a consequence, we cannot legally call isParallel() after calling
spli
On 02/06/2016 10:32 PM, Peter wrote:
The 0x040ebee8 monitor is most likely being held by native code.
Regards,
Peter Firmstone.
Ok, but where? The deadlock report says it is held by main thread.
Somewhere between the following two java frames?
"main" #1 prio=5 os_prio=0 tid=0x017cf400 ni
12 matches
Mail list logo
