August 2018 - core-libs-dev

RFR(M) : 8210039 : move OSInfo to top level testlibrary
by Igor Ignatyev 04 Sep '18

04 Sep '18

http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html > 698 lines changed: 114 ins; 240 del; 344 mod Hi all, could you please review this clean up of jdk testlibrary? the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion. testing: changed tests + :jdk_desktop test group webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8210039 Thanks, -- Igor

5 8

RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
by Langer, Christoph 04 Sep '18

04 Sep '18

Hi, please review and give feedback for this augmentation of java.io.Console. We have users that have the need to query for Width and Height of the console device in Java. In our own JVM implementation we had given them this hook as a custom extension already quite some time ago. We think, however, that it is a worthwhile augmentation of java.io.Console. Bug: https://bugs.openjdk.java.net/browse/JDK-8209937 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/ I'll also open a CSR for this, but I'll wait for some feedback on our proposal first. Thanks & Best regards Christoph

5 7

RFR: JDK-8197398, (zipfs) Files.walkFileTree walk indefinitelly while processing JAR file with "/" as a directory inside.
by Xueming Shen 03 Sep '18

03 Sep '18

Hi, Please help review the proposed change for JDK-8197398. issue: https://bugs.openjdk.java.net/browse/JDK-8197398 webrev: http://cr.openjdk.java.net/~sherman/8197398/webrev A little background: The existing zipfs has an assumption that the "normal/healthy/secured" zip/jar file should not include any entry that has an absolute path, root "/" included. Various jar/zip tools have been fixed/patched in the past years to avoid create such a jar/zip file for security reason. But there are zip/jar files in the wild that do include absolute paths and do include a "/" root sometime, the offending jar file included in the bug report is just one of those. With this "wrong" assumption, the existing zipfs implementation always add a pseudo root directory before building the internal inode tree and unfortunately attaches the "real" root entry (exists in the jar/zip file) to be its child, in which trigger a circle when iteration. The proposed change is to solve this problem by only adding the pseudo root when there is no real root in the zip/jar file. Further the proposed change will try to "normalize" the zip/jar file when it has any update needs to sync/write the update to the underlying zip/jar file when closing, by removing any absolute path for all the entries, root "/" included, with the assumption that the zipfis implementation should never create/generate an unsecured zip/jar file. Thanks, Sherman

2 3

RFR 8210226: Add support for multiple project folders to idea.sh
by Maurizio Cimadamore 31 Aug '18

31 Aug '18

Hi, this patch adds proper support for -o option to the idea.sh script, which allows to place the .idea folder under any given output folder (not necessarily the JDK root). To be able to do this, I had to revampo the logic for template substitution in idea.sh, as it was growing too brittle. I now have a much more declarative logic, where replacements can be added by calling the add_replacement function. This allows to replace a lot of the previous code with very simple and self-explanatory calls to that routine. This piece was necessary, as we needed to replace a lot of references to the idea variable $PROJECT_DIR with the new template variable ###ROOT_DIR### (otherwise the project is ill-formed, since $PROJECT_DIR merely points at the folder containing the .idea project folder). Webrev: http://cr.openjdk.java.net/~mcimadamore/8210226/ Cheers Maurizio

3 4

RFR: 8210153 : java/text/Format/NumberFormat/CurrencyFormat.java failed
by li.jiang＠oracle.com 30 Aug '18

30 Aug '18

Hi Naoto, Please review the fix to update the currency symbol for VES. Bug: https://bugs.openjdk.java.net/browse/JDK-8210153 Webrev: http://cr.openjdk.java.net/~ljiang/8210153/webrev/ Built and tier1~tier3 tests passed on mach5. Thanks, Leo

2 1

RFR: 8208746 8209775 : ISO 4217 Amendment #168 #169 Update
by li.jiang＠oracle.com 30 Aug '18

30 Aug '18

Hi, Please review the changes for ISO 4217 Amendment #168 #169. Bugs: https://bugs.openjdk.java.net/browse/JDK-8208746 168 https://bugs.openjdk.java.net/browse/JDK-8209775 169 Only in amendment #168 has real currency data update for Java, but I also updated the data version to #169 for consistent. Changes include: - Update the currency for VENEZUELA (BOLIVARIAN REPUBLIC OF), VES 928 minor 2 - Update the currency name to 'Bolívar Soberano' - Move the currency VEF to historical currencies - Correct the currency name for PHILIPPINES (THE): Philippine Peso (instead of Piso) - Change the country name: SWAZILAND to ESWATINI Webrev: http://cr.openjdk.java.net/~ljiang/8208746/webrev.00/ Build and test passed on mach5 for all platforms. Thanks, Leo

5 4

MethodHandles.Lookup.defineResource?
by Stephen Colebourne 29 Aug '18

29 Aug '18

A new method MethodHandles.Lookup defineClass() was added recently. But what about a defineResource? For adding a new resource to the classpath (such as a .txt file). I just needed such a thing, and though undoubtedly rare, all the recommended solutions use reflection and setAccessible(). thanks Stephen

3 12

Java VM Questions
by mr rupplin 29 Aug '18

29 Aug '18

Can I ask you guys a quick question. Does the VM development team plan on implementing any pure pass by reference. Also I think we would like security and RMI integration going forward with the VM directly. No way to hook memory allocation seems like a miss. Let me know with some feedback. Thanks. Max R. Get Outlook for Android<https://aka.ms/ghei36>

1 0

RFR 8209064: Make intellij support more robust after changes for 2018.2
by Maurizio Cimadamore 28 Aug '18

28 Aug '18

Hi, last week I submitted an 'emergency' patch to fix intellij project support after 2018.2 changes. The goal of these changes was to move the build.xml ant file out of the .idea folder, as the IDE no longer supported DOM indexing in such folders (as a result of https://youtrack.jetbrains.com/issue/IDEA-189915) As a workaround, I tweaked the scripts to copy build.xml in the build folder. Thinking more about this issue, there's a more robust fix possible, which doesn't involve moving files to the build folder (which could be potentially unreliable, depending on how people build the JDK). In fact, the best solution is to leave build.xml where it is, and fix the remaining configuration files to point at it. This allows to revert all changes in the scripts that set up the project configuration (bin/idea.sh for JDK, and make/langtools/build.xml for langtools). For the langtools project a bit more changes were necessary, given that in langtools we did not have a 'template' folder - and all intellij files were dumped onto the same path. So I had to move the configuration langtools files (all but build.xml) under a new template folder (located under make/langtools/intellij/make) and place build.xml outside it. Then tweak the build.xml script to work off this new template folder. These are all small conceptual changes, but the impact on the webrev is quite biggie (because of file renaming etc.). I also took the chance to fix some issues with the JDK project ANT configuration (see changes in make/idea/template/workspace.xml), as the last changes did not update the location of the ant file used here - as a result no ant target entries were showing up under the Build menu. Webrev here: http://cr.openjdk.java.net/~mcimadamore/8209064/ Cheers Maurizio

3 4

RE: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir versus opendir64/closedir64
by Baesken, Matthias 28 Aug '18

28 Aug '18

Hi Brian , builds + tests ( with your change included) last night on AIX were good . However while looking into the coding a bit more, I noticed the following : IBM states for AIX : https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.baset… Note An open directory by opendir64 subroutine must always be closed with the closedir64 subroutine to ensure that the next attempt to open that directory is successful. In addition, it must be operated using the 64-bit interfaces (readdir64, telldir64, seekdir64, rewinddir64, and closedir64) to obtain the correct directory information. However this is currently not the case everywhere : for example I see in http://cr.openjdk.java.net/~bpb/8207744/webrev.01/src/java.base/share/nativ… a readdir (without 64). Same for http://cr.openjdk.java.net/~bpb/8207744/webrev.01/raw_files/new/src/java.ba… Best regards, Matthias From: Brian Burkhalter <brian.burkhalter(a)oracle.com> Sent: Mittwoch, 1. August 2018 16:53 To: Baesken, Matthias <matthias.baesken(a)sap.com> Cc: Langer, Christoph <christoph.langer(a)sap.com> Subject: Re: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir versus opendir64/closedir64 Hi Matthias On Aug 1, 2018, at 3:51 AM, Baesken, Matthias <matthias.baesken(a)sap.com<mailto:matthias.baesken@sap.com>> wrote: [F]irst sorry for the messed up previous mail . I forgot to fix the subject and remove some parts of the digest ☹ . No worries. Hi Brian , I'll build it on AIX + in case it builds fine put it into our test patch queue . Build was fine on AIX . I put it into our test patch queue and come back to your tomorrow with some info about the tests . Thank you very much! Best regards, Brian PS I will still need an imprimatur from a JDK 12 Reviewer.

5 19