February 2019 - core-libs-dev

jpackage Packaging Tool Early Access Update 3
by Andy Herrick 15 Feb '19

15 Feb '19

A third EA build (Build 17) of jpackage tool is available at https://jdk.java.net/jpackage/ This release contains fixes to the following: JDK-8217894: jpackage CLI syntax changes JDK-8217792: Investigate what modules are included JDK-8217793: Modular jars in jpackage are not working JDK-8217687: jpackage --help improvements JDK-8214564: --win-upgrade-uuid does not work as expected JDK-8217317: Create jpackage native library for windows JDK-8217751: jpackage messages and failures JDK-8217331: Problems when space in application name JDK-8208404: Multiple Application Launcher JDK-8217269: jpackage Makefile improvments please send feedback to core-libs-dev(a)openjdk.java.net /Andy Herrick

1 0

RFR: JDK-8217802: Invalid Option warning message.
by Andy Herrick 15 Feb '19

15 Feb '19

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This is a simple fix to the unsupported Option warning message, and also fixes a problem when the new "--installer-type" option is used when not in "create-installer" mode. [1] https://bugs.openjdk.java.net/browse/JDK-8217802 [2] http://cr.openjdk.java.net/~herrick/8217802/ /Andy

3 2

RFR(JDK 13/java.xml) 8187697: Cleanup: irrelevant code in OutputPropertiesFactory
by Joe Wang 13 Feb '19

13 Feb '19

Please review a cleanup patch for the OutputPropertiesFactory. The original intention was to remove the (awkward) JDK 1.2-related code, line 235-258 in the old file. I then went a bit further to remove another nuisance that annoyed users with an error "Could not load the property file 'output_xml.properties' for output method 'xml'" from time to time. The output properties files are now removed and the contents moved into static arrays in OutputPropertiesFactory between line 192 and 288 in the new file. The processing process is kept mostly as is. The only change was removing the "fixupPropertyString" process, as a result the only line kept from the old file line 447 - 500 was line 376 in the new file. JBS: https://bugs.openjdk.java.net/browse/JDK-8187697 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8187697/webrev/ Thanks, Joe

2 2

RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument
by Ivan Gerasimov 13 Feb '19

13 Feb '19

Hello! The specification states: """ If the length of the specified CharSequence is less than or equal to zero, then an empty buffer of capacity 16 is returned. """ However, the current implementation throws either NegativeArraySizeException or IndexOutOfBounds instead (the actual exception type depends on the value of reported negative length). It is proposed to do two things: 1) remove the problematic sentence from the javadoc (CSR is filed). 2) unify the exception type thrown, if the argument reports negative length. NegativeArraySizeException will be consistent with, for example, StringBuffer(negativeCapacity). Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 -- With kind regards, Ivan Gerasimov

3 13

RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn
by Thomas Stüfe 13 Feb '19

13 Feb '19

Hi all Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-pr… (@Roger: I hope you do not mind? The bug is assigned to you but since I happened to play around with posix_spawn I prepared this webrev. If you rather do this change, that is fine and I will leave it to you.) When we added the possibility to use posix_spawn as underlying implementation for Runtime.exec() on Linux with https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep VFORK as default until work on 13 starts. So now would be a good time to switch the default to posix_spawn to get a good testing window. Note that at SAP we run our VMs internally with posix_spawn as default since some months and have not seen problems. As for the fix, I added a test which tests that the default is indeed posix_spawn - not sure whether this is overdoing it though. Also, I use strace for the test, and /bin/true, and while strace is usually available and reachable by path resolution, I am afraid on some test machines it may not. What do you think, should I leave the test out? The fix ran through all java/lang/ProcessBuilder jtreg tests ok. Thanks, Thomas

3 21

Missing Blank Line Suspected in jar.html
by Philipp Kunz 12 Feb '19

12 Feb '19

Hi, https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#per-entry-att ributes shows an example manifest Manifest-Version: 1.0 Created-By: 1.8 (Oracle Inc.) Sealed: true Name: foo/bar/ Sealed: false with the explanation It means that all the packages archived in a.jar are sealed, except that package foo.bar is not. However, this is not a valid manifest because the same page also states Attribute names cannot be repeated within a section. which I guess also should apply to main attributes and The main section [...]. No attribute in this section can have its name equal to "Name". Long story short, I guess a blank line is missing before line 4 of that example manifest between "Sealed: true" and "Name: foo/bar/". There are example manifests further down at the end of section https:// docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature-validation with such blank lines. It would look then like this: Manifest-Version: 1.0 Created-By: 1.8 (Oracle Inc.) Sealed: true Name: foo/bar/ Sealed: false I haven't found the sources of that referenced jar.html and therefore I'm not sure whether my concern still currently applies or has been fixed since JDK 10. Regards, Philipp

2 1

Java SSLSocketChannel/SSLSelector?
by Andi Mullaraj 12 Feb '19

12 Feb '19

Hi java-core community, I have been directed to this channel to discuss matters related to Java performant ssl communications. Maybe this is a topic that has been discussed in the past, in which case I would appreciate if someone pointed me to that particular topic. Back in 2002 I personally applauded the java.nio.channels (jdk1.4) package, realizing that there was no way to port this to the secure communications, due to lack of a comparable implementation for SSL. But I thought it was going to just be matter of time. A couple of years ago I had to go back search for it, and was kind of surprised to find the following in http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERef… : --- begin quote --- Newcomers to the API may wonder "Why not just have an SSLSocketChannel which extends java.nio.channels.SocketChannel?" There are two main reasons: 1. There were a lot of very difficult questions about what a SSLSocketChannel should be, including its class hierarchy and how it should interoperate with Selectors and other types of SocketChannels. Each proposal brought up more questions than answers. It was noted that any new API abstraction extended to work with SSL/TLS would require the same significant analysis and could result in large and complex APIs. 2. Any JSSE implementation of a new API would be free to choose the "best" I/O & compute strategy, but hiding any of these details is inappropriate for those applications needing full control. Any specific implementation would be inappropriate for some application segment. --- end quote --- It has been a while since this was stated, and I would really like to revisit it. I personally believe that the question #1 has a quite natural answer, while #2 should not really be a concern if we adhere to the spi model where users can bring their own implementation if needed. I know because I have also implemented it (but would like to discuss that in a later stage, if it comes to it). The benefit of such implementation would be immense. Imagine many Java services written with nio and which struggle to move to SSL due to the great complexity of using SSLEngine (zookeeper service to name one), while all they would need to do (if SSLSocketChannels were available) is to instantiate an instance of SSLSocketChannel/SSLSelector when the security is required and the rest would stay the same (as in case of plain communication using SocketChannel/Selector). Another important use case is the advent of IOT, where millions of devices, with relatively low throughput would want to protect their communication via SSL. The ways I have seen the community deal with this are mainly: 1. Go through the pain of learning SSLEngine (and hope to get it right) 2. Build their services around tested libraries (like Jetty, which handle the SSL offload but don't resurface it in SocketChannel/Selector paradigm, that also come with their huge set of dependencies, bringing in unavoidable version collisions) 3. Use proxies (nginx, ha) to deal with the high number of SSL connections and divide the load by scaling horizontally in the back end (making for a harder deployment model) We can make this a lot easier! Any feedback is greatly appreciated, Best, Andi Mullaraj

2 1

RFR: JDK-8200758 JEP 343: Packaging Tool
by Tornai András 12 Feb '19

12 Feb '19

Hi all, jpackage* does not have an option to specify the classpath anymore while javapackager** has this feature. jpackage just collects all the .jar files from --input directory and puts them on classpath***. I would like to add some extra .jar files to my application/package but I do not want them on classpath - with jpackage this seems to be impossible. Have I overlook something? Would it be possible to improve jpackage with this? Many thanks, András * https://bugs.openjdk.java.net/browse/JDK-8200758 ** https://docs.oracle.com/javase/10/tools/javapackager.htm#JSWOR719 under "General Bundler Arguments" *** https://hg.openjdk.java.net/jdk/sandbox/file/225a4ac5bd57/src/jdk.jpackage/…

1 0

JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()
by Michal Vala 11 Feb '19

11 Feb '19

Hi, I've been looking into this bug in HashMap where resize() is called multiple times when putting whole map into another. I come up with following patch: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.00/ I've tried to do it as little invasive as possible. New resize(int) method is called just from putMapEntries for now. Notice that method is called with size of the new map. I was experimenting with calling it with 'size()+s', but this leads to unwanted space allocation when inserted map rewrites a lot of existing keys. I've benchmarked this with adding 10millions elements into existing map and it gets ~50% improvement: unpatched Benchmark Mode Cnt Score Error Units MyBenchmark.testMethod thrpt 10 1.248 ± 0.058 ops/s patched Benchmark Mode Cnt Score Error Units MyBenchmark.testMethod thrpt 10 1.872 ± 0.109 ops/s public class MyBenchmark { static Map<Integer, Integer> mapTocopy = IntStream.range(1, 10_000_000).boxed().collect(Collectors.toMap(k -> k, k -> k)); @Benchmark public int testMethod() { var map = new HashMap<Integer, Integer>(); map.put(-5, -5); map.putAll(mapTocopy); return map.size(); } } Any ideas for missed corner-cases or some good tests? -- Michal Vala OpenJDK QE Red Hat Czech

7 33

RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format
by Ivan Gerasimov 08 Feb '19

08 Feb '19

Hello! String representation of UUID should conform to RFC4122 <https://tools.ietf.org/html/rfc4122>, i.e. each its part has to be of the fixed size. Unfortunately, the UUID.fromString() method does not keep up to this requirement: - First, it permits the leading zeroes of any part to be omitted; - Second, it permits some of the UUID parts to be larger then allowed. In such a case, the value is effectively clipped with & 0x..FFFF. While some existing application may depend on the former case -- i.e. be able to parse UUID with stripped leading zeroes, the later case is likely to be an error. In the past, the check on the input has already been strengthened with JDK-8006627 <https://bugs.openjdk.java.net/browse/JDK-8006627>. I propose we go further and make UUID.fromString() to reject such string representations that contain too large individual parts. If people agree on the proposal, I'll file CSR to fix the change of behavior. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407 WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov

3 5