Re: a quick question about String

er they are indeed equivalent. IMO equivalent here means > “for practical purposes”; locking on an arbitrary string which you did not > allocate is a silly thing to do, so it is reasonable that the doc opted for a > common-sense interpretation of equivalent, rather than a more precise

Re: a quick question about String

use as lock. >> >> XenoAmess >> ____ >> From: core-libs-dev on behalf of >> Bernd Eckenfels >> Sent: Friday, December 24, 2021 5:51:55 AM >> To: alan Snyder ; core-libs-dev < >> core-libs-dev@openjdk.j

a quick question about String

Do the public constructors of String actually do what their documentation says (allocate a new instance), or is there some kind of compiler magic that might avoid allocation?

Re: RFR: 8277861: Terminally deprecate Thread.stop

ems that it should be possible to stop a thread spawned to execute code in a native library that works on data in native memory.. If what you say about thread tear-down is true, then I guess I would need to spawn the thread from native code as well. > On Nov 30, 2021, at 5:58 PM, Davi

Re: RFR: 8277861: Terminally deprecate Thread.stop

I think you are saying that to kill a thread running native code I would need to use native code. Is that right? > On Nov 30, 2021, at 10:17 AM, Alan Bateman wrote: > > On 30/11/2021 17:13, Alan Snyder wrote: >> Although I understand the potential dangers of using Thread.stop,

Re: RFR: 8277861: Terminally deprecate Thread.stop

Although I understand the potential dangers of using Thread.stop, it seems to me there are cases where its use is legitimate and valuable. The examples I am thinking of involve a potentially long running computation whose result is no longer needed. In particular, I am thinking of pure computati

Re: Adding an @Immutable annotation to Java

> On Nov 29, 2021, at 10:42 AM, Simon Roberts > wrote: > > I will say that as Java provides more and more features modeled on more > functional languages, I'm finding more and more people struggling with the > inherently mutable nature of Java, and that I strongly believe that > something that

Re: Adding an @Immutable annotation to Java

I like the idea of an @Immutable annotation. So much so, that I have created one and use it heavily. However, my @Immutable is just for documentation; it does not have a rigorous semantics that would be needed for a compiler to validate its use or generate different code. But it could be used by

Re: [External] : Re: jpackage - notarizing

on issue, which is most definitely a JDK issue, as it is a direct consequence of AWT/Swing using its own UI event thread instead of using the AppKit main thread. See: https://bugs.openjdk.java.net/browse/JDK-8270211 > > On 11/22/2021 11:56 AM, Michael Hall wrote: >> >>>

Re: jpackage - notarizing

> On Nov 22, 2021, at 10:12 AM, Kevin Rushforth > wrote: > > JNF was removed from the JDK if that's what you are asking. Indeed, that is why there is an issue. The JDK may not be using JNF, but library developers still use it. The JDK replacement for JNF is not supported for use outside t

Re: jpackage - notarizing

Well, if you look at the JNF part of the tree, the only include I see that comes from the JDK is jni.h. Isn’t that what you were questioning? > On Nov 22, 2021, at 10:06 AM, Michael Hall wrote: > > > >> On Nov 22, 2021, at 11:59 AM, Alan Snyder > <mailto:javali

Re: jpackage - notarizing

I’m talking about the Xcode project for JNF. > On Nov 22, 2021, at 9:54 AM, Michael Hall wrote: > > > >> On Nov 22, 2021, at 11:44 AM, Alan Snyder wrote: >> >> JNF is just an Objective-C library that uses jni.h. Otherwise, it is not >> dependent on the J

Re: jpackage - notarizing

JNF is just an Objective-C library that uses jni.h. Otherwise, it is not dependent on the JDK. > On Nov 22, 2021, at 9:23 AM, Michael Hall wrote: > > > >> On Nov 22, 2021, at 10:40 AM, Alan Snyder wrote: >> >> I’m still hoping someone will step up to p

Re: jpackage - notarizing

I’m still hoping someone will step up to provide a home for the compiled JavaNativeFoundation framework. In any case, the sources are available and you can build it yourself. https://github.com/apple/openjdk.git > On Nov 22, 2021, at 7:15 AM, Michael Hall wrote: > > In order to use JavaNative

Re: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem

> On Oct 27, 2021, at 9:28 AM, Mandy Chung wrote: > >>> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The >>> libraries are no longer present on the filesystem. >>> `NativeLibraries::loadLibrary` checks for the file existence before calling >>> `JVM_LoadLibrary`.

Re: what does the spec say about file paths that are too long?

> On Aug 26, 2021, at 8:57 AM, Alan Bateman wrote: > > On 26/08/2021 15:43, Alan Snyder wrote: >> As I said, I think it's great that we agree an exception should be thrown >> when an over-length path is used in an actual file operation. >> >> However,

Re: what does the spec say about file paths that are too long?

n Aug 26, 2021, at 3:39 AM, Alan Bateman wrote: > > On 25/08/2021 23:12, Alan Snyder wrote: >> Lacking any new data, I guess it is fair to assume that there is no >> specification for the behavior of methods that use file paths that are too >> long, and presumably no t

Re: what does the spec say about file paths that are too long?

. A case can be made for distinguishing this error from general IOExceptions because it is repeatable and explainable, unlike the general IOException. Thoughts? Alan > On Aug 20, 2021, at 7:05 AM, Alan Snyder wrote: > > Where did I say that I was seeing silent truncation

Re: [External] : Re: JPackage and ask for microphone permissions broken on OSX...

Good to hear! > On Aug 25, 2021, at 7:35 AM, Andy Herrick wrote: > > > On 8/25/2021 9:40 AM, Alan Snyder wrote: >> >> >>> On Aug 24, 2021, at 6:52 AM, Andy Herrick >> <mailto:andy.herr...@oracle.com>> wrote: >>> >>> One final

Re: JPackage and ask for microphone permissions broken on OSX...

> On Aug 24, 2021, at 6:52 AM, Andy Herrick wrote: > > One final thing to note, MacOS keeps track of what you have ever previously > granted microphone permission to (and will never ask again) based on the mac > package identifier (which defaults to the main class name), so I explicitly > s

Re: what does the spec say about file paths that are too long?

Where did I say that I was seeing silent truncation? My question is about the specification. I want to know if I should write code that defends against silent truncation. I should be writing code based on the specification, not what I observe in a test program on a particular platform. I’m ple

what does the spec say about file paths that are too long?

I’ve been looking for some specification of what happens when a file request is made using a path that is too long (whatever that means to the underlying system). I have not found one. Is there one? My opinion is that silent truncation should not happen. Instead, an exception should be thrown.

Re: RFR: 8272137: Make Collection and Optional classes streamable [plug for Extensible interface]

This provides an opportunity for me to promote what I believe is a much more important missing interface, namely, an interface that supports a semantic replacement for type casting. Using type casting (instanceof) is a really bad way to test an object for an optional capability. The reason is

Re: RFR: 8272137: Make Collection and Optional classes streamable

Ah, if only one could define a type alias Streamable = Supplier>... > On Aug 15, 2021, at 8:42 PM, Tagir F.Valeev wrote: > > On Mon, 9 Aug 2021 12:28:23 GMT, CC007 > wrote: > >> create Streamable and ParallelStreamable interface and use them in >> Collection and Optional > > Mostly agreed w

Re: jpackage OS/X JDK-8263157 fix regressed out

Why is a directory named “app” used for dynamic libraries instead of the conventional directory “Frameworks”? Alan > On Jul 22, 2021, at 11:04 AM, Michael Hall wrote: > > > >> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk >> wrote: >> >> The fix for JDK-8263157 cleared the default val

Re: JEP draft: Scope Locals

would be less confusing if “Scope Locals” instead were called “Scoped Thread Locals”. > On May 14, 2021, at 1:28 AM, Andrew Haley wrote: > > On 5/13/21 4:59 PM, Alan Snyder wrote: >> >> >>> On May 13, 2021, at 2:03 AM, Andrew Haley wrote: >>> &g

Re: JEP draft: Scope Locals

> On May 13, 2021, at 2:03 AM, Andrew Haley wrote: > > On 5/12/21 8:12 PM, Alan Snyder wrote: >> From the motivation section: >> >>> So you want to invoke a method |X| in a library that later calls back into >>> your code. In your callback you need

Re: JEP draft: Scope Locals

From the motivation section: > So you want to invoke a method X in a library that later calls back into your > code. In your callback you need some context, perhaps a transaction ID or > some File instances. However, X provides no way to pass a reference through > their code into your callback.

Re: ReversibleCollection proposal

It sounds like the items processing maintainer would be looking for OrderedCollection and might or might not find ReversibleCollection. :-) I suspect you would agree that OrderedCollection by itself is too weak to justify being a type. It’s basically Iterable with the extra bit that the iterati

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

On Apr 21, 2021, at 11:40 AM, Alan Bateman wrote: > > Sure, if you are using native code then you have the full power of JVM TI and > JNI available. Project Panama is exploring how to restrict access to native > code, I think too early to say how this might extend to JNI. I looked at some of t

Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version

> On Dec 2, 2020, at 12:22 PM, Phil Race wrote: > > On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov wrote: > >>> Surely these days you can just call [NSProcessInfo operatingSystemVersion] >>> directly ? >>> If I read the doc below it is in the 10.10 SDK and later. >>> https://developer.apple.com

Re: RFR: 8180352: Add Stream.toList() method

> On Nov 8, 2020, at 3:32 AM, fo...@univ-mlv.fr wrote: > > It's a strawman but the effect is real, the more interfaces you have the less > you can reuse code because the code is written with the wrong interface for > your use case. There are points of compromise. If someone can accept misbe

Re: RFR: 8180352: Add Stream.toList() method

>> This discussion of unmodifiable lists brings me back to the thought that >> there would be good client-side reasons for inserting an UnmodifiableList >> interface as a parent of LIst > On Nov 6, 2020, at 1:14 AM, Remi Forax > wrote: > > > This question is asked at l

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Do you believe that Set.equals() should behave this way on SortedSets? > On May 20, 2020, at 11:23 AM, Jason Mehrens wrote: > > public class SetEquals { > >public static void main(String[] args) { >Comparator cc = String.CASE_INSENSITIVE_ORDER; >Set s1 = new TreeSet<>(cc); >

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

You have said: I'm trying to fix semantic bugs in the way various collection operations handle situations with mixed membership semantics I believe this statement is misleading and is at the root of our apparently irreconcilable differences. Many if not most of the problematic examples of mi

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

> HashSet/TreeSet could do what ConcurrentHashMap/ConcurrentSkipListSet do by > using the "this contains that and that contains this" logic. Yes, at the cost of yet another performance regression. But how about this problem: Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new TreeSet<>(

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

You must have misunderstood. Even so, a snarky answer is uncalled for. The specification of Object.equals() is violated by the example, but that outcome would be *required* by your version of the specification of Set.equals(). Do you really think that the specification of Object.equals() is uni

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

But what kind of instance should be created by Set.copyOf? > On May 12, 2020, at 2:30 PM, Stuart Marks wrote: > > > > On 5/9/20 7:48 PM, Alan Snyder wrote: >> A small point… you might want to reconsider your analysis of Set.copyOf(), >> as it is a static meth

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

> On May 8, 2020, at 1:49 PM, Stuart Marks wrote: > > The containsAll() and equals() methods both use the membership contract of > the receiver, not the argument. Unfortunately, the equals() specification > says, > >Returns true if the specified object is also a set, the two sets have t

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

A small point… you might want to reconsider your analysis of Set.copyOf(), as it is a static method and there is no receiver.

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

> On May 8, 2020, at 6:46 PM, Jason Mehrens wrote: > > Given this has been around since JDK 1.3 would it be safe to assume that code > that is mixing collections with different membership semantics is already > working around this issue and therefore the risk is a bit lower in changing > th

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

; > > On 5/6/20 5:05 PM, Alan Snyder wrote: >> Let me clarify. I was referring to the non-support by the framework, which >> restricts membership semantics: >> ...[specification text regarding equals()]... > > OK, thanks for the clarification. > >> Altho

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

> On May 6, 2020, at 2:08 PM, Stuart Marks wrote: > > > > On 5/4/20 6:44 PM, Alan Snyder wrote: >> What problem are you trying to solve? >> The Collections framework explicitly does not support custom membership >> semantics. If you think it should, file an

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

What problem are you trying to solve? The Collections framework explicitly does not support custom membership semantics. If you think it should, file an RFE and create a JEP. It’s not a small change and tinkering is not the way to get there. If your present concern is performance surprises, be

Re: JEP 343: Packaging Tool

I haven’t used recent versions of this tool, but I have found it essential to be able to modify the image before the final package is created. There is no way that this tool can anticipate all of the custom configuration that might be needed, and I do not want to duplicate its ability to create

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

For the record, the performance change that concerns me involves the removal of a small number of elements from a large HashSet. Let’s say I want to remove three elements from a large HashSet. I could write target.remove(e1); target.remove(e2); target.remove(e3); or, if the elements were in a

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

specification is currently inconsistent. Alan > On May 20, 2019, at 3:57 PM, Stuart Marks wrote: > > On 5/16/19 10:06 PM, Alan Snyder wrote: >> Could you explain the inconsistency in the specification that affects >> removeAll()? I don’t see it. > > It's the assu

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

n't change the semantics? > > Here's a sketch of one: > - create a marker interface (could be JDK-internal) and mark all conforming > Set implementations with it > - use AbstractSet.removeAll optimization only when both collections implement > the marker interface &g

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Hi Stuart, I believe I already accepted the fact of ersatz Collections. Could you explain the inconsistency in the specification that affects removeAll()? I don’t see it. In the current specification, the classes that can create ersatz Collections all call out the ersatz Collections in their d

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Hi Stuart, I strongly disagree with this change. (Fortunately, I am not a Reviewer, just Opinionated.) Summary: 1. The change to removeAll() is a significant incompatible change because of its performance implications. 2. The benefit of the change to removeAll() is restricted to a few edge

Re: jpackage on macOS

all wrote: > > > >> On Apr 6, 2019, at 8:49 PM, Alan Snyder wrote: >> >> I have just tried using the latest jpackage release on macOS, after >> successfully using a very old sandbox version from long ago. >> Two command line argument names had to be changed,

jpackage on macOS

I have just tried using the latest jpackage release on macOS, after successfully using a very old sandbox version from long ago. Two command line argument names had to be changed, but otherwise the usage appears to be the same for my simple case of building a bundled app. However, the bundled app

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Also, if the upper bound is an expression, the range() approach makes it clear that the upper bound expression is intended to be evaluated once. > On Mar 11, 2019, at 4:07 PM, John Rose > wrote: > > P.S. I also saw the fiery objections to the range() idiom, and I

Re: JDK-6982173: Small problem causing thousands of wasted CPU hours

ey are getting all the objects that are members of the collection, but instead they are getting representative objects? Alan > On Feb 25, 2019, at 11:06 AM, Stuart Marks wrote: > > > > On 2/15/19 11:30 AM, Alan Snyder wrote: >> I think this situation is a mess. >>

Re: JDK-6982173: Small problem causing thousands of wasted CPU hours

2/14/19 9:30 AM, Alan Snyder wrote: >>> Care must be exercised if this method is used on collections that >>> do not comply with the general contract for {@code Collection}. >> So, what does this mean? Are we catering to incorrect implementations? > > I th

Re: JDK-6982173: Small problem causing thousands of wasted CPU hours

2/13/19 7:22 PM, Alan Snyder wrote: >> If we take this route, how about changing the parameter type to Iterable? > > Won't work. Where I've ended up is that we need to iterate over "this" > collection and, for each element, call contains() on the pa

Re: JDK-6982173: Small problem causing thousands of wasted CPU hours

If we take this route, how about changing the parameter type to Iterable? Alan > On Feb 13, 2019, at 7:12 PM, Stuart Marks wrote: > > Right, as I mentioned in my earlier emails [1][2] this is related to > JDK-6394757 [3] where the semantics shift depending on the relative sizes of > the c

Re: possible problem with JNI GetStringUTFChars

I don’t think that is correct. There are issues with whether and how file names are normalized when stored in a directory, and the answers are file system dependent. File system lookups are described as normalization-insensitive. I’m not an expert, though, and it is hard to find decent up-to-da

Re: possible problem with JNI GetStringUTFChars

If you search the JDK repo for GetStringUTFChars, you will find several uses that do not appear to involve serialization or data input/output. It is not obvious whether these uses are correct or not. Consider test/jdk/java/nio/channels/FileChannel/directio/libDirectIO.c where GetStringUTFChars

Re: possible problem with JNI GetStringUTFChars

In case you missed my previous message, there is a use case for file paths using macOS APIs. Alan > On Jan 28, 2019, at 2:10 PM, Stuart Marks wrote: > > I think it would be far too troublesome to try to migrate the JNI methods to > process real UTF-8 instead of modified UTF-8. That raises t

Re: possible problem with JNI GetStringUTFChars

aces throughout the Java SE > libraries, like java.io.DataInput/Output: > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/DataInput.html#modified-utf-8 > > > Today, in C++14, std::string supports embedding '\0' values, and is thus > much more UTF-8

Re: possible problem with JNI GetStringUTFChars

9 3:29 am, Alan Snyder wrote: >> My question was not about why it does what it does, but why it still does >> that. Is there a valid use of this primitive that depends upon it returning >> something other than true UTF-8? > > It still does what it does because that was how

Re: possible problem with JNI GetStringUTFChars

mes wrote: > > On 25/01/2019 4:39 am, Alan Snyder wrote: >> Thank you. That post does explain what is happening, but leaves open the >> question of whether GetStringUTFChars should be changed. >> What is the value of the current implementation of GetStringUTFChars versus >

Re: possible problem with JNI GetStringUTFChars

gt; docs): > https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni > > HTH > > /Claes > > On 2019-01-24 19:23, Alan Snyder wrote: >> I am having a problem with file names that contain emojis when passed to a >> macOS system call

possible problem with JNI GetStringUTFChars

I am having a problem with file names that contain emojis when passed to a macOS system call. Things work when I convert the path to bytes in Java, but fail (file not found) when I convert the path to bytes in native code using GetStringUTFChars. For example, where String.getBytes() returns -1

Re: enhanced for loop with multiple iteration variables

(int index, T element : Arrays.indexedElements(array)) { ... } Map.entrySet() is not a good test of performance since the Entry objects already exist and are returned without copying. Alan > On Jan 1, 2019, at 11:16 AM, Remi Forax wrote: > > - Mail original - >> D

Re: enhanced for loop with multiple iteration variables

. > }); > > Rémi > > - Mail original ----- >> De: "Brian Goetz" >> À: "Alan Snyder" , "core-libs-dev" >> >> Envoyé: Jeudi 20 Décembre 2018 23:50:15 >> Objet: Re: enhanced for loop with multiple iteration variables >

Re: enhanced for loop with multiple iteration variables

: map.entrySet()) { ... } > > and you're already there. > > > > On 12/19/2018 9:54 AM, Alan Snyder wrote: >> Has any consideration been given to supporting iterators that provide more >> than one iteration variable in the enhanced for loop? >> >> Obvio

enhanced for loop with multiple iteration variables

Has any consideration been given to supporting iterators that provide more than one iteration variable in the enhanced for loop? Obvious uses would be maps (keys and values) and lists (indexes and values). I have in mind keeping the syntactic sugar approach by using one or more extensions of th

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Can someone say whether the two-step package creation feature is implemented and explain how to use it? What is the plan for documentation? The command line help is inadequate. > On Oct 26, 2018, at 1:09 PM, Alan Snyder wrote: > > I noticed the following statement in the JEP: >

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I noticed the following statement in the JEP: In this latter case, the tool can either create a native package from a previously created application image, or it can create a native package directly. I cannot tell from the command summary whether this option has been implemented or not. Wit

PollingWatchService possible issue

I notice that PollingWatchService never checks the file key when it reads a directory to see if it is reading from the same directory that it started with. I suspect that creates a potential for incorrect behavior if the directory tree is rearranged (between polls) so that the original path acce