> > > This is why I put the Ant developers in CC. The correct way would be
> > > to look at the *decoded* path (not just getPath() because this is also
> > > one of the "famous" traps in the URL class - one reason why it should
> > > be avoided in favor of URI). URL.toURI().getPath() is most safe t
Hi Tagir,
Nice work. I looked at the implementation and have two comments:
- in Limiter.put:
127 final boolean put(T t) {
128 int l = limit;
129 T[] d = data;
130 if (l == 1) {
131 // limit == 1 is the special case: exactly one
le
Hi,
I have been asked to split the changes needed to remove
jdk.internal.ref.Cleaner into two changesets. The first one is to
contain the straightforward non-controversial changes that remove the
references to jdk.internal.ref.Cleaner and swaps them with
java.lang.ref.Cleaner in all places bu
On 5/03/2016 11:50 PM, Claes Redestad wrote:
Hi,
similar issues were discovered too late to stop b108, e.g.,
https://bugs.openjdk.java.net/browse/JDK-8150920. Fix is already in jdk9/dev,
so I think the next build should be more well-behaved and hope we can provide
it more promptly than normal
Hi Christoph,
Thanks for reporting and providing patch for the issue! Looks like a
nice solution that may potentially reduce memory requirement for some
large templates. Could you also verify that the patch also fixes
JDK-8150699 [1] that was created the same day as yours?
I assume the styl
