Re: RFR: 8284209: Replace remaining usages of 'a the' in source code [v3]
On Tue, 24 May 2022 09:52:29 GMT, Alexey Ivanov wrote: >> Replaces usages of articles that follow each other in all combinations: >> a/the, an?/an?, the/the… >> >> It's the last issue in the series, and it still touches different areas of >> the code. > > Alexey Ivanov has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright to 2022 Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8771
Re: RFR: 8287155: Additional make typos
On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote: > Testing ispell + shell magic to locate typos. It worked, but is not scalable > to the entire JDK. :-( Keep the fixes for the problems found in the make > directory, though. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8837
Re: RFR: 8284209: Replace remaining usages of 'a the' in source code
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > It's the last issue in the series, and it still touches different areas of > the code. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8771
Re: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2]
On Fri, 13 May 2022 14:39:44 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the failure >> handler command `dmesg` on macOS? >> >> As noted in the JBS issue, the command currently fails with permission >> error. The commit in this PR uses `sudo` as suggested in the man pages of >> that command. >> >> Tested locally on macOS by running: >> >> >> cd test/failure_handler >> make clean >> make test >> >> Then checked the generated environment.html files for the dmesg command >> output. Looks fine after this change. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > copyright year looks ok to me - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8703
Re: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes > bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 > systems for several months now. After investigation we have been able to > ascertain that the root cause of the issue lies within the zlib that's > shipped on macos aarch64 systems. The complete details about that issue is > available at https://bugs.openjdk.java.net/browse/JDK-8282954. > We have filed a bug with Apple for their inputs on what we can do to fix it > in that shipped library. Given the nature of that issue, we don't have a > timeline on when/if the solution for that will be available. Until that time, > at least, the proposal is to use bundled zlib (which doesn't reproduce those > failures) by default on macos aarch64. Hi Jai, Thank you for your efforts with testing and reaching out to Apple. Given we do not see the issue with the bundled zlib, this is our best path forward for stability on macOS aarch64. Once we can determine the cause with the help of Apple, we can switch back to the zlib that comes with macOS on this platform. - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8675
Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos >> when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system >> zlib variants). >> >> tier1, tier2 and tier3 testing has been done and no related failures have >> been noticed. > > Jaikiran Pai has updated the pull request incrementally with four additional > commits since the last revision: > > - copyright years > - disable format-nonliteral warning when building LIBSPLASHSCREEN with > bundled zlib > - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file > - Magnus' suggestion - Disable format-nonliteral in build section of zlib > instead of source code Thanks Jai for the latest tweaks to the our original patch. I think we should be good to go - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8651
Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]
On Wed, 11 May 2022 22:03:38 GMT, Magnus Ihse Bursie wrote: > It would not make sense to set the disabled warning in the configure script, > no. The current code looks perfectly fine. Disabled warnings per module are > set in the makefiles. OK, that you for your feedback regarding the makefile changes vs. configure script. > > If you feel strongly that this needs to be documented more than in the JBS > issue and this PR review, updating the zlib ChangeLog file is probably the > way to go. I have no strong opinion on that. But from the build system PoV, > the current code is fine as it is to be committed. OK, I am probably overthinking the need to document this - PR: https://git.openjdk.java.net/jdk/pull/8651
Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]
On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional >> commits since the last revision: >> >> - copyright years >> - disable format-nonliteral warning when building LIBSPLASHSCREEN with >> bundled zlib >> - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file >> - Magnus' suggestion - Disable format-nonliteral in build section of zlib >> instead of source code > > make/autoconf/lib-bundled.m4 line 220: > >> 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then >> 219: LIBZ_CFLAGS="$LIBZ_CFLAGS >> -I$TOPDIR/src/java.base/share/native/libzip/zlib" >> 220: if test "x$OPENJDK_TARGET_OS" = xmacosx; then > > Please add a comment here as to why we are doing this > @LanceAndersen Is that really needed? We normally don't comment on the reason > why certain code needs certain defines. We tried to document some compiler > flags in the beginning, but it turned out that most command lines ended up as > essays, and this were not helpful. I think it's quite obvious what this code > does: libz requires the define HAVE_UNISTD_H on macOS. I'm not even sure how > you'd formulate a "why" -- "otherwise it does not work properly"? The zlib configure script, which needs to be run prior running make to build the upstream repository, will determine if HAVE_UNISTD_H is needed and generate zconf.h replacing the macro with "1".My reason for adding a comment as this is a variant from how zlib is built upstream. Perhaps just updating open/src/java.base/share/native/libzip/zlib/ChangeLog is enough. I was just trying to document why we are doing this. Another question would it make sense to set LIBZ_DISABLED_WARNINGS_CLANG in make/autoconf/lib-bundled.m4 so that the value in the case of zlib is set in one location? In addition, I can log a request to address this in the upstream project so we do not need to worry about this warning going forward. - PR: https://git.openjdk.java.net/jdk/pull/8651
Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos >> when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system >> zlib variants). >> >> tier1, tier2 and tier3 testing has been done and no related failures have >> been noticed. > > Jaikiran Pai has updated the pull request incrementally with four additional > commits since the last revision: > > - copyright years > - disable format-nonliteral warning when building LIBSPLASHSCREEN with > bundled zlib > - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file > - Magnus' suggestion - Disable format-nonliteral in build section of zlib > instead of source code Hi Jai, thank you for continuing the work to allow us to build/use the bundled zlib on macOS we should also update: open/src/java.base/share/native/libzip/zlib/ChangeLog to add a comment regarding why the build changes were required make/autoconf/lib-bundled.m4 line 220: > 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then > 219: LIBZ_CFLAGS="$LIBZ_CFLAGS > -I$TOPDIR/src/java.base/share/native/libzip/zlib" > 220: if test "x$OPENJDK_TARGET_OS" = xmacosx; then Please add a comment here as to why we are doing this make/modules/java.base/lib/CoreLibraries.gmk line 139: > 137: DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \ > 138: DISABLED_WARNINGS_clang := format-nonliteral, \ > 139: LDFLAGS := $(LDFLAGS_JDKLIB) \ A comment would be good here also as to the reasoning make/modules/java.desktop/lib/Awt2dLibraries.gmk line 683: > 681: ifeq ($(USE_EXTERNAL_LIBZ), false) > 682: LIBSPLASHSCREEN_EXTRA_SRC += java.base:libzip/zlib > 683: LIBZ_DISABLED_WARNINGS_CLANG := format-nonliteral Same here for a comment - PR: https://git.openjdk.java.net/jdk/pull/8651
Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]
On Wed, 11 May 2022 14:25:39 GMT, Jaikiran Pai wrote: >> I agree with Magnus and try to avoid changing the imported zlib code. > >> I did these changes locally but for some reason this format-nonliteral is >> not getting picked up while building that library. > > Turns out that was slightly inaccurate. What was actually happening was that, > that setting you suggested in that build file did indeed work and got picked > up. But it ran into an error which looked like: > > > src/java.base/share/native/libzip/zlib/gzwrite.c:452:40: error: format string > is not a string literal [-Werror,-Wformat-nonliteral] > len = vsnprintf(next, state->size, format, va); >^~ > I agree with Magnus and try to avoid changing the imported zlib code. We already had modified gzwrite.c in our port so I thought keeping the changes narrowed to apple made sense here. - PR: https://git.openjdk.java.net/jdk/pull/8651
Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo What problem are you having editing the PR header? You should be able to do so as the author of the PR - PR: https://git.openjdk.java.net/jdk/pull/7268
Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo The changes look OK. The copyright year probably should be updated as part of this PR - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268
Re: RFR: 8279877: Document IDEA IDE setup in docs/ide.md [v2]
On Wed, 12 Jan 2022 14:46:54 GMT, Daniel Jelinski wrote: >> Currently the information about using IDEA can only be found on mailing >> lists. >> >> Additionally fixed the documentation for Visual Studio; the target >> `ide-project` does not exist. > > Daniel Jelinski has updated the pull request incrementally with one > additional commit since the last revision: > > Improved wording > I think you are good to go with your latest set of changes. > > Not sure if you want to refer to the idea.sh -h for additional options > (though that does not seem to give you any detail regarding the options) > > Not sure if you want to refer to the idea.sh -h for additional options > > I'm not sure about that either. These options are usually not required, and > the -h output leaves something to be desired. I'd rather keep the current > version, and only expand if users start asking. > > /integrate Works for me. BTW typically we do the /integrate in a separate comment but it seems to have worked her - PR: https://git.openjdk.java.net/jdk/pull/7044
Re: RFR: 8279877: Document IDEA IDE setup in docs/ide.md [v2]
On Wed, 12 Jan 2022 14:46:54 GMT, Daniel Jelinski wrote: >> Currently the information about using IDEA can only be found on mailing >> lists. >> >> Additionally fixed the documentation for Visual Studio; the target >> `ide-project` does not exist. > > Daniel Jelinski has updated the pull request incrementally with one > additional commit since the last revision: > > Improved wording I think you are good to go with your latest set of changes. Not sure if you want to refer to the idea.sh -h for additional options (though that does not seem to give you any detail regarding the options) - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7044
Re: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
On Wed, 12 Jan 2022 12:10:50 GMT, Daniel Jelinski wrote: > > (...) As far as I am aware, the ide.html should be generated from the > > ide.md so you should only need to modify ide.md > > Are you sure about this? The discussion on #5676 suggests that the HTML files > need to be modified. > > I wouldn't mind not having to edit htmls; `make update-build-docs` is broken > on Cygwin, and I had to fix paths in compile commands manually. Yes pandoc as far as I am aware should be generating the html so lets wait for Erik to comment as it seems strange to have to do both and would be better to address the issue so only one file needs updated if there is indeed an issue. - PR: https://git.openjdk.java.net/jdk/pull/7044
Re: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
On Wed, 12 Jan 2022 07:29:33 GMT, Daniel Jelinski wrote: > Currently the information about using IDEA can only be found on mailing lists. > > Additionally fixed the documentation for Visual Studio; the target > `ide-project` does not exist. Thank you for taking a stab at this. As far as I am aware, the ide.html should be generated from the ide.md so you should only need to modify ide.md doc/ide.md line 88: > 86: ``` > 87: > 88: This creates a subfolder called `.idea` in the current folder. To use it, I might consider rewording this. Typically this is run at the top of the your openjdk fork/clone. - PR: https://git.openjdk.java.net/jdk/pull/7044
Re: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from > version 13 to version 14. Corresponding CSR has also been drafted. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6974
Re: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote: > This PR enables reproducible Jars, Jmods and openjdk image zip files > (eg.src.zip). > It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying > ZipOutputStream's. > It fixes the following keys issues relating to reproducibility: > - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware > - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting > - Jar and Jmod file content ordering was non-determinsitic > - Fixes to Jar and Jmod main's to ensure sorted classes content ordering > - openjdk image zip file generation used "zip" which is non-determinsitic > - New openjdk build tool "GenerateZip" which produces the final > determinsitic zip files as part of the build and also detects > SOURCE_DATE_EPOCH > > Signed-off-by: Andrew Leonard Thank you for your contribution Andrew. Thank you for your efforts here Andrew. A few comments in addition to what have already been mentioned by others on a very quick scan. For new tests, please consider using TestNG. src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 795: > 793: // Ensure files list is sorted for reproducible jar content > 794: Arrays.sort(files); > 795: Have you had a chance to measure the performance with a large number of Zip entries with this change? test/jdk/java/util/zip/TestZipSourceDateEpoch.sh line 1: > 1: #!/bin/sh Unless there is a specific reason to use a shell script, it would be better to convert this to java. We have been trying to reduce the usage of shell scripts - PR: https://git.openjdk.java.net/jdk/pull/6268
Re: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2]
On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by >> default. jtreg 6.1 does not set its own security manager if JDK version is >> >= 18. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6012
Re: RFR: 8274658: ISO 4217 Amendment #170 Update
On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment #170, which has been released > today, effective immediately. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5790
Re: RFR: 8274083: Update testing docs to mention tiered testing [v6]
On Fri, 24 Sep 2021 06:12:20 GMT, Aleksey Shipilev wrote:
>> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions,
>> let's mention them in `testing.md`.
>>
>> Current patch is my braindump, I am open for suggestions :)
>
> Aleksey Shipilev has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Another minor touchup
Looks good to me.
-
PR: https://git.openjdk.java.net/jdk/pull/5615
Re: RFR: 8268267: Remove -Djavatest.security.noSecurityManager=true from jtreg runs
On Fri, 4 Jun 2021 15:53:42 GMT, Weijun Wang wrote: > Now that the default behavior of JDK 17 is still > `-Djava.security.manager=allow`, we can remove the > `-Djavatest.security.noSecurityManager=true` option from the jtreg command > line inside `RunTests.gmk`. Three problem-listed langtools tests can also be > liberated. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4364
Re: RFR: JDK-8266254: Update to use jtreg 6
On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the > version of jtreg to use, for those systems that rely on this file. In > addition, the `requiredVersion` has been updated in the various `TEST.ROOT` > files. > > All the tests that could be updated ahead of time have been updated. There > are a few tests remaining that need to be done at this time, because of the > change in the module name for TestNG 7.3. It changed from a default of > `testng` to and explicit `org.testng`. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4315
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6]
On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 >> The essential change for this JEP, including the `@Deprecate` annotations >> and spec change. It also update the default value of the >> `java.security.manager` system property to "disallow", and necessary test >> change following this update. >> 2. >> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 >> Manual changes to several files so that the next commit can be generated >> programatically. >> 3. >> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 >> Automatic changes to other source files to avoid javac warnings on >> deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is >> generated programmatically, see the comment below for more details. If you >> are only interested in a portion of the 3rd commit and would like to review >> it as a separate file, please comment here and I'll generate an individual >> webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for >> any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system >> property is now "disallow", most of the tests calling >> `System.setSecurityManager()` need to launched with >> `-Djava.security.manager=allow`. This is covered in a different PR at >> https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, >> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are >> reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > default behavior reverted to allow Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4073
Re: RFR: JDK-8262315: missing ';' in generated entities
On Wed, 24 Feb 2021 17:45:19 GMT, Jonathan Gibbons wrote: > Fix typo-by-omission. A `;` is missing after ``. > > This is in the build tools, in the code for the `@jls` taglet, used to > generate docs. No change to JDK product code. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2709
Re: RFR: 8251549: Update docs on building for Git
On Sat, 5 Sep 2020 20:13:18 GMT, Joe Darcy wrote: > 8251549: Update docs on building for Git Hi Joe, This looks OK.Are similar changes being made to http://openjdk.java.net/guide/producingChangeset.html as well given it refers to mercurial? - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/21
Re: Documenting options; was Re: RFR: JDK-8220639 Need a way to augment JTREG_LAUNCHER_OPTIONS from command-line
Hi Magnus, Can we update this page to include an example of how to run a JTREG manual test via the make infrastructure? Best Lance > On Jun 16, 2020, at 8:26 AM, Magnus Ihse Bursie > wrote: > > On 2020-06-16 04:33, Jonathan Gibbons wrote: >> Thanks; I'll link to that page from the jtreg FAQ. > ... but please use the tip URL: > https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/testing.html > > Actually, that link is going to get stale in just a few months time. Probably > better to link here directly: > > https://github.com/openjdk/jdk/blob/master/doc/testing.md > > /Magnus > >> >> -- Jon >> >> On 6/15/20 2:23 PM, Erik Joelsson wrote: >>> The makefile test documentation is in the repo, so you could link directly >>> to it: >>> >>> https://hg.openjdk.java.net/jdk/jdk/raw-file/87828d2e32fe/doc/testing.html >>> >>> Which reminds me that Magnus should update that documentation with these >>> new options. >>> >>> /Erik >>> >>> On 2020-06-15 14:19, Jonathan Gibbons wrote: >>>> Magnus, >>>> >>>> Would it be worth while adding something to the jtreg documentation, such >>>> as a new page describing these options for the JDK makefile support, >>>> giving due deference to the makefile (like "If in doubt, consult `make >>>> test JTREG=help`") >>>> >>>> I can write the page, with your help, if you think this would be a good >>>> idea. >>>> >>>> -- Jon >>>> >>>> On 6/15/20 8:56 AM, Magnus Ihse Bursie wrote: >>>>> It turned out that it was not possible to send arguments directly to the >>>>> java that launches jtreg, something that was needed, especially to change >>>>> the output limit using Djavatest.maxOutputSize. >>>>> >>>>> This patch adds JTREG=LAUNCHER_OPTIONS=xxx to pass generic options to the >>>>> launcher. Also, for the specific case of changing the max output size, it >>>>> adds JTREG=MAX_OUTPUT=nnn. >>>>> >>>>> All these new options made me realize there's no way apart from reading >>>>> the code to know what options are available, so I added a help system, >>>>> and documented this in "make help". Now you can get: >>>>> >>>>> $ make test JTREG=help >>>>> Building target 'test' in configuration 'linux-x64' >>>>> Valid keywords for JTREG: >>>>> JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE >>>>> RETAIN MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT MAX_OUTPUT OPTIONS >>>>> JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS AOT_MODULES >>>>> LAUNCHER_OPTIONS. >>>>> RunTests.gmk:292: *** Re-run without 'help' to continue. Stop. >>>>> >>>>> Finally, I fixed some broken comments regarding AOT that I noticed while >>>>> fixing this. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220639 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8220639-add-jtreg-launcher-options/webrev.01 >>>>> >>>>> /Magnus > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR 15 8225319: Remove the RMI static stub compiler rmic
Hi Roger, This looks good and brought back memories of removing the Java EE modules :-) Best Lance > On Apr 3, 2020, at 11:43 AM, 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 or relying on rmic > - update or remove makefiles to remove references and dependencies on rmic > - update source files in java.rmi module to remove extraneous references to > rmic > > Wevrev: > http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 > > Thanks, Roger > > [1] CSR: > https://bugs.openjdk.java.net/browse/JDK-8242049 > > [2] Issue: > https://bugs.openjdk.java.net/browse/JDK-8225319 > > [3] Deprecate rmic for removal > https://bugs.openjdk.java.net/browse/JDK-8217412 > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR [15] 8238918 idea.sh should work with both mercurial and git repo
+1 > On Feb 11, 2020, at 5:29 PM, Roger Riggs wrote: > > Please review a small change to the idea.sh script that generates an IntelliJ > project. > It detects either Mercurial or Git repos and generates the appropriate > vcs.xml. > > Webrev: >http://cr.openjdk.java.net/~rriggs/webrev-idea-git-8238918/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8238918 > > Thanks, Roger > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: [14] Review Request: JDK-8231027 Correct typos
Looks fine Sergey > On Sep 16, 2019, at 5:50 PM, Sergey Bylokhov > wrote: > > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231027 > Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00 > > One common typo is fixed across a few components like client, build, and > hotspot. > > -- > Best regards, Sergey. <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
hg/python issues on Sierra(OS X 10.12.6)
ifi Successfully installed certifi-2019.6.16 You are using pip version 18.1, however version 19.1.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command. -- removing any existing file or link -- creating symlink to certifi certificate bundle -- setting permissions -- update complete ljanders-mac:Python 2.7 ljanders$ — If you do not you will receive the following error accessing an https URL (you could also work around it by: export PYTHONHTTPSVERIFY=0), for example: $ python URLTest.py Testing urllib2! Loading author names ... accessing db.open.jdk.java.net/people. calling urlopen Traceback (most recent call last): File "URLTest.py", line 28, in load_authors() File "URLTest.py", line 17, in load_authors f = urllib2.urlopen(req) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 154, in urlopen return opener.open(url, data, timeout) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 429, in open response = self._open(req, data) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 447, in _open '_open', req) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 407, in _call_chain result = func(*args) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1241, in https_open context=self._context) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1198, in do_open raise URLError(err) urllib2.URLError: ljanders-mac:JDK13-examples ljanders$ <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR: S, 13 JDK-8226628 The copyright footer should be enclosed in
+1 > On Jun 21, 2019, at 8:22 PM, Jonathan Gibbons > wrote: > > Please review a small change to make/Docs.gmk so that the copyright footer > added to specs pages is enclosed in > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226628 > > -- Jon > > > $ hg diff -R open > diff -r 179204eb9444 make/Docs.gmk > --- a/make/Docs.gmk Fri Jun 21 12:09:07 2019 -0700 > +++ b/make/Docs.gmk Fri Jun 21 17:14:56 2019 -0700 > @@ -532,7 +532,7 @@ > # file. The number 0-2 below represent how many extra directory levels down > # below the specs dir the specs html file is located. Each file name is > # stored in a variable SPECS_BOTTOM_FILE_$n where $n is 0, 1 or 2. > -SPECS_BOTTOM = $(COPYRIGHT_BOTTOM) > +SPECS_BOTTOM = $(COPYRIGHT_BOTTOM) > # The legal dir is one ../ below the specs dir, so start with one ../. > specs_bottom_rel_path := ../ > $(foreach n, 0 1 2, \ > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR XXS,docs JDK-8225346: Convert file to HTML5
+1 > On Jun 5, 2019, at 11:21 AM, Jonathan Gibbons > wrote: > > Please review a trivial fix to change the doctype for a file from HTML 4 to > HTML 5. This gets the file off the doccheck radar. > > No webrev; patch below. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225346 > > $ hg diff -R open > diff -r f4df9d4201cc make/data/docs-resources/index.html > --- a/make/data/docs-resources/index.htmlTue Jun 04 16:50:25 2019 -0700 > +++ b/make/data/docs-resources/index.htmlWed Jun 05 08:11:55 2019 -0700 > @@ -1,4 +1,4 @@ > - > + >
Re: RFR: JDK-8215304 Make target "docs-jdk-index" has unnecessary dependencies
Looks OK Magnus > On Dec 12, 2018, at 1:00 PM, Magnus Ihse Bursie > wrote: > > The target docs-jdk-index has dependencies that are quite heavyweight, and > are not needed. They should just be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215304 > Patch inline: > diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -862,8 +862,6 @@ > docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ > docs-jdk-index > > - docs-jdk-index: exploded-image buildtools-modules > - > docs-zip: docs-jdk > > # Tests > > /Magnus <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR: JDK-8214910 If pandoc is present, markdown spec files should be processed
Hi Magnus The patch looks good. I also verified that ‘make docs’ generates the spec with the patch Thank you for addressing this. > On Dec 10, 2018, at 10:14 AM, Magnus Ihse Bursie > wrote: > > If pandoc is available, specs should be built, even if full docs is not > enabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214910 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214910-create-specs-if-pandoc-present/webrev.01 > > /Magnus <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR: JDK-8213237 Remove test-compile-commands from jib-profiles.js
+1
> On Nov 1, 2018, at 6:06 AM, Magnus Ihse Bursie
> wrote:
>
> In JDK-8210958, a broken version of jib-profiles.js was unfortunately checked
> in.
>
> The change at
> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.02/make/conf/jib-profiles.js.udiff.html,
> as reviewed, was unfortunately reverted in the process.
>
> Without this fix, the *-testmake profiles fails when run.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213237
> Patch inline:
> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js
> --- a/make/conf/jib-profiles.js
> +++ b/make/conf/jib-profiles.js
> @@ -485,7 +485,7 @@
> .forEach(function (name) {
> var maketestName = name + "-testmake";
> profiles[maketestName] = concatObjects(profiles[name],
> testmakeBase);
> -profiles[maketestName].default_make_targets = [ "test-make",
> "test-compile-commands" ];
> +profiles[maketestName].default_make_targets = [ "test-make" ];
> });
>
> // Profiles for building the zero jvm variant. These are used for
> verification.
>
> /Magnus
> (Sorry for the mess :-()
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR: XXS: JDK-8213102: Oracle Unilinks are [301 Moved Permanently] to https://docs.oracle.com
looks fine jon
> On Oct 29, 2018, at 2:57 PM, Jonathan Gibbons
> wrote:
>
> Please review the following simple fix to change the host for Oracle Unilinks
> from www.oracle.com to docs.oracle.com to avoid unnecessary redirects.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8213102
>
> The fix was done with the following command:
>
> grep -rl oracle.com/pls open/make | xargs sed --in-place
> 's|www.oracle.com/pls|docs.oracle.com/pls|g'
>
> -- Jon
>
>
> Patch inline:
>
> $ hg diff -R open
> diff -r 3152b928769d make/Docs.gmk
> --- a/make/Docs.gmk Mon Oct 29 11:05:45 2018 -0700
> +++ b/make/Docs.gmk Mon Oct 29 11:45:11 2018 -0700
> @@ -61,7 +61,7 @@
> $(SUPPORT_OUTPUTDIR)/rmic/* $(TOPDIR)/src/*/share/doc/stub)
>
> # URLs
> -JAVADOC_BASE_URL :=
> https://www.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)id=homepage
> +JAVADOC_BASE_URL :=
> https://docs.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)id=homepage
> BUG_SUBMIT_URL := https://bugreport.java.com/bugreport/
> COPYRIGHT_URL := {@docroot}/../legal/copyright.html
> LICENSE_URL :=
> https://www.oracle.com/technetwork/java/javase/terms/license/java$(VERSION_NUMBER)speclicense.html
> diff -r 3152b928769d make/jdk/src/classes/build/tools/taglet/ExtLink.java
> --- a/make/jdk/src/classes/build/tools/taglet/ExtLink.java Mon Oct 29
> 11:05:45 2018 -0700
> +++ b/make/jdk/src/classes/build/tools/taglet/ExtLink.java Mon Oct 29
> 11:45:11 2018 -0700
> @@ -48,7 +48,7 @@
> * will produce the following html
> *
> * {@code
> - * Please see href="https://www.oracle.com/pls/topic/lookup?ctx=javase10=Borealis;>a
> spectacular sight.
> + * Please see href="https://docs.oracle.com/pls/topic/lookup?ctx=javase10=Borealis;>a
> spectacular sight.
> * }
> */
> public class ExtLink implements Taglet {
> @@ -63,7 +63,7 @@
>
> static final String TAG_NAME = "extLink";
>
> -static final String URL =
> "https://www.oracle.com/pls/topic/lookup?ctx=javase; +
> +static final String URL =
> "https://docs.oracle.com/pls/topic/lookup?ctx=javase; +
> SPEC_VERSION + "id=";
>
> static final Pattern TAG_PATTERN =
> Pattern.compile("(?s)(\\s*)(?\\w+)(\\s+)(?.*)$");
>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR(XS): 8212994: Links to Oracle websites should use "https:"
+1 > On Oct 25, 2018, at 4:33 PM, Iris Clark wrote: > > Hi. > > Please review changes to use "https" instead of "http" for links in the > generated JavaDoc API pages: > > 8212994: Links to Oracle websites should use "https:" > bug: https://bugs.openjdk.java.net/browse/JDK-8212994 > webrev: https://cr.openjdk.java.net/~iris/8212994/webrev/ > > I did a full "make docs" build and verified that the old links are > no longer in the created image. > > Thanks, > iris > > $ pwd > /u/iris/se/full-jdk/build/images > > $ find . -name "*.html" -print | xargs grep > "http://www.oracle.com/technetwork/java/redist-137594.html; | wc -l > 0 > $ find . -name "*.html" -print | xargs grep > "https://www.oracle.com/technetwork/java/redist-137594.html; | wc -l > 20312 > > ## link in banner and footer > $ find . -name "*.html" -print | xargs grep > "http://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html; > | wc -l > 0 > $ find . -name "*.html" -print | xargs grep > "https://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html; > | wc -l > 40624 > > $ find . -name "*.html" -print | xargs grep > "http://bugreport.java.com/bugreport/; | wc -l > 0 > $ find . -name "*.html" -print | xargs grep > "https://bugreport.java.com/bugreport/; | wc -l > 20312 > > $ find . -name "*.html" -print | xargs grep > "http://www.oracle.com/pls/topic/lookup?ctx=javase12\\;id=homepage; | wc > -l > 0 > $ find . -name "*.html" -print | xargs grep > "https://www.oracle.com/pls/topic/lookup?ctx=javase12\\;id=homepage; | wc > -l > 20312 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR: JDK 11 P1: 8209806: API docs should be updated to refer to javase11
looks fine Jon > On Aug 21, 2018, at 2:58 PM, Jonathan Gibbons > wrote: > > Please review a simple high priority fix for JDK 11 that updates the link in > the bottom of each page of the generated API docs. > > Instead of simply changing "10" to "11", the fix is to use the macro > $(VERSION_NUMBER) instead, in line with other URLs nearby in the same > makefile, and in the ExtLink taglet [1] > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209806 > Webrev: http://cr.openjdk.java.net/~jjg/8209806/webrev.00/index.html > > [1]: > http://hg.openjdk.java.net/jdk/jdk11/file/ed52ea83f830/make/jdk/src/classes/build/tools/taglet/ExtLink.java#l66 > > -- Jon <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: [12] RFR JDK-8167314: Enable the check to detect duplicate provides in in GenModuleInfoSource
looks good Mandy On Aug 20, 2018, at 6:35 PM, mandy chung wrote: > A simple patch to enable the check to enforce no duplicate provides > in module-info.java.extra, same checks as javac. This check > was disabled in the fix for JDK-8202941 because of duplicated > provides generated for jdk.internal.vm.compiler. Since JDK-8208463 > is now resolved [1], we can enable this check. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8167314/webrev.00/ > > Mandy > [1] http://hg.openjdk.java.net/jdk/jdk/rev/c5461fe16efb Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR: 8208157: requires.VMProps throws NPE for missing properties in "release" file
Looks fine shura
> On Jul 24, 2018, at 6:48 PM, Alexandre (Shura) Iline
> wrote:
>
> Hi,
>
> Could you please tale a quick look on this simple fix?
>
> diff --git a/test/jtreg-ext/requires/VMProps.java
> b/test/jtreg-ext/requires/VMProps.java
> --- a/test/jtreg-ext/requires/VMProps.java
> +++ b/test/jtreg-ext/requires/VMProps.java
> @@ -432,7 +432,8 @@
> System.getProperty("java.home") + "/release"))) {
> Properties properties = new Properties();
> properties.load(in);
> -return properties.getProperty("IMPLEMENTOR").replace("\"", "");
> +String implementorProperty =
> properties.getProperty("IMPLEMENTOR");
> +return (implementorProperty == null) ? "null" :
> implementorProperty.replace("\"", "");
> } catch (IOException e) {
> e.printStackTrace();
> }
>
>
> Thank you.
>
> Shura
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR: JDK-8205942: Build failure on macosx after JDK-8189429
I can verify the patch worked for me Erik Best Lance > On Jun 27, 2018, at 6:29 PM, Erik Joelsson wrote: > > For some users, the build fails with: > > dirname: illegal option -- s > usage: dirname path > usage: basename string [suffix] >basename [-a] [-s suffix] string [...] > error: cannot read file > /Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c > > Gensrc-jdk.hotspot.agent.gmk:52: recipe for target > '/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c' > failed > make[3]: *** > [/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c] > Error 1 > make/Main.gmk:112: recipe for target 'jdk.hotspot.agent-gensrc-src' failed > make[2]: *** [jdk.hotspot.agent-gensrc-src] Error 2 > make[2]: *** Waiting for unfinished jobs > > I have identified two reasons for failures here and this patch makes it work > for at least one reporter of the problem. The missing MakeTargetDir caues a > race where the target directory may not exist yet. It seems mig on newer > Macos handles this anyway. For some configurations, the SDKROOT variable does > not have a value. In that case, we should not set the -isysroot parameter to > mig. (I also changed the MKDIR in the other recipe to the now preferred > MakeTargetDir macro) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205942 > > Webrev: http://cr.openjdk.java.net/~erikj/8205942/webrev.01/ > > /Erik > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR JDK-8197533 move javax.transaction.xa into its own module
While running the JDK regression tests, I found a test that needed to be updated, test/langtools/tools/jdeps/modules/DotFileTest.java, due to the update to the java.sql module The updated webrev is at http://cr.openjdk.java.net/~lancea/8197533/webrev.03/ <http://cr.openjdk.java.net/~lancea/8197533/webrev.03/> Best Lance > On Mar 1, 2018, at 12:37 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > > +1 > >> On Mar 1, 2018, at 8:59 AM, Lance Andersen <lance.ander...@oracle.com >> <mailto:lance.ander...@oracle.com>> wrote: >>> >>> +1, i second Joe’s request to update package-info.java while we are >>> opportunistically cleaning this area up. >> >> Per your and Joe’s request, please see >> cr.openjdk.java.net/~lancea/8197533/webrev.02 >> <http://cr.openjdk.java.net/~lancea/8197533/webrev.02> which has your >> suggested update to use package-info.java >> >> Thank you both >> >> Best >> Lance > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR JDK-8197533 move javax.transaction.xa into its own module
> On Feb 28, 2018, at 8:29 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > > > >> On Feb 28, 2018, at 1:22 PM, Lance Andersen <lance.ander...@oracle.com >> <mailto:lance.ander...@oracle.com>> wrote: >> >>> >>> On Feb 28, 2018, at 2:20 PM, Lance Andersen <lance.ander...@oracle.com >>> <mailto:lance.ander...@oracle.com>> wrote: >>> >>> Hi Paul, >>> >>> Thank you for the review. >>>> On Feb 28, 2018, at 1:40 PM, Paul Sandoz <paul.san...@oracle.com >>>> <mailto:paul.san...@oracle.com>> wrote: >>>> >>>> Compatible module refactoring in action! >>>> >>>> Looks good, one comment: >>>> >>>> test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java >>>> >>>> This is not a valid Java source file can you merge the jtreg meta data >>>> into XAExceptionTests instead? >>> >>> As we discussed offline, I will change the above file and Driver.java. I >>> naively assumed this was OK as the change to add Driver.java was made >>> after I had originally added these tests in 2015. >> >> http://cr.openjdk.java.net/~lancea/8197533/webrev.01/ >> <http://cr.openjdk.java.net/~lancea/8197533/webrev.01/> has the updated tests > > +1, i second Joe’s request to update package-info.java while we are > opportunistically cleaning this area up. Per your and Joe’s request, please see cr.openjdk.java.net/~lancea/8197533/webrev.02 which has your suggested update to use package-info.java Thank you both Best Lance > > Paul. <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR JDK-8197533 move javax.transaction.xa into its own module
> On Feb 28, 2018, at 2:20 PM, Lance Andersen <lance.ander...@oracle.com> wrote: > > Hi Paul, > > Thank you for the review. >> On Feb 28, 2018, at 1:40 PM, Paul Sandoz <paul.san...@oracle.com >> <mailto:paul.san...@oracle.com>> wrote: >> >> Compatible module refactoring in action! >> >> Looks good, one comment: >> >> test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java >> >> This is not a valid Java source file can you merge the jtreg meta data into >> XAExceptionTests instead? > > As we discussed offline, I will change the above file and Driver.java. I > naively assumed this was OK as the change to add Driver.java was made after > I had originally added these tests in 2015. http://cr.openjdk.java.net/~lancea/8197533/webrev.01/ has the updated tests Best Lance > > Best > Lance >> >> Paul. >> >>> On Feb 28, 2018, at 10:25 AM, Lance Andersen <lance.ander...@oracle.com >>> <mailto:lance.ander...@oracle.com><mailto:lance.ander...@oracle.com >>> <mailto:lance.ander...@oracle.com>>> wrote: >>> >>> Hi all, >>> >>> This RFR request moves the javax.transaction.xa package out of the java.sql >>> module and into its own module java.transaction.xa. One of the motivators >>> for this change is due to the fact JSR 907 1.3 MR indicated that the >>> javax.transaction.xa package will be subsumed by Java SE. >>> >>> There should be no compatibility issues with this change. Any module that >>> `requires java.sql` will continue to have access to the public classes in >>> the javax.transaction.xa package at both compile-time and run-time. >>> >>> >>> The CSR has been approved >>> >>> The webrev can be found at: >>> http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ >>> >>> Best >>> Lance >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>>> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>>> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>>> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif >>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>>>Lance Andersen| >>> Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> >>> <mailto:lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>> >>> <mailto:lance.ander...@oracle.com >>> <mailto:lance.ander...@oracle.com><mailto:lance.ander...@oracle.com >>> <mailto:lance.ander...@oracle.com>>> > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR JDK-8197533 move javax.transaction.xa into its own module
> On Feb 28, 2018, at 2:43 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 28/02/2018 18:25, Lance Andersen wrote: >> Hi all, >> >> This RFR request moves the javax.transaction.xa package out of the java.sql >> module and into its own module java.transaction.xa. One of the motivators >> for this change is due to the fact JSR 907 1.3 MR indicated that the >> javax.transaction.xa package will be subsumed by Java SE. >> >> There should be no compatibility issues with this change. Any module that >> `requires java.sql` will continue to have access to the public classes in >> the javax.transaction.xa package at both compile-time and run-time. >> >> > I skipped the tests but everything else looks good. It is a compatible change > as you noted. Thank you Alan > > 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 the PDF spec, that is still needing to be completed. So I think for now, we go with what we have and can circle back if needed. Best Lance > > -Alan <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR JDK-8197533 move javax.transaction.xa into its own module
Hi Paul, Thank you for the review. > On Feb 28, 2018, at 1:40 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > > Compatible module refactoring in action! > > Looks good, one comment: > > test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java > > This is not a valid Java source file can you merge the jtreg meta data into > XAExceptionTests instead? As we discussed offline, I will change the above file and Driver.java. I naively assumed this was OK as the change to add Driver.java was made after I had originally added these tests in 2015. Best Lance > > Paul. > >> On Feb 28, 2018, at 10:25 AM, Lance Andersen <lance.ander...@oracle.com >> <mailto:lance.ander...@oracle.com>> wrote: >> >> Hi all, >> >> This RFR request moves the javax.transaction.xa package out of the java.sql >> module and into its own module java.transaction.xa. One of the motivators >> for this change is due to the fact JSR 907 1.3 MR indicated that the >> javax.transaction.xa package will be subsumed by Java SE. >> >> There should be no compatibility issues with this change. Any module that >> `requires java.sql` will continue to have access to the public classes in >> the javax.transaction.xa package at both compile-time and run-time. >> >> >> The CSR has been approved >> >> The webrev can be found at: >> http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ >> >> Best >> Lance >> <http://oracle.com/us/design/oracle-email-sig-198324.gif >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> >> <mailto:lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
RFR JDK-8197533 move javax.transaction.xa into its own module
Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. The CSR has been approved The webrev can be found at: http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: [11] RFR JDK-8197865: @moduleGraph taglet generates incorrect link to module graph
Change is pushed. Thank you Tim for the review
your change looks good Mandy...
Best
Lance
> On Feb 13, 2018, at 2:38 PM, Lance Andersen <lance.ander...@oracle.com> wrote:
>
> Hi Mandy
>
> I just submitted an RFR to build-dev so our emails crossed
>
>> On Feb 13, 2018, at 2:29 PM, mandy chung <mandy.ch...@oracle.com> wrote:
>>
>> Jon, Kumar,
>>
>> This is a regression from JDK-8195795 that generates
>> but module-summary.html
>> is under ${MODULE} directory. The correct link should be
>> a href="module-graph.png">...
>>
>> Lance - I include make/Docs.gmk fix here since the docs hangs.
>> Are you going to push a fix for it? If not, I can create
>> a separate issue and fix it.
>>
>> diff --git a/make/Docs.gmk b/make/Docs.gmk
>> --- a/make/Docs.gmk
>> +++ b/make/Docs.gmk
>> @@ -445,9 +445,9 @@
>>
>> # Setup generation of the Java SE API documentation (javadoc + modulegraph)
>>
>> -# The Java SE module scope is just java.se.ee and its transitive indirect
>> +# The Java SE module scope is just java.se and its transitive indirect
>> # exports.
>> -JAVASE_MODULES := java.se.ee
>> +JAVASE_MODULES := java.se
>>
>> $(eval $(call SetupApiDocsGeneration, JAVASE_API, \
>> MODULES := $(JAVASE_MODULES), \
>> diff --git a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
>> b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
>> --- a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
>> +++ b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
>> @@ -64,7 +64,7 @@
>> }
>>
>> String moduleName = ((ModuleElement)
>> element).getQualifiedName().toString();
>> -String imageFile = moduleName + "/module-graph.png";
>> +String imageFile = "module-graph.png";
>> int thumbnailHeight = -1;
>> String hoverImage = "";
>> if (!moduleName.equals("java.base")) {
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
>
>
>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: [11] RFR JDK-8197865: @moduleGraph taglet generates incorrect link to module graph
Hi Mandy
I just submitted an RFR to build-dev so our emails crossed
> On Feb 13, 2018, at 2:29 PM, mandy chung <mandy.ch...@oracle.com> wrote:
>
> Jon, Kumar,
>
> This is a regression from JDK-8195795 that generates
> but module-summary.html
> is under ${MODULE} directory. The correct link should be
> a href="module-graph.png">...
>
> Lance - I include make/Docs.gmk fix here since the docs hangs.
> Are you going to push a fix for it? If not, I can create
> a separate issue and fix it.
>
> diff --git a/make/Docs.gmk b/make/Docs.gmk
> --- a/make/Docs.gmk
> +++ b/make/Docs.gmk
> @@ -445,9 +445,9 @@
>
>
> # Setup generation of the Java SE API documentation (javadoc + modulegraph)
>
> -# The Java SE module scope is just java.se.ee and its transitive indirect
> +# The Java SE module scope is just java.se and its transitive indirect
> # exports.
> -JAVASE_MODULES := java.se.ee
> +JAVASE_MODULES := java.se
>
> $(eval $(call SetupApiDocsGeneration, JAVASE_API, \
> MODULES := $(JAVASE_MODULES), \
> diff --git a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
> b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
> --- a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
> +++ b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
> @@ -64,7 +64,7 @@
> }
>
> String moduleName = ((ModuleElement)
> element).getQualifiedName().toString();
> -String imageFile = moduleName + "/module-graph.png";
> +String imageFile = "module-graph.png";
> int thumbnailHeight = -1;
> String hoverImage = "";
> if (!moduleName.equals("java.base")) {
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
RFR: 8197866 Docs.mk still had a reference to java.se.ee
Hi, Please review this change to address the missed reference to java.se.ee —— hg diff make/Docs.gmk diff -r 345f41527dcc make/Docs.gmk --- a/make/Docs.gmk Thu Feb 08 15:35:49 2018 +0100 +++ b/make/Docs.gmk Tue Feb 13 14:31:36 2018 -0500 @@ -445,9 +445,9 @@ # Setup generation of the Java SE API documentation (javadoc + modulegraph) -# The Java SE module scope is just java.se.ee and its transitive indirect +# The Java SE module scope is just java.se and its transitive indirect # exports. -JAVASE_MODULES := java.se.ee +JAVASE_MODULES := java.se $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ MODULES := $(JAVASE_MODULES), \ —— make and make docs runs clean —— $ make docs Building target 'docs' in configuration 'macosx-x64' Generating JDK_API javadoc for 69 modules Finished building target 'docs' in configuration 'macosx-x64' ljanders-mac:Test-jdk10-Feb09 ljanders$ — Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR 8190378: Java EE and CORBA modules removal
Hi David, I thought I did make that change. Let me go back and double check and if not, will push. My build worked fine but maybe I missed this in a merge. Best Lance > On Feb 13, 2018, at 8:05 AM, David Holmes <david.hol...@oracle.com> wrote: > > Lance, > > In Docs.gmk you seem to have missed this: > > 445 > > 446 # Setup generation of the Java SE API documentation (javadoc + > modulegraph) > 447 > 448 # The Java SE module scope is just java.se.ee and its transitive indirect > 449 # exports. > 450 JAVASE_MODULES := java.se.ee > 451 > 452 $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ > 453 MODULES := $(JAVASE_MODULES), \ > 454 SHORT_NAME := $(JAVASE_SHORT_NAME), \ > 455 LONG_NAME := $(JAVASE_LONG_NAME), \ > 456 TARGET_DIR := $(IMAGES_OUTPUTDIR)/javase-docs/api, \ > 457 )) > > which now results in a doc build hanging due to the non-existent java.se.ee > module. It leads to execution of: > > grep -e @moduleGraph > > with no module-info.java argument, which causes grep to hang trying to read > from stdin. > > At least that is what my analysis indicates. I simply set: > > JAVASE_MODULES := > > to work around it. > > David > - > > On 8/02/2018 11:37 PM, Lance Andersen wrote: >>> On Feb 8, 2018, at 3:04 AM, Alan Bateman <alan.bate...@oracle.com> wrote: >>> >>> On 07/02/2018 16:57, Lance Andersen wrote: >>>> Hi all, >>>> >>>> I think we are at a point where we are ready to start reviewing the >>>> changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, >>>> has been targeted to JDK 11. >>>> The CSR for removing the modules has been approved: >>>> https://bugs.openjdk.java.net/browse/JDK-8193757 >>>> <https://bugs.openjdk.java.net/browse/JDK-8193757> >>>> >>>> The open webrev can be found at: >>>> http://cr.openjdk.java.net/~lancea/8190378/open_changes/ >>>> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/> >>>> >>> 800 KLOC deleted, wonderful! >>> >>> The update to technology-summary.html page means its html title no longer >>> matches the contents. We should probably change it to "JCP Technologies in >>> JDK 11" for now. >> I updated the webrev. Thanks for catching that (btw we missed this for JDK >> 10) >>> >>> The removal of test cases from the tests in tools/launcher/modules removes >>> most of the test coverage for the upgrade module path. We'll need to >>> replace these sub-tests. Can you create an issue to track that? >> I can do that >>> >>> Everything else looks good and it's okay to track residual issues with >>> other JIRA issues. I think the important thing is to get this monster patch >>> into JDK builds soon so that libraries and the eco system can start to >>> adjust. >> Thank you Alan for the review >> Best >> Lance >>> >>> -Alan >> <http://oracle.com/us/design/oracle-email-sig-198324.gif >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> >> <mailto:lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR 8190378: Java EE and CORBA modules removal
> On Feb 8, 2018, at 3:04 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 07/02/2018 16:57, Lance Andersen wrote: >> Hi all, >> >> I think we are at a point where we are ready to start reviewing the changes >> to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been >> targeted to JDK 11. >> The CSR for removing the modules has been approved: >> https://bugs.openjdk.java.net/browse/JDK-8193757 >> <https://bugs.openjdk.java.net/browse/JDK-8193757> >> >> The open webrev can be found at: >> http://cr.openjdk.java.net/~lancea/8190378/open_changes/ >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/> >> > 800 KLOC deleted, wonderful! > > The update to technology-summary.html page means its html title no longer > matches the contents. We should probably change it to "JCP Technologies in > JDK 11" for now. I updated the webrev. Thanks for catching that (btw we missed this for JDK 10) > > The removal of test cases from the tests in tools/launcher/modules removes > most of the test coverage for the upgrade module path. We'll need to replace > these sub-tests. Can you create an issue to track that? I can do that > > Everything else looks good and it's okay to track residual issues with other > JIRA issues. I think the important thing is to get this monster patch into > JDK builds soon so that libraries and the eco system can start to adjust. Thank you Alan for the review Best Lance > > -Alan <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: RFR 8190378: Java EE and CORBA modules removal
Hi Mandy > On Feb 7, 2018, at 5:00 PM, mandy chung <mandy.ch...@oracle.com> wrote: > > Hi Lance, > > Great to see this JEP moving along. I reviewed all changes except > test/langtools/tools/javac tests. > > Looks fine overall. Thank you for the review. > Minor comments: > > src/java.base/share/lib/security/default.policy > - no change in this file. Weird, not sure what happened, but it is now fixed. > > test/jdk/tools/jmod/hashes/HashesTest.java > test/jdk/tools/launcher/modules/addexports/AddExportsTest.java > - I think we should replace this test case with a different upgradeable > module. > It's okay to remove this case in this patch and follow up separately with > a new JBS issue. I can do that. > > test/langtools/tools/jdeps/modules/patches/java/sql/NonNull.java > - copyright start year needs update. Updated. Best Lance > > Mandy > > On 2/7/18 8:57 AM, Lance Andersen wrote: >> Hi all, >> >> I think we are at a point where we are ready to start reviewing the changes >> to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been >> targeted to JDK 11. >> The CSR for removing the modules has been approved: >> https://bugs.openjdk.java.net/browse/JDK-8193757 >> <https://bugs.openjdk.java.net/browse/JDK-8193757> >> <https://bugs.openjdk.java.net/browse/JDK-8193757> >> <https://bugs.openjdk.java.net/browse/JDK-8193757> >> >> The open webrev can be found at: >> http://cr.openjdk.java.net/~lancea/8190378/open_changes/ >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/> >> >> To make the open review easier, I have broken the changes into 5 webrevs: >> build changes are: >> http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/> >> miscellaneous changes are at: >> http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/> >> module changes are at: >> http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/> >> rmic changes are at: >> http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/> >> test changes are at: >> http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/> >> <http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/> >> >> As part of the removal, the following issues have also been logged: >> Removal of the Java EE and CORBA tools from the documentation: >> https://bugs.openjdk.java.net/browse/JDK-8193906 >> <https://bugs.openjdk.java.net/browse/JDK-8193906> >> <https://bugs.openjdk.java.net/browse/JDK-8193906> >> <https://bugs.openjdk.java.net/browse/JDK-8193906> >> Updating the RMIC man pages for the removal of the -iiop and -idl options: >> https://bugs.openjdk.java.net/browse/JDK-8196510 >> <https://bugs.openjdk.java.net/browse/JDK-8196510> >> <https://bugs.openjdk.java.net/browse/JDK-8196510> >> <https://bugs.openjdk.java.net/browse/JDK-8196510> >> Hotspot tests may require further updating or just removed: >> https://bugs.openjdk.java.net/browse/JDK-8194310 >> <https://bugs.openjdk.java.net/browse/JDK-8194310> >> <https://bugs.openjdk.java.net/browse/JDK-8194310> >> <https://bugs.openjdk.java.net/browse/JDK-8194310> >> jdeprescan will need up
Re: RFR 8190378: Java EE and CORBA modules removal
Hi Goetz, I updated the webrev with the suggested update http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/test/jdk/tools/launcher/HelpFlagsTest.java.sdiff.html Best Lance > On Feb 7, 2018, at 3:20 PM, Lindenmaier, Goetz <goetz.lindenma...@sap.com> > wrote: > > Hi Lance, > > Would you mind to add similar change as for > test/jdk/tools/launcher/VersionCheck.java > also for > test/jdk/tools/launcher/HelpFlagsTest.java > > That test is pretty recent which is why you may have missed it. > It will not fail though, there will just be left over stuff in it. > > Best regards, > Goetz. > > > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf > Of Lance Andersen > Sent: Wednesday, February 7, 2018 5:57 PM > To: core-libs-dev <core-libs-...@openjdk.java.net>; build-dev > <build-dev@openjdk.java.net> > Subject: RFR 8190378: Java EE and CORBA modules removal > > Hi all, > > I think we are at a point where we are ready to start reviewing the changes > to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been > targeted to JDK 11. > The CSR for removing the modules has been approved: > https://bugs.openjdk.java.net/browse/JDK-8193757 > <https://bugs.openjdk.java.net/browse/JDK-8193757> > > The open webrev can be found at: > http://cr.openjdk.java.net/~lancea/8190378/open_changes/ > <http://cr.openjdk.java.net/~lancea/8190378/open_changes/> > > To make the open review easier, I have broken the changes into 5 webrevs: > build changes are: > http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ > <http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/> > miscellaneous changes are at: > http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ > <http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/> > module changes are at: > http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ > <http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/> > rmic changes are at: > http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ > <http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/> > test changes are at: > http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ > <http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/> > > As part of the removal, the following issues have also been logged: > Removal of the Java EE and CORBA tools from the documentation: > https://bugs.openjdk.java.net/browse/JDK-8193906 > <https://bugs.openjdk.java.net/browse/JDK-8193906> > Updating the RMIC man pages for the removal of the -iiop and -idl options: > https://bugs.openjdk.java.net/browse/JDK-8196510 > <https://bugs.openjdk.java.net/browse/JDK-8196510> > Hotspot tests may require further updating or just removed: > https://bugs.openjdk.java.net/browse/JDK-8194310 > <https://bugs.openjdk.java.net/browse/JDK-8194310> > jdeprescan will need updates due to the removal of the Java EE and CORBA > modules: https://bugs.openjdk.java.net/browse/JDK-8194308 > <https://bugs.openjdk.java.net/browse/JDK-8194308> > > > > Best, > Lance > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> > > > > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
RFR 8190378: Java EE and CORBA modules removal
Hi all, I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 <https://bugs.openjdk.java.net/browse/JDK-8193757> The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ <http://cr.openjdk.java.net/~lancea/8190378/open_changes/> To make the open review easier, I have broken the changes into 5 webrevs: build changes are: http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ <http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/> miscellaneous changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ <http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/> module changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ <http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/> rmic changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ <http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/> test changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ <http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/> As part of the removal, the following issues have also been logged: Removal of the Java EE and CORBA tools from the documentation: https://bugs.openjdk.java.net/browse/JDK-8193906 <https://bugs.openjdk.java.net/browse/JDK-8193906> Updating the RMIC man pages for the removal of the -iiop and -idl options: https://bugs.openjdk.java.net/browse/JDK-8196510 <https://bugs.openjdk.java.net/browse/JDK-8196510> Hotspot tests may require further updating or just removed: https://bugs.openjdk.java.net/browse/JDK-8194310 <https://bugs.openjdk.java.net/browse/JDK-8194310> jdeprescan will need updates due to the removal of the Java EE and CORBA modules: https://bugs.openjdk.java.net/browse/JDK-8194308 <https://bugs.openjdk.java.net/browse/JDK-8194308> Best, Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: make reconfigure fails on idk 10
Hi Erik, Thank you. I just brought over an update and you are correct, it looks like the fix my Magnus also addressed this issue. Best Lance > On Oct 18, 2017, at 4:22 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > Hello Lance, > > I have seen similar problems recently, but I think it was caused by an old > configuration created a few days ago and an incompatible build change that > came in later. It may also have been that this was failing before Magnus' fix > a few days back. Could you "rm -rf build" and "hg pull -u" and see if the > problem still exists? > > /Erik > > > On 2017-10-17 23:08, Lance Andersen wrote: >> Hi, >> >> I just tried to run ‘make reconfigure’ in a JDK 10 workspace which was >> cloned from an existing workspace it fails: >> >> hg paths >> default = /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-master/open >> >> make reconfigure >> Re-running configure using arguments >> '--with-freetype-include=/usr/X11/include --with-freetype-lib=/usr/X11/lib >> --disable-warnings-as-errors JT_HOME=/Users/ljanders/Dropbox/openjdk/jtreg' >> Running generated-configure.sh >> configure: Configuration created at Tue Oct 17 16:39:44 EDT 2017. >> configure: configure script generated at timestamp 1508136203. >> checking for basename... /usr/bin/basename >> checking for bash... /bin/bash >> checking for cat... /bin/cat >> checking for chmod... /bin/chmod >> checking for cmp... /usr/bin/cmp >> checking for comm... /usr/bin/comm >> checking for cp... /bin/cp >> checking for cut... /usr/bin/cut >> checking for date... /bin/date >> checking for gdiff... no >> checking for diff... /usr/bin/diff >> checking for dirname... /usr/bin/dirname >> checking for echo... /bin/echo >> checking for expr... /bin/expr >> checking for file... /usr/bin/file >> checking for find... /usr/bin/find >> checking for head... /usr/bin/head >> checking for gunzip... /usr/bin/gunzip >> checking for pigz... no >> checking for gzip... /usr/bin/gzip >> checking for ln... /bin/ln >> checking for ls... /bin/ls >> checking for mkdir... /bin/mkdir >> checking for mktemp... /usr/bin/mktemp >> checking for mv... /bin/mv >> checking for nawk... no >> checking for gawk... no >> checking for awk... /usr/bin/awk >> checking for printf... /usr/bin/printf >> checking for rm... /bin/rm >> checking for rmdir... /bin/rmdir >> checking for sh... /bin/sh >> checking for sort... /usr/bin/sort >> checking for tail... /usr/bin/tail >> checking for gtar... no >> checking for tar... /usr/bin/tar >> checking for tee... /usr/bin/tee >> checking for touch... /usr/bin/touch >> checking for tr... /usr/bin/tr >> checking for uname... /usr/bin/uname >> checking for uniq... /usr/bin/uniq >> checking for wc... /usr/bin/wc >> checking for which... /usr/bin/which >> checking for xargs... /usr/bin/xargs >> checking for gawk... no >> checking for mawk... no >> checking for nawk... no >> checking for awk... awk >> checking for grep that handles long lines and -e... /usr/bin/grep >> checking for egrep... /usr/bin/grep -E >> checking for fgrep... /usr/bin/grep -F >> checking for a sed that does not truncate output... /usr/bin/sed >> checking for cygpath... no >> checking for greadlink... no >> checking for readlink... /usr/bin/readlink >> checking for df... /bin/df >> checking for cpio... /usr/bin/cpio >> checking for nice... /usr/bin/nice >> checking for pandoc... no >> checking build system type... x86_64-apple-darwin16.7.0 >> checking host system type... x86_64-apple-darwin16.7.0 >> checking target system type... x86_64-apple-darwin16.7.0 >> checking openjdk-build os-cpu... macosx-x86_64 >> checking openjdk-target os-cpu... macosx-x86_64 >> checking compilation type... native >> checking for top-level directory... >> /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba >> checking if custom source is suppressed (openjdk-only)... no >> checking which variant of the JDK to build... normal >> checking which debug level to use... release >> checking which variants of the JVM to build... server >> checking for xcodebuild... /usr/bin/xcodebuild >> checking for sdk name... >> checking for sysroot... >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk >> checking for toolchain path... >> checking for extra path... >> checking where to store config
Re: make reconfigure fails on idk 10
braries... /usr/X11/lib checking if we can compile and link with freetype... yes checking if we should bundle freetype... yes checking for which libjpeg to use... bundled checking for which giflib to use... bundled checking for which libpng to use... bundled checking for compress in -lz... yes checking for which zlib to use... system checking for which lcms to use... bundled checking for cos in -lm... yes checking for dlopen in -ldl... yes checking if jdk.internal.vm.compiler should be built... yes checking if aot should be enabled... yes checking if elliptic curve crypto implementation is present... yes checking if jtreg failure handler should be built... yes, jtreg present checking if the CDS classlist generation should be enabled... yes checking for number of cores... 8 checking for memory size... 8192 MB checking for appropriate number of jobs to run in parallel... 8 checking flags for boot jdk java command ... -Duser.language=en -Duser.country=US -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces -XX:SharedArchiveFile=/Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/build/macosx-x86_64-normal-server-release/configure-support/classes.jsa -Xshare:auto checking flags for boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 checking flags for boot jdk java command for small workloads... -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 checking whether to use sjavac... no checking whether to use javac server... yes checking If precompiled header is enabled... yes checking is ccache enabled... no configure: WARNING: The following variables might be unknown to configure: JT_HOME checking if build directory is on local disk... yes checking JVM features for JVM variant 'server'... all-gcs aot cds compiler1 compiler2 dtrace graal jni-check jvmci jvmti management nmt services vm-structs configure: creating /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/build/macosx-x86_64-normal-server-release/configure-support/config.status config.status: creating /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/build/macosx-x86_64-normal-server-release/spec.gmk config.status: creating /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/build/macosx-x86_64-normal-server-release/bootcycle-spec.gmk config.status: creating /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/build/macosx-x86_64-normal-server-release/buildjdk-spec.gmk config.status: creating /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/build/macosx-x86_64-normal-server-release/compare.sh config.status: creating /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/build/macosx-x86_64-normal-server-release/Makefile The existing configuration has been successfully updated in /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/build/macosx-x86_64-normal-server-release using configure arguments '--with-freetype-include=/usr/X11/include --with-freetype-lib=/usr/X11/lib --disable-warnings-as-errors JT_HOME=/Users/ljanders/Dropbox/openjdk/jtreg'. Configuration summary: * Debug level:release * HS debug level: product * JDK variant:normal * JVM variants: server * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64 * Version string: 10-internal+0-adhoc.ljanders.open-corba (10-internal) Tools summary: * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) (at /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home) * Toolchain: clang (clang/LLVM from Xcode 5.1.1) * C Compiler: Version 5.1 (at /usr/bin/clang) * C++ Compiler: Version 5.1 (at /usr/bin/clang++) Build performance summary: * Cores to use: 8 * Memory limit: 8192 MB WARNING: The result of this configuration has overridden an older configuration. You *should* run 'make clean' to make sure you get a proper build. Failure to do so might result in strange build problems. The following warnings were produced. Repeated here for convenience: WARNING: The following variables might be unknown to configure: JT_HOME — Best Lance > > b) there have been some bugs fixed, but they mainly relate to open+closed > configurations Yes I did see some of the put-backs and not sure if this is related. Best Lance > > Cheers, > David > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
make reconfigure fails on idk 10
Hi, I just tried to run ‘make reconfigure’ in a JDK 10 workspace which was cloned from an existing workspace it fails: hg paths default = /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-master/open make reconfigure Re-running configure using arguments '--with-freetype-include=/usr/X11/include --with-freetype-lib=/usr/X11/lib --disable-warnings-as-errors JT_HOME=/Users/ljanders/Dropbox/openjdk/jtreg' Running generated-configure.sh configure: Configuration created at Tue Oct 17 16:39:44 EDT 2017. configure: configure script generated at timestamp 1508136203. checking for basename... /usr/bin/basename checking for bash... /bin/bash checking for cat... /bin/cat checking for chmod... /bin/chmod checking for cmp... /usr/bin/cmp checking for comm... /usr/bin/comm checking for cp... /bin/cp checking for cut... /usr/bin/cut checking for date... /bin/date checking for gdiff... no checking for diff... /usr/bin/diff checking for dirname... /usr/bin/dirname checking for echo... /bin/echo checking for expr... /bin/expr checking for file... /usr/bin/file checking for find... /usr/bin/find checking for head... /usr/bin/head checking for gunzip... /usr/bin/gunzip checking for pigz... no checking for gzip... /usr/bin/gzip checking for ln... /bin/ln checking for ls... /bin/ls checking for mkdir... /bin/mkdir checking for mktemp... /usr/bin/mktemp checking for mv... /bin/mv checking for nawk... no checking for gawk... no checking for awk... /usr/bin/awk checking for printf... /usr/bin/printf checking for rm... /bin/rm checking for rmdir... /bin/rmdir checking for sh... /bin/sh checking for sort... /usr/bin/sort checking for tail... /usr/bin/tail checking for gtar... no checking for tar... /usr/bin/tar checking for tee... /usr/bin/tee checking for touch... /usr/bin/touch checking for tr... /usr/bin/tr checking for uname... /usr/bin/uname checking for uniq... /usr/bin/uniq checking for wc... /usr/bin/wc checking for which... /usr/bin/which checking for xargs... /usr/bin/xargs checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for a sed that does not truncate output... /usr/bin/sed checking for cygpath... no checking for greadlink... no checking for readlink... /usr/bin/readlink checking for df... /bin/df checking for cpio... /usr/bin/cpio checking for nice... /usr/bin/nice checking for pandoc... no checking build system type... x86_64-apple-darwin16.7.0 checking host system type... x86_64-apple-darwin16.7.0 checking target system type... x86_64-apple-darwin16.7.0 checking openjdk-build os-cpu... macosx-x86_64 checking openjdk-target os-cpu... macosx-x86_64 checking compilation type... native checking for top-level directory... /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba checking if custom source is suppressed (openjdk-only)... no checking which variant of the JDK to build... normal checking which debug level to use... release checking which variants of the JVM to build... server checking for xcodebuild... /usr/bin/xcodebuild checking for sdk name... checking for sysroot... /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk checking for toolchain path... checking for extra path... checking where to store configuration... in current directory configure: Current directory is /Users/ljanders. configure: Since this is not the source root, configure will output the configuration here configure: (as opposed to creating a configuration in /build/). configure: However, this directory is not empty. This is not allowed, since it could configure: seriously mess up just about everything. configure: Try 'cd /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba' and restart configure configure: (or create a new empty directory and cd to it). configure: error: Will not continue creating configuration in /Users/ljanders /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/make/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor configure exiting with result code 1 make[1]: *** [reconfigure] Error 1 make: *** [reconfigure] Error 2 —— running configure on its own works fine. Is this a known issue? Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
JIB build failures JDK 10 full repro of install
Hi, Trying to use JIB for the 1st time to build the full JDK 10 and seeing errors such as the following from jib make — In file included from /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-full/closed/install/src/settings/macosx/MacSettings.cpp:6: In file included from /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-full/closed/install/src/settings/share/Misc.h:10: /Users/ljanders/Documents/hg-workspaces/openjdk-tools/jib-artifacts/install/jpg/infra/builddeps/devkit-macosx_x64/Xcode6.3-MacOSX10.9+1.0/devkit-macosx_x64-Xcode6.3-MacOSX10.9+1.0.tar.gz/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cctype:39:10: fatal error: 'ctype.h' file not found #include — I did not see anything obvious WRT errors in the configure.log from running jib configure It looks like the images were build though —— ./build/*/images/jdk/bin/java -version java version "10-internal" Java(TM) SE Runtime Environment (build 10-internal+0-2017-09-23-2007047.ljanders.jdk10-full) Java HotSpot(TM) 64-Bit Server VM (build 10-internal+0-2017-09-23-2007047.ljanders.jdk10-full, mixed mode) ——— Also, am i correct that ~/.config/jib/jib.conf needs to be created manually as I did not see that after running jib configure I have installed the bootstrap launcher as well Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: Review Request: JDK-8179035: Include tool modules in unified docs
The javadocs read fine. Probably need to update the copyright date for the module-info.java files Best Lance > On Apr 20, 2017, at 2:37 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > A few modules are missing in the unified docs such as jdk.jcmd, > jdk.jdwp.agent, jdk.jstatd, etc. Some tool modules are providers > and they were in the initial set. The modules that are neither > a provider nor exporting any API package are missed in the initial > patch. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179035/webrev.00/ > > Mandy <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: JDK 9 RFR Enable doclint reference checking for the java.management.rmi module
+1 -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPhone > On Feb 14, 2017, at 8:27 PM, joe darcy <joe.da...@oracle.com> wrote: > > Hello, > > As a follow-up to enabling doclint reference checking in the java.compiler > modules (JDK-8174945), I checked the other modules where reference checking > is currently disabled and found one where the check could be turned on: > java.management.rmi. > > Please review the patch below which does this. > > Thanks, > > -Joe > > diff -r 04a685edd41d make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmkTue Feb 14 09:00:43 2017 -0800 > +++ b/make/CompileJavaModules.gmkTue Feb 14 17:24:04 2017 -0800 > @@ -247,7 +247,7 @@ > > > > -java.management.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference > '-Xdoclint/package:javax.*' > +java.management.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:javax.*' > > > >
Re: support/gensrc/jdk.jdi/jdwp-protocol.html build error
In case this bites anyone else, the workaround below will keep you going :-) Thank you again Magnus Best Lance > On Oct 31, 2016, at 2:09 PM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > Lance, > > This is most likely due to a missed dependency in the recent Javadoc > refactoring, which is triggered on your build platform. > > A workaround for you right now is to do 'make jdk.jdi' first, which will make > sure the Javadoc stage later will succeed. > > Sorry for the inconvenience. :-( > > /Magnus > >> 31 okt. 2016 kl. 19:07 skrev Lance Andersen <lance.ander...@oracle.com>: >> >> Hi, >> >> I just pulled the latest JDK 9 source (open and closed) and can no longer >> build as I am getting the following error: >> >> make[3]: *** No rule to make target >> `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/gensrc/jdk.jdi/jdwp-protocol.html', >> needed by >> `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/javadoc/platform/jpda/jdwp/jdwp-protocol.html'. >> Stop. >> make[2]: *** [docs-copy] Error 2 >> >> >> >> I did a make clean prior to make all. >> >> Anyone else encounter this? >> >> >> Thank you in advance… >> >> Best >> Lance >> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> >> >> >> > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Re: support/gensrc/jdk.jdi/jdwp-protocol.html build error
Thank you for the suggestion Magnus, I will try that. I am on OS X 10.11.4 FWIW Best Lance > On Oct 31, 2016, at 2:09 PM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > Lance, > > This is most likely due to a missed dependency in the recent Javadoc > refactoring, which is triggered on your build platform. > > A workaround for you right now is to do 'make jdk.jdi' first, which will make > sure the Javadoc stage later will succeed. > > Sorry for the inconvenience. :-( > > /Magnus > >> 31 okt. 2016 kl. 19:07 skrev Lance Andersen <lance.ander...@oracle.com>: >> >> Hi, >> >> I just pulled the latest JDK 9 source (open and closed) and can no longer >> build as I am getting the following error: >> >> make[3]: *** No rule to make target >> `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/gensrc/jdk.jdi/jdwp-protocol.html', >> needed by >> `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/javadoc/platform/jpda/jdwp/jdwp-protocol.html'. >> Stop. >> make[2]: *** [docs-copy] Error 2 >> >> >> >> I did a make clean prior to make all. >> >> Anyone else encounter this? >> >> >> Thank you in advance… >> >> Best >> Lance >> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> >> >> >> > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
support/gensrc/jdk.jdi/jdwp-protocol.html build error
Hi, I just pulled the latest JDK 9 source (open and closed) and can no longer build as I am getting the following error: make[3]: *** No rule to make target `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/gensrc/jdk.jdi/jdwp-protocol.html', needed by `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/javadoc/platform/jpda/jdwp/jdwp-protocol.html'. Stop. make[2]: *** [docs-copy] Error 2 I did a make clean prior to make all. Anyone else encounter this? Thank you in advance… Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Problem running configure on El Capitan
Hi, Has there been any changes to the build requirements recently as I am getting the error: —— configure: error: Could not find freetype! /Users/ljanders/Documents/hg-workspaces/openjdk9/javadoc-mod/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor configure exiting with result code 1 I have not seen this before Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Cloning issues anyone seeing them?
Hi all, Seeing issues with a openjdk9 clone today source get_source.sh WARNING: Mercurial version 2.6.3 or later is recommended. /usr/local/bin/hg is version 2.2 # Repositories: langtools langtools: hg clone http://hg.openjdk.java.net/jdk9/dev/langtools langtools langtools: requesting all changes langtools: adding changesets langtools: adding manifests langtools: adding file changes langtools: transaction abort! langtools: rollback completed langtools: abort: stream ended unexpectedly (got 2032 bytes, expected 4304) WARNING: langtools exited abnormally (255) Saving session... ...copying shared history... ...saving history...truncating history files... ...completed. [Process completed] — I have experienced the above occasionally before but now it is also killing the terminal process which it never used to do… This is on el Capitan Anyone else having this experience? Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Errors building on OSX 10.8.5
While I plan to upgrade this week to El Capitan from 10.8.5, it looks like the build now requires a more current version of OSX than it did a few weeks ago based on the error I am seeing after updating my jdk9 workspace today before the jake integration. I assume I am out of luck until i get off the bench and upgrade OSX now (which is more motivation :-) )? p.s. Was there an email I might have missed on this change (I know I was probably lucky before) - ljanders-mac:modular-dev ljanders$ make all Building target 'all' in configuration 'macosx-x86_64-normal-server-release' Warning: generation and use of skeletons and static stubs for JRMP is deprecated. Skeletons are unnecessary, and static stubs have been superseded by dynamically generated stubs. Users are encouraged to migrate away from using rmic to generate skeletons and static stubs. See the documentation for java.rmi.server.UnicastRemoteObject. /Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/jdk/src/java.desktop/macosx/native/libosx/CFileManager.m:225:25: error: 'trashItemAtURL:resultingItemURL:error:' is unavailable returnValue = [[NSFileManager defaultManager] trashItemAtURL:url ^ /System/Library/Frameworks/Foundation.framework/Headers/NSFileManager.h:162:1: note: declaration has been explicitly marked unavailable here - (BOOL)trashItemAtURL:(NSURL *)url resultingItemURL:(NSURL **)outResultingURL error:(NSError **)error NS_AVAILABLE_MAC(10_8); ^ 1 error generated. make[3]: *** [/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/native/java.desktop/libosx/CFileManager.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [java.desktop-libs] Error 2 make[2]: *** Waiting for unfinished jobs Compiling 775 files for jdk.xml.bind Starting server. Command: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java -d64 -Xms512M -Xmx2048M -Xbootclasspath/p:/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/buildtools/interim_langtools.jar -cp /Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --startserver:portfile=/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/make-support/javacservers/server.port,poolsize=8,keepalive=120 Trying to connect. Attempt 1 of 3 Connected Compiling 1226 files for java.xml.ws Trying to connect. Attempt 1 of 3 Connected [server] Note: Some input files use or override a deprecated API. [server] Note: Recompile with -Xlint:deprecation for details. [server] Note: Some input files use unchecked or unsafe operations. [server] Note: Recompile with -Xlint:unchecked for details. [server] Note: Some input files use or override a deprecated API. [server] Note: Recompile with -Xlint:deprecation for details. [server] Note: Some input files use unchecked or unsafe operations. [server] Note: Recompile with -Xlint:unchecked for details. ERROR: Build failed for target 'all' in configuration 'macosx-x86_64-normal-server-release' (exit code 2) === Output from failing command(s) repeated here === * For target support_native_java.desktop_libosx_CFileManager.o: /Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/jdk/src/java.desktop/macosx/native/libosx/CFileManager.m:225:25: error: 'trashItemAtURL:resultingItemURL:error:' is unavailable returnValue = [[NSFileManager defaultManager] trashItemAtURL:url ^ /System/Library/Frameworks/Foundation.framework/Headers/NSFileManager.h:162:1: note: declaration has been explicitly marked unavailable here - (BOOL)trashItemAtURL:(NSURL *)url resultingItemURL:(NSURL **)outResultingURL error:(NSError **)error NS_AVAILABLE_MAC(10_8); ^ 1 error generated. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: If caused by a warning, try configure --disable-warnings-as-errors. make[1]: *** [main] Error 2 make: *** [all] Error 2 ljanders-mac:modular-dev ljanders$ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
jdk 9 build broken?
I just updated my jdk 9 workspace and I am not seeing the following errors
trying to build on OSX:
ERROR: Build failed for target 'all' in configuration
'macosx-x86_64-normal-server-release' (exit code 2)
=== Output from failing command(s) repeated here ===
* For target java.xml:
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/jaxp/src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SafeThread.java:36:
error: cannot find symbol
private static final jdk.internal.misc.Unsafe UNSAFE;
^
symbol: class Unsafe
location: package jdk.internal.misc
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/jaxp/src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SafeThread.java:82:
error: cannot find symbol
UNSAFE = jdk.internal.misc.Unsafe.getUnsafe();
^
symbol: class Unsafe
location: package jdk.internal.misc
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
2 errors
* For target jdk.scripting.nashorn:
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java:98:
error: cannot find symbol
import jdk.internal.misc.Unsafe;
^
symbol: class Unsafe
location: package jdk.internal.misc
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java:308:
error: cannot find symbol
private static final Unsafe UNSAFE = getUnsafe();
^
symbol: class Unsafe
location: class AnonymousContextCodeInstaller
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java:346:
error: cannot find symbol
private static Unsafe getUnsafe() {
^
symbol: class Unsafe
location: class AnonymousContextCodeInstaller
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java:347:
error: cannot find symbol
return AccessController.doPrivileged(new PrivilegedAction()
{
^
symbol: class Unsafe
location: class AnonymousContextCodeInstaller
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java:349:
error: cannot find symbol
public Unsafe run() {
^
symbol: class Unsafe
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java:351:
error: cannot find symbol
final Field theUnsafeField =
Unsafe.class.getDeclaredField("theUnsafe");
^
symbol: class Unsafe
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java:353:
error: cannot find symbol
return (Unsafe)theUnsafeField.get(null);
^
symbol: class Unsafe
7 errors
=== End of repeated output ===
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: If caused by a warning, try configure --disable-warnings-as-errors.
--
I did run
reconfigure
make clean
Unsafe.java is in java.base/share/classes/sun/misc in my jdk 9 workspace
Best
Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Re: Change in hotspot causing build issues on OSX 10.8.5
Hi David, thank you for your reply. I was using Xcode 4.6.2 - Using gcc C++ compiler version 4.2.1 [i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] --- I upgraded to XCode 5.1.1 -- C Compiler: Version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.6.0 Thread model: posix (at /usr/bin/clang) C++ Compiler: Version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.6.0 Thread model: posix (at /usr/bin/clang++) -- and now get the warnings: - Compiling 13 files for jdk.policytool clang: error: unknown warning option '-Wno-tautological-constant-out-of-range-compare'; did you mean '-Wno-tautological-compare'? make[3]: *** [/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/native/java.desktop/libfontmanager/AlternateSubstSubtables.o] Error 1 make[2]: *** [java.desktop-libs] Error 2 Also see a lot of these messages which I do not recall before --- Compiling 43 files for jdk.httpserver nm: no name list nm: no name list nm: no name list -- After running - ./configure --disable-warnings-as-errors The build completed but I get a lot of warnings now for that I did not see before such as --- /Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/jdk/src/java.base/unix/native/libjava/jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined #define ptr_to_jlong(a) ((jlong)(a)) -- Best Lance On Aug 24, 2015, at 12:18 AM, David Holmes david.hol...@oracle.com wrote: Hi Lance, On 22/08/2015 1:20 AM, Lance Andersen wrote: Hi, I just pulled over the latest updates for jdk 9 and it looks like there is a hotspot change that now causes the build to fail for me on osx 10.8.5 -- /Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/hotspot/src/os/bsd/vm/jsig.c:45: error: thread-local storage not supported for this target https://bugs.openjdk.java.net/browse/JDK-8072147 introduced the change to use a compiler based thread-local variable. What compiler chain are you using? Thanks, David make[10]: *** [libjsig.dylib] Error 1 make[10]: *** Waiting for unfinished jobs make[9]: *** [the_vm] Error 2 make[8]: *** [product] Error 2 make[7]: *** [generic_build2] Error 2 make[6]: *** [product] Error 2 make[5]: *** [all_product_universal] Error 2 make[4]: *** [universal_product] Error 2 make[3]: *** [/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 make[2]: *** [hotspot] Error 2 make[2]: *** Waiting for unfinished jobs -- I had done a configure and make clean? Thoughts? Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Change in hotspot causing build issues on OSX 10.8.5
Hi, I just pulled over the latest updates for jdk 9 and it looks like there is a hotspot change that now causes the build to fail for me on osx 10.8.5 -- /Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/hotspot/src/os/bsd/vm/jsig.c:45: error: thread-local storage not supported for this target make[10]: *** [libjsig.dylib] Error 1 make[10]: *** Waiting for unfinished jobs make[9]: *** [the_vm] Error 2 make[8]: *** [product] Error 2 make[7]: *** [generic_build2] Error 2 make[6]: *** [product] Error 2 make[5]: *** [all_product_universal] Error 2 make[4]: *** [universal_product] Error 2 make[3]: *** [/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 make[2]: *** [hotspot] Error 2 make[2]: *** Waiting for unfinished jobs -- I had done a configure and make clean? Thoughts? Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: regression test failures
: java/text/Bidi/Bug6665028.java Error: No tests selected Missing file: /Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/JTreport/text/summary.txt Best Lance On Jan 13, 2014, at 9:26 PM, David Holmes david.hol...@oracle.com wrote: -l :jdk_all Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: regression test failures
Thank you for the follow up On Jan 14, 2014, at 8:35 AM, Alan Bateman alan.bate...@oracle.com wrote: On 14/01/2014 13:25, Lance Andersen wrote: Hi David, Thank you for the email. Running the command jtreg -l :jdk_all produces (I assume running this from jdk/test was the correct spot to run this from) --- ~/Dropbox/LancePTR/jtreg/win32/bin/jtreg -l :jdk_all Testsuite: /Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/test /Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/test/TEST.groups: group needs_jre: file not found: java/text/Bidi/Bug6665028.java jdk_all is not the name of a jtreg group (jdk_other is, which is why this works for you). On the java/text/Bidi/Bug6665028.java message then this is just a warning (and is harmless). That test was removed and it looks like the TEST.groups file wasn't updated. Got that. I will log a bug and submit a review and make the change to nuke the rogue entry. If I run --- . new-host-4:jdbc-jdk lance$ make test TEST=jdk_all Building OpenJDK for target 'test' in configuration 'macosx-x86_64-normal-server-release' ## Starting langtools ## Finished langtools (build time 00:00:00) ## Starting hotspot ## Finished hotspot (build time 00:00:01) ## Starting corba ## Finished corba (build time 00:00:01) ## Starting jaxp ## Finished jaxp (build time 00:00:00) ## Starting jaxws ## Finished jaxws (build time 00:00:01) ## Starting jdk ## Finished jdk (build time 00:00:05) ## Starting demos ## Finished demos (build time 00:00:01) ## Starting nashorn ## Finished nashorn (build time 00:00:00) ## Starting images Copying images/j2re-bundle/jre1.8.0.jre/Contents/Home/release Copying images/j2sdk-bundle/jdk1.8.0.jdk/Contents/Home/release ## Finished images (build time 00:00:05) ## Starting test /usr/bin/make -k -C ../jdk/test TEST=jdk_all jdk_all echo Running tests: jdk_all Running tests: jdk_all for each in jdk_all; do \ /usr/bin/make -j 1 TEST_SELECTION=:$each UNIQUE_DIR=$each jtreg_tests; \ done make[3]: *** No rule to make target `/java/re/jtreg/4.1/promoted/latest/binaries/jtreg', needed by `/java/re/jtreg/4.1/promoted/latest/binaries/jtreg/win32/bin/jtreg'. make[3]: Target `jtreg_tests' not remade because of errors. make[2]: *** [jdk_all] Error 2 make[1]: *** [jdk_all] Error 2 ## Finished test (build time 00:00:00) - Build times --- Start 2014-01-14 10:51:11 End 2014-01-14 10:51:26 00:00:01 corba 00:00:01 demos 00:00:01 hotspot 00:00:05 images 00:00:00 jaxp 00:00:01 jaxws 00:00:05 jdk 00:00:00 langtools 00:00:00 nashorn 00:00:00 test 00:00:15 TOTAL - Finished building OpenJDK for target 'test' -- Seems like it always looks for the internal jtreg vs was JT_HOME is set to? Best Lance -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: get_source.sh using JT_HOME?
On Jan 14, 2014, at 12:17 PM, Alan Bateman alan.bate...@oracle.com wrote: On 14/01/2014 16:36, Lance Andersen wrote: Not sure if this is intentional, but I had JT_HOME set when i sourced get_source.sh against jdk8u-dev noticed the following messages: jdk/src/closed: hg clone JT_HOME=/Users/lance/Dropbox/LancePTR/jtreg/jdk8u/jdk8u-dev/jdk/src/closed jdk/src/closed I would think that should not happen? I don't think this should matter Ok thank you, it just seemed strange (to me at least) that is was looking at closed with the property set . So when you ran configure then did you specify --with-jtreg to set the path to jtreg? I did not as it was not listed as an option for configure in the README-builds.html which is why I set JT_HOME re-ran configure specifying --with-jtreg and then ran the tests still no luck with jdk_all and this was against jdk8u-dev - cd test make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all make -k -C ../jdk/test TEST=jdk_all jdk_all echo Running tests: jdk_all Running tests: jdk_all for each in jdk_all; do \ make -j 1 TEST_SELECTION=:$each UNIQUE_DIR=$each jtreg_tests; \ done make[2]: *** No rule to make target `/java/re/jtreg/4.1/promoted/latest/binaries/jtreg', needed by `/java/re/jtreg/4.1/promoted/latest/binaries/jtreg/win32/bin/jtreg'. make[2]: Target `jtreg_tests' not remade because of errors. make[1]: *** [jdk_all] Error 2 make: *** [jdk_all] Error 2 - Best Lance -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: regression test failures
/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/Stats.txt;
fi; if [ -f
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/Stats.txt
] ; then cat
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/Stats.txt;
fi; ( mkdir -p `dirname
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/ARCHIVE_BUNDLE.zip`
cd
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all
chmod -R a+r . zip -q -r
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/ARCHIVE_BUNDLE.zip
. ) ; if [ ! -s
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt
] ; then echo ERROR: EXITCODE file not filled in.; echo 1
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt;
fi ; testExitCode=`cat
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt`;
echo EXIT CODE: ${testExitCode}; exit ${testExitCode} )
\
) 21 | tee
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/output.txt
; if [ ! -s
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt
] ; then echo ERROR: EXITCODE file not filled in.; echo 1
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt;
fi ; testExitCode=`cat
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt`;
echo EXIT CODE: ${testExitCode}; exit ${testExitCode}
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/test/TEST.groups: group
needs_jre: file not found: java/text/Bidi/Bug6665028.java
Error: No tests selected
Missing file:
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/JTreport/text/summary.txt
EXIT CODE: 1
EXIT CODE: 1
make[2]: *** [jtreg_tests] Error 1
make[1]: *** [jdk_all] Error 2
make: *** [jdk_all] Error 2
java/text/Bidi/Bug6665028.java does not exist in the workspace that i pulled
over yesterday:
ls test/java/text/Bidi/
BidiBug.javaBidiEmbeddingTest.java Bug6850113.java
Bug7041232.java Bug7051769.java
BidiConformance.javaBidiSurrogateTest.java Bug7002398.java
Bug7042148.java Bug8005277.java
I do see it in older workspaces, though that I have for jdk8,
Best
Lance
On Jan 12, 2014, at 10:52 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 11/01/2014 19:15, Lance Andersen wrote:
:
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/test/TEST.groups:
group compact2_minimal: file not found: :needs_compact3
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/test/TEST.groups:
group compact2_minimal: file not found: :needs_jre
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/test/TEST.groups:
group compact2_minimal: file not found: :needs_jdk
Error: No tests selected
Missing file:
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/JTreport/text/summary.txt
EXIT CODE: 1
---
is there another setting I need?
I haven't seen this but it looks like jtreg is interpreting properties that
it doesn't understand into files to read. Do you know which version of jtreg
you have? I just wonder if you might have a really old version that doesn't
understand groups.
-Alan.
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Re: configure error on OSX 10.8.5: Could not find free type!
/Stats.txt;
fi; if [ -f
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/Stats.txt
] ; then cat
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/Stats.txt;
fi; ( mkdir -p `dirname
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/ARCHIVE_BUNDLE.zip`
cd
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all
chmod -R a+r . zip -q -r
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/ARCHIVE_BUNDLE.zip
. ) ; if [ ! -s
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt
] ; then echo ERROR: EXITCODE file not filled in.; echo 1
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt;
fi ; testExitCode=`cat
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt`;
echo EXIT CODE: ${testExitCode}; exit ${testExitCode} )
\
) 21 | tee
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/output.txt
; if [ ! -s
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt
] ; then echo ERROR: EXITCODE file not filled in.; echo 1
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt;
fi ; testExitCode=`cat
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt`;
echo EXIT CODE: ${testExitCode}; exit ${testExitCode}
Cannot determine version of java to run jtreg
Missing file:
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/JTreport/text/summary.txt
EXIT CODE: 1
EXIT CODE: 1
make[2]: *** [jtreg_tests] Error 1
make[1]: *** [jdk_all] Error 2
make: *** [jdk_all] Error 2
-
Any thoughts why jtreg fails? I did set JT_HOME
java seems to be OK:
bin/java -version
openjdk version 1.8.0-internal
OpenJDK Runtime Environment (build 1.8.0-internal-lance_2014_01_10_22_17-b00)
OpenJDK 64-Bit Server VM (build 25.0-b64, mixed mode)
Best
Lance
On Jan 11, 2014, at 3:19 AM, Andrej Golovnin andrej.golov...@gmail.com wrote:
Hi Lance,
just install the latest XQuartz version, e.g. 2.7.5.
It helped me on OSX 10.9.1.
Hope this helps.
Best regards,
Andrej Golovnin
On 10.01.2014, at 23:45, Lance Andersen lance.ander...@oracle.com wrote:
Hi all,
Trying to get a build environment on OSX 10.8.5 set up and am getting the
following error from configure:
configure: error: Could not find free type!
I have attached the config.log
I originally installed Xcode 5.0.2 but that caused configure to fail due to
a gcc version issue :-(
I then installed Xcode 4.6.2 but it thought that the command line tools were
already installed and the only way I could get the4.6.2 command line tools
to install was via downloading the 4.6.2 command line tool installer. that
got me by the gcc issue but now have the error above.
Any guidance would be appreciated!
Best
Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
regression test failures
} )
\
) 21 | tee
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/output.txt
; if [ ! -s
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt
] ; then echo ERROR: EXITCODE file not filled in.; echo 1
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt;
fi ; testExitCode=`cat
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/exitcode.txt`;
echo EXIT CODE: ${testExitCode}; exit ${testExitCode}
Cannot determine version of java to run jtreg
Missing file:
/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/testoutput/jdk_all/JTreport/text/summary.txt
EXIT CODE: 1
EXIT CODE: 1
make[2]: *** [jtreg_tests] Error 1
make[1]: *** [jdk_all] Error 2
make: *** [jdk_all] Error 2
-
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
configure error on OSX 10.8.5: Could not find free type!
Hi all, Trying to get a build environment on OSX 10.8.5 set up and am getting the following error from configure: configure: error: Could not find free type! I have attached the config.log I originally installed Xcode 5.0.2 but that caused configure to fail due to a gcc version issue :-( I then installed Xcode 4.6.2 but it thought that the command line tools were already installed and the only way I could get the4.6.2 command line tools to install was via downloading the 4.6.2 command line tool installer. that got me by the gcc issue but now have the error above. Any guidance would be appreciated! Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: configure error on OSX 10.8.5: Could not find free type!
In case configure is looking for it is here on my system freetype.6.dylib ew-host-5:lib lance$ ls -l /usr/X11/lib/libfreetype.6.dylib -rwxr-xr-x 1 root wheel 25984 Nov 15 2012 /usr/X11/lib/libfreetype.6.dylib Best Lance On Jan 10, 2014, at 5:45 PM, Lance Andersen lance.ander...@oracle.com wrote: Hi all, Trying to get a build environment on OSX 10.8.5 set up and am getting the following error from configure: configure: error: Could not find free type! I have attached the config.log I originally installed Xcode 5.0.2 but that caused configure to fail due to a gcc version issue :-( I then installed Xcode 4.6.2 but it thought that the command line tools were already installed and the only way I could get the4.6.2 command line tools to install was via downloading the 4.6.2 command line tool installer. that got me by the gcc issue but now have the error above. Any guidance would be appreciated! Best Lance oracle_sig_logo.gif Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com config.log Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: 8014500: bootcycle-images fails after upgrade to JAXP 1.5
+1
On May 14, 2013, at 8:16 AM, Alan Bateman wrote:
The bootcycle-images target is currently broken in jdk8/tl.
Jon has taken 8014461 to fix genstubs but once you get past that then the
CLDRConverter fails parsing LDML due to DTD references that aren't allowed by
the default policy in jdk8 (since the update to JAXP 1.5). This policy is due
to be re-visited later in jdk8 and I expect it will need to allow at least
access to the DTDs on the file system. For now, and to get the boot cycle
builds going again, I propose to update the CLDRConverter to set the
accessExternalDTD property.
Attached is the proposed patch. It uses a hard-coded string rather than
XMLConstants.ACCESS_EXTERNAL_DTD because the boot JDK will likely have an
older version of JAXP where this constant isn't defined.
Thanks,
Alan.
diff --git a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java
b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java
--- a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java
+++ b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java
@@ -34,6 +34,8 @@
import java.util.*;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
+import org.xml.sax.SAXNotRecognizedException;
+import org.xml.sax.SAXNotSupportedException;
/**
@@ -234,6 +236,17 @@
}
}
+/**
+ * Configure the parser to allow access to DTDs on the file system.
+ */
+private static void enableFileAccess(SAXParser parser) throws
SAXNotSupportedException {
+try {
+
parser.setProperty(http://javax.xml.XMLConstants/property/accessExternalDTD;,
file);
+} catch (SAXNotRecognizedException ignore) {
+// property requires = JAXP 1.5
+}
+}
+
private static ListBundle readBundleList() throws Exception {
ResourceBundle.Control defCon =
ResourceBundle.Control.getControl(ResourceBundle.Control.FORMAT_DEFAULT);
ListBundle retList = new ArrayList();
@@ -279,6 +292,7 @@
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setValidating(true);
SAXParser parser = factory.newSAXParser();
+enableFileAccess(parser);
LDMLParseHandler handler = new LDMLParseHandler(id);
File file = new File(SOURCE_FILE_DIR + File.separator + id + .xml);
if (!file.exists()) {
@@ -314,6 +328,7 @@
SAXParserFactory factorySuppl = SAXParserFactory.newInstance();
factorySuppl.setValidating(true);
SAXParser parserSuppl = factorySuppl.newSAXParser();
+enableFileAccess(parserSuppl);
handlerSuppl = new SupplementDataParseHandler();
File fileSupply = new File(SPPL_SOURCE_FILE);
parserSuppl.parse(fileSupply, handlerSuppl);
@@ -322,6 +337,7 @@
SAXParserFactory numberingParser = SAXParserFactory.newInstance();
numberingParser.setValidating(true);
SAXParser parserNumbering = numberingParser.newSAXParser();
+enableFileAccess(parserNumbering);
handlerNumbering = new NumberingSystemsParseHandler();
File fileNumbering = new File(NUMBERING_SOURCE_FILE);
parserNumbering.parse(fileNumbering, handlerNumbering);
@@ -330,6 +346,7 @@
SAXParserFactory metazonesParser = SAXParserFactory.newInstance();
metazonesParser.setValidating(true);
SAXParser parserMetaZones = metazonesParser.newSAXParser();
+enableFileAccess(parserMetaZones);
handlerMetaZones = new MetaZonesParseHandler();
File fileMetaZones = new File(METAZONES_SOURCE_FILE);
parserNumbering.parse(fileMetaZones, handlerMetaZones);
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Re: RFR: 8011814/8013271/8013272: Three improvements to J2SE Netbeans project
Hi Mike, The changes look good to me. Best Lance On Apr 29, 2013, at 10:11 PM, Mike Duigou wrote: Hello All; This is a review for three changes to the J2SE Netbeans project. If necessary I can break this up into three separate patches but I would rather not if possible. http://cr.openjdk.java.net/~mduigou/JDK-8011814/0/webrev/ 8011814: Add testng.jar to Netbeans projects test compile classpath An increasing number of jtreg tests now use TestNG. This change adds the TestNG jar from you JTReg installation to the tests classpath. The location of JTReg is specified in build.properties using jtreg.home or from the environment via JT_HOME. 8013271: Add OS X sources to J2SE Netbeans project Adds as source entry for Apple OS X sources to match the Unix and Windows entries. I checked the trademark with the Apple Trademarks page to make sure I got it correct. 8013272: JDK Netbeans projects should use ASCII encoding for sources The build scripts compile all OpenJDK java sources using the US-ASCII encoding. This change causes Netbeans to respect this encoding. Whether US-ASCII is the awesomest encoding is certainly debatable, but all editors and IDEs should use what the compiler uses. Thanks for reviewing, Mike Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: review request: 8011620 adding free form netbeans project for jdbc to jdk/make/netbeans
still looking for a committer to bless this webrev so I can put it back thank you in advance best Lance On Apr 9, 2013, at 11:58 AM, Lance Andersen - Oracle wrote: Thank you ulf, I made the change in my workspace so that it will be accommodated as part of the putback Best Lance On Apr 9, 2013, at 11:26 AM, Ulf Zibis wrote: Hi, there is a little indentation error in build.xml in line 42. -Ulf Am 09.04.2013 16:55, schrieb Lance Andersen - Oracle: Hi, This is a request to review adding a netbeans freeform project to jdk/make/netbeans for jdbc As part of this change, I also modified common/shared.xml to properly look for the jtreg report.html in the html directory and so the javadoc was using version 1.8 The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/ Best lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
review request: 8011620 adding free form netbeans project for jdbc to jdk/make/netbeans
Hi, This is a request to review adding a netbeans freeform project to jdk/make/netbeans for jdbc As part of this change, I also modified common/shared.xml to properly look for the jtreg report.html in the html directory and so the javadoc was using version 1.8 The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/ Best lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: review request: 8011620 adding free form netbeans project for jdbc to jdk/make/netbeans
Thank you ulf, I made the change in my workspace so that it will be accommodated as part of the putback Best Lance On Apr 9, 2013, at 11:26 AM, Ulf Zibis wrote: Hi, there is a little indentation error in build.xml in line 42. -Ulf Am 09.04.2013 16:55, schrieb Lance Andersen - Oracle: Hi, This is a request to review adding a netbeans freeform project to jdk/make/netbeans for jdbc As part of this change, I also modified common/shared.xml to properly look for the jtreg report.html in the html directory and so the javadoc was using version 1.8 The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/ Best lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: Build changes for 7176225: Remove JDBC-ODBC Bridge
On Oct 30, 2012, at 7:55 AM, Alan Bateman wrote: On 29/10/2012 12:41, John Yeary wrote: Thanks Ulf, that was my exact point Ulf. Although, you were much more eloquent. One of the most consistent things that Java has done is ensuring backwards compatibility. The removal of something like the JDBC-ODBC bridge will cause issues later. We tell people to upgrade all the time. Security problems arise and we patch them followed by a message to tell folks to upgrade. The consumer JRE even has a reminder application which asks them if they want to upgrade. One click, and their applications stop working. The JDBC-ODBC Bridge was never included with the JRE, you had to install a JDK which provided it and not all JDKs do. Although I don't do anything now with MS Access, I see these nice Swing applications which end up with an Access database. The software that runs a number of Yoga studios has this configuration. It is the small businesses which rely on the cheaper Access based applications which will have problems. The JDBC-ODBC bridge was a useful stop-gap 10+ years ago when there wasn't JDBC drivers available for all databases. It has never supported to my knowledge and the recommendation has always been to use a JDBC driver for the database. For those that are still using it then they have another year to find an alternative. I don't think that is too unreasonable. There will of course be a warning on the download pages that developers will see. For MS Access there are several JDBC drivers available, many of which support JDBC 4.1. There are also other alternatives such as MySQL or Derby available that might be better anyway. I think your point about communities or developers that have been using it and aren't reading download pages, release notes or blogs is valid concern. Any help reaching out to those communities would be appreciated. As regards releasing the source code then this is easier said than done. The JDBC-ODBC bridge came from a third-party originally. To be honest I don't think it's worth the cost and effort anyway as it's completely obsolete. There is a pretty big cost to continue to maintain, support, and test the JDBC-ODBC bridge properly given the amount of platforms, ODBC drivers, databases you would have to adequately test to do it properly. If folks really see a need for this then it provides an opportunity to start up a new project to develop a modern JDBC-ODBC bridge. -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: Build changes for 7176225: Remove JDBC-ODBC Bridge
On Oct 26, 2012, at 5:39 PM, Alan Bateman wrote: On 26/10/2012 21:14, John Yeary wrote: Hello All, Out of curiosity what will replace it? I looked at the transitional notification[1], but it leaves me feeling a little uneasy about it. At one point, I worked on a number of simple applications which used MS Access as the database for a Java Swing front end. The only driver to connect these applications was the JDBC-ODBC bridge. A number of those applications are still around today. Is it safe to assume that the users will not upgrade their systems? When JDK 8 comes out, their applications will fail. I realize that I have come late to the conversation on this since the removal is almost completed, but I see an issue cropping up in the future. John The JDBC-ODBC bridge has never been in OpenJDK, it's just the make files. In any case, the JDBC-ODBC bridge has been on death row for a long time. Lance can confirm but I believe that it hasn't been updated beyond JBDC 2.0 whereas JDK7 moved to JDBC 4.1. I don't think it has been usable with any of the JDBC features that were added over the last few major releases. That is correct, it has not been enhanced in close to 10 years. It has been tweaked just enough to allow it to continue to build. We do not test it, we do not fix bugs in it (and I have a long list of bugs) and it does not run on all of the platforms for which there is a JDK and is not part of the JRE. Another thing is that I don't think it has ever been supported. That is correct. The oldest documentation I found is JDK 1.3 where it was recommended only for experimental use. I don't think it has really been necessary for many years anyway as so many JDBC drivers available. There are some databases, such as access, where you might be out of luck in the short term with Java SE 8 but again we have not been updating the bridge and it is sorely behind the times. If someone sees a need for this, it provides an opportunity to create a driver that they might choose to support commercially. Best Lance -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
