JDK-8153481 is being fixed, so put
tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java in Problem list.
bug: https://bugs.openjdk.java.net/browse/JDK-8156189
webrev: http://cr.openjdk.java.net/~mli/8156189/webrev.00/
Thank you
-Hamlin
Hi Hamlin,
code-tools-dev is not the right group for jdeps. This can send to
core-libs-dev.
Can you put them in ProblemList instead? I’m working on jdeps fixes and will
resolve these issues.
Mandy
> On May 5, 2016, at 8:43 PM, Hamlin Li wrote:
>
> tools/jdeps/modules/GenModuleInfo.java
>
Hi Stuart,
In MapN.entrySet(), is the "int idx" being declared in the wrong
place? It looks like it should be a field of the Iterator rather than
the Set.
@Override
public Set> entrySet() {
return new AbstractSet>() {
int idx = 0; // <-- this...
Hi Paul,
I have to apologize. Due to an email error on my part, I just now saw your and
Mark's responses (from 4/8/16).
> On Apr 8, 2016, at 1:41 AM, Paul Sandoz wrote:
>
> Hi Steve,
>
>> On 8 Apr 2016, at 00:03, Dohrmann, Steve wrote:
>>
>> Hi Paul,
>>
>> We would like to have an an AP
Hi Paul,
I have to apologize. Due to an email error on my part, I just now saw your and
Mark's responses (from 4/8/16).
> On Apr 8, 2016, at 1:41 AM, Paul Sandoz wrote:
>
> Hi Steve,
>
>> On 8 Apr 2016, at 00:03, Dohrmann, Steve wrote:
>>
>> Hi Paul,
>>
>> We would like to have an an AP
> On May 5, 2016, at 3:50 PM, Florent Guillaume wrote:
>
> On Thu, May 5, 2016 at 6:59 PM, Mandy Chung wrote:
>> * where loader is determined as follows: if there is a
>> * method on the current thread's stack whose declaring class is not a
>> *
>> * platform class (and was not
On Thu, May 5, 2016 at 6:59 PM, Mandy Chung wrote:
> * where loader is determined as follows: if there is a
> * method on the current thread's stack whose declaring class is not a
> *
> * platform class (and was not a generated to implement
> * reflective invocations), th
OK for java.compiler
-- Jon
On 04/29/2016 10:02 PM, Mandy Chung wrote:
JDK-8154190: Deprivilege java.compiler module
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154190/webrev.00/
JDK-8155513: Deprivilege jdk.charsets module
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/we
Hi all,
Here's a revised webrev, incorporating some of the comments from Peter Levart,
Stephen Colebourne, and Rémi Forax.
http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.1/
I'd like to proceed with this changeset mostly as-is, and to allow discussion of
other issues (such as spec
On 5/5/16 5:54 AM, Stephen Colebourne wrote:
To be clear, I believe that the spec of Set.of() and Map.of() should
require iteration order matching insertion order (because the order is
very clearly defined in this case and anything else will be
surprising).
OK. This would be a spec change. The
On 5/5/16 5:34 AM, Alan Bateman wrote:
I understand the goal, just wondering if there is something less devious that
would make sense here. One idea is to use some portion of the Version, say the
build number, so that it at least changes each week or build. That would at
keeping the ordering co
On 5/5/16 6:42 AM, Chris Hegarty wrote:
I have some sympathy for this. Since we are specifying that these
Collections are serializable, it would be nice for them to deserialize
on an older release, but I don’t think we should compromise the
serial form to achieve that. In fact, I agree with St
On 5/5/16 4:34 AM, fo...@univ-mlv.fr wrote:
The problem is that AbstractList is a public class, removing it from the
hierarchy is not a backward compatible change,
so it's not something that can be changed as an after through.
(and AbstractSet and AbstractMap)
I disagree that removing those
Thanks for providing test coverage for 8152912. The changes look good!
Best,
Joe
On 5/5/2016 3:44 AM, Frank Yuan wrote:
Hi
Would you like to review http://cr.openjdk.java.net/~fyuan/8156119/webrev.00/?
Bug: https://bugs.openjdk.java.net/browse/JDK-8156119
This change is to add/upd
> On May 5, 2016, at 11:42 AM, Alexandre (Shura) Iline
> wrote:
> Whether the java.tools API behavior is correct is a separate matter. I am
> planning to create a standalone test case and take it with javac ppl.
I take this ^^ back, as the error was there all along:
"java.nio.file.Provider
Hi,
Using the current number of ZoneIDs to avoid the recompilation of the
cache is a bit weak anyway,
though it seems unlikely that a ZoneID would be added and one deleted
without being noticed.
An alternative would be a API that returned a number that would change
every time the set of Zone
Chris, could you please take another look:
http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/
What I have discovered is that jdk.zipfs was used to access jars on the
classpath, which were JTreg jars: jtreg.jar, testing.jar, etc. Cleaning the
class path through the environment removed depe
On 5 May 2016, at 17:59, Mandy Chung wrote:
>
>> On May 5, 2016, at 6:10 AM, Alan Bateman wrote:
>>
>> In resolveClass then "is class loader corresponding to the closest .."
>> should probably be "is the class loader ...". You didn't introduce this of
>> course, just noticed it while reading
On reflection, both your and my solution have a race.
the size method, is a clear check-then-act
the read-only method uses Collections.unmodifiableSet() which only
decorates the underlying set, thus is still check-thern-act
(the current implementation does not have a race condition, as the
data
On 05/05/2016 17:59, Mandy Chung wrote:
:
I was wondering why the resolveClass and resolveProxyClass methods are
specified differently w.r.t. class loader search. I made only localized change
as I didn’t have the history.
I’m happy to clean up the spec. I’d also fix the spec “user-defined
Where is the current commitment to unspecified iteration order? Is that in
Java 9?
Generally speaking, I see no problem with going from unspecified to
specified iteration order; if code had to be able to deal with *any* order
previously they can certainly deal with an order that happens to be the
> On May 5, 2016, at 6:10 AM, Alan Bateman wrote:
>
> In resolveClass then "is class loader corresponding to the closest .." should
> probably be "is the class loader ...". You didn't introduce this of course,
> just noticed it while reading the complete paragraph.
>
> The rest looks okay to
Hi,
On 05/05/2016 02:54 PM, Stephen Colebourne wrote:
On 5 May 2016 at 02:30, Stuart Marks wrote:
I disagree with altering the iteration order. Guava's ImmutableSet and
ImmutableMap have reliable iteration specified to match creation
order. This aspect of the design is very useful.
I think
Hi Stephen,
The aspect of the current implementation that is problematic is the
copying of the set,
its not just single object creation but an entry for every ZoneID.
Adding a size method exposing some internal state increases the
possibility that
when it is used independently it will be out
Hi,
I've just ran in to the same problem described in this bug:
https://bugs.openjdk.java.net/browse/JDK-8149521
I found it in java7u79 and I used java8u91 to confirm it still exists.
The error is in "com.sun.jndi.ldap.ServiceLocator" at line 273
(http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/
On 5/5/16 5:18 AM, Alan Bateman wrote:
On 04/05/2016 20:54, Xueming Shen wrote:
Thanks Claes! fixed and webrev has been updated.
http://cr.openjdk.java.net/~sherman/8150496/webrev
sherman
I skimmed through this and it looks quite. I just wonder if we should
check in the micro benchmarks as it
I fail to see why adding a new read-only method alongside the existing
method adds any more value to the API than adding a new size method.
At least with the size method the API is still sensible - a mutable
and immutable method alongside each other shouts out that a mistake
was made. A size method
Hi Bhanu,
Adding a trivial method to the public API used only for an optimization
is not a good fix for this issue.
A better fix was suggested to add a non-copying read-only version of
ZoneRulesProvider.getAvailableZoneIds()
Please revise the fix to instead implement and use:
/**
* G
On 5 May 2016, at 01:21, Stuart Marks wrote:
> Hi Daniel,
>
> On 5/4/16 3:08 AM, Daniel Fuchs wrote:
>> I wonder about serial interoperability with earlier
>> versions of the JDK. For instance it will not be possible to
>> send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM.
>> I wonder
On 5 May 2016, at 01:21, Stuart Marks wrote:
> Hi Daniel,
>
> On 5/4/16 3:08 AM, Daniel Fuchs wrote:
>> I wonder about serial interoperability with earlier
>> versions of the JDK. For instance it will not be possible to
>> send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM.
>> I wonder
On 25/04/2016 22:26, Stuart Marks wrote:
> On 4/22/16 3:03 AM, Mark Thomas wrote:
Sorry for the delayed reply. I got distracted on other things.
>> The good news is that, with the information above, this leak is
>> something that modules/applications can and should do something about.
>
> I thin
On 05/05/2016 13:56, Aleks Efimov wrote:
Hello,
corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java
file contains incorrect GPL header which fails
make/scripts/lic_check.sh script check with such error:
### Checking copyright notice in th
On 04/05/2016 20:29, Mandy Chung wrote:
The default implementation of ObjectInputStream::resolveClass and
resolveProxyClass finds the user-defined class loader on the stack and assumes
that only system classes are loaded by null loader. As JDK modules are
deprivileged, classes on the stack d
Hello,
corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java
file contains incorrect GPL header which fails make/scripts/lic_check.sh
script check with such error:
### Checking copyright notice in the file:
corba/src/java.corba/share/classes/
On 5 May 2016 at 02:30, Stuart Marks wrote:
>> I disagree with altering the iteration order. Guava's ImmutableSet and
>> ImmutableMap have reliable iteration specified to match creation
>> order. This aspect of the design is very useful.
>
>
> I think this is a reasonable thing to want, but it wou
Added classes are indeed generated from idl present in Security Server
Specification which is part of Corba 3.3 specification. I can find no
information about formal corba compliance process. Can you please point me to
people who can help me regarding this?
Regards,
Tomek
--
Tomasz Adamski
So
On 05/05/2016 01:28, Stuart Marks wrote:
Hi Alan,
Yes, the unpredictability does introduce some risk of intermittent and
hard-to-diagnose failures. On the other hand, the
unspecified-but-mostly-stable iteration order we have with things like
HashMap lets implicit order dependencies creep i
On 04/05/2016 20:54, Xueming Shen wrote:
Thanks Claes! fixed and webrev has been updated.
http://cr.openjdk.java.net/~sherman/8150496/webrev
sherman
I skimmed through this and it looks quite. I just wonder if we should
check in the micro benchmarks as it is likely we'll need those again in
th
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Jeudi 5 Mai 2016 08:32:08
> Objet: Re: RFR(m): 8139233 add initial compact immutable collection
> implementations
>
> On 5/4/16 1:38 AM, Remi Forax wrote:
> > nice work !
>
> Spoken like a true un
Hi
Would you like to review http://cr.openjdk.java.net/~fyuan/8156119/webrev.00/?
Bug: https://bugs.openjdk.java.net/browse/JDK-8156119
This change is to add/update some tests for verifying JDK-8152912: SAX
XMLReaderFactory needs to be ServiceLoader compliant, see
Joe's RFR mail thread
h
Fine by me
thanks
Stephen
On 5 May 2016 at 10:57, Bhanu Gopularam
wrote:
> Please see the updated webrev:
> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.01/
>
> Thanks,
> Bhanu
>
> -Original Message-
> From: Stephen Colebourne [mailto:scolebou...@joda.org]
> Sent: Thur
Please see the updated webrev:
http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.01/
Thanks,
Bhanu
-Original Message-
From: Stephen Colebourne [mailto:scolebou...@joda.org]
Sent: Thursday, May 05, 2016 3:18 PM
To: core-libs-dev
Subject: Re: RFR 8066291: ZoneIdPrinterParse
In ZoneRulesProvider.getAvailableZoneIdsSize() there is no need for
the trailing paragraph tag in the Javadoc.
Otherwise, fine by me.
thanks
Stephen
On 5 May 2016 at 10:10, Bhanu Gopularam
wrote:
> Hi all,
>
>
>
> Please review fix following issue
>
>
>
> Bug Id : https://bugs.openjdk.java.net/
Hi all,
Please review fix following issue
Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291
Solution: provided new method to get size of available zone ids
webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00
Thanks,
Bhanu
On 4 May 2016, at 20:29, Mandy Chung wrote:
> The default implementation of ObjectInputStream::resolveClass and
> resolveProxyClass finds the user-defined class loader on the stack and
> assumes that only system classes are loaded by null loader. As JDK modules
> are deprivileged, classes on
45 matches
Mail list logo
