Please review the patch to add com/sun/corba/cachedSocket to
exclusiveAccess.dirs so as tests won't run concurrently.
This is to address one potential issue that corba tests (start and use
orbd service) may run into port conflict issue if run in concurrency.
Most of such tests are under javax/
Hello all,
I proposed a patch to provide wrapping for some native methods in
FileInputStream a while ago in May, and the patch has been reviewed but it has
not been integrated. I have checked the patch again with the latest JDK9 dev
builds and it still works correctly passing java.io regression
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168386/webrev.00
This patch tightens the option validation to jdeps and the new test shows some
example of conflicting options.
Mandy
> On Nov 9, 2016, at 2:53 PM, Brent Christian
> wrote:
>
> Hi,
>
> It seems that the method name used in 8165793[1], "isParallelCapable", was a
> little *too* intuitive. An existing use of that method name has been
> uncovered (via NetBeans, in Eclipse Equinox).
>
> Because the newly added
Hi,
On 2016-11-09 23:53, Brent Christian wrote:
Hi,
It seems that the method name used in 8165793[1], "isParallelCapable",
was a little *too* intuitive. An existing use of that method name has
been uncovered (via NetBeans, in Eclipse Equinox).
Because the newly added method was marked final,
Hi,
It seems that the method name used in 8165793[1], "isParallelCapable",
was a little *too* intuitive. An existing use of that method name has
been uncovered (via NetBeans, in Eclipse Equinox).
Because the newly added method was marked final, the pre-existing method
results in a VerifyErr
Hi Remi,
On 11/09/2016 06:29 PM, Remi Forax wrote:
- Mail original -
De: "Paul Sandoz"
Cc: "Core-Libs-Dev"
Envoyé: Mercredi 9 Novembre 2016 17:47:34
Objet: Re: 8169425: Values computed by a ClassValue should not strongly
reference the ClassValue
Hi Peter,
Good point about if such s
Hi,
Looks OK. Is it 100% pass rate?
—Andrey
> On 9 Nov 2016, at 20:36, Denis Kononenko wrote:
>
>
>
> Hi,
>
> After discussion with Andrey we decided to add more tests for corner cases.
> The new changes are available by the link below.
>
> WEBREV: http://cr.openjdk.java.net/~dkononenko/8
> On Nov 9, 2016, at 10:13 AM, David DeHaven wrote:
>
>
> Please review the fix for:
> https://bugs.openjdk.java.net/browse/JDK-8169001
>
> Webrev at:
> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/
Overall this looks like a complete eradication of the la
On 11/09/2016 03:32 AM, Remi Forax wrote:
We should really lock Doug Lea and a GC guy in a room and only release them
when they have produce a java.util.EphemeronHashMap (or maybe something which
doesn't implement the whole Map contract but only put and get), using a
WeakHashMap with the value
Please review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8169001
Webrev at:
http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/
>>>
>>> Overall this looks like a complete eradication of the launcher
>>> ergonomics. A few specific comments:
>>>
>>> src/java.
Hi,
After discussion with Andrey we decided to add more tests for corner cases.
The new changes are available by the link below.
WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240
Thank you,
Denis.
> Hi,
>
> Looks OK to
- Mail original -
> De: "Paul Sandoz"
> Cc: "Core-Libs-Dev"
> Envoyé: Mercredi 9 Novembre 2016 17:47:34
> Objet: Re: 8169425: Values computed by a ClassValue should not strongly
> reference the ClassValue
> Hi Peter,
>
> Good point about if such support was added it would break t
Hi Peter,
Good point about if such support was added it would break the API and also
(with Remi) about Ephemerons.
You are correct in stating the constraints in more detail regarding classes in
the same loader. However, i think that is going into more detail than I would
prefer for what i thin
Hi Paul,
What do you think of introducing a static factory method in ClassValue
in addition to your @implNotes. The method would go like this (similar
to ThreadLocal.withInitial()):
public abstract class ClassValue {
/**
* Creates a {@code ClassValue} instance which uses given {@cod
Or, better yet, using value factory Function instead of Supplier:
public class WeakFactoryClassValue extends ClassValue {
private final WeakReference, ? extends
T>> factoryRef;
public WeakFactoryClassValue(Function, ? extends
T> factory) {
factoryRef = new WeakReference<>(fa
Hi Paul,
On 11/09/2016 09:13 AM, Peter Levart wrote:
It is not always the case that when ClassValue instance is strongly
reachable from the associated computed value, unloading of classes and
class loaders is prevented.
Take the following example (assume that the code is loaded by a special
On 8 Nov 2016, at 23:52, Paul Sandoz wrote:
>
> Hi,
>
> Please review an update to the api note of Optional.map() which
> embarrassingly contained erroneous code (labouring under the misapprehension
> that exception transparency is supported!).
>
> I tweaked the example to refer to a Stream w
We should really lock Doug Lea and a GC guy in a room and only release them
when they have produce a java.util.EphemeronHashMap (or maybe something which
doesn't implement the whole Map contract but only put and get), using a
WeakHashMap with the value strongly referencing the key is way too com
Hi Paul,
On 11/09/2016 12:27 AM, Paul Sandoz wrote:
Hi,
Please review the addition of an api note to ClassValue.computeValue.
There is some history behind this issue. Another issue was logged [1] related
to Groovy using ClassValue and there being a memory leak with classes/loaders
not being
20 matches
Mail list logo
