> On 1/29/20 9:56 PM, Roman Leventov wrote:
> > 1) ZoneRules.of() implies that transitionList is a superset of
> > standardOffsetTransitionList but doesn't check that. Then it's possible
> to
> > construct ZoneRules instances that don't work correctly:
> &g
ns) in place for the 4th argument on ZoneRules.of(), so
> that the transition happens on the transition day?
>
> For 2), good catch for the missing 'i', we need a JBS issue for that to
> fix it.
>
> Naoto
>
> On 1/31/20 6:08 AM, Roman Leventov wrote:
> > java.bugs.com &l
1) ZoneRules.of() implies that transitionList is a superset of
standardOffsetTransitionList but doesn't check that. Then it's possible to
construct ZoneRules instances that don't work correctly:
@Test
public void zoneRulesTest() {
LocalDateTime transitionDay =
e them
> right.
>
> Maybe we could tackle this (and similar requests in the future) by adding,
> once
> and for all, something like:
>
> Consider using concurrent collections instead, such as those that can
> be
> found in the java.util.concurrent package.
>
> -Pav
I think Javadocs for Collections.synchronizedXxx() should mention not
only "traversing it via Iterator, Spliterator or Stream" as something that
must be synchronized externally, but also cases when a synchronized
collection is an argument to a bulk collection method, including:
- new
computeValue() documentation says:
"This method will be invoked within the first thread that accesses the
value with the get method. Normally, this method is invoked at most once
per class, but it may be invoked again if there has been a call to remove."
It sounds exactly like ClassValue
Is there a reason why java.util.stream.Collector doesn't support sized
supply of a mutable result container? It seems that it could be hugely
beneficial when the size of the stream is known, e. g. for precise
ArrayList and HashMap.
iterator() has chances to be slightly more efficient than listIterator().
At very least AbstractList's own ListItr implementation contains one more
implicit field referencing the base class, so objects of
AbstractList.ListItr are often 8 bytes bigger than objects of
AbstractList.Itr.
nd avoid zeroing out the newly allocated array
> that we have to take care not to break.
>
> /Claes
>
>
> On 2018-02-22 17:51, Roman Leventov wrote:
>
>> AbstractStringBuilder.ensureCapacityInternal() doesn't need to copy the
>> whole underlying array, only the part unt
Similar optimizations are also possible in ArrayList and Vector.
On 22 February 2018 at 17:51, Roman Leventov <leventov...@gmail.com> wrote:
> AbstractStringBuilder.ensureCapacityInternal() doesn't need to copy the
> whole underlying array, only the part until the current count.
&g
AbstractStringBuilder.ensureCapacityInternal() doesn't need to copy the
whole underlying array, only the part until the current count.
diff --git
a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java
b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java
---
I'm sure there was a discussion somewhere in JDK mailing lists, but I couldn't
find. Please, give me a link.
I've tried to ask on SO:
http://stackoverflow.com/questions/21758081/why-many-methods-in-jcf-interfaces-not-made-default-in-java-8,
proved that JDK developers don't read SO :)
12 matches
Mail list logo
