Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

On 04/09/2020 10:00, Alan Bateman wrote: On 04/09/2020 08:55, Aleksei Voitylov wrote: : Tests tools/launcher/Test7029048.java and tools/launcher/ExecutionEnvironment.java need to change behavior on systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we first considered

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

On 04/09/2020 08:55, Aleksei Voitylov wrote: : Tests tools/launcher/Test7029048.java and tools/launcher/ExecutionEnvironment.java need to change behavior on systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we first considered was to detect the libc of the OS with ldd in the

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

On 01/09/2020 12:41, Aleksei Voitylov wrote: Hi, JEP 386 is now Candidate [1] and as we resolved all outstanding issues within the Portola project I'd like to ask for comments from HotSpot, Core Libs (changes in libjli/java_md.c), and Build groups before moving the JEP to Proposed to Target:

Re: RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

On 17/06/2020 16:38, Erik Joelsson wrote: Ah, misunderstood you then. I added a comment to JDK-8213216 with more details and shortened the comment in the test: http://cr.openjdk.java.net/~erikj/8213214/webrev.03/ Looks okay as a workaround until we figure out what to do with subst. -Alan.

Re: RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

On 17/06/2020 14:47, Erik Joelsson wrote: I've tried to make this clearer in the comment. http://cr.openjdk.java.net/~erikj/8213214/webrev.02/ I would prefer if you could move the notes/comment from L125-157 to the bug report to avoid cluttering the test. Instead, the test just needs a one

Re: RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

On 16/06/2020 18:44, Erik Joelsson wrote: There are a lot of jtreg tests that use temporary files. These temporary files add up over time and fill up the global temp directories on our test systems. To tackle this, we should try to redirect these temporary files into a directory controlled by

Re: RFR: JDK-8244928 Build log output too verbose after JDK-8244844

On 13/05/2020 09:16, Magnus Ihse Bursie wrote: Unfortunately, an error crept into JDK-8244844 so that the build log displays the filenames of all compiled java files, instead of the count of files. Bug: https://bugs.openjdk.java.net/browse/JDK-8244928 Patch inline: diff --git

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

On 30/04/2020 08:03, Jan Lahoda wrote: Hi, The building of lib/ct.sym is not reproducible, due to timestamps of files inside the file (which is basically a zip file). The proposed solution is to use a constant timestamp for the files inside the ct.sym file. To simplify the construction,

Re: RFR: JDK-8243665 exploded-image-optimize touches module-info.class in all modules

On 29/04/2020 11:40, Magnus Ihse Bursie wrote: : http://cr.openjdk.java.net/~ihse/JDK-8243665-fix-AddPackagesAttribute/webrev.02 Looks good. It could be optimized to only read the module-info.class once but will hardly be noticeable I suspect. -Alan

Re: RFR: JDK-8243665 exploded-image-optimize touches module-info.class in all modules

On 29/04/2020 10:27, Magnus Ihse Bursie wrote: Due to the current design of the AddPackagesAttribute build tool, all module-info.class files will be written to, when the tool is run. This happens whenever at least one module-info.class file has been updated. The end result of this is that

Re: RFR 15 8225319: Remove the RMI static stub compiler rmic

On 03/04/2020 16:43, Roger Riggs wrote: Please review the CSR[1] and changes to remove the RMI static stub compiler (rmic). RMIC was deprecated for removal in JDK 13 [3]. The components modified are:  - remove the jdk.rmic module  - remove the jdk.rmic man page  - remove all tests of rmic

Re: RFR (S): 8241947: Minor comment fixes for system property handling

On 01/04/2020 17:03, Roger Riggs wrote: Hi, Does dropping the "The following properties are guaranteed to be defined:" would seem to be a spec change. It's a comment on a private field, there's no change to the getProperties spec. -Alan

Re: RFR (S): 8241947: Minor comment fixes for system property handling

On 31/03/2020 19:57, Langer, Christoph wrote: Hi Mandy, this is a good suggestion. The listing of system properties at the props field declaration seems somewhat redundant, given that it already exists more exactly and with API normativity in the doc of System::getProperties(). So what do

Re: RFR: JDK-8241463 Move build tools to respective modules

On 23/03/2020 19:03, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore.

Re: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

On 18/03/2020 21:24, Roger Riggs wrote: Hi, Some small updates to the source files to minimize the changes to javadoc of the _Stub classes. All looks good but the updated ActivationGroup_Stub should probably get a one-pass to eliminate the inconsistencies, e.g. the new version imports some

Re: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

On 16/03/2020 16:02, Roger Riggs wrote: Please review adding pre-generated RMI stub classes to the jdk repo and the removal of make files supporting the specific APIs. It removes a dependency on build time generation invoking RMIC. RMIC was  deprecated in JDK 13 [1]. The source files have been

Re: RFR: JDK-8239139 testmake fail with warning about strncpy using gcc version 8

On 17/02/2020 07:48, linzang(臧琳) wrote: Hi, May I ask help to review one tiny fix of build failure described at https://bugs.openjdk.java.net/browse/JDK-8239139 Root cause is gcc version 8 prints warning for strncpy. The fix simply replace strncpy with snprintf. Thanks!

Re: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

On 12/02/2020 22:16, Erik Joelsson wrote: Hello Christoph, This patch certainly looks better to me, though I agree it's a bit hackish to have to filter and rename the stripped.pdb files twice, once for jmods and again for bundles. I think I'm ok with it for now though. The future improvement

Re: RFR: JDK-8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary

On 04/02/2020 17:45, Erik Joelsson wrote: Does anyone have an opinion on this? I think this looks okay, would be good if Henry could look at it too as we've been bitten by changes in this area, I think with Eclipse Tools that are locating in unusual ways (we think Info.plist). I was happy to

Re: RFR: JEP 367: Remove the Pack200 Tools and API

On 05/12/2019 08:16, Henry Jen wrote: Hi, Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up. Changes to symbols is reverted, as we expect that only need to be updated in next release by running

Re: RFR: JEP 367: Remove the Pack200 Tools and API

On 21/11/2019 19:53, Vicente Romero wrote: Hi, I think I have covered all the proposed fixes so far. This is the last iteration of the webrev [1], all the current changes are in this one, the code hasn't been split into different webrevs. I'm also forwarding to build-dev as there are some

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

On 22/10/2019 04:22, mark.reinh...@oracle.com wrote: RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ I've read through the code for the new jlink plugins and the changes to

Re: [PATCH] Add *.iml to .hgignore and .gitignore

I think the .ignore files are maintained on build-dev. Note that .idea is already excluded and it contains the .iml and other workspace files are created for the IntelliJ project, maybe your setup might be different? -Alan. On 15/09/2019 21:22, JARvis PROgrammer wrote: This is a small

Re: JDK 14 RFR of JDK-8230373: Use java.io.Serial in generated exception types

On 30/08/2019 21:12, Joe Darcy wrote: Hello, As noted during the code review of JDK-8229997 (http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062049.html), for completeness @java.io.Serial annotation should be included on generated exception types. Please review the

Re: RFR: JDK-8058539: Platform specific source files may not end up in src.zip

On 20/06/2019 10:39, Erik Joelsson wrote: For both java and native source files, we have a feature in the build which allows overriding based on file name for more specific version (i.e. OS specific overrides shared). This works quite well and is used in several locations. It does however

Re: Build failing on macOS in hotspot module

This seems to have been fixed a few hours ago:    http://hg.openjdk.java.net/jdk/jdk/rev/4d421888ad63 On 19/07/2019 13:12, Jaikiran Pai wrote: I just updated my local jdk workspace to the latest default branch and did: bash configure make clean make images The build keeps failing with:

Re: RFR (XXS) 8224790: Remove Xusage.txt file

On 25/05/2019 06:49, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ Before Java 7 the Xusage.txt file was used to print the "java -X" help information in English. From Java 7 this information was provided in

Re: zlib configuration : system vs. bundled

On 17/05/2019 09:18, Baesken, Matthias wrote: Hi Alan, thanks for the info . Are you aware of a way to reliably see the info (e.g. in hs_err file) what version of libz was used at runtime ? On linux (with some luck ) we see it in hs_err , at least a lot of distros put the

Re: RFR: docs/build JDK-8223663 Update links for tool guides

On 18/05/2019 01:16, Jonathan Gibbons wrote: In JDK 13, the pages for the Tools Reference guides are moving, and so the links from the API pages to these guides needs to be updated. Please review a two-part change. I went changes to each of the module-info.java files and skimmed through the

Re: zlib configuration : system vs. bundled

On 16/05/2019 15:18, Baesken, Matthias wrote: Hello Alan, I found http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032106.html and http://mail.openjdk.java.net/pipermail/build-dev/2016-February/thread.html#16602 but without much details on real or potential performance

Re: zlib configuration : system vs. bundled

On 16/05/2019 12:34, Baesken, Matthias wrote: Hello, the updated webrev is here : http://cr.openjdk.java.net/~mbaesken/webrevs/8223944.1/ This looks good to me. -Alan

Re: zlib configuration : system vs. bundled

On 15/05/2019 09:16, Baesken, Matthias wrote: Hi Alan, thanks for pointing me at the old discussion . http://mail.openjdk.java.net/pipermail/build-dev/2016-February/016602.html talks about performance benefits . Are you aware of some benchmarks that showed the improvements ? If you can

Re: zlib configuration : system vs. bundled

On 14/05/2019 15:58, Baesken, Matthias wrote: : On the other OS platforms, in case a zlib is found on the system : if test "x${ZLIB_FOUND}" != "xyes"; then # If we don't find any system...set default to bundled DEFAULT_ZLIB=bundled fi we use it from the system . Wouldn't it

Re: RFR: 8221610: Resurrect (legacy) JRE bundle target

On 28/03/2019 09:07, Langer, Christoph wrote: Hi build-dev, today I’m coming up with kind of a backward oriented suggestion… don’t know how well that would be received. Let’s see. For JDK 11, with JDK-8200132 [0], the JRE build has been moved to legacy. There has been some discussion

Re: RFR (S) 8074817: Resolve disabled warnings for libverify

On 08/03/2019 17:35, Aleksey Shipilev wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8074817 Fix: http://cr.openjdk.java.net/~shade/8074817/webrev.03/ This hopefully resolves warnings in libverify. See bug report for warnings list. This looks okay to me (we should probably have

Re: RFR(T) : 8219132 : switch to jtreg4.2-b14

On 20/02/2019 00:34, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html 1 line changed: 0 ins; 0 del; 1 mod; Hi all, could you please review this one-liner which switch jtreg version to jtreg4.2-b14? webrev:

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 08/02/2019 18:53, Mandy Chung wrote: Renaming it to make it clear is good.  How about: --strip-debug-attribute --strip-native-debug-symbols --strip-debug will invoke both --strip-debug-attribute and --strip-native-debug-symbols, if supported. Typically we want to strip both.  If only

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 07/02/2019 17:09, Severin Gehwolf wrote: Hi, Could I please get reviews for this enhancement? It adds a debug symbols stripping plug-in to jlink for Linux and Unix platforms. It's the first platform specific jlink plugin and the approach taken for keeping it contained is to use a plugin

Re: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 28/01/2019 09:26, Severin Gehwolf wrote: : I skimmed the current patch and I see the usability has improved since the original proposal. It would be nice to get to `--strip-native-debug-symbols` without needing the "=defaults" suffix. There are details around the sub-options and naming that

Re: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 26/01/2019 00:06, Mandy Chung wrote: Hi Severin, Another alternative would be to support per-jlink-plugin resource bundle to avoid merging .properties files at build time.  The plugin-specific messages should only be used by the plugin itself and it would be cleaner for each plugin to manage

Re: RFR: 8214533 IBM-29626C is required for AIX default charset

On 15/01/2019 00:51, Ichiroh Takiguchi wrote: Hello Alan. Could you review the fix again ? Bug:    https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ I added IBM29626C charset as standard way. Please give any suggestion and

Re: RFR: JDK-8216489: Issues with ModulePackages attribute generation on incremental build

On 10/01/2019 17:14, Erik Joelsson wrote: The incremental build of exploded-image-optimize is broken. This is caused by a small typo in the prerequisites declaration for the recipe. Bug: https://bugs.openjdk.java.net/browse/JDK-8216489 Webrev:

Re: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration

On 03/01/2019 07:22, Fu Jie wrote: Thanks Alan for your review and valuable advice. I think it's worth keeping a NB project in the repo since it seems more convenient for IDE developers. And to keep configurations.xml current is also important. I made a patch to fix the issue mentioned by

Re: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration

On 28/12/2018 06:34, Fu Jie wrote: Hi, Please review this patch for a build failure with NetBeans: Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ Summary The build failure is caused by an incorrect setting of preBuildCommand

Re: [PATCH] Windows 32-bit DLL name decoration

On 12/12/2018 11:14, Magnus Ihse Bursie wrote: : I searched the code for "jdwpTransport_On" to see of there was any corresponding OnUnload function (or other), but could not find any. That's right, an unload wasn't needed when that SPI was originally added but could be added in the event that

Re: [12] RFR for JDK-8215123: Crash in runtime image built with jlink --compress=2

On 10/12/2018 13:01, Magnus Ihse Bursie wrote: Hi Alexey, On 2018-12-10 13:32, Alexey Ivanov wrote: Hi, Could you please review the following fix for jdk12? bug: https://bugs.openjdk.java.net/browse/JDK-8215123 webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/ The fix looks

Re: RFR: 8214533 IBM-29626C is required for AIX default charset

On 10/12/2018 11:01, Magnus Ihse Bursie wrote: On 2018-12-07 21:20, Roger Riggs wrote: Hi, It is a nice feature that charsets are selected at build time using the stdcs-xxx files. This change breaks that pattern and embeds os specific information in more than one place. That does not seem

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On 10/12/2018 11:05, Magnus Ihse Bursie wrote: On 2018-12-10 11:56, Nick Gasson (Arm Technology China) wrote: Hi, Any update on this one? Or do we want to give up on it until JDK-8165620 is implemented? I think Alan reviewed it as OK with just a minor fix, and offered to sponsor it for you.

Re: JDK 13 RFR of JDK-8205626: Start of release updates for JDK 13

On 05/12/2018 17:28, joe darcy wrote: Hello, With the inception of JDK 13 right around the corner, please review the build-related changes of the update:     http://cr.openjdk.java.net/~darcy/jdk13-fork.2 As usual, javac defines a new -source/-target 13 which is used in the build of the

Re: RFR: JDK-8214710 Fix hg log in update_copyright_year.sh

On 03/12/2018 16:10, Magnus Ihse Bursie wrote: The commands for hg log is missing -l1, which will limit the log to just the revision specified. Instead, all revisions from repo creation will now be included, and the script fails to work. I will publish a separate changeset with missed

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 28/11/2018 22:49, Henry Jen wrote: Since there is no header file in JDK provides the function prototypes, I don’t think this is considered public(supported) APIs. Anyway, in case a tools is build with launcher code, and shipped separately from JDK, that would be impacted by this bug. So

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 28/11/2018 13:13, Kevin Rushforth wrote: The jpackage tool calls JLI_Launch. I remember that from Andy's webrev but it's not integrated yet. Does the JavaFX packager tool do the same? -Alan

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 28/11/2018 13:03, Kevin Rushforth wrote: This is related to a bug I filed back in October, JDK-8211959 [1], in which JLI_Launch is failing for the same reason. The fix to java_md_macosx.m is the same one I identified in that bug. You might consider adding a test that calls JLI_Launch, but

Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

On 28/11/2018 09:28, Magnus Ihse Bursie wrote: I'm quite unsatisfied with the current handling of character sets in the build in general. :-( I'd really like to modernize it. I have a, slightly fuzzy, laundry list of things I want to fix from a build perspective, but I'm not sure of what

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 27/11/2018 23:05, Henry Jen wrote: Hi, Please review a follow up webrev[1] based on Priyanka’s patch, it simply added a test case for Mac only that will link with libjli. Note that, to use invoke API, one should probably link with libjvm, which works for all supported platforms, not just

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On 26/11/2018 09:08, Nick Gasson wrote: Hi Alan, I've done this here: http://cr.openjdk.java.net/~njian/8214077/webrev.3/ I missed one thing then looking at this. In TimeZone_md.c it should be #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but I need to change this one

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On 27/11/2018 13:28, Magnus Ihse Bursie wrote: 26 nov. 2018 kl. 13:27 skrev Alan Bateman : On 26/11/2018 09:08, Nick Gasson wrote: Hi Alan, I've done this here: http://cr.openjdk.java.net/~njian/8214077/webrev.3/ This looks good and I think means we no longer have any stat usages in libjava

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On 26/11/2018 09:08, Nick Gasson wrote: Hi Alan, I've done this here: http://cr.openjdk.java.net/~njian/8214077/webrev.3/ This looks good and I think means we no longer have any stat usages in libjava. -Alan

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On 23/11/2018 11:13, Nick Gasson wrote: This looks right and reduces the stat usages in libjava down to one remaining case (ProcessHandlerImpl_linux.c). Hi Alan, Do you want me to do this one too for completeness? Although as it's calling stat() on the /proc/ directory I don't think it's

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On 23/11/2018 09:37, Nick Gasson wrote: Hi Alan, I've done this here: http://cr.openjdk.java.net/~njian/8214077/webrev.2/ This looks right and reduces the stat usages in libjava down to one remaining case (ProcessHandlerImpl_linux.c). I'm a bit unsure about #ifndef MACOSX - some existing

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On 22/11/2018 10:54, Nick Gasson wrote: Have you looked at replacing the remaining usages of stat changed to stat64 instead? I've tried this just now and it also resolves the issue. I can test on some more platforms and update the webrev if this is the preferred solution? I'd say this is

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On 21/11/2018 02:46, Nick Gasson wrote: Hi, Can someone please help me review this small makefile patch to fix an issue with java.io.File::setLastModified on 32-bit systems? https://bugs.openjdk.java.net/browse/JDK-8214077 http://cr.openjdk.java.net/~njian/8214077/webrev.0/ If the file size

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 12/11/2018 21:40, Philip Race wrote:   74   75 static String getTmpDir() {   76 String os = System.getProperty("os.name").toLowerCase();   77 if (os.contains("win")) {   78 return System.getProperty("user.home")   79 +

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 10/11/2018 21:59, Magnus Ihse Bursie wrote: I can't see that you've addressed any of the build system changes Erik and I requested? Or is this just a preliminary review, and you intend to go at least one more round before attempting to push? If so, this was not very clear to me. I see

Re: Review Request : JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 06/11/2018 04:35, Priyanka Mangal wrote: The Eclipse launcher is capable of loading the Java VM in the eclipse process using the Java Native Interface Invocation API. The launcher is still capable of starting the Java VM in a separate process the same as previous version of Eclipse did.

Re: Review Request : JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 05/11/2018 14:21, Magnus Ihse Bursie wrote: Hi, Fix looks good, but maybe we should have a regression test of GetJREPath()? /Magnus The fix looks okay but I'm puzzled as to how Eclipse is running into this. Do they locate/call libjli/GetJREPath directly or is this happening then it is

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 30/10/2018 14:11, Andy Herrick wrote: : What is the status of the JNLPConverter tool? I see it is included as a "demo" but maybe it would be better to host somewhere else as this is for developers migrating Java Web Start applications. Our current plan is to deliver it only as a demo.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 23/10/2018 16:49, Andy Herrick wrote: This patch implements the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool jpackager is a simple packaging tool, based on the JavaFX |javapackager| tool, that:  * Supports

Re: RFR(S): 8211350: Remove jprt support

On 02/10/2018 19:17, Mikael Vidstedt wrote: Thanks for the reviews. I’ve reverted the changes related to Helper and “just” adjusted the comments instead. webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ incremental (from webrev.00):

Re: RFR(S): 8211350: Remove jprt support

On 02/10/2018 08:21, Mikael Vidstedt wrote: Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. bug: https://bugs.openjdk.java.net/browse/JDK-8211350 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ Does

Re: RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef

On 26/09/2018 10:24, Baesken, Matthias wrote: Hello, please review this small build fix . After the recent changes  to  the gcc compile flags   with  8211029    , most of our  Linux builds stopped working . Error : === Output from failing command(s) repeated here === * For target

Re: [8u] Include all classes in sources (src.zip)?

On 25/09/2018 16:43, Erik Joelsson wrote: At Oracle, I'm pretty sure we need to maintain the current behavior so that patch needs to be accompanied by a corresponding patch in Oracle closed. Is this the same issue as JDK-8044235 that Omair fixed in JDK 9:

Re: RFR: JDK-8210931 JLI and launchers normalization and cleanup

On 20/09/2018 12:31, Magnus Ihse Bursie wrote: I'm pretty sure I've run at least the instrument tests, but I'll rerun it just to make sure. Does :jdk_instrument and :jdk_launcher sound reasonable? Yes that will run them. At some point I hope we can get the JPLIS agent in libinstrument

Re: Why static_jli for java/javaw on Windows?

On 13/09/2018 14:07, Magnus Ihse Bursie wrote: : Apparently, someone was trying to get rid of dll dependencies from java.exe. Why that would be desirable it does not say. Neither why this should not apply to all other launchers. (Perhaps there were not that many in these days?) Do

Re: RFR: JDK-8210704 Remove dead build tools hasher and jarreorder

On 13/09/2018 09:46, Magnus Ihse Bursie wrote: On 2018-09-13 10:35, Magnus Ihse Bursie wrote: The two build tools hasher and jarreorder is not used in the build anymore and should be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8210704 WebRev:

Re: RFR: JDK-8059019 sdp.conf.template should move from unix to solaris

On 10/09/2018 09:10, Magnus Ihse Bursie wrote: : Updated patch, which copies the SDP template for linux too: diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk --- a/make/copy/Copy-java.base.gmk +++ b/make/copy/Copy-java.base.gmk @@ -183,7 +183,7 @@  TARGETS +=

Re: RFR: JDK-8059019 sdp.conf.template should move from unix to solaris

On 05/09/2018 13:58, Magnus Ihse Bursie wrote: The file sdp.conf.template is copied only when building for solaris, but it resides in the unix source directory. SDP is legacy now and we should probably think about removing it, esp. with the rsocket support in the works. In the mean time, as

8210087: Classes in jdk.unsupported not accessible from jconsole plugin

JDK-8210087 [1] is an issue with the launcher generated for jconsole. The launcher needs to be compiled with --add-modules ALL-DEFAULT so that plugins compiled (and run) in an unnamed module can make use of exported APIs in modules that aren't resolved by jdk.jconsole. The change is trivial:

Re: 8202794: Native Unix code should use readdir rather than readdir_r

On 03/08/2018 20:26, t...@tedneward.com wrote: Hey, all; did this get resolved? I'm still getting this error in pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer not to make local changes (mostly I want to build debug builds so I can spelunk the JVM bits), but if this isn't

Re: RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs builds

On 03/08/2018 00:21, David Holmes wrote: On 3/08/2018 4:59 PM, Baesken, Matthias wrote: Thank  you  David ,  can the change be pushed ,  or do I need a second review for an XS change  ? (any way a second review would be good  ) Need a review from official build team member :) I'm not in

Re: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 / JDK-8205621: Increment JDK version for JDK 12

On 25/06/2018 19:10, joe darcy wrote: Hello, With the JDK 11 and 12 split fast approaching [1], it is time to work on the various start of release update tasks for JDK 12. Those tasks are being tracked under the umbrella bug JDK-8205615: "Start of release updates for JDK 12". This thread

Re: RFR: JDK-8200132: Remove jre images and bundles

On 04/06/2018 22:22, Erik Joelsson wrote: Given the feedback, I have revised the patch to restore the ability to produce a legacy jre image, but it is still removed from the default "product-images" and "images" targets. To build it you need to specify it explicitly as "legacy-jre-image" (or

Re: RFR: JDK-8200132: Remove jre images and bundles

On 04/06/2018 21:40, Bob Vandette wrote: : I could live with a jlink option to create a JRE. The problem is that the list of modules required to produce a compatible JRE is not documented anywhere. I tried fishing the list out of the build makefile but it’s not trivial. I ended up running

Re: RFR: JDK-8200132: Remove jre images and bundles

On 04/06/2018 20:45, Bob Vandette wrote: If we do this, shouldn’t we provide an aggregator module to allow developers to easily create a Java runtime with the same list of modules?  AFAIK, this doesn’t exists. The java.se  module is not the same.  It’s missing many modules.

Re: RFR: JDK-8200132: Remove jre images and bundles

On 02/06/2018 15:07, Magnus Ihse Bursie wrote: It is probably relatively trivial to add a configure option to select just the "JRE modules" when building, rather than all modules. If we add such an option, it would still be possible to build a traditional JRE, not just at the same time as

Re: RFR: JDK-8200132: Remove jre images and bundles

On 02/06/2018 08:05, Aleksey Shipilev wrote: : Unfortunately, in the age of containers, distribution size matters. It makes the whole sense to ship JRE in Docker containers to provide the execution environment for the upper layers. Remember, hardly any application is fully modularized and/or

Re: RFR: JDK-8200132: Remove jre images and bundles

On 01/06/2018 23:02, Erik Joelsson wrote: Since JDK 9 and modules, the idea of a prebuilt JRE is no longer providing much value. The idea is rather that you link together an image with the modules and settings you actually need, either with or without your application. For this reason oracle

Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

On 04/05/2018 16:31, B. Blaser wrote: : I'll create a new JBS issue (unless you want to) since the fix is mostly located in core-libs and only intended to make the build complete. But I'll still need someone to review and push the fix, would you be interested in doing this? I think someone

Re: RFR: JDK-8196113: Remove the Compact Profile builds

On 30/04/2018 21:19, Erik Joelsson wrote: Compact profiles were added in JDK 8, and superceded by modules in JDK 9. The build logic for compact profiles was left in place in 9, but as we head into 11 it is time to remove this. This patch removes all the build logic related to that. Bug:

Re: RFR 8202210: jlink uses little-endian for big-endian cross-compilation targets

On 25/04/2018 10:06, Aleksey Shipilev wrote: Hi, I was doing the exercise of cross-compiling from x86_64 to most OpenJDK arches, and we have discovered the bug with endianness. Right now, compiling big-endian s390x target on little-endian x86_64 host produces the modules blob that cannot be

Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

Adding core-libs-dev as this is change code in libjava, libzip, libjimage, ... Can you confirm that this is the up to date webrev:    http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ As I read it, this changes the calling convention of these functions on 32-bit Windows but it will have

Re: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10

On 04/04/2018 22:00, Jonathan Gibbons wrote: Erik, Why bother?  What are you trying to achieve? Either the boot JDK is JDK 9, or it is JDK 10.  This should be a clear decision. If internally at Oracle, we use 10, then as soon as code creeps in that relies on 10 features, we've broken the

Re: (urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure

This revert looks okay to me. I see Tim is going to push it for you. -Alan On 29/03/2018 15:18, Erik Joelsson wrote: The removal of mapfiles didn't completely work out. On Solaris we now get the following build error: "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c",

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

On 28/03/2018 22:48, Magnus Ihse Bursie wrote: 2) The exported symbols from executables are a public API and the change therefore require a CSR. I don't think there are any supported/documented interfaces here. It would be nice if the launchers were linked without any exported symbols, that

Re: [11] Review Request: 8200198 javah man pages were not removed by JDK-8191054

On 26/03/2018 00:44, Sergey Bylokhov wrote: On 24/03/2018 00:32, Alan Bateman wrote: This looks okay. Are we sure we've got everything now? (as this will be the fourth change to remove pieces of javah). Fix updated, there were some links to javah from other man pages: http

Re: [11] Review Request: 8200198 javah man pages were not removed by JDK-8191054

On 24/03/2018 06:03, Sergey Bylokhov wrote: Hello. Please review fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8200198 Webrev can be found at: http://cr.openjdk.java.net/~serb/8200198/webrev.00 This looks okay. Are we sure we've got everything now? (as this will be the fourth

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

On 23/03/2018 15:15, Magnus Ihse Bursie wrote: : Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports. The changes looks good to me and I think we should follow this up

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

On 23/03/2018 13:56, Magnus Ihse Bursie wrote: With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so

Re: RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass

On 14/03/2018 12:56, Chris Hegarty wrote: This is a review request to remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass. JDK-8179424 removed terminally deprecated jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these references are to the no-args

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

On 28/02/2018 19:54, Lance Andersen wrote: : Is there any XA text from the original JTA spec that should be added to the module description as part of this? Another way to ask this is whether the JTA 1.3 drops any text dealing with the XA part. Still waiting to see what changes are made to

<    1   2   3   4   5   6   7   >