Re: RFR 8241749: Remove the Nashorn JavaScript Engine

Thanks Mandy. I'll add bug id next to @ignore before push. Thanks, -Sundar On 16/04/20 2:50 am, Mandy Chung wrote: This looks okay to me. Can you add the bug ID next to @ignore that will make it easier to find the JBS issue?   These test bugs are filed with P4 but I think they should be

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

Thanks for spotting this Magnus! I'll fix this before push. Thanks. -Sundar On 15/04/20 10:44 pm, Magnus Ihse Bursie wrote: On 2020-04-15 17:56, sundararajan.athijegannat...@oracle.com wrote: Please review. Nashorn script engine modules (jdk.scripting.nashorn, jdk.scripting.nashorn.shell)

Re: RFR(S): 8242848: Improve performance of InflaterOutputStream.write()

Hi Volker, Thanks for doing this, i think the below code change is not required . Please do let me know if i am not reading it correctly. if (inf.finished() || (len == 0)/* no more input */) { If you check the native code "inf.finished() will be true only of the corresponding native call

Re: Some Classes with a public void close() don't implement AutoCloseable

Hi Joe, thanks for all the info. As I'm not yet familiar with the way how OpenJDK is developed, mind if I ask what steps would have to be taken to add Closeable to javax.naming.Context? The first thing would be to create a patch, test it, run the tests. Then the change has to be proposed, and

Re: Some Classes with a public void close() don't implement AutoCloseable

Hi Johannes, FYI, back during Project Coin during JDK 7, there were various systematic efforts to review types with a "close" method in the JDK and retrofit AutoCloseable where appropriate:     JDK-6911261: Project Coin: Retrofit Automatic Resource Management (ARM) support onto platform

Some Classes with a public void close() don't implement AutoCloseable

After failing to wrap a XMLStreamReader in a try-with-resources after discovering it's close() method, I thought about checking what other classes have a public void close() method in the JDK but don't implement AutoCloseable. So I wrote a small program that enumerates all classes present in

Re: RFR: JDK-8232935: jpackage failed with NPE whenever --file-associations provided

Hi Alexey, Updated webrev looks fine. Thanks, Alexander On 4/15/20 1:43 PM, Alexey Semenyuk wrote: On 4/15/2020 4:21 PM, Alexander Matveev wrote: Hi Alexey,

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

This looks okay to me. Can you add the bug ID next to @ignore that will make it easier to find the JBS issue?   These test bugs are filed with P4 but I think they should be fixed in 15. Mandy On 4/15/20 8:56 AM, sundararajan.athijegannat...@oracle.com wrote: Please review. Nashorn script

Re: RFR: JDK-8232935: jpackage failed with NPE whenever --file-associations provided

On 4/15/2020 4:21 PM, Alexander Matveev wrote: Hi Alexey, http://cr.openjdk.java.net/~asemenyuk/8232935/webrev.00/src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources.properties.frames.html Line 58-59: I think we do not need "." at the end of

Re: RFR: JDK-8232935: jpackage failed with NPE whenever --file-associations provided

Hi Alexey, http://cr.openjdk.java.net/~asemenyuk/8232935/webrev.00/src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources.properties.frames.html Line 58-59: I think we do not need "." at the end of error messages to make it same as other messages. Do

RFR: JDK-8242302 : Refactor jpackage native code

Please review fix [2] for jpackage bug [1]. Refactor jpackage native code. - Improve code reuse between different platforms. - Replace custom string classes with the standard std::basic_string. - Merge functionality of libapplauncher.dll(.so) library with jpackageapplauncher(.exe) binary.

Re: RFR: JDK-8232935: jpackage failed with NPE whenever --file-associations provided

ok - looks good. /Andy On 4/15/2020 4:10 PM, Alexey Semenyuk wrote: I've updated the webrev. No more unexpected changes. - Alexey On 4/15/2020 3:18 PM, Alexey Semenyuk wrote: On 4/15/2020 2:36 PM, Andy Herrick wrote: The change looks good, but I am confused why Japanese and Chinese

Re: RFR: JDK-8232935: jpackage failed with NPE whenever --file-associations provided

I've updated the webrev. No more unexpected changes. - Alexey On 4/15/2020 3:18 PM, Alexey Semenyuk wrote: On 4/15/2020 2:36 PM, Andy Herrick wrote: The change looks good, but I am confused why Japanese and Chinese MainResources property files show a lot of changes that seem to be no

Re: RFR: JDK-8232935: jpackage failed with NPE whenever --file-associations provided

On 4/15/2020 2:36 PM, Andy Herrick wrote: The change looks good, but I am confused why Japanese and Chinese MainResources property files show a lot of changes that seem to be no change. Good catch. Seems like my text editor replaced upper case letters in character codes with lower case

Re: jpackage and macOS Catalina notarization

Update on notarization of jpackage artifacts: Changes have been made (as part of JDK-8237490 ) that enable notarization of dmg files and zipped app-images assembled and signed using jpackage tool. Given that, the current package layout on

Re: RFR: JDK-8232935: jpackage failed with NPE whenever --file-associations provided

The change looks good, but I am confused why Japanese and Chinese  MainResources property files show a lot of changes that seem to be no change. On 4/15/2020 2:13 PM, Alexey Semenyuk wrote: Please review fix [2] for jpackage bug [1]. Move function checking values of mime types in file

Re: Need sponsor to fix Javadoc warnings

Thanks Pavel, I will keep this in mind for future patches. > On Apr 15, 2020, at 10:22 PM, Pavel Rappo wrote: > > Vipin, > > After a private exchange with Naoto Sato, who is fluent in that area, I > decided > to leave out all the changes to the jdk.internal.icu package from the > changeset.

Re: RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size

Hi Philipp, Thanks for the update. I like you enriched the RegExTest.java. Two nits: - RegExTest.java at line 4805: I'd use parentheses for this return statement. - PatternBench.java should keep the original copyright year, i.e., "2020," -> "2019, 2020," Otherwise, it looks good. Naoto

RFR: JDK-8232935: jpackage failed with NPE whenever --file-associations provided

Please review fix [2] for jpackage bug [1]. Move function checking values of mime types in file associations from Linux to shared code. Added jtreg tests to cover use cases when no or multiple mime types are specified for file associations. - Alexey [1]

RFR(S): 8242848: Improve performance of InflaterOutputStream.write()

Hi, can I please have a review for the following simple performance enhancement: http://cr.openjdk.java.net/~simonis/webrevs/2020/8242848/ https://bugs.openjdk.java.net/browse/JDK-8242864 InflaterOutputStream has an internal buffer which is used for the inflated data. This buffer can be

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

On 2020-04-15 17:56, sundararajan.athijegannat...@oracle.com wrote: Please review. Nashorn script engine modules (jdk.scripting.nashorn, jdk.scripting.nashorn.shell) and jjs tool are removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8241749 JEP: https://openjdk.java.net/jeps/372 CSR:

Re: Need sponsor to fix Javadoc warnings

Vipin, After a private exchange with Naoto Sato, who is fluent in that area, I decided to leave out all the changes to the jdk.internal.icu package from the changeset. The reason is quite simple. A significant portion of code in jdk.internal.icu comes from an upstream project, ICU4J. Making

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

+1 > On Apr 15, 2020, at 12:56 PM, sundararajan.athijegannat...@oracle.com wrote: > > Please review. > > Nashorn script engine modules (jdk.scripting.nashorn, > jdk.scripting.nashorn.shell) and jjs tool are removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241749 > > JEP:

RFR 8241749: Remove the Nashorn JavaScript Engine

Please review. Nashorn script engine modules (jdk.scripting.nashorn, jdk.scripting.nashorn.shell) and jjs tool are removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8241749 JEP: https://openjdk.java.net/jeps/372 CSR: https://bugs.openjdk.java.net/browse/JDK-8241751 Webrev:

Re: RFR: 8242842: Avoid reallocating name when checking for trailing slash in ZipFile.getEntryPos

Lance, Alan, thanks for reviewing! I think there's more things we can improve in this area, but will move ahead carefully. /Claes On 2020-04-15 15:52, Alan Bateman wrote: On 15/04/2020 13:58, Claes Redestad wrote: Hi, a trivial optimization to ZipFile.getEntryPos extracted from some

Re: RFR: 8242842: Avoid reallocating name when checking for trailing slash in ZipFile.getEntryPos

On 15/04/2020 13:58, Claes Redestad wrote: Hi, a trivial optimization to ZipFile.getEntryPos extracted from some experiments conducted mostly by Eirik Bjørsnøs. Webrev: http://cr.openjdk.java.net/~redestad/8242842/open.00/ Bug:    https://bugs.openjdk.java.net/browse/JDK-8242842 This

Re: RFR: 8242842: Avoid reallocating name when checking for trailing slash in ZipFile.getEntryPos

Hi Claes, I think this looks good overall. Vwar LNXW > On Apr 15, 2020, at 8:58 AM, Claes Redestad wrote: > > Hi, > > a trivial optimization to ZipFile.getEntryPos extracted from some > experiments conducted mostly by Eirik Bjørsnøs. > > Webrev:

RFR: 8242842: Avoid reallocating name when checking for trailing slash in ZipFile.getEntryPos

Hi, a trivial optimization to ZipFile.getEntryPos extracted from some experiments conducted mostly by Eirik Bjørsnøs. Webrev: http://cr.openjdk.java.net/~redestad/8242842/open.00/ Bug:https://bugs.openjdk.java.net/browse/JDK-8242842 This removes an extra array copy on every miss, and the

Re: Need sponsor to fix Javadoc warnings

Vipin, I saw that Max had already reviewed that incremental patch. That's good. I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu (International Components for Unicode) package. Once this has been cleared by experts in that area, we are good to go. Here's the

Re: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable

Thanks, Paul and John, for the CSR reviews. Please find the latest version of the patch here: http://cr.openjdk.java.net/~jvernee/8241100/webrev.04/index.html Jorn On 14/04/2020 18:18, Jorn Vernee wrote: Hi David, Thanks for the heads up! A CSR for this patch was created here:

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

* Florian Weimer: > * Mark Kralj-Taylor: > >> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME) >> should be supported if the clock_gettime() API exists. But other clock >> sources are not mandatory. > > Really old glibc emulates clock_gettime (CLOCK_REALTIME) using >

Re: Improving ZipFile.getEntry performance using Bloom filters

> > Unfortunately, this is going to be the reality for a many existing and > new apps. Most production Java apps are built from many library jars. > Java is the biggest 'divide and conquer' programming eco-system we have > ever seen in the history of computing. Andrew, Thanks for providing some

Re: Improving ZipFile.getEntry performance using Bloom filters

On 14/04/2020 23:34, Ioi Lam wrote: > I am a little worried adding extra overhead unconditionally into the JAR > reader that people may not need/want. A reasonable worry. We should always try to avoid fixes that benefit a majority if they 'punish' a minority . . . > Maybe we should take a step