Here the first batch of changes
Cheers
Patrick
> Am 07.05.2015 um 20:44 schrieb Pavel Rappo :
>
> Hi Patrick,
>
> That's a good idea! I can sponsor them no problem.
>
> -Pavel
diff -r 7101bcceb43d make/src/classes/build/tools/module/ModuleArchive.java
--- a/make/src/classes/build/tools/modul
Hi Pavel,
I have changed the most obvious files and made a patch of each repo. I hope the
patches will not be removed…
Cheers
Patrick
> Am 07.05.2015 um 20:44 schrieb Pavel Rappo :
>
> Hi Patrick,
>
> That's a good idea! I can sponsor them no problem.
>
> -Pavel
>
>> On 7 May 2015, at 19
looks good!
On 5/8/15 10:58 AM, Jeremy Manson wrote:
There's a fairly harmless buffer underflow with empty zip names in libzip.
Martin has offered to sponsor this (right, Martin?).
We detected this with ASan, an automatic memory error and leak checking
tool built into Clang/LLVM. This is one o
Thank you Doug for your comments!
On 08.05.2015 20:10, Doug Lea wrote:
On 05/08/2015 10:49 AM, Ivan Gerasimov wrote:
I believe that they also break the AbstractList.subList spec.
http://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#subList-int-int-
I think that the propos
http://cr.openjdk.java.net/~vlivanov/8079205/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8079205
Recent change in sun.misc.Cleaner behavior broke CallSite context cleanup.
CallSite references context class through a Cleaner to avoid its
unnecessary retention.
The problem is the followi
On 05/08/2015 10:49 AM, Ivan Gerasimov wrote:
I believe that they also break the AbstractList.subList spec.
http://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#subList-int-int-
I think that the proposed fix formally conforms to the spec.
That would surprise me. The spec say
Hi Dmitry, Staffan,
Lots of good comments here.
On the topic of what list should be printed out, I think we should focus
on objects waiting to be finalized - e.g. the contents of the
ReferenceQueue. It's more of a pain to walk the ReferenceQueue, but you
could add a summerizeQueue(TreeMap) me
Well then those would obviously be left out, documenting that it’s the
responsibility of the implementor to provide them. This would be true in
general for other interfaces as well that have a specification for expected
meaning of equals/hashCode.
There’s still a lot of boilerplate code that co
On 08.05.2015 1:26, Martin Buchholz wrote:
On Thu, May 7, 2015 at 12:23 PM, Doug Lea wrote:
It would be possible (and easy) to create a specialization for the
java.util.Arrays.ArrayList class (i.e., the kind returned by
Arrays.asList(a).subList), which would also fix the SOE problem
in this p
Looks ok to me Felix.
-Chris.
On 08/05/15 15:57, FELIX YANG wrote:
Hi all,
java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java
has been observed to fail intermittently. This fix is to mark it with
keyword 'intermittent'.
Bug: https://bugs.openjdk.java.net/browse/JDK-807977
Hi all,
java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java
has been observed to fail intermittently. This fix is to mark it with
keyword 'intermittent'.
Bug: https://bugs.openjdk.java.net/browse/JDK-8079778
thanks,
-Felix
diff -r d18205a1ef80
test/java/rmi/activation/r
Hi Doug!
On 07.05.2015 22:23, Doug Lea wrote:
On 05/06/2015 07:23 PM, Martin Buchholz wrote:
Hi Ivan,
I'm afraid of these changes - they are hard to review.
I believe that they also break the AbstractList.subList spec.
http://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#sub
On 08/05/15 13:13, Pavel Rappo wrote:
Here's the latest update:
http://cr.openjdk.java.net/~prappo/8029689/webrev.01/
The source changes look good to me Pavel.
Just a few minor comments on the test:
1) There is a trivial System.out on L143 that could be removed.
2) L157, is this refer
Am 08.05.2015 um 13:28 schrieb Aleksey Shipilev:
On 05/07/2015 06:00 PM, Ulf Zibis wrote:
May be:
..., then a new internal array becomes allocated and refilled with
greater capacity.
... to give a hint, that this action may be expensive.
The Javadoc already says "If the current capacity is le
Here's the latest update:
http://cr.openjdk.java.net/~prappo/8029689/webrev.01/
-Pavel
> On 21 Apr 2015, at 09:08, Chris Hegarty wrote:
>
> On 21 Apr 2015, at 03:00, David Holmes wrote:
>
>> On 21/04/2015 1:24 AM, Chris Hegarty wrote:
>>>
>>> On 20/04/15 16:17, Lance Andersen wrote
On 05/07/2015 06:00 PM, Ulf Zibis wrote:
> May be:
> ..., then a new internal array becomes allocated and refilled with
> greater capacity.
>
> ... to give a hint, that this action may be expensive.
The Javadoc already says "If the current capacity is less than the
argument, then a new internal a
I was just going to propose something similar: A base abstract class for
AbstractList, which implements everything but SubList-related stuff
(including modCount).
This way we could easily create specializations for sublists of
Arrays.ArrayList and Collections.SingleToneList, which do not need to
> (I’ll hand-wave the issue of “protected int modCount” issue for now.)
Not only. Consider this: java.util.AbstractList overrides some methods from
java.lang.Object such as equals and hashCode. And this is a no-no [1]:
...It is a compile-time error if a default method is override-equivalent
> I’m in a position where I’d need to have a class implement List, but it
> already extends something else, so I can’t have it extend AbstractList
Would composition help you instead of inheritance? (I might be missing
something obvious)
-Pavel
So I’m in a position where I’d need to have a class implement List, but it
already extends something else, so I can’t have it extend AbstractList, which
leaves me with a lot of boilerplate methods to implement.
Would it seem like a good idea to reimagine AbstractList and friends as
interfaces w
20 matches
Mail list logo
