Re: 8252827: Caching Integer.toString just like Integer.valueOf

[Tagir Valeev]

Hello!

I would vote to close this. The benefit for all JDK users is questionable.
If it's necessary in a particular application, it could be implemented in
user code.

With best regards,
Tagir Valeev.

пт, 16 апр. 2021 г., 23:49 Raffaello Giulietti <
raffaello.giulie...@gmail.com>:

> Hello,
>
> does the enhancement proposed in [1] make sense, both today and when
> wrappers will be migrated to primitive classes?
> If so, it should be rather simple to add it and I could prepare a PR.
> If not, the issue might perhaps be closed.
>
>
> Greetings
> Raffaello
>
> 
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
>

Re: ReversibleCollection proposal

[Tagir Valeev]

Hello, Remi!

On Sat, Apr 17, 2021 at 11:50 PM Remi Forax  wrote:
> Introducing a new interface (two in this case) has a really huge cost and in 
> this case, i've trouble to see why i will want to write a method that takes a 
> ReversibleCollection as parameter, ReversibleCollection as a type does not 
> seem to be useful. About the cost of introducing a new collection interface, 
> it means that we also have to update all emptyXXX, singleXXX, uncheckedXXX 
> with a new interface, and that only for the JDK. Every libraries that proxy 
> collections has also to be updated to take care of this new type, otherwise 
> the integration with an application that uses this new type and the library 
> is not seamless anymore.

Note that in Stuart's proposal, java.util.List extends
ReversibleCollection. So, existing emptyList() and singletonList()
also return ReversibleCollection and no new methods are necessary
here. Probably unmodifiableReversibleSet could be useful as a
LinkedHashSet wrapper. On the other hand, we don't have, e.g.
checkedDeque or synchronizedDeque, and it looks like nobody complains.
So probably it's not always necessary to create a wrapper for every
single collection interface.

> I fully agree that having a way to reverse a collection is a powerful API 
> point, as Brian said, it's better to reverse the collection and then ask for 
> a stream than providing a method reverseStream (and this is true for 
> iterators or views like keySet/entrySet/values or subList too). Several 
> people also ask to have findLast() on Stream, using 
> list.descendingList().findFirst() will be equivalent.

A dedicated findLast() would be a great addition to reversible
streams! It could short-circuit for reversible stream
(reverse().findFirst()) and use reduce((a, b) -> b) for non-reversible
(so intermediate buffering is not necessary). I've found 8 Stream API
call chains ending with .reduce((a, b) -> b) in our sources. Clearly,
some of them could short-circuit, as the source is potentially
reversible (e.g. allAnchors.subList(0,
idx).stream().filter(hasNewName).reduce((x1, x2) -> x2)). Having
dedicated findLast operation would be less error-prone, compared to
creating the stream as reversed().stream(), as you don't have to think
whether the stream is reversible or not. If you accidentally add a
non-reversible operation, you'll miss the optimization but not
correctness.

With best regards,
Tagir Valeev.

Re: ReversibleCollection proposal

[Tagir Valeev]

> Adding a REVERSIBLE characteristic to spliterators is easy enough

Actually not. There are already tons of delegating spliterators in the
wild, and many of them delegate characteristics in one or another way.
Usually, it's like 'copy all the source characteristics except A and
B' (i.e. `source.characteristics() & (~(A|B))`), so if we introduce a
new one, some existing spliterators may start reporting it without
actually providing the claimed functionality. As the author of the
library that contains dozens of custom spliterator, I think, this is
the largest problem. I don't buy an infinite streams argument, as
`sorted()` is equally not applicable to infinite streams, yet it's
possible to call it (btw reversed() after sorted() could be optimized,
even if the original source is not reversible). Also, in fact,
infinite streams are not widely used. I think, 99% of real-life
streams start from collection, array, or integral range. Yes, my idea
was to fall back to drain-line implementation.

> But, Stuart's proposal gives us much of this with less fuss.  IF a collection 
> is reversible, you can just say
>
> c.reversed().stream()
>
> and off you go, plus a similar method for arrays (Arrays.reversedStream).  
> Given that, what is the value of pushing this further into stream?

Arrays.reversedStream should be added for Object/int/long/double and
probably for array slices. Also, IntStream.reversedRange, please! And
LongStream.reversedRange. And probably `reversedRangeClosed`. So we
already have 12 methods to add (aside from collections). Adding single
.reversed() to the Stream is a much smaller API surface. Though I
admit that it requires much more work. On the other hand, I believe
(efforts/usefulness) for this feature is much bigger than, say, for
parallel streams.

In StreamEx, I have

public static  StreamEx ofReversed(List list)
public static  StreamEx ofReversed(T[] array)
(did not bother to add IntStreamEx ofReversed(int[] array) and friends)
the List version just assumes that every list is random access and
does something like IntStream.range(0, size).mapToObj(idx ->
list.get(size - idx - 1))
I've found 16 usages of them in IntelliJ IDEA sources (10 for List and
6 for array), which is not very small, given the fact that only a few
of our developers in our project know/use StreamEx.

I also have three-arg IntStreamEx.range(int startInclusive, int
endExclusive, int step) (and rangeClosed, and the corresponding
LongStreamEx), which can be used for reverse range (with step = -1)
I've found a couple of usages with step = -1 to iterate over a slice
of an array in reverse order. Though step = 2 is more popular.

I also checked the uses of Collections::reverse. There are hundreds of
them. Often it's traversal in tree-like structure through the parent
chain from leaf to root, like Stream.iterate(leaf, Objects::nonNull,
Node::getParent),
then the result is dumped into the list (probably with some
intermediate ops like map(Node::getName)), then reversed to get "from
root to leaf" order. Sometimes the resulting list is just returned (so
it's possible to create
Collectors.toReversedList() to avoid extra reversal step), sometimes
it's converted to an array and returned, sometimes it's
iterated/streamed again. In one case, it's even followed by
left-to-right reduction,
so foldRight is what was actually wanted there.

One more case is a simple parser of the Java stack trace:

String[] lines = stack.split("\n");
List calls =
  StreamEx.of(lines).filter(s -> s.startsWith("\tat")).map(method ->
getMethodCall(method, ...)).nonNull().toList();
Collections.reverse(calls);

Here's an example of a stream where reversibility is preserved during
the whole pipeline. It's possible to rewrite it using
StreamEx.ofReversed() (probably the code author was not aware of this
method). But it also could be stack.lines().reversed() (and it's
possible to make String::lines reversible without extra buffering!),
so with the dedicated reversed() method it could be completely lazy.

I also see patterns like fill LinkedHashSet, dump it to the List, then
reverse the list and iterate from it. Clearly, it can benefit from the
Stuart's proposal.

With best regards,
Tagir Valeev.


>
> On 4/17/2021 7:49 AM, Tagir Valeev wrote:
>
> Great proposal, thanks!
>
> It has most functionality from my previous proposal, except the
> ability to iterate LinkedHashSet starting from a specific element.
> Well, probably we can skip this for now.
>
> Some people really want to reverse Streams as well. E. g., the
> corresponding StackOverflow question [1] has 171 upvotes and 200k+
> views. Also, if the stream were reversible, it would be possible to
> implement efficient foldRight/reduceRight operation. See the
> discussion at [2]. It would be nice to explore the possibility of
> extending Stream API to take into account the source reversibility.
> Some existing ordered sources that have no underlying collection (e.g.
> IntStream.range, or Arrays.stream) can be 

Re: ReversibleCollection proposal

[Donald Raab]

> I'm also concerned about conflicts over the other method names; something 
> like addFirst() is a pretty obvious method to add to a custom List 
> implementation. I haven't seen any, but that doesn't mean there aren't any.
> 
> s'marks

The getFirst() and getLast() methods will have collisions. We have both these 
methods on Eclipse Collections, and thankfully they return the same type. It is 
possible that someone decided to implement these methods and return Optional.

Re: ReversibleCollection proposal

[Donald Raab]

Hi, Stuart, happy to help.

I took a look at Groovy and Kotlin. Groovy has reverse() [1] and Kotlin has 
reversed() [2] and asReversed() [3] and reverse() [4]. I’m not quite familiar 
enough with Kotlin to know whether the reversed() method will collide.

[1] 
http://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/List.html#reverse()
[2] 
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/reversed.html
[3] 
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/as-reversed.html
[4] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/reverse.html

> On Apr 17, 2021, at 2:24 PM, Stuart Marks  wrote:
> 
> 
> 
> On 4/16/21 3:06 PM, Donald Raab wrote:
>> We should be cautious when adding new APIs to existing interfaces. There may 
>> be libraries which extend JDK types and already have reversed(), 
>> toReversed() or asReversed() APIs and corresponding interfaces.
>> There are OrderedIterable and ReversibleIterable interfaces and asReversed() 
>> and toReversed() methods in the Eclipse Collections API.
> 
> Hi Don, thanks for looking at the proposal.
> 
> Certainly a lot of care is required when introducing new interfaces, new 
> methods on existing interfaces, and covariant overrides. I believe the 
> primary risks are with name clashes and with return type mismatches.
> 
> On name clashes, "reversed" seems to thread the needle well, as I cannot find 
> any methods with that exact name on Eclipse Collections, Guava, Apache 
> Commons Collections, or several others. There are methods with similar names, 
> of course, such as "reverse", "asReversed", and "toReversed" but they 
> shouldn't cause name conflicts.
> 
> (There might be semantic conflicts, such as creating an reversed copy instead 
> of a reversed view, but I don't think that can be helped.)
> 
> If there are no name clashes with "reversed", the covariant overrides in the 
> sub-interfaces won't a problem. The covariant overrides on existing methods 
> (such as LinkedHashMap.entrySet) are a greater danger, I think. There are a 
> lot of LinkedHashMap subclasses (several dozen are visible in the Yawkat 
> browser) but only one had a conflicting override. It's trivially fixable, but 
> nonetheless it's an incompatibility.
> 
> I'm also concerned about conflicts over the other method names; something 
> like addFirst() is a pretty obvious method to add to a custom List 
> implementation. I haven't seen any, but that doesn't mean there aren't any.
> 
> s'marks

Re: ReversibleCollection proposal

[Stuart Marks]

On 4/17/21 4:49 AM, Tagir Valeev wrote:

Great proposal, thanks!

It has most functionality from my previous proposal, except the
ability to iterate LinkedHashSet starting from a specific element.
Well, probably we can skip this for now.


Thanks! And thanks for making that proposal a year ago; the ideas there and in the 
ensuing discussion clearly informed this proposal.


I did spend a bunch of time thinking about the "start from a specific element" case. 
Certainly it isn't difficult to create an iterator that starts from a specific 
element and proceeds in either direction. However, it's 2021, and nobody wants to 
program using Iterators anymore!! :-)


Perhaps an obvious extension is a LinkedHashSet subset-view from a particular 
element to the end (or beginning). This is kind of interesting, however, it leads 
off into the weeds. That is, the complexity in doing this seemed to outweigh the 
rest of the proposal, especially for the limited value it supplies, so I've left it 
aside for now.


It's possible to get a stream of LHS elements starting or ending at a particular 
element though a combination of reversed, takeWhile, and dropWhile.


s'marks

Re: ReversibleCollection proposal

[Stuart Marks]

On 4/17/21 2:48 AM, Stephen Colebourne wrote:

On Fri, 16 Apr 2021 at 18:41, Stuart Marks  wrote:

This is a proposal to add a ReversibleCollection interface to the Collections
Framework. I'm looking for comments on overall design before I work on detailed
specifications and tests. Please send such comments as replies on this email 
thread.


I think this could be an interesting addition to the framework.


Great!


# Ordering and Reversibility


Reading this section, it seems like ordering is a more significant
quality than reversibility. Yet the API is named "reversible". That
seems odd, esepcially given the stream characteristic.


I probably could have explained this better in the writeup.

"Reversible" is a stronger concept (i.e., it implies more things) than "Ordered". A 
reversible collection is ordered, it is traversable in both directions, both ends 
are accessible, and it affords operations at both ends. However, being ordered does 
not imply reversibility. For example, a PriorityQueue is ordered, but you can't get 
to the tail or iterate in reverse without a bunch of computation.



SortedSet::addFirst and addLast throw UnsupportedOperationException. This is 
because
SortedSet's ordering is determined by the comparison method and cannot be 
controlled
explicitly.


This seems undesirable. Maybe SortedSet should not implement
reversible/ordered? Maybe they should add to the set but validate
whether they would be in first/last position? Simply allowing users to
get a new instance with a different (eg. reversed) comparator would
meet much of the use case.


This is certainly an unpleasant asymmetry. But this is the Collections Framework; we 
should be used to unpleasant asymmetries. :-)


My typical examples of this are: various Map views like entrySet are that elements 
can be removed but they cannot be added; elements in Arrays.asList can be set but 
not added or removed; CopyOnWriteArrayList is mutable, but its iterators are not; etc.


Of course the presence of asymmetries doesn't justify the addition of more. But 
there is a precedent here: collections will implement an interface if they can 
support "most" of the operations, and the ones that aren't appropriate will throw 
UnsupportedOperationException. That's the precedent I'm following here with 
SortedSet (and NavigableSet).


An alternative as you suggest might be that SortedSet::addFirst/addLast could throw 
something like IllegalStateException if the element is wrongly positioned. 
(Deque::addFirst/addLast will throw ISE if the addition would exceed a capacity 
restriction.) This seems error-prone, though, and it's easier to understand and 
specify that these methods simply throw UOE unconditionally. If there's a good use 
case for the alternative I'd be interested in hearing it though.



Also, SortedSet uses first() and last(), yet the proposed interface
uses getFirst() and getLast().


Deque defines a full set of operations at both ends, including:

{ add, get, remove } x { First, Last }

so it seemed sensible to take that complete set and promote it to 
ReversibleCollection.

s'marks

Re: ReversibleCollection proposal

[Stuart Marks]

On 4/16/21 3:06 PM, Donald Raab wrote:

We should be cautious when adding new APIs to existing interfaces. There may be 
libraries which extend JDK types and already have reversed(), toReversed() or 
asReversed() APIs and corresponding interfaces.

There are OrderedIterable and ReversibleIterable interfaces and asReversed() 
and toReversed() methods in the Eclipse Collections API.


Hi Don, thanks for looking at the proposal.

Certainly a lot of care is required when introducing new interfaces, new methods on 
existing interfaces, and covariant overrides. I believe the primary risks are with 
name clashes and with return type mismatches.


On name clashes, "reversed" seems to thread the needle well, as I cannot find any 
methods with that exact name on Eclipse Collections, Guava, Apache Commons 
Collections, or several others. There are methods with similar names, of course, 
such as "reverse", "asReversed", and "toReversed" but they shouldn't cause name 
conflicts.


(There might be semantic conflicts, such as creating an reversed copy instead of a 
reversed view, but I don't think that can be helped.)


If there are no name clashes with "reversed", the covariant overrides in the 
sub-interfaces won't a problem. The covariant overrides on existing methods (such as 
LinkedHashMap.entrySet) are a greater danger, I think. There are a lot of 
LinkedHashMap subclasses (several dozen are visible in the Yawkat browser) but only 
one had a conflicting override. It's trivially fixable, but nonetheless it's an 
incompatibility.


I'm also concerned about conflicts over the other method names; something like 
addFirst() is a pretty obvious method to add to a custom List implementation. I 
haven't seen any, but that doesn't mean there aren't any.


s'marks

How to know if cpu supports unaligned memory accesses ?

[Laurent Bourgès]

Hi,
In the Marlin renderer & in other Unsafe use cases (pixel tile processing)
for java2d pipelines, I do use putInt()/putLong() primitives even if the
address is not aligned (to 4 or 8 bytes) to get faster processing of byte
buffer or arrays...

Is it possible in java (jdk internals) to query cpu capabilities like
endianness, unaligned support ?

For x86-64: unaligned ~ aligned, so it is not necessary to add padding in
the data layout and then it is better to have smaller buffers.

I would like write code like:
if (cpu_supports_unaligned) {
...
Use int/long to pack bytes...
} else {
Use byte (fallback)
}


Laurent

Re: ReversibleCollection proposal

[Remi Forax]

- Mail original -
> De: "Stuart Marks" 
> À: "core-libs-dev" 
> Envoyé: Vendredi 16 Avril 2021 19:40:55
> Objet: ReversibleCollection proposal

> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on 
> detailed
> specifications and tests. Please send such comments as replies on this email
> thread.
> 
> Here's a link to a draft PR that contains the code diffs. It's prototype
> quality,
> but it should be good enough to build and try out:
> 
> https://github.com/openjdk/jdk/pull/3533
> 
> And here's a link to a class diagram showing the proposed additions:
> 
> 
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
> 
> Thanks,
> 
> s'marks
> 
> 
> # Ordering and Reversibility
> 
> 
> A long-standing concept that's been missing from collections is that of the
> positioning, sequencing, or arrangement of elements as a structural property 
> of
> a
> collection. (This is sometimes called the "iteration order" of a collection.)
> For
> example, a HashSet is not ordered, but a List is. This concept is mostly not
> manifested in the collections API.
> 
> Iterating a collection produces elements one after another in *some* sequence.
> The
> concept of "ordered" determines whether this sequence is defined or whether 
> it's
> a
> coincidence of implementation. What does "having an order" mean? It implies 
> that
> there is a first element and that each element has a successor. Since
> collections
> have a finite number of elements, it further implies that there is a last
> element
> that has no successor. However, it is difficult to discern whether a 
> collection
> has
> a defined order. HashSet generally iterates its elements in the same undefined
> order, and you can't actually tell that it's not a defined order.
> 
> Streams do have a notion of ordering ("encounter order") and this is 
> preserved,
> where appropriate, through the stream pipeline. It's possible to detect this 
> by
> testing whether its spliterator has the ORDERED characteristic. Any collection
> with
> a defined order will have a spliterator with this characteristic. However, 
> this
> is
> quite a roundabout way to determine whether a collection has a defined order.
> Furthermore, knowing this doesn't enable any additional operations. It only
> provides
> constraints on the stream's implementations (keeping the elements in order) 
> and
> provides stronger semantics for certain operations. For example, findFirst() 
> on
> an
> unordered stream is the same as findAny(), but actually finds the first 
> element
> if
> the stream is ordered.
> 
> The concept of ordering is thus present in the system but is surfaced only in 
> a
> fairly indirect way. We can strengthen abstraction of ordering by making a few
> observations and considering their implications.
> 
> Given that there is a first element and a last element, the sequence of 
> elements
> has
> two ends. It's reasonable to consider operations (add, get, remove) on either
> end.
> Indeed, the Deque interface has a full complement of operations at each end.
> This is
> an oft-requested feature on various other collections.
> 
> Each element except for the last has a successor, implying that each element
> except
> for the first has a predecessor. Thus it's reasonable to consider iterating 
> the
> elements from first to last or from last to first (that is, in forward or
> reverse
> order). Indeed, the concept of iterating in reverse order appears already in
> bits
> and pieces in particular places around the collections:
> 
>  - List has indexOf() and lastIndexOf()
>  - Deque has removeFirstOccurrence() and removeLastOccurrence()
>  - List has a ListIterator with hasPrevious/previous methods
>  - Deque and NavigableSet have descendingIterator methods
> 
> Given an ordered collection, though, there's no general way to iterate it in
> reverse
> order. Reversed iteration isn't the most common operation, but there are some
> frequent use cases, such as operating on elements in most-recently-added 
> order.
> Questions and bug reports about this have come up repeatedly over the years.
> 
> Unfortunately, iterating in reverse order is much harder than iterating in
> forward
> order. There are a variety of ways to iterate in forward order. For example,
> given a
> List, one can do any of the following:
> 
> for (var e : list) { ... }
> list.forEach(...)
> list.stream()
> list.toArray()
> 
> However, to iterate a list in reverse order, one must use an explicit loop 
> over
> ListIterator:
> 
> for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
> var e = it.previous();
> ...
> }
> 
> Streaming the elements of a List in reverse order is even worse. One approach
> would
> be to implement a reverse-ordered Iterator that wraps a ListIterator and
> delegates
> hasNext/next calls to the ListIterator's 

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 9:37 AM, Michael Hall  wrote:
> 
> So apparently ‘cp’ is not a good idea on a signed application. At least not 
> on a signed java one. 

Fyi for anyone who wants to copy a Mac signed java app from a script or maybe 
from java Runtime. Instead of…

cp -r /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app

this…

ditto /Volumes/HalfPipe outputdir

Copies and still codesign verifies.

Re: ReversibleCollection proposal

[Brian Goetz]

Adding a REVERSIBLE characteristic to spliterators is easy enough, and 
as you say, many useful sources can easily provide an efficient reverse 
operation.  Filtering and mapping can preserve reversibility. The real 
question is what to do if someone calls reverse() on a non-reversible 
stream.  (Finite streams that are not easily reversible can still be 
reversed by draining the stream into a buffer, but that's likely 
inefficient; infinite streams have no chance.)  Should reverse() just 
throw when it encounters a source not designed for reversibility?  I 
don't particularly like the idea of throwing based on a dynamic source 
property, but trying to thread ReversibleStream through the static types 
is probably worse.


In the "drain" it case, the user can always simulate this manually: call 
toArray and get a reversed stream from that (since array-based streams 
are trivially reversible.)


I'm not particularly convinced of the value of folding from both 
directions.  The main value of foldr over foldl in Haskell is that 
because of laziness, foldr on infinite lists can work with 
short-circuiting combiners, whereas foldl cannot.  In strict languages, 
this benefit is not present, making the marginal value of foldr over 
foldl much smaller.


But, Stuart's proposal gives us much of this with less fuss.  IF a 
collection is reversible, you can just say


    c.reversed().stream()

and off you go, plus a similar method for arrays 
(Arrays.reversedStream).  Given that, what is the value of pushing this 
further into stream?


On 4/17/2021 7:49 AM, Tagir Valeev wrote:

Great proposal, thanks!

It has most functionality from my previous proposal, except the
ability to iterate LinkedHashSet starting from a specific element.
Well, probably we can skip this for now.

Some people really want to reverse Streams as well. E. g., the
corresponding StackOverflow question [1] has 171 upvotes and 200k+
views. Also, if the stream were reversible, it would be possible to
implement efficient foldRight/reduceRight operation. See the
discussion at [2]. It would be nice to explore the possibility of
extending Stream API to take into account the source reversibility.
Some existing ordered sources that have no underlying collection (e.g.
IntStream.range, or Arrays.stream) can be easily reversed as well. Map
and filter operations preserve reversibility and flatMap is reversible
if the supplied stream is reversible as well.

With best regards,
Tagir Valeev.

[1] https://stackoverflow.com/q/24010109/4856258
[2] https://bugs.openjdk.java.net/browse/JDK-8133680

On Sat, Apr 17, 2021 at 12:41 AM Stuart Marks  wrote:

This is a proposal to add a ReversibleCollection interface to the Collections
Framework. I'm looking for comments on overall design before I work on detailed
specifications and tests. Please send such comments as replies on this email 
thread.

Here's a link to a draft PR that contains the code diffs. It's prototype 
quality,
but it should be good enough to build and try out:

  https://github.com/openjdk/jdk/pull/3533

And here's a link to a class diagram showing the proposed additions:


https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf

Thanks,

s'marks


# Ordering and Reversibility


A long-standing concept that's been missing from collections is that of the
positioning, sequencing, or arrangement of elements as a structural property of 
a
collection. (This is sometimes called the "iteration order" of a collection.) 
For
example, a HashSet is not ordered, but a List is. This concept is mostly not
manifested in the collections API.

Iterating a collection produces elements one after another in *some* sequence. 
The
concept of "ordered" determines whether this sequence is defined or whether 
it's a
coincidence of implementation. What does "having an order" mean? It implies that
there is a first element and that each element has a successor. Since 
collections
have a finite number of elements, it further implies that there is a last 
element
that has no successor. However, it is difficult to discern whether a collection 
has
a defined order. HashSet generally iterates its elements in the same undefined
order, and you can't actually tell that it's not a defined order.

Streams do have a notion of ordering ("encounter order") and this is preserved,
where appropriate, through the stream pipeline. It's possible to detect this by
testing whether its spliterator has the ORDERED characteristic. Any collection 
with
a defined order will have a spliterator with this characteristic. However, this 
is
quite a roundabout way to determine whether a collection has a defined order.
Furthermore, knowing this doesn't enable any additional operations. It only 
provides
constraints on the stream's implementations (keeping the elements in order) and
provides stronger semantics for certain operations. For example, findFirst() on 
an
unordered stream is the same as findAny(), but actually finds 

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 9:14 AM, Michael Hall  wrote:
> 
>> only executables and libraries are signed - this tool running across the 
>> whole app will find unsigned files, that would be expected.
> 
> Hmm. ok. Is the jdk separately signed? Would something in copying it change a 
> date or something that would cause the verify to fail on the jdk signature 
> thinking something has changed rather than what you sign for the app?
> 
> ls -l HalfPipe.app/Contents/runtime/Contents
> total 8
> ...
> drwxr-xr-x  3 mjh  staff   96 Apr 16 19:29 _CodeSignature

OK I think this may be it. For my testing I sort of force the DMG build back to 
the —install-dir one.

open -Wg HalfPipe-1.0.dmg
cp -r /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app
…
diskutil eject HalfPipe
open outputdir/HalfPipe.app

codesign -v outputdir/HalfPipe.app
outputdir/HalfPipe.app: a sealed resource is missing or invalid

If instead I do the proper drag and drop install to the Applications directory.
codesign -v /Applications/HalfPipe.app

No error. So apparently ‘cp’ is not a good idea on a signed application. At 
least not on a signed java one. 

This one can probably be closed permanently.

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 9:14 AM, Michael Hall  wrote:
> 
 
 With —install-dir this remains a reproducible bug for me at 17-ea.
>> yes - but what is value of "--install-dir" - can you insure it is a fully 
>> qualified directory path that exists on all users machines and all users 
>> have write access to ?  With the current code, if applescript cannot create 
>> alias to this location on target machine it will show this buggy looklin 
>> gfinder view.
 
 If a reference build was provided somewhere I might have picked up on the 
 parameter difference sooner.
 
 
>> /Andy
> 
> Yes, there is no good reason to do this and my doing it was a mistake. But 
> currently still at 17ea

Sorry got distracted thinking about the signature thing.
But currently at 17ea if a user, other than myself now, makes the same mistake 
of including —install-dir the DMG problem is still there.

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 8:57 AM, Andy Herrick  wrote:
> 
> 
> On 4/17/2021 1:14 AM, David Holmes wrote:
>> Hi Michael,
>> 
>> On 17/04/2021 10:57 am, Michael Hall wrote:
>>> Is there anyway to get a simple/test reference type application available 
>>> that could be used in reproducing bugs?
> I put a simple test application I was using in your bug report: 
> https://bugs.openjdk.java.net/browse/JDK-8263156 
> 

I’ll start with this or at least take a look at it in attempting a reproducer.

>>> 
>>> I had two I think potentially serious bugs that were basically not 
>>> addressed for problems in reproducing.
>>> 
>>> JDK-8263156 : [macos]: OS X application signing concerns - a sealed 
>>> resource is missing or invalid
>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 
>>>  
>>> >> >
>>> 
>>> The command to reproduce was provided. The error appears to be in files 
>>> included in the embedded JDK not being signed. So apparently not having to 
>>> do with anything of mine. (Mentioned I now see in the comments).
> 
> only executables and libraries are signed - this tool running across the 
> whole app will find unsigned files, that would be expected.

Hmm. ok. Is the jdk separately signed? Would something in copying it change a 
date or something that would cause the verify to fail on the jdk signature 
thinking something has changed rather than what you sign for the app?

ls -l HalfPipe.app/Contents/runtime/Contents
total 8
...
drwxr-xr-x  3 mjh  staff   96 Apr 16 19:29 _CodeSignature

> 
>>> 
>>> As I indicate this is not a serious error for me since I am not submitting 
>>> the app to the Mac App Store but I believe this would get the app Apple 
>>> rejected for anyone who is attempting that. A show stopper for a major use 
>>> case. It seems too bad to simply close it because I missed an email asking 
>>> for a reproduce.
>> 
>> Note the bug referenced is closed as "incomplete" - that is a temporary 
>> state while awaiting additional information  (usually from the submitter). 
>> If we never hear back from the submitter then it will be closed with a 
>> different (more terminal) state. If we do hear back then the bug gets 
>> reopened.
>> 
>> Cheers,
>> David
>> 
>>> With a reference application I could demonstrate the error against would 
>>> eliminate the need to provide a separate reproducible test case. Quite 
>>> sized for the application in question. Such an application is actually 
>>> mentioned in the bug report comments. Could such a application be made 
>>> available for download or user reproducing - the jpackage command and 
>>> arguments?
>>> 
>>> I have looked a little bit at if to see if I can figure out how to sign the 
>>> embedded jdk files. So far only accomplishing that I can no longer simply 
>>> use my name for signing but have to use my fully qualified security 
>>> identity.
>>> 
>>> The question now seems to be what is in fact the difference between mine 
>>> and the, unavailable to me, reference application as to these files 
>>> verifying as correctly signed.
>>> 
>>> A second bug
>>> JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect
>>> 
>>> I thought a fix for this was all set to go in and was pulled. It was 
>>> apparently determined that the problem only applies if the —install-dir 
>>> parameter is used for DMG’s. Where it really makes no sense. My use 
>>> apparently held over from when I was just creating the app.I thought this 
>>> had somehow also in some way regressed to not reproducible. I still think a 
>>> fairly simple change to the AppleScript as was originally planned would 
>>> resolve the issue independently of parameters. The default DMG build I 
>>> would think should _always_ indicate installation to the Applications 
>>> folder.
> 
> This is the change proposed now by Alexander on pull request: 
> https://git.openjdk.java.net/jdk/pull/3505 
> 
> 
> That  dmg should ignore --input-dir and always propose dragging apps into 
> /Applications

Agreed.

> 
>>> 
>>> With —install-dir this remains a reproducible bug for me at 17-ea.
> yes - but what is value of "--install-dir" - can you insure it is a fully 
> qualified directory path that exists on all users machines and all users have 
> write access to ?  With the current code, if applescript cannot create alias 
> to this location on target machine it will show this buggy looklin gfinder 
> view.
>>> 
>>> If a reference build was provided somewhere I might have picked up on the 
>>> parameter difference sooner.
>>> 
>>> 
> /Andy

Yes, there is no good reason to do this and my doing it was a mistake. But 
currently still at 17ea

Re: jpackage bugs

[Andy Herrick]

On 4/17/2021 1:14 AM, David Holmes wrote:

Hi Michael,

On 17/04/2021 10:57 am, Michael Hall wrote:
Is there anyway to get a simple/test reference type application 
available that could be used in reproducing bugs?
I put a simple test application I was using in your bug report: 
https://bugs.openjdk.java.net/browse/JDK-8263156


I had two I think potentially serious bugs that were basically not 
addressed for problems in reproducing.


JDK-8263156 : [macos]: OS X application signing concerns - a sealed 
resource is missing or invalid
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 



The command to reproduce was provided. The error appears to be in 
files included in the embedded JDK not being signed. So apparently 
not having to do with anything of mine. (Mentioned I now see in the 
comments).


only executables and libraries are signed - this tool running across the 
whole app will find unsigned files, that would be expected.




As I indicate this is not a serious error for me since I am not 
submitting the app to the Mac App Store but I believe this would get 
the app Apple rejected for anyone who is attempting that. A show 
stopper for a major use case. It seems too bad to simply close it 
because I missed an email asking for a reproduce.


Note the bug referenced is closed as "incomplete" - that is a 
temporary state while awaiting additional information  (usually from 
the submitter). If we never hear back from the submitter then it will 
be closed with a different (more terminal) state. If we do hear back 
then the bug gets reopened.


Cheers,
David

With a reference application I could demonstrate the error against 
would eliminate the need to provide a separate reproducible test 
case. Quite sized for the application in question. Such an 
application is actually mentioned in the bug report comments. Could 
such a application be made available for download or user reproducing 
- the jpackage command and arguments?


I have looked a little bit at if to see if I can figure out how to 
sign the embedded jdk files. So far only accomplishing that I can no 
longer simply use my name for signing but have to use my fully 
qualified security identity.


The question now seems to be what is in fact the difference between 
mine and the, unavailable to me, reference application as to these 
files verifying as correctly signed.


A second bug
JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect

I thought a fix for this was all set to go in and was pulled. It was 
apparently determined that the problem only applies if the 
—install-dir parameter is used for DMG’s. Where it really makes no 
sense. My use apparently held over from when I was just creating the 
app.I thought this had somehow also in some way regressed to not 
reproducible. I still think a fairly simple change to the AppleScript 
as was originally planned would resolve the issue independently of 
parameters. The default DMG build I would think should _always_ 
indicate installation to the Applications folder.


This is the change proposed now by Alexander on pull request: 
https://git.openjdk.java.net/jdk/pull/3505


That  dmg should ignore --input-dir and always propose dragging apps 
into /Applications




With —install-dir this remains a reproducible bug for me at 17-ea.
yes - but what is value of "--install-dir" - can you insure it is a 
fully qualified directory path that exists on all users machines and all 
users have write access to ?  With the current code, if applescript 
cannot create alias to this location on target machine it will show this 
buggy looklin gfinder view.


If a reference build was provided somewhere I might have picked up on 
the parameter difference sooner.




/Andy

Re: 8252827: Caching Integer.toString just like Integer.valueOf

[Raffaello Giulietti]

Hi,

in view of Integer becoming a primitive class [1], the IntegerCache is 
probably going to disappear.


For a small, fixed range like the one you are proposing [-1, 16], 
there's no real need for a separate cache class. You could have a switch 
in the implementation of toString(), with the string literals then being 
part of the constant pool of the class. Not free beer, but supported by 
the VM since day 0.


It's only when the range is open that you'd need a cache similar to 
IntegerCache.



My 2 cents as well :-)
Raffaello



[1] https://openjdk.java.net/jeps/402

On 2021-04-17 11:18, Laurent Bourgès wrote:

Hi,

I read the JBS bug and I interpret it as:
- IntegerCache provides Integer instances for [-128, 127] by default
- Having Integer.toString(int) could behave the same or at least cache 
most probable values like [-1 to 16] or using the IntegerCache range.


It looks trivial and potentially could benefits to jdk itself to reduce 
memory garbage : is Integer.toString(int) widely used in the jdk codebase ?


Finally it can be alternatively implemented in application's code.

My 2 cents,
Laurent

Le sam. 17 avr. 2021 à 11:06, Raffaello Giulietti 
mailto:raffaello.giulie...@gmail.com>> a 
écrit :




On 2021-04-17 07:07, David Holmes wrote:
 > On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
 >> I guess the reporter meant to limit the cache range similarly to
the
 >> one used for valueOf().
 >>
 >> I have no clue about the benefit/cost ratio for the proposed String
 >> cache. It really depends on usage, workload, etc. One can easily
 >> imagine both extreme scenarios but it's hard to tell how the
average
 >> one would look.
 >>
 >> My post is only about either solving the issue by implementing the
 >> cache, which I can contribute to; or closing it because of lack of
 >> real-world need or interest.
 >
 > Caching for the sake of caching is not an objective in itself.
Unless
 > the caching can be shown to solve a real problem, and the
strategy for
 > managing the cache is well-defined, then I would just close the
 > enhancement request. (Historically whether an issue we don't have
any
 > firm plans to address is just left open "forever" or closed, depends
 > very much on who does the bug triaging in that area. :) )
 >
 > Cheers,
 > David
 >


Indeed, the impression is that many of the issues are probably open
because it's unclear whether they should be addressed with some
implementation or spec effort or whether they should be closed.
Triaging
is certainly a harder job than it appears at first sight ;-)

It would be useful to have a kind of "suspended" or "limbo" resolution
state on the JBS for issues like this one, so people searching for more
compelling open ones would not encounter them.

Personally, I would close this issue without a "fix"; or "suspend" it.


Greetings
Raffaello



 >>
 >> Greetings
 >> Raffaello
 >>
 >>
 >> On 2021-04-16 20:36, Roger Riggs wrote:
 >>> Hi,
 >>>
 >>> Is there any way to quantify the savings?
 >>> And what technique can be applied to limit the size of the cache.
 >>> The size of the small integer cache is somewhat arbitrary.
 >>>
 >>> Regards, Roger
 >>>
 >>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
  Hello,
 
  does the enhancement proposed in [1] make sense, both today
and when
  wrappers will be migrated to primitive classes?
  If so, it should be rather simple to add it and I could
prepare a PR.
  If not, the issue might perhaps be closed.
 
 
  Greetings
  Raffaello
 
  
 
  [1] https://bugs.openjdk.java.net/browse/JDK-8252827

 >>>

Re: ReversibleCollection proposal

[Tagir Valeev]

Great proposal, thanks!

It has most functionality from my previous proposal, except the
ability to iterate LinkedHashSet starting from a specific element.
Well, probably we can skip this for now.

Some people really want to reverse Streams as well. E. g., the
corresponding StackOverflow question [1] has 171 upvotes and 200k+
views. Also, if the stream were reversible, it would be possible to
implement efficient foldRight/reduceRight operation. See the
discussion at [2]. It would be nice to explore the possibility of
extending Stream API to take into account the source reversibility.
Some existing ordered sources that have no underlying collection (e.g.
IntStream.range, or Arrays.stream) can be easily reversed as well. Map
and filter operations preserve reversibility and flatMap is reversible
if the supplied stream is reversible as well.

With best regards,
Tagir Valeev.

[1] https://stackoverflow.com/q/24010109/4856258
[2] https://bugs.openjdk.java.net/browse/JDK-8133680

On Sat, Apr 17, 2021 at 12:41 AM Stuart Marks  wrote:
>
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on 
> detailed
> specifications and tests. Please send such comments as replies on this email 
> thread.
>
> Here's a link to a draft PR that contains the code diffs. It's prototype 
> quality,
> but it should be good enough to build and try out:
>
>  https://github.com/openjdk/jdk/pull/3533
>
> And here's a link to a class diagram showing the proposed additions:
>
>
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
>
> Thanks,
>
> s'marks
>
>
> # Ordering and Reversibility
>
>
> A long-standing concept that's been missing from collections is that of the
> positioning, sequencing, or arrangement of elements as a structural property 
> of a
> collection. (This is sometimes called the "iteration order" of a collection.) 
> For
> example, a HashSet is not ordered, but a List is. This concept is mostly not
> manifested in the collections API.
>
> Iterating a collection produces elements one after another in *some* 
> sequence. The
> concept of "ordered" determines whether this sequence is defined or whether 
> it's a
> coincidence of implementation. What does "having an order" mean? It implies 
> that
> there is a first element and that each element has a successor. Since 
> collections
> have a finite number of elements, it further implies that there is a last 
> element
> that has no successor. However, it is difficult to discern whether a 
> collection has
> a defined order. HashSet generally iterates its elements in the same undefined
> order, and you can't actually tell that it's not a defined order.
>
> Streams do have a notion of ordering ("encounter order") and this is 
> preserved,
> where appropriate, through the stream pipeline. It's possible to detect this 
> by
> testing whether its spliterator has the ORDERED characteristic. Any 
> collection with
> a defined order will have a spliterator with this characteristic. However, 
> this is
> quite a roundabout way to determine whether a collection has a defined order.
> Furthermore, knowing this doesn't enable any additional operations. It only 
> provides
> constraints on the stream's implementations (keeping the elements in order) 
> and
> provides stronger semantics for certain operations. For example, findFirst() 
> on an
> unordered stream is the same as findAny(), but actually finds the first 
> element if
> the stream is ordered.
>
> The concept of ordering is thus present in the system but is surfaced only in 
> a
> fairly indirect way. We can strengthen abstraction of ordering by making a few
> observations and considering their implications.
>
> Given that there is a first element and a last element, the sequence of 
> elements has
> two ends. It's reasonable to consider operations (add, get, remove) on either 
> end.
> Indeed, the Deque interface has a full complement of operations at each end. 
> This is
> an oft-requested feature on various other collections.
>
> Each element except for the last has a successor, implying that each element 
> except
> for the first has a predecessor. Thus it's reasonable to consider iterating 
> the
> elements from first to last or from last to first (that is, in forward or 
> reverse
> order). Indeed, the concept of iterating in reverse order appears already in 
> bits
> and pieces in particular places around the collections:
>
>   - List has indexOf() and lastIndexOf()
>   - Deque has removeFirstOccurrence() and removeLastOccurrence()
>   - List has a ListIterator with hasPrevious/previous methods
>   - Deque and NavigableSet have descendingIterator methods
>
> Given an ordered collection, though, there's no general way to iterate it in 
> reverse
> order. Reversed iteration isn't the most common operation, but there are some
> frequent use cases, such as operating on elements in 

Re: ReversibleCollection proposal

[Anthony Vanelverdinghe]

On Saturday, April 17, 2021 11:48 CEST, Stephen Colebourne 
 wrote:

> On Fri, 16 Apr 2021 at 18:41, Stuart Marks  wrote:
> > This is a proposal to add a ReversibleCollection interface to the 
> > Collections
> > Framework. I'm looking for comments on overall design before I work on 
> > detailed
> > specifications and tests. Please send such comments as replies on this 
> > email thread.
>
> I think this could be an interesting addition to the framework.
>
> > # Ordering and Reversibility
>
> Reading this section, it seems like ordering is a more significant
> quality than reversibility. Yet the API is named "reversible". That
> seems odd, esepcially given the stream characteristic.

Since `reversible = ordered + sized`, using reversible makes sense imho (even 
though in the context of the Collections Framework, reversible <-> ordered, 
since all collections are sized). Also, I think "reversible" is much less 
likely to clash with existing code (e.g. a quick GitHub search shows 1 result 
for `ReversibleCollection`, while there's plenty for `OrderedCollection`).

>
> > SortedSet::addFirst and addLast throw UnsupportedOperationException. This 
> > is because
> > SortedSet's ordering is determined by the comparison method and cannot be 
> > controlled
> > explicitly.
>
> This seems undesirable. Maybe SortedSet should not implement
> reversible/ordered? Maybe they should add to the set but validate
> whether they would be in first/last position? Simply allowing users to
> get a new instance with a different (eg. reversed) comparator would
> meet much of the use case.

I'd argue throwing UOE is the right thing to do. Not having `SortedSet` 
implement `ReversibleSet` doesn't make sense to me. Adding with validation is 
reasonable in itself, but then you'd have to specify `IllegalArgumentException` 
in `ReversibleCollection` (where you'd have a hard time specifying the 
conditions under which it might be thrown without explicitly referencing 
`SortedSet`), just to accommodate these 2 methods which would be very rarely 
used.

>
> Also, SortedSet uses first() and last(), yet the proposed interface
> uses getFirst() and getLast().

Since `Deque` uses `getFirst()` and `getLast()`, it's impossible to match all 
existing methods in the different interfaces.

>
> Stephen

Kind regards, Anthony

Re: ReversibleCollection proposal

[Stephen Colebourne]

On Fri, 16 Apr 2021 at 18:41, Stuart Marks  wrote:
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on 
> detailed
> specifications and tests. Please send such comments as replies on this email 
> thread.

I think this could be an interesting addition to the framework.

> # Ordering and Reversibility

Reading this section, it seems like ordering is a more significant
quality than reversibility. Yet the API is named "reversible". That
seems odd, esepcially given the stream characteristic.

> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is 
> because
> SortedSet's ordering is determined by the comparison method and cannot be 
> controlled
> explicitly.

This seems undesirable. Maybe SortedSet should not implement
reversible/ordered? Maybe they should add to the set but validate
whether they would be in first/last position? Simply allowing users to
get a new instance with a different (eg. reversed) comparator would
meet much of the use case.

Also, SortedSet uses first() and last(), yet the proposed interface
uses getFirst() and getLast().

Stephen

Re: 8252827: Caching Integer.toString just like Integer.valueOf

[Laurent Bourgès]

Hi,

I read the JBS bug and I interpret it as:
- IntegerCache provides Integer instances for [-128, 127] by default
- Having Integer.toString(int) could behave the same or at least cache most
probable values like [-1 to 16] or using the IntegerCache range.

It looks trivial and potentially could benefits to jdk itself to reduce
memory garbage : is Integer.toString(int) widely used in the jdk codebase ?

Finally it can be alternatively implemented in application's code.

My 2 cents,
Laurent

Le sam. 17 avr. 2021 à 11:06, Raffaello Giulietti <
raffaello.giulie...@gmail.com> a écrit :

>
>
> On 2021-04-17 07:07, David Holmes wrote:
> > On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
> >> I guess the reporter meant to limit the cache range similarly to the
> >> one used for valueOf().
> >>
> >> I have no clue about the benefit/cost ratio for the proposed String
> >> cache. It really depends on usage, workload, etc. One can easily
> >> imagine both extreme scenarios but it's hard to tell how the average
> >> one would look.
> >>
> >> My post is only about either solving the issue by implementing the
> >> cache, which I can contribute to; or closing it because of lack of
> >> real-world need or interest.
> >
> > Caching for the sake of caching is not an objective in itself. Unless
> > the caching can be shown to solve a real problem, and the strategy for
> > managing the cache is well-defined, then I would just close the
> > enhancement request. (Historically whether an issue we don't have any
> > firm plans to address is just left open "forever" or closed, depends
> > very much on who does the bug triaging in that area. :) )
> >
> > Cheers,
> > David
> >
>
>
> Indeed, the impression is that many of the issues are probably open
> because it's unclear whether they should be addressed with some
> implementation or spec effort or whether they should be closed. Triaging
> is certainly a harder job than it appears at first sight ;-)
>
> It would be useful to have a kind of "suspended" or "limbo" resolution
> state on the JBS for issues like this one, so people searching for more
> compelling open ones would not encounter them.
>
> Personally, I would close this issue without a "fix"; or "suspend" it.
>
>
> Greetings
> Raffaello
>
>
>
> >>
> >> Greetings
> >> Raffaello
> >>
> >>
> >> On 2021-04-16 20:36, Roger Riggs wrote:
> >>> Hi,
> >>>
> >>> Is there any way to quantify the savings?
> >>> And what technique can be applied to limit the size of the cache.
> >>> The size of the small integer cache is somewhat arbitrary.
> >>>
> >>> Regards, Roger
> >>>
> >>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
>  Hello,
> 
>  does the enhancement proposed in [1] make sense, both today and when
>  wrappers will be migrated to primitive classes?
>  If so, it should be rather simple to add it and I could prepare a PR.
>  If not, the issue might perhaps be closed.
> 
> 
>  Greetings
>  Raffaello
> 
>  
> 
>  [1] https://bugs.openjdk.java.net/browse/JDK-8252827
> >>>
>

Re: RFR: 8265237: String.join and StringJoiner can be improved further [v2]

[Tagir F . Valeev]

On Thu, 15 Apr 2021 19:26:48 GMT, Peter Levart  wrote:

>> While JDK-8148937 improved StringJoiner class by replacing internal use of 
>> getChars that copies out characters from String elements into a char[] array 
>> with StringBuilder which is somehow more optimal, the improvement was 
>> marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was 
>> reduced by about 50% in average per operation.
>> Initial attempt to tackle that issue was more involved, but was later 
>> discarded because it was apparently using too much internal String details 
>> in code that lives outside String and outside java.lang package.
>> But there is another way to package such "intimate" code - we can put it 
>> into String itself and just call it from StringJoiner.
>> This PR is an attempt at doing just that. It introduces new package-private 
>> method in `java.lang.String` which is then used from both pubic static 
>> `String.join` methods as well as from `java.util.StringJoiner` (via 
>> SharedSecrets). The improvements can be seen by running the following JMH 
>> benchmark:
>> 
>> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
>> 
>> The comparative results are here:
>> 
>> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
>> 
>> The jmh-result.json files are here:
>> 
>> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
>> 
>> Improvement in speed ranges from 8% (for small strings) to 200% (for long 
>> strings), while creation of garbage has been further reduced to an almost 
>> garbage-free operation.
>> 
>> So WDYT?
>
> Peter Levart has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add String.join benchmark method to StringJoinerBenchmark and adjust some 
> parameters to cover bigger range

Great work, thanks! I tried to do something similar a couple of years ago but 
did not submit my patch. One thing that stopped me is that joining many 
one-character strings was slower with my patch, compared to the baseline. 
Something like this:


// setup
String[] strings = new String[100];
Arrays.fill(strings, "a");
// benchmark
return String.join(",", strings);


Could you add this case to your benchmark, for completeness?

-

PR: https://git.openjdk.java.net/jdk/pull/3501

Re: 8252827: Caching Integer.toString just like Integer.valueOf

[Raffaello Giulietti]

On 2021-04-17 07:07, David Holmes wrote:

On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
I guess the reporter meant to limit the cache range similarly to the 
one used for valueOf().


I have no clue about the benefit/cost ratio for the proposed String 
cache. It really depends on usage, workload, etc. One can easily 
imagine both extreme scenarios but it's hard to tell how the average 
one would look.


My post is only about either solving the issue by implementing the 
cache, which I can contribute to; or closing it because of lack of 
real-world need or interest.


Caching for the sake of caching is not an objective in itself. Unless 
the caching can be shown to solve a real problem, and the strategy for 
managing the cache is well-defined, then I would just close the 
enhancement request. (Historically whether an issue we don't have any 
firm plans to address is just left open "forever" or closed, depends 
very much on who does the bug triaging in that area. :) )


Cheers,
David




Indeed, the impression is that many of the issues are probably open 
because it's unclear whether they should be addressed with some 
implementation or spec effort or whether they should be closed. Triaging 
is certainly a harder job than it appears at first sight ;-)


It would be useful to have a kind of "suspended" or "limbo" resolution 
state on the JBS for issues like this one, so people searching for more 
compelling open ones would not encounter them.


Personally, I would close this issue without a "fix"; or "suspend" it.


Greetings
Raffaello





Greetings
Raffaello


On 2021-04-16 20:36, Roger Riggs wrote:

Hi,

Is there any way to quantify the savings?
And what technique can be applied to limit the size of the cache.
The size of the small integer cache is somewhat arbitrary.

Regards, Roger

On 4/16/21 12:48 PM, Raffaello Giulietti wrote:

Hello,

does the enhancement proposed in [1] make sense, both today and when 
wrappers will be migrated to primitive classes?

If so, it should be rather simple to add it and I could prepare a PR.
If not, the issue might perhaps be closed.


Greetings
Raffaello



[1] https://bugs.openjdk.java.net/browse/JDK-8252827

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 12:14 AM, David Holmes  wrote:
> 
>> 
> 
> Note the bug referenced is closed as "incomplete" - that is a temporary state 
> while awaiting additional information  (usually from the submitter). If we 
> never hear back from the submitter then it will be closed with a different 
> (more terminal) state. If we do hear back then the bug gets reopened.

I was unaware of this distinction. Then I will attempt to come up with a 
simpler reproducible test case but I don’t know if I’ll succeed. If the test 
that didn’t reproduce that is mentioned in the comments was available I could 
try to compare that with what I am doing for differences. 

I could provide my invocation parameters to the email requesting the 
reproducer. That is my only direct involvement. If it is something else 
particular to the application itself I don’t know what that might be. Modular 
vs. my non-modular? Or something like that maybe. I think this always embeds 
the current JDK and I have checked against more than one so it doesn’t seem to 
be JDK version specific.

Thanks for pointing this status information out.

RFR: 8265356: need code example for getting canonical constructor of a Record

[Tagir F . Valeev]

I decided to show a complete static method in the example, so it could be 
copied to user utility class as is. Not sure if it's reasonable to add `assert 
cls.isRecord();` there. Also I don't know whether there's a limitation on max 
characters in the sample code. Probable a line break in `static \nConstructor getCanonicalConstructor(Class cls)` is unnecessary.

---
Aside from this PR, I've found a couple of things to clean up in 
`java.lang.Class`:
1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by 
@jddarcy in #3038). It should be `#isArray()` instead of `isArray()`.
2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused 
type parameters ``.
3. Probably too much but AnnotationData can be nicely converted to a record! 
Not sure, probably nobody wants to have `java.lang.Record` initialized too 
early or increasing the footprint of such a basic class in the metaspace, so I 
don't insist on this.


private record AnnotationData(
Map, Annotation> annotations,
Map, Annotation> declaredAnnotations,
// Value of classRedefinedCount when we created this AnnotationData 
instance
int redefinedCount) {
}


Please tell me if it's ok to fix 1 and 2 along with this PR.

-

Commit messages:
 - 8265356: need code example for getting canonical constructor of a Record

Changes: https://git.openjdk.java.net/jdk/pull/3556/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3556=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265356
  Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3556.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3556/head:pull/3556

PR: https://git.openjdk.java.net/jdk/pull/3556