RFR: 8259485: Document need for short paths when building on Windows
Though this content seems simple, it would be extremely frustrating to newcomers, especially when the build stalls at "cannot find valid visual studio installation" for no clear reason in logs at all. - Commit messages: - 8259485: Document need for short paths when building on Windows Changes: https://git.openjdk.java.net/jdk/pull/2043/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2043=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259485 Stats: 15 lines in 2 files changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2043.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2043/head:pull/2043 PR: https://git.openjdk.java.net/jdk/pull/2043
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3]
On Mon, 11 Jan 2021 17:09:14 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:
>>
>>> 39:NSLog(@"%@",[NSThread callStackSymbols]); \
>>> 40:if ([NSThread isMainThread] == NO) { \
>>> 41:if ((*env)->ExceptionOccurred(env) == NULL) { \
>>
>> Not sure that the check for ExceptionOccurred is needed, in all other places
>> where we check the ref to methods/field we only check the return value, and
>> if it is null then return immediately assuming that an exception is rased
>> already, for example :
>> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357
>>
>> Note that the exception in the static initializer is fatal for the
>> application.
>
>> Not sure that the check for ExceptionOccurred is needed,
> It may not be needed in practice but if the code path is never taken no harm
> ...
>
> in all other places where we check the ref to methods/field we only check the
> return value, and if it is null then return immediately assuming that an
> exception is rased already, for example :
>>
>> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357
>>
>> Note that the exception in the static initializer is fatal for the
>> application.
>
> Nothing new here.
The new thing here is that you check the result of the ExceptionOccurred if
NULL is returned from the GetMethodID/etc, we usually never do it. If such
checks are necessary then I'll create a separate bug to update other similar
use cases.
-
PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3]
On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote:
>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8259343: [macOS] Update JNI error handling in Cocoa code.
src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197:
> 195: } \
> 196: if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \
> 197: [NSException raise:NSGenericException format:@"Java
> Exception"]; \
How did you check that the logging in the NSApplication was swallowing? Both
macro will throw the NSException on the toolkit thread now, does it mean that
in both cases the logging in the NSApplication will be ignored/no output?
-
PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v4]
On Fri, 8 Jan 2021 00:49:36 GMT, Vladimir Kozlov wrote: >> Hao Sun has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Split the PR, addressing -Wdeprecated-copy only >> >> As suggested by kimbarrett, we should focus on warnings produced by >> '-Wdeprecated-copy' in this PR. Because JDK-8259288 is a very different >> problem and might be reviewed by folks from different teams. >> >> Will create a new PR to address JDK-8259288. >> >> Change-Id: I1b9f434ab6fcdf2763a46870eaed91641984fd76 >> CustomizedGitHooks: yes > > Still good. @vnkozlov would you mind helping to review the latest commit (again)? Really appreciate it. - PR: https://git.openjdk.java.net/jdk/pull/1874
Integrated: Merge jdk16
On Mon, 11 Jan 2021 22:04:16 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: b378f54d Author:Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/b378f54d Stats: 139 lines in 12 files changed: 116 ins; 2 del; 21 mod Merge - PR: https://git.openjdk.java.net/jdk/pull/2040
Re: RFR: Merge jdk16 [v2]
> Forwardport JDK 16 -> JDK 17 Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Merge - Changes: - all: https://git.openjdk.java.net/jdk/pull/2040/files - new: https://git.openjdk.java.net/jdk/pull/2040/files/e55da33b..69dad8ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2040=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2040=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040
Integrated: 8258925: configure script failed on WSL
On Thu, 24 Dec 2020 08:04:34 GMT, Yasumasa Suenaga wrote: > I ran configure script on WSL 1, but it failed as below: > > $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 > > : > > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as > "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java > configure exiting with result code 1 > > `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with > original path, but `.exe` would not be added even if `$path.exe` exists. This pull request has now been integrated. Changeset: 712ea250 Author:Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/712ea250 Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod 8258925: configure script failed on WSL Reviewed-by: dholmes, erikj - PR: https://git.openjdk.java.net/jdk/pull/1889
RFR: Merge jdk16
Forwardport JDK 16 -> JDK 17 - Commit messages: - Merge - 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing - 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl - 8259043: More Zero architectures need linkage with libatomic - 8259429: Update reference to README.md - 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win) The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk=2040=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk=2040=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2040/files Stats: 140 lines in 12 files changed: 117 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3]
On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. Build changes look good. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2]
On Mon, 11 Jan 2021 18:56:38 GMT, Erik Joelsson wrote: > There should be a dependency declaration added too. Something like this right > after the SetupJdkLibrary macro call: > > $(BUILD_LIBOSXAPP): $(call FindLib, java.base, java) Fixed. - PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3]
> Proposed updates to JNI error handling. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8259343: [macOS] Update JNI error handling in Cocoa code. - Changes: - all: https://git.openjdk.java.net/jdk/pull/1967/files - new: https://git.openjdk.java.net/jdk/pull/1967/files/08a41150..913b37c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1967=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1967=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967 PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2]
On Mon, 11 Jan 2021 17:52:19 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. make/modules/java.desktop/Lib.gmk line 96: > 94: $(call SET_SHARED_LIBRARY_ORIGIN), \ > 95: LIBS := \ > 96: -ljava \ There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call: $(BUILD_LIBOSXAPP): $(call FindLib, java.base, java) - PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8258426: Split up autoconf/version-numbers and move it to conf dir [v3]
> The file `make/autoconf/version-numbers` is plagued by a two-fold problem: > first of all, it's a configuration file, not a part of autoconf, so it should > reside in `make/conf` instead of `make/autoconf`. > > Secondly, contrary to the name, it does not only contain version numbers, but > also the branding properties (company name, product name, etc). This should > be split out into a separate branding configuration file. > > This is the last patch in the series of moving configuration into `make/conf`. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into version-numbers-to-conf - Also update submit.yml - 8258426: Split up autoconf/version-numbers and move it to conf dir - Changes: - all: https://git.openjdk.java.net/jdk/pull/1786/files - new: https://git.openjdk.java.net/jdk/pull/1786/files/bcd3b338..63162969 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1786=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1786=01-02 Stats: 51838 lines in 1653 files changed: 23670 ins; 14499 del; 13669 mod Patch: https://git.openjdk.java.net/jdk/pull/1786.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1786/head:pull/1786 PR: https://git.openjdk.java.net/jdk/pull/1786
Integrated: 8258426: Split up autoconf/version-numbers and move it to conf dir
On Tue, 15 Dec 2020 19:07:55 GMT, Magnus Ihse Bursie wrote: > The file `make/autoconf/version-numbers` is plagued by a two-fold problem: > first of all, it's a configuration file, not a part of autoconf, so it should > reside in `make/conf` instead of `make/autoconf`. > > Secondly, contrary to the name, it does not only contain version numbers, but > also the branding properties (company name, product name, etc). This should > be split out into a separate branding configuration file. > > This is the last patch in the series of moving configuration into `make/conf`. This pull request has now been integrated. Changeset: 38619602 Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/38619602 Stats: 152 lines in 8 files changed: 81 ins; 55 del; 16 mod 8258426: Split up autoconf/version-numbers and move it to conf dir Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk/pull/1786
Integrated: 8259559: COMPARE_BUILD can't compare patch files
On Mon, 11 Jan 2021 11:11:01 GMT, Magnus Ihse Bursie wrote: > COMPARE_BUILD will fail to run the compare stage, since re-applying an > applied patch does not work. This pull request has now been integrated. Changeset: dab17875 Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/dab17875 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8259559: COMPARE_BUILD can't compare patch files Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk/pull/2025
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2]
On Mon, 11 Jan 2021 05:58:28 GMT, Sergey Bylokhov wrote:
>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46:
>>
>>> 44: if ((*env)->ExceptionOccurred(env) != NULL) { \
>>> 45: (*env)->ExceptionDescribe(env); \
>>> 46: } \
>>
>> So the update here is that if we are not on the appkit thread, make sure a
>> java exception is thrown.
>> If we are on the appkit thread, clear any java exception since it isn't
>> going anywhere but do it using
>> describe which prints it.
>
> I read the logic of the method differently, probably the wrong indents?
> - If we are not on the toolkit thread then
> - Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or
> check exception again ->call ExceptionDescribe
> - NSException raise at the end.
I have a paren in the wrong place ! I've pushed an update.
-
PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2]
On Mon, 11 Jan 2021 06:01:36 GMT, Sergey Bylokhov wrote: >> I hadn't noticed that line - and definintely not realised it was recent. >> I suppose he must have had a way to trigger it. >> But I don't think it hurts to have both. > > I just tried to understand why we need to complicate this, to me, it is > unclear why handling the same errors in the NSApplicationAWT.m does not work. Because of the reason I've said before. That logging in NSApplication AWT is not being seen. Something is swallowing it. So I'd say if anything remove that logging and keep the new one but as I also said it isn't harmful to have provision in case it also logs some case we aren't catching. - PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2]
> Proposed updates to JNI error handling. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8259343: [macOS] Update JNI error handling in Cocoa code. - Changes: - all: https://git.openjdk.java.net/jdk/pull/1967/files - new: https://git.openjdk.java.net/jdk/pull/1967/files/0e745aa6..08a41150 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1967=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1967=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967 PR: https://git.openjdk.java.net/jdk/pull/1967
Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2]
On Mon, 11 Jan 2021 05:52:02 GMT, Sergey Bylokhov wrote: > Not sure that the check for ExceptionOccurred is needed, It may not be needed in practice but if the code path is never taken no harm ... in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : > > https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 > > Note that the exception in the static initializer is fatal for the > application. Nothing new here. - PR: https://git.openjdk.java.net/jdk/pull/1967
RE: [11u] RFR: 8256810: Incremental rebuild broken on Macosx
Hi Roland, > Sure. Is a comment stating that this was backported what you have in mind? Preferrably comment + link "backportet by" to your backport issue. > Would you mind reviewing my RFR given you've already taken a look at > this area? I'll take a look. Best regards, Martin > -Original Message- > From: Roland Westrelin > Sent: Montag, 11. Januar 2021 17:40 > To: Doerr, Martin ; jdk-updates- > d...@openjdk.java.net; build-dev@openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: RE: [11u] RFR: 8256810: Incremental rebuild broken on Macosx > > > > thanks for letting me know. My plan was to backport both changes in the > original order, but I'm fine if you do change to the new version at once. > > May I ask you to flag both issues as backported once you're done? > > Sure. Is a comment stating that this was backported what you have in mind? > > Would you mind reviewing my RFR given you've already taken a look at > this area? > > Roland.
RE: [11u] RFR: 8256810: Incremental rebuild broken on Macosx
> thanks for letting me know. My plan was to backport both changes in the > original order, but I'm fine if you do change to the new version at once. > May I ask you to flag both issues as backported once you're done? Sure. Is a comment stating that this was backported what you have in mind? Would you mind reviewing my RFR given you've already taken a look at this area? Roland.
RE: [11u] RFR: 8256810: Incremental rebuild broken on Macosx
Hi Roland, thanks for letting me know. My plan was to backport both changes in the original order, but I'm fine if you do change to the new version at once. May I ask you to flag both issues as backported once you're done? Best regards, Martin > -Original Message- > From: Roland Westrelin > Sent: Montag, 11. Januar 2021 17:16 > To: Doerr, Martin ; jdk-updates- > d...@openjdk.java.net; build-dev@openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8256810: Incremental rebuild broken on Macosx > > > Hi Martin, > > > JDK-8256810 is backported to 11.0.11-oracle. I'd like to backport it for > > parity. > > Change doesn't apply cleanly because of an unlrelated context change > (Solaris removal). > > See my RFR for the backport of 8257547. It basically replaces all of > that code. > > Roland.
Re: [11u] RFR: 8256810: Incremental rebuild broken on Macosx
Hi Martin, > JDK-8256810 is backported to 11.0.11-oracle. I'd like to backport it for > parity. > Change doesn't apply cleanly because of an unlrelated context change (Solaris > removal). See my RFR for the backport of 8257547. It basically replaces all of that code. Roland.
[11u] RFR: 8256810: Incremental rebuild broken on Macosx
Hi, JDK-8256810 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly because of an unlrelated context change (Solaris removal). Bug: https://bugs.openjdk.java.net/browse/JDK-8256810 Original change: https://github.com/openjdk/jdk/commit/4c86e46d 11u backport: http://cr.openjdk.java.net/~mdoerr/8256810_build_11u/webrev.00/ Please review. Best regards, Martin
Re: RFR: 8259559: COMPARE_BUILD can't compare patch files
On Mon, 11 Jan 2021 11:11:01 GMT, Magnus Ihse Bursie wrote: > COMPARE_BUILD will fail to run the compare stage, since re-applying an > applied patch does not work. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2025
Re: RFR: 8258925: configure script failed on WSL [v5]
On Sat, 9 Jan 2021 14:05:10 GMT, Yasumasa Suenaga wrote: >> I ran configure script on WSL 1, but it failed as below: >> >> $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 >> >> : >> >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as >> "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java >> configure exiting with result code 1 >> >> `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with >> original path, but `.exe` would not be added even if `$path.exe` exists. > > Yasumasa Suenaga has updated the pull request incrementally with one > additional commit since the last revision: > > Use "unixpath" instead of "path" This looks good to me. Thanks! - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1889
[jdk16] Integrated: 8259043: More Zero architectures need linkage with libatomic
On Mon, 4 Jan 2021 08:34:02 GMT, Aleksey Shipilev wrote: > JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are > other 32-bit Zero platforms that need the same kind of treatment. > > Additional testing: > - [x] linux-mipsel-zero-fastdebug build This pull request has now been integrated. Changeset: e05f36f4 Author:Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16/commit/e05f36f4 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod 8259043: More Zero architectures need linkage with libatomic Co-authored-by: Matthias Klose Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk16/pull/76
Re: [jdk16] RFR: 8259043: More Zero architectures need linkage with libatomic
On Mon, 4 Jan 2021 18:42:05 GMT, Erik Joelsson wrote: >> JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are >> other 32-bit Zero platforms that need the same kind of treatment. >> >> Additional testing: >> - [x] linux-mipsel-zero-fastdebug build > > Marked as reviewed by erikj (Reviewer). Matthias reports (privately) that Zero arches still build in Debian with this patch. Integrating. - PR: https://git.openjdk.java.net/jdk16/pull/76
Re: RFR: 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk [v4]
> Right now `CompileJavaModules.gmk` contains two different part: one part with > the functionality needed to compile a java module, and one part were all > special requirements for all modules are listed. > > The second part should be removed from `CompileJavaModules.gmk`, and instead > listed directly for each individual module in `make/modules/$M/Java.gmk`. > > I used a special-written shell script to automatically extract the > module-specific part from CompileJavaModules.gmk into the respective Java.gmk > files, to avoid risking any hard-to-detect copy/paste errors. After this I > did a `sed -i` to remove the module-specific prefix. All this makes me > confident that I have correctly moved the variables (I realize this is hard > to verify from the patch). Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' of https://git.openjdk.java.net/jdk into modularize-java-part - Final bug fixes... - Rename DISABLED_WARNINGS to DISABLED_WARNINGS_java to avoid overwriting the global variable - $($(MODULE)_COPY_EXTRA) target is not used anymore - Remove module prefix from java variables - Remove debug code mistakenly pushed - Move some more module-specific stuff to Java.gmk files - Only include the module Java.gmk file we need - First step: break out Java settings to separate files - Changes: https://git.openjdk.java.net/jdk/pull/1779/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1779=03 Stats: 2118 lines in 47 files changed: 1556 ins; 548 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1779/head:pull/1779 PR: https://git.openjdk.java.net/jdk/pull/1779
Integrated: 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk
On Tue, 15 Dec 2020 13:11:30 GMT, Magnus Ihse Bursie wrote: > Right now `CompileJavaModules.gmk` contains two different part: one part with > the functionality needed to compile a java module, and one part were all > special requirements for all modules are listed. > > The second part should be removed from `CompileJavaModules.gmk`, and instead > listed directly for each individual module in `make/modules/$M/Java.gmk`. > > I used a special-written shell script to automatically extract the > module-specific part from CompileJavaModules.gmk into the respective Java.gmk > files, to avoid risking any hard-to-detect copy/paste errors. After this I > did a `sed -i` to remove the module-specific prefix. All this makes me > confident that I have correctly moved the variables (I realize this is hard > to verify from the patch). This pull request has now been integrated. Changeset: 1bd015fb Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/1bd015fb Stats: 2118 lines in 47 files changed: 1556 ins; 548 del; 14 mod 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk/pull/1779
Re: RFR: 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk [v3]
On Mon, 4 Jan 2021 15:16:35 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Final bug fixes... > > Marked as reviewed by erikj (Reviewer). @erikj79 Actually, I had not done that. But it was a great idea. Now I have, and it looks good. :-) - PR: https://git.openjdk.java.net/jdk/pull/1779
RFR: 8259559: COMPARE_BUILD can't compare patch files
COMPARE_BUILD will fail to run the compare stage, since re-applying an applied patch does not work. - Commit messages: - 8259559: COMPARE_BUILD can't compare patch files Changes: https://git.openjdk.java.net/jdk/pull/2025/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2025=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259559 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2025/head:pull/2025 PR: https://git.openjdk.java.net/jdk/pull/2025
Integrated: JDK-8250768: javac should be adapted to changes in JEP 12
On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote: > This is an update to javac and javadoc, to introduce support for Preview > APIs, and generally improve javac and javadoc behavior to more closely adhere > to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only > preview language features, and APIs associated with preview language > features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", > which should be true for reflective Preview APIs, false otherwise. This > replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described > in the JEP 12. E.g. the module that declares the preview API is free to use > it without warnings > * improving error/warning messages. Please see [1] for a list of > cases/examples. > * class files are only marked as preview if they are using a preview > feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package > (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in > the source files. javadoc will auto-generate a note for @PreviewFeature > elements, see e.g. [2] and [3] (non-reflective and reflective API, > respectively). A summary of preview elements is also provided [4]. Existing > uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses > of Preview elements, and for declaring elements using preview language > features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 This pull request has now been integrated. Changeset: 23548821 Author:Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/23548821 Stats: 3802 lines in 133 files changed: 2724 ins; 695 del; 383 mod 8250768: javac should be adapted to changes in JEP 12 Reviewed-by: mcimadamore, erikj, jjg, ihse - PR: https://git.openjdk.java.net/jdk/pull/703
Re: RFR: 8257733: Move module-specific data from make to respective module [v4]
On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due >> to a merge or a rebase. The incremental webrev excludes the unrelated >> changes brought in by the merge/rebase. The pull request contains eight >> additional commits since the last revision: >> >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - Step 2: Update references >> - First stage, move actual data files > > Marked as reviewed by prr (Reviewer). This PR is not stale; it's just still waiting for input from @AlanBateman. - PR: https://git.openjdk.java.net/jdk/pull/1611
