Thanks for information. I'm looking at it. I'm also in contact with JacORB team
regarding the compatibility issues. I should be able to present more elaborate
opinion about 2.3.1 vs 3.3 compatibility (especially regarding Security
Service) at the beginning of the next week.
Regards,
Tomek
--
ConcurrentHashMap is (probably!) cheaper than it used to be. For
read-mostly operations there won't be a lock. But yes, even better
for read-mostly use is to keep an immutable map and CAS-loop whenever
you need to update. The VarHandle work and the immutable collections
work should make that bet
On 5/6/16 10:57 AM, Stuart Marks wrote:
I've been doing too much last-minute refactoring.
Actually that's wasn't the cause of this bug. The bug was in the previous webrev
and also in the prototype from my branch in the sandbox, so it's been in there
quite a while.
Again, thanks for spotting
On 5/5/16 8:51 PM, Michael Hixson wrote:
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.
Hi Michael,
Well spotted! You're quite correct. I've been doing too much last-minute
refactoring.
I note
Hi Stephen,
It still seems pretty elaborate and duplicates the set; but it would be
a bigger change
to restructure the internal ZONES map to have an immutable map in the
implementation
and synchronize its update when a new Provider is added (very
infrequently/never).
ConcurrentHashMap is a pre
While working my way through Tomcat's memory leak protection / detection
/ fixing code, I have found an issue that remains unresolved in the
latest JDK 9 source.
The thread created by the GC class does not explicitly set the context
class loader so it inherits the current context class loader. Con
> On May 5, 2016, at 11:18 PM, Hamlin Li wrote:
>
> 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/
Looks oka
Hi,
This is a fix for a subtle test bug caused by a logger being GCed.
bug id:
https://bugs.openjdk.java.net/browse/JDK-8156153
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8156153/webrev/
This test has been seen failing in hs integration with the following
error:
Hi Bill,
The bug has been updated with the additional information from you.
Thanks
Balchandra
On 5/6/2016 4:59 PM, Bill Mair wrote:
Hi,
Am I posting this to the correct list? If I am, would someone please
tell me who to send this information to?
I would like to confirm that this bug
Hi,
Am I posting this to the correct list? If I am, would someone please
tell me who to send this information to?
I would like to confirm that this bug still indeed exists, as Balchandra
Vaidya requested.
From what I can see error hasn't been fixed in jdk9 either:
http://hg.openjdk.java.net/jdk
On 05/05/2016 13:51, Tomasz Adamski wrote:
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 regardi
The set of zones can only increase, it cannot decrease as there is no
removal mechanism. As such, the size of the set is a proxy for the
number you describe.
One other point. The method that most users will call to get the set
of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to
th
12 matches
Mail list logo
