On 26/09/2017 21:13, mandy chung wrote:
Minor update to the spec of ClassLoader::getPackages and other
relevant methods to clarify that the Package(s) are the packages that
*have been* defined. Also include a link to JVMS 5.3 about run-time
packages, as in Package class spec.
http://cr.ope
Thanks Mandy!
I removed the ln#657-#663, and updated the @apiNote in deflter, inflater
and zipfile accordingly, mainly combined your comment and the approach
for the fis/fo. they are "simpler" and straightforward now, at least for me.
https://bugs.openjdk.java.net/browse/JDK-8187485
http://cr.op
Comment on the CSR:
On 9/26/17 11:35 PM, Xueming Shen wrote:
csr: https://bugs.openjdk.java.net/browse/JDK-8187485
I think the @apiNote can be simpler.
Deflater (similar comment for Inflater)
|* @apiNote * In earlier versions, the {@link Object#finalize} method was
overridden * to c
Hi,
Can I, please, ask for review and approval of JDK-8159240 backport to
JDK8? This bug was resolved in JDK9 as part of JAXWS-RI sync changeset
(JDK-8164479) therefore separate review for the partially backported
changes is needed: http://cr.openjdk.java.net/~aefimov/8159240/8/00/
File chan
> On Sep 27, 2017, at 1:55 PM, Hans Boehm wrote:
>
> "And of course, it guarantees that the tracked referent can not be
> resurrected as a result of cleanup code execution."
>
> True, but it seems to me that the real property you want is "it guarantees
> that the tracked referent can not be resu
On 09/27/2017 02:38 PM, Paul Sandoz wrote:
>> Looks good, i just need to look a little more closely at the
>> ConcurrentSkipListMap changes.
>>
>
>
> 328 * Note that, with VarHandles, a boolean result of
> 329 * compareAndSet must be declared even if not used.
> This should not be ne
On 9/27/17 10:55 AM, Hans Boehm wrote:
"And of course, it guarantees that the tracked referent can not be
resurrected as a result of cleanup code execution."
True, but it seems to me that the real property you want is "it guarantees
that the tracked referent can not be resurrected". Full stop.
> On 26 Sep 2017, at 13:13, mandy chung wrote:
>
> Minor update to the spec of ClassLoader::getPackages and other relevant
> methods to clarify that the Package(s) are the packages that *have been*
> defined. Also include a link to JVMS 5.3 about run-time packages, as in
> Package class spec
On 9/27/17 5:49 AM, David Holmes wrote:
I missed the fact that we already special case this for JNI_OnLoad and
JNI_OnUnload.
Yes this is buried in JNI_FindClass method.
I would have thought that in the OnLoad case we would find the
classloader of the class loading the native library witho
> On 21 Sep 2017, at 10:29, Paul Sandoz wrote:
>
> Looks good, i just need to look a little more closely at the
> ConcurrentSkipListMap changes.
>
328 * Note that, with VarHandles, a boolean result of
329 * compareAndSet must be declared even if not used.
This should not be neces
Hi Uwe,
Unfortunately i don’t recall there being a publicly supported way to validate
an existing Mr.Jar (except by recreating it), either by the jar tool itself nor
by a programatic API.
In a more general sense the problem is one of given two jars validate that the
class file bytes in each ex
Hi Peter,
Sorry, I might not understand your use scenario correctly. Let me try :-)
If clean() is invoked via Deflater.end() first, my reading of the
Cleaner code suggests that
the clean()->ZStreamRef.run() is run by the thread calling
deflater.end() directly, not
the Cleaner thread. In this s
Corrections ...
On 27/09/2017 2:36 PM, David Holmes wrote:
On 27/09/2017 1:36 PM, mandy chung wrote:
On 9/26/17 7:35 PM, David Holmes wrote:
On 27/09/2017 12:11 PM, mandy chung wrote:
On 9/26/17 7:06 PM, David Holmes wrote:
It is not tied with the Cleaner change. Instead, the FindClass bug
Hi David,
On 09/27/2017 11:52 AM, David Holmes wrote:
Hi Peter,
I thought Cleaner was supposed to avoid all these unpredictable
reachability races? Otherwise why switch from using a finalizer ??
Unfortunately, there is no hidden magic in Cleaner. It is better than
finalize() mostly because
Hi,
I am building a multi-release JAR file using Apache Ant (for Lucene, see
https://issues.apache.org/jira/browse/LUCENE-7966).
As build tools like Ant/Gradle/Maven are packaging JAR files on their own, not
using the official JAR tool, I wanted to do a quick check if the resulting JAR
file is
Hi Peter,
I thought Cleaner was supposed to avoid all these unpredictable
reachability races? Otherwise why switch from using a finalizer ??
David
On 27/09/2017 7:31 PM, Peter Levart wrote:
Hi Sherman,
At first I checked the Deflater/Inflater changes. I'll come back with
ZipFile later.
I
Hi Sherman,
At first I checked the Deflater/Inflater changes. I'll come back with
ZipFile later.
I think the code is mostly correct, but I have a concern. If clean() is
invoked via Deflater.end(), then the Deflater instance is still alive
and synchronization is necessary as other threads mig
Hi Chris,
Thanks for review, please find the latest
webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html).
I incorporated review comments from you and re-base the patch to our
consolidated repo(jdk10/master).
Thanks,
Vyom
On Monday 25 September 2017 01:57 AM, Chris Hega
18 matches
Mail list logo
