Re: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

OK - looks good. /Andy On 5/12/2020 11:42 AM, Alexey Semenyuk wrote: Changed the patch to try AddDllDirectory() first and alter PATH as the last resort. Webrev at [1] Log output: --- $ env JPACKAGE_DEBUG=true ./JTwork/scratch/output/test/test.exe [TRACE] applauncher.cpp:217: Entering AppLaunc

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 method and there is no receiver. > >

Re: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

Hi Alexey, Looks good. I do not see any issues with keeping code which alters PATH. I think it might be better to keep it, just in case. Thanks, Alexander On 5/12/2020 8:42 AM, Alexey Semenyuk wrote: Changed the patch to try AddDllDirectory() first and alter PATH as the last resort. Webrev a

Re: RFR: JDK-8244758,: DMG bundler ignores --install-dir option.

Hi Andy, Looks good. Thanks, Alexander On 5/12/2020 6:56 AM, Andy Herrick wrote: Please review jpackage fix for issue [1] at [2]. The change allows the specified --install-dir (instead of always /Applications) to be suggested for drag target of a DMG image. [1] - https://bugs.openjdk.java.

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

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 the    same size, and every member of the specified set is conta

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

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 method and there is no receiver. Of course there is no receiver. For static factory methods, and for constructors, I meant the newly created instance is the on

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

You say: The issue of membership semantics is part of the original design. I agree, but only to the point of identifying inconsistent membership semantics as a source of non-conformance. What is not part of the original design is allowing a broader range of membership semantics to be confo

Re: RFR: 8244855 : Remove unused "getParent" function from Windows jni_util_md.c

Ah, thanks. I meant to check that, then it slipped my mind. -Brent On 5/12/20 12:17 PM, naoto.s...@oracle.com wrote: Looks good, with the change to copyright year to "2020." Naoto On 5/12/20 12:12 PM, Lance @ Oracle wrote: +1 Best, Lance Lance Andersen| Principal Member of Technical Sta

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

On 5/8/20 6:46 PM, Jason Mehrens wrote: I assume Deque/Queue would suffer the same issue as List. It would be nice to some how ensure ArrayDeque.contains is not called as far as the heuristic goes. Looks like PriorityQueue uses equals for contains but that is not to say there are not othe

Re: RFR: 8244855 : Remove unused "getParent" function from Windows jni_util_md.c

Looks good, with the change to copyright year to "2020." Naoto On 5/12/20 12:12 PM, Lance @ Oracle wrote: +1 Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my

Re: RFR: 8244855 : Remove unused "getParent" function from Windows jni_util_md.c

+1 Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On May 12, 2020, at 3:05 PM, Brent Christian > wrote: > > Hi, > > Please review this change to

RFR: 8244855 : Remove unused "getParent" function from Windows jni_util_md.c

Hi, Please review this change to remove the unused "getParent()" function from jni_util_md.c on Windows. https://bugs.openjdk.java.net/browse/JDK-8244855 Automated build+test job is in progress. The diff is as follows: diff -r ee4bd700b772 src/java.base/windows/native/libjava/jni_util_md.c -

Re: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function

Looks okay to me. On 12/05/2020 19:46, Bob Vandette wrote: BUG: https://bugs.openjdk.java.net/browse/JDK-8244853 Please review this simple fix for JDK 15 which adds the required JNI_OnLoad_extnet function to the libextnet.a static library when it is built. the JDK 15 make static-libs-image t

RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function

BUG: https://bugs.openjdk.java.net/browse/JDK-8244853 Please review this simple fix for JDK 15 which adds the required JNI_OnLoad_extnet function to the libextnet.a static library when it is built. the JDK 15 make static-libs-image target currently builds this static library but it is not spec

Re: RFR: 8244767 - Potential non-terminated string in getEncodingInternal() on Windows

Thanks - change is pushed. -B On 5/11/20 5:26 PM, naoto.s...@oracle.com wrote: +1 Naoto On 5/11/20 5:25 PM, Brian Burkhalter wrote: Hi Brent, It looks OK to me. Brian On May 11, 2020, at 4:36 PM, Brent Christian wrote: Please review this small fix in Windows native code:    Bug: http

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. Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new ConcurrentHashMap().keySet(""); Set s2 = new ConcurrentSkipListSet<>(cc); s1.add("hell

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: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

Changed the patch to try AddDllDirectory() first and alter PATH as the last resort. Webrev at [1] Log output: --- $ env JPACKAGE_DEBUG=true ./JTwork/scratch/output/test/test.exe [TRACE] applauncher.cpp:217: Entering AppLauncher::launch [TRACE] applauncher.cpp:100: Launcher config file path: "C:

Re: RFR: JDK-8244758,: DMG bundler ignores --install-dir option.

Looks good. - Alexey On 5/12/2020 9:56 AM, Andy Herrick wrote: Please review jpackage fix for issue [1] at [2]. The change allows the specified --install-dir (instead of always /Applications) to be suggested for drag target of a DMG image. [1] - https://bugs.openjdk.java.net/browse/JDK-8244

Re: RFR(s): 8244659: Improve ZipFile.getInputStream

On 2020-05-12 16:07, Martin Buchholz wrote: On Tue, May 12, 2020 at 6:42 AM Claes Redestad mailto:claes.redes...@oracle.com>> wrote: Hi Volker, I think this look like a nice improvement! One high-level concern I have with the design is that this will add and retain (at l

Re: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

> Is the problem that by removing the copy of the microsoft dlls from the applications bin directory, then on machines that do not have all of these dll's already in the PATH (usually in C:\windows\system32) they can no longer be found ? Yes. > Is there a way you can link the launcher (e.g., s

Re: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result

Hi Andrew, Thanks for looking at this. On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote: > On 5/7/20 4:09 PM, Severin Gehwolf wrote: > > jvm_version_info.jvm_version currently holds this quadruplet: > > > > Most significant 8 bits => major version, followed by 8 bits => minor > > version, f

Re: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

I think that sorry if things is usually handled in an “Application Manifest” on Windows https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests Scott > On May 12, 2020, at 8:33 AM, Kevin Rushforth > wrote: > > Is there a way you can link the launcher (e.g., something simi

Re: RFR(s): 8244659: Improve ZipFile.getInputStream

On Tue, May 12, 2020 at 6:42 AM Claes Redestad wrote: > Hi Volker, > > I think this look like a nice improvement! > > One high-level concern I have with the design is that this will add and > retain (at least) one 64k buffer to each Jar-/ZipFile we've read a > stream from. We routinely see apps r

RFR: JDK-8244758,: DMG bundler ignores --install-dir option.

Please review jpackage fix for issue [1] at [2]. The change allows the specified --install-dir (instead of always /Applications) to be suggested for drag target of a DMG image. [1] - https://bugs.openjdk.java.net/browse/JDK-8244758 [2] - http://cr.openjdk.java.net/~herrick/8244758 /Andy

Re: RFR(s): 8244659: Improve ZipFile.getInputStream

Hi Volker, I think this look like a nice improvement! One high-level concern I have with the design is that this will add and retain (at least) one 64k buffer to each Jar-/ZipFile we've read a stream from. We routinely see apps reading classes from 100s of jar files on their class path, so this

Re: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result

On 5/7/20 4:09 PM, Severin Gehwolf wrote: > jvm_version_info.jvm_version currently holds this quadruplet: > > Most significant 8 bits => major version, followed by 8 bits => minor > version, followed by 8 bits => micro version, followed by 8 bits => > build version. Note that JVM minor version repr

Re: RFR(s): 8244659: Improve ZipFile.getInputStream

Sure, here it is: http://cr.openjdk.java.net/~simonis/webrevs/2020/8244659.01/ Fortunately, it still applies cleanly :) It also passed the zip-related JTreg tests and submit repo. On Mon, May 11, 2020 at 10:27 PM Lance Andersen wrote: > Hi Volker, > > Could you update your patch now that Claes

Re: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

Is there a way you can link the launcher (e.g., something similar to RPATH on Unix systems) to look in the right place relative to the launcher? Otherwise, the solution with adding to the PATH seems OK to me. -- Kevin On 5/12/2020 5:22 AM, Andy Herrick wrote: Is the problem that by removing t

Re: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

Is the problem that by removing the copy of the microsoft dlls from the applications bin directory, then on machines that do not have all of these dll's already in the PATH (usually in C:\windows\system32) they can no longer be found ? I don't like manually manipulating the PATH env variable e

Re: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java

Thanks for your comments. Below you can find a new web rev version that includes a test description in a comment: http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.01/ I will also create a JBS ticket to revisit this test and