April 2021 - core-libs-dev

RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations
by Sandhya Viswanathan 10 May '21

10 May '21

All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin). Changes include: * Rewrite Vector API slice/unslice using already intrinsic methods * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails * Vector API conversion tests thresholds adjustment Base Performance: Benchmark (size) Mode Cnt Score Error Units TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ± 254.580 ops/ms TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ± 326.770 ops/ms TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ± 22.060 ops/ms TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ± 220.340 ops/ms TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ± 231.703 ops/ms Performance with patch: Benchmark (size) Mode Cnt Score Error Units TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ± 37.296 ops/ms TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ± 115.886 ops/ms TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ± 8.203 ops/ms TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ± 43.637 ops/ms TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ± 13.376 ops/ms ------------- Commit messages: - 8265128: [REDO] Optimize Vector API slice and unslice operations Changes: https://git.openjdk.java.net/jdk/pull/3804/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265128 Stats: 886 lines in 44 files changed: 175 ins; 518 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/3804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3804/head:pull/3804 PR: https://git.openjdk.java.net/jdk/pull/3804

3 20

RFR: 8265208: [JEP-356] : SplittableRandom and SplittableGenerators - splits() methods does not throw NullPointerException when source is null
by Jim Laskey 10 May '21

10 May '21

Add check for null. ------------- Commit messages: - Check for null source - Make makeXXXSpliterator final - Move makeXXXSpilterator from public (@hidden) to protected. No API change. Changes: https://git.openjdk.java.net/jdk/pull/3495/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3495&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265208 Stats: 178 lines in 4 files changed: 28 ins; 131 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3495.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3495/head:pull/3495 PR: https://git.openjdk.java.net/jdk/pull/3495

2 3

Proposal to add JavaScript platform to jpackage
by Andrew Oliver 10 May '21

10 May '21

Below is a Java Enhancement Proposal for your consideration to add JavaScript to jpackage as a new target platform. I would appreciate feedback on the proposal contents. I am also interested in learning about the process, specifically what approvals are required prior to start of implementation, should sufficient consensus be reached. ( To view this proposal as a web page, please visit: https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html ) Thank you! -Andrew Oliver Title: Add JavaScript platform to jpackage Author: Andrew Oliver Created: 2021/04/24 Type: Feature State: Draft Exposure: Open Component: tools/jpackage Scope: JDK Discussion: core-libs-dev(a)openjdk.java.net Template: 1.0 Summary ------- jpackage already allows packaging Java applications for several platforms. This proposal adds a new platform: JavaScript. This effort will enable jpackage to convert bytecode from the provided classes into JavaScript, and generate the required HTML to invoke the specified main method when opened in a web browser. These files will be bundled into a WAR file for easy deployment. Goals ----- * Enabling JVM languages to build client-side web applications * Allow easy generation of JavaScript from JVM bytecode * Allow easy deployment and execution of generated JavaScript in web browsers * Allow easy deployment of the generated JavaScript in all web server environments * Java web application container (like Tomcat) * Static file web servers * Static file web hosting services Non-Goals --------- * Allowing execution of JavaScript server-side. (Java already has numerous options for executing bytecode server-side.) Motivation ---------- Java was once used to create client-side web applications via applets that could be launched by visiting a web page. Applets could draw on an area of the screen (like HTML5 Canvas) or manipulate the page DOM to create dynamic front-end applications (like JS single-page apps). However, as evident in JEP 398 ([ https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)) applets are no longer feasible due to the actions of browser vendors. While browsers have lost the ability to execute Java bytecode or invoke methods from the Java class libraries, they do have mature engines for executing a different sort of code (JavaScript) and an extensive list of useful APIs. By converting class files to JavaScript, and providing mechanisms to invoke browser APIs, Java can again be used to create in-browser applications. [TeaVM](https://teavm.org) has demonstrated that this is feasible and has numerous benefits: * Provides a strongly-typed language for client-side web development * Provides a wealth of IDEs, build tools, and testing tools for client-side web development * Allows teams with Java experience to produce apps with familiar technology * Allows sharing of POJO and business logic classes, simplifying development * Allows options for porting applet- and JNLP-based systems to present-day browsers Details ------- An additional jpackage option for type will be added: `js` jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java code to JavaScript, with the main class compiled to a JavaScript method called 'main()'. jpackage bundles application code, runtime, and resources into a platform-specific format. For this new JavaScript type, the layout will be either a ZIP file or a standard WAR file. The ZIP format will contain the files ready to be extracted to a static file webserver or HTML hosting service. Generated WARs will have the required structure to be deployable in a Java web application container. ### WAR layout * HelloApp.war * index.html (Main application page, loads classes.js and invokes main()) * teavm * classes.js (Class files, templates, and resources compiled to JavaScript) * css * (CSS files from application) * META-INF * MANIFEST.MF * WEB-INF * web.xml ### ZIP Layout * HelloApp.zip * index.html (Main application page, loads classes.js and invokes main()) * teavm * classes.js (Class files, templates, and resources compiled to JavaScript) * css * (CSS files from application) Basic usage: Non-modular applications ------------------------------------- Command-line usage is similar to jpackage today, except you use the `--type js`. For example, if you have your application JARs in a folder called `lib` and the JAR with the declared `main()` method is `main.jar`, you could use this command: ``` $ jpackage --type js --name myapp --input lib --main-jar main.jar ``` This will produce `myapp.war` in the current directory. This is a standard WAR file ready for deployment in any web application container (like Tomcat). When myapp/index.html is opened in a browser, the code in main() will be executed, in-browser. A typical Hello World main() method like ``` public static void main(String args\[\]) { System.out.println("Hello, Browser!"); } ``` will print the message on the browser developer console. Processing ---------- Conversion of the input JAR files to the classes.js file will be done by TeaVM. It will * Convert provided class files to JavaScript * Expose the specified main method as main() * Provide implementation of selected core Java classes that function in a browser environment * Bundle resources into the generated JavaScript * Include images, css, and web.xml in the generated package, if provided * Provide default index.html if omitted * Provide default web.xml if omitted and WAR format specified * Optionally minify the generated JavaScript ### js-specific options 1. `--minify`: Perform a minification pass after generating JavaScript, renaming classes and methods to short, generated names to reduce download sizes and provide some obfuscation. 2. `--debug`: Enable generation of source maps. 3. `--debug-full`: Enable generation of source maps and bundled source files. 4. `--optimization`: Choose simple, advanced, or full. * simple: Perform only basic optimizations * advanced: Perform more optimizations. Recommended for production. * full: Perform aggressive optimizations. Increases compilation time. 5. `--timezone-support`: Enables timezone support, at the cost of increased application size 6. `--locale-list`: Add extra locales via a list, at the cost of increased application size. Format: comma-separated list of locale IDs like "en\_US, ru\_RU" ### Unsupported options for the JavaScript type These options are unsupported for `--type js` * `--file-associations`: Not yet meaningful for a web-based app, though it may be in the future once PWAs support file types: [ https://github.com/WICG/file-handling](https://github.com/WICG/file-handlin… * `--app-version, --copyright, --description, --license-file, --vendor`: jpackage will only support --name initially. Users can customize index.html (and the rest of the application) to show branding and metadata as desired. * `--java-options`: Not yet supported, use `--arguments` instead. Caveats ------- Certain Java classes are not feasible to implement in a browser setting. Socket, for example, is not useful in a browser since JavaScript cannot open arbitrary socket connections. Code using unavailable classes will fail during packaging time with warnings about the missing classes. Testing ------- Since TeaVM is Java-based, tests will be able to run on any platform. Testing will focus on the new jpackage code and added functionality. Tests will confirm that when valid parameters are provided, that output is generated with the right name and in the right folder. Contents of the generated ZIP and WAR files will be checked for the presence of expected files. Testing generated files in a browser will be done manually. A thorough test of TeaVM itself is out of scope for the jpackage testing. This is in line with jpackage testing for other platforms, in which the external packaging tool (like Wix on Windows) isn't exhaustively tested. Dependencies ------------ The jpackage `js` type will require TeaVM binaries to be present. Implementation options: * Download TeaVM on-demand and cache it. (This is the likely option.) * Look for TeaVM in local repositories for popular build tools like Maven and Gradle * If not found locally, download TeaVM binaries from the read-only central repository and store in the cache folder * Invoke TeaVM from the local repository or cache * Require that TeaVM binaries be installed locally * Provide the path to TeaVM binaries on the command line * Bundle TeaVM * Challenging due to incompatible licenses (Apache v2 vs. GPL v2 with CPE) * Probably unnecessary given the options above. Other jpackage options require pre-installed tools, this will be no different. High-Level Design ----------------- A new bundler will be added to the jpackage Java source code. It will first ensure that TeaVM binaries (JAR files) are available locally, as described in the section above. The new bundler will use TeaVM's TeaVMRunner ([ https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/o…) which conveniently accepts options similar to jpackage itself. TeaVMRunner will do the heavy lifting of converting the application JAR files and resources into `classes.js`. The bundler will provide additional files required to make a web application, including an `index.html` to launch the `main()` method. The bundler will create the final archive (ZIP or WAR) using Java's ZipOutputStream. For the WAR format, the bundler will also add `web.xml` and `MANIFEST.MF` if not present to create a deployable, standard WAR file.

3 5

RFR: 8266168: -Wmaybe-uninitialized happens in check_code.c
by Yasumasa Suenaga 06 May '21

06 May '21

We can see following compiler warning in check_code.c on GCC 11. ------------- Commit messages: - 8266168: -Wmaybe-uninitialized happens in check_code.c Changes: https://git.openjdk.java.net/jdk/pull/3787/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3787&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266168 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3787/head:pull/3787 PR: https://git.openjdk.java.net/jdk/pull/3787

2 3

RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files
by Alexander Matveev 04 May '21

04 May '21

jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. ------------- Commit messages: - 8266179: [macos] jpackage should specify architecture for produced pkg files Changes: https://git.openjdk.java.net/jdk/pull/3807/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266179 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3807.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3807/head:pull/3807 PR: https://git.openjdk.java.net/jdk/pull/3807

4 20

RFR: JDK-8266227: Fix help text for --mac-signing-keychain
by Andy Herrick 04 May '21

04 May '21

JDK-8266227: Fix help text for --mac-signing-keychain ------------- Commit messages: - JDK-8266227: Fix help text for --mac-signing-keychain Changes: https://git.openjdk.java.net/jdk/pull/3819/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3819&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266227 Stats: 89 lines in 3 files changed: 27 ins; 5 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/3819.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3819/head:pull/3819 PR: https://git.openjdk.java.net/jdk/pull/3819

3 5

Fast and cheap (Double|Float)::toString Java algorithm
by Raffaello Giulietti 04 May '21

04 May '21

Hello, as a reminder, a Java implementation of Schubfach [1] intended to replace the current slow and expensive OpenJDK (Double|Float)::toString algorithm has been discussed, presented and contributed to this mailing list in several posts. The last implementation is available in pre-Skara webrev form, as referenced in [2]. On my laptop hardware, the speedup factor is 17.7x wrt OpenJDK. Recently, Alexander Bolz translated Schubfach to C++ for the purpose of comparing the performance of several bin2dec floating-point numbers algorithms [3]. In the meantime, Junekey Jeon implemented and perfected his own Dragonbox in C++, a new algorithm based on Schubfach [4]. From [5]: "In addition to the core idea of Schubfach, Dragonbox utilizes some Grisu-like ideas to minimize the number of expensive 128-bit × 64-bit multiplications, at the cost of having more branches and divisions-by-constants." In the C++ ecosystem, Schubfach has been the fastest known algorithm before being gently pushed aside by Dragonbox, as can be seen in the graphs in [3]. While developing Schubfach back in 2018, I experimented myself with blending core Schubfach with my own earlier algorithm similar to Grisu. However, probably due to uncontrollable JIT compilation behavior, I could not observe any benefit. On the contrary, I measured performance drops probably because of the added complexity, which is public enemy nr. 1 for JIT compilers. Therefore, I opted for the simpler current design that seemed more suitable for (the then 2018 version of) C2. I hope this can somehow revive this community's interest and confidence toward Schubfach to definitely supplant the current expensive (Double|Float)::toString algorithm. Greetings Raffaello ---- [1] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065297.html [3] https://github.com/abolz/Drachennest [4] https://github.com/jk-jeon/dragonbox [5] https://github.com/jk-jeon/dragonbox/blob/master/other_files/Dragonbox.pdf

2 3

RFR: 8265989: System property for the native character encoding name
by Naoto Sato 04 May '21

04 May '21

After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information. ------------- Commit messages: - 8265989: System property for the native character encoding name Changes: https://git.openjdk.java.net/jdk/pull/3777/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3777&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265989 Stats: 15 lines in 3 files changed: 8 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3777.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3777/head:pull/3777 PR: https://git.openjdk.java.net/jdk/pull/3777

6 22

RFR: 8265279: Remove unused RandomGeneratorFactory.all(Class<T> category)
by Jim Laskey 04 May '21

04 May '21

No longer needed ------------- Commit messages: - RandomGeneratorFactory.all(Class<T> category) no longer needed - Remove extraneous references to makeXXXSpliterator - Move makeXXXSpliterator methods to RandomSupport - change static final from 'proxy' to 'PROXY' - Make makeXXXSpliterator final - Move makeXXXSpilterator from public (@hidden) to protected. No API change. Changes: https://git.openjdk.java.net/jdk/pull/3516/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3516&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265279 Stats: 229 lines in 5 files changed: 19 ins; 184 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/3516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3516/head:pull/3516 PR: https://git.openjdk.java.net/jdk/pull/3516

2 3

RFR: 8265137: java.util.Random suddenly has new public methods nowhere documented
by Jim Laskey 04 May '21

04 May '21

Move makeXXXSpilterator from public (@hidden) to protected. No API ch ------------- Commit messages: - Move makeXXXSpilterator from public (@hidden) to protected. No API change. Changes: https://git.openjdk.java.net/jdk/pull/3469/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265137 Stats: 107 lines in 4 files changed: 0 ins; 91 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3469.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469 PR: https://git.openjdk.java.net/jdk/pull/3469

5 23