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 >

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

I believe I can agree with you on a number of points. • The specification is confusing. • The problem areas involve the “membership contract”. • There may have been some intent initially to support multiple membership semantics (this was new to me). • There are

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

Stuart, 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 other queue implementations in the wild

Re: JDK-8226810: An other case and a small change suggestion

Thanks. I think strcpy(ret+2, "1252") vs. strcpy(ret, "Cp1252")  is a just matter of style. I would prefer the later, as it makes the intent clear. But not my call. Do you have any info how I can change the detected codepage there? I wrote a small C program that basically just does that part

Re: RFR: JDK-8244620: test failure in WinUpgradeUUIDTest

Revised webrev at [3] - this fixes the test problem that was caused by the test assuming wix tools are on all systems. /Andy [3] - http://cr.openjdk.java.net/~herrick/8244620/webrev.02/ On 5/7/2020 4:23 PM, Andy Herrick wrote: please review fix for issue [1] at [2]. /Andy [1] -

Re: JDK-8226810: An other case and a small change suggestion

On 5/7/20 5:50 AM, Alan Bateman wrote: On 07/05/2020 12:37, Johannes Kuhn wrote: : In the end, I don't know what causes the bug, or how I can replicate it. I think I did find a likely suspect. > Good sleuthing. I don't what the conditions are for GetLocaleInfo to fail but it does look like

Re: JDK-8226810: An other case and a small change suggestion

Hi Johannes, On 5/8/20 1:37 PM, Johannes Kuhn wrote: Thanks. I think strcpy(ret+2, "1252") vs. strcpy(ret, "Cp1252")  is a just matter of style. I would prefer the later, as it makes the intent clear. But not my call. I thought the former was clearer, as at that point, Cp/MS/GB part is not

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. Although the framework provides implementation classes that MAY

Re: RFR: 8244624: Improve handling of JarFile META-INF resources

I updated open.01 with a reworked microbenchmark that uses JarFile.getInputStream to trigger the "maybe instantiate the JAR verifier" logic. This exercise the code being optimized in this patch better, while also being a little bit more realistic. Improvements around 1.3x-1.5x across tested jar

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

Hi Fernando, While you add the comment (about compile/run), you may want to update the original comment about the test as well as it mentioned "see run.sh" that is now gone. A minor comment on the header:  a space between the years would be good, that is "2014,2020," -> 2014, 2020, -Joe

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

Hi, Philipp. Sorry for the further delay. Just to step back a bit: The current manifest-writing behavior dates back to JDK 1.2 (at least), so compatibility is an overriding concern. It is unfortunate that multi-byte characters weren't better accounted for in the placement of line breaks

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

Sure, I will add some of the explanation as a comment. Thank you Daniel! > On 8 May 2020, at 18:39, Daniel Fuchs wrote: > > Hi Fernando, > > Ah - I see the keypoint is the: > 39 * @clean org.w3c.dom.* > OK, I missed that. Then I agree - ignore my previous comments. > > Maybe the

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

Hi Fernando, Ah - I see the keypoint is the: 39 * @clean org.w3c.dom.* OK, I missed that. Then I agree - ignore my previous comments. Maybe the explanations below should be added to the test in some comment to help future maintainers (and reviewers). best regards, -- daniel On 08/05/2020

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

Hi Daniel and Alan, @compile/module=java.xml was my first try, but for the nature of this test, it didn't work. The reason is that the original shell test does the following: - Compiles it’s own version of Node and Document interfaces - Compiles DocumentImpl patching java.xml with those 2

Re: JDK-8226810: An other case and a small change suggestion

Ditto. Good catch! I am not sure the fix would address the issue in 8226810 (cannot confirm it either, as my Windows box is at my office where I cannot enter at the moment :-), but this definitely looks like a bug. I would change the additional line to "strcpy(ret+2, "1252");" as Cp is copied

RFR(s): 8244659: Improve ZipFile.getInputStream

Hi, can I please have a review for the following small enhancement which improves the speed of reading from ZipFile.getInputStream() by ~5%: http://cr.openjdk.java.net/~simonis/webrevs/2020/8244659/ https://bugs.openjdk.java.net/browse/JDK-8244659 ZipFile.getInputStream() tries to find a good

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

On 08/05/2020 15:40, Alan Bateman wrote:   31 /*   32  * @test   33  * @bug 8035437   34  * @summary Tests that java.lang.AbstractMethodError is not thrown when   35  * serializing improper version of DocumentImpl class.   36  * @library /test/lib   * @modules javax.xml/org.w3c.dom   * 

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

On 08/05/2020 15:16, Daniel Fuchs wrote: : then:   31 /*   32  * @test   33  * @bug 8035437   34  * @summary Tests that java.lang.AbstractMethodError is not thrown when   35  * serializing improper version of DocumentImpl class.   36  * @library /test/lib   * @modules

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

Hi Fernando, I believe that if you simply move the patched file under a directory named javax.xml, then you can get rid of all the @compile in the test. Starting from your patch: cd test/jdk/javax/xml/jaxp/common/8035437 mkdir java.xml hg move org javax.xml hg move com javax.xml then: 31

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

Hi all, Please, review the following change: webrev: http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.00/ Testbug: https://bugs.openjdk.java.net/browse/JDK-8209774

Re: RFR: 8244624: Improve handling of JarFile META-INF resources

Hi Max, On 2020-05-08 09:08, Weijun Wang wrote: JarFile.java: 734: extra new line? Fixed 930: Remove or rewrite the comment. Did even better: now that I find the position of the manifest during initCEN, this method should always call JUZFA.getManifest(this, false); - which is both a

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

On 2020-05-07 23:27, Mikael Vidstedt wrote: On May 7, 2020, at 7:52 AM, Kumar Srinivasan wrote: Hi Mikael, I may have created solinux when the macosx port was merged and in an effort to reduce the CPP conditionals. solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has

Re: RFR: 8244624: Improve handling of JarFile META-INF resources

JarFile.java: 734: extra new line? 930: Remove or rewrite the comment. ZipFile.java: 49: seems not used Please add links to each other between src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java::isBlockOrSF and

Re: Was functional-Try already discussed?

I realized it may still not be clear! Sorry, My dream Try would be something like this: ``` import static java.util.Try.on; import static java.util.Try.safe; private Bar convert (Foo foo) throws ConversionException { ... } Stream foos; Stream bars =