On Thu, 18 Nov 2021 09:10:16 GMT, Andrew Leonard wrote:
>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 131:
>>
>>> 129: // There's also a files array per version
>>> 130: // Use a LinkedHashMap to keep original insertion ordering
>>> 131: Map filesMap = new
On Wed, 17 Nov 2021 15:11:24 GMT, Maurizio Cimadamore
wrote:
>> So the refresh is still upcoming? Sorry, I thought it was pushed last week.
>> When it is pushed, I'll merge in master and the duplicated changes will just
>> be removed from the PR.
>
>> So the refresh is still upcoming? Sorry,
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by
On Fri, 12 Nov 2021 17:01:38 GMT, Paul Sandoz wrote:
>>> > You could also do this directly in the Panama repo branches. I'll
>>> > volunteer to help, if you want.
>>>
>>> I'll run the script on the PR I've submitted for the Foreign API, and I
>>> will update that one - thanks. Perhaps
On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source code in java.xml and
> java.xml.crypto. This scripts verifies that modifiers are in the "blessed"
> order, and fixes it otherwise. I have manually check
On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source code in java.xml and
> java.xml.crypto. This scripts verifies that modifiers are in the "blessed"
> order, and fixes it otherwise. I have manually check
I ran bin/blessed-modifier-order.sh on source code in java.xml and
java.xml.crypto. This scripts verifies that modifiers are in the "blessed"
order, and fixes it otherwise. I have manually checked the changes made by the
script to make sure they are sound.
-
Commit messages:
-
On Fri, 12 Nov 2021 11:13:24 GMT, Maurizio Cimadamore
wrote:
>>> You could also do this directly in the Panama repo branches. I'll volunteer
>>> to help, if you want.
>>
>> I'll run the script on the PR I've submitted for the Foreign API, and I will
>> update that one - thanks. Perhaps
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by
I assume this is relevant for panama-dev as well, but I can't
unfortunately tag the issue as such in Github/Skara. (Maybe we should
have a mapping for jdk.incubator.vector/foreign -> panama-dev?)
/Magnus
On 2021-11-11 15:57, Magnus Ihse Bursie wrote:
I ran bin/blessed-modifier-order
I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This
scripts verifies that modifiers are in the "blessed" order, and fixes it
otherwise. I have manually checked the changes made by the script to make sure
they are sound.
In this case, while the script did into the
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
On Thu, 4 Nov 2021 11:48:04 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts
> verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
> have manually checked the changes made by the
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
On Fri, 5 Nov 2021 11:31:34 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
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
> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts
> verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
> have manually checked the changes made by the script to make sure they are
> sound.
Magnus Ihse Bursie has up
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the scr
On Thu, 4 Nov 2021 05:16:42 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
>> components to compute
On Thu, 4 Nov 2021 12:30:40 GMT, Aleksei Efimov wrote:
>> I can see that this PR changes java.naming. Another bug to change
>> java.naming, JDK-8276552, was filed yesterday. Please check with its
>> reporter and coordinate this effort if necessary.
>
>> I can see that this PR changes
I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts
verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
have manually checked the changes made by the script to make sure they are
sound.
-
Commit messages:
- 8276635: Use blessed
I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts
verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
have manually checked the changes made by the script to make sure they are
sound.
-
Commit messages:
- 8276629: Use blessed
On Fri, 22 Oct 2021 10:44:31 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
>> components to compute
On Wed, 20 Oct 2021 09:28:30 GMT, Leslie Zhai wrote:
>> 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:
>
> Hi @wangweij
>
> But how to be
On Tue, 19 Oct 2021 13:51:45 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.
LGTM
-
Marked as reviewed by ihse (Reviewer).
PR:
On 2021-10-05 03:22, John Platts wrote:
I wrote a test program (in C++) to detect the codepages that would be returned by the
GetACP(), GetOEMCP(), and GetConsoleCP() functions when the
UTF-8 setting is added to the
manifest.
The manifest element (supported on Windows 10 Version
1903 or
On Wed, 22 Sep 2021 10:27:45 GMT, Jaikiran Pai wrote:
>> The commit in this PR implements the proposal for enhancement that was
>> discussed in the core-libs-dev mailing list recently[1], for
>> https://bugs.openjdk.java.net/browse/JDK-8231640
>>
>> At a high level - the `store()` APIs in
On Wed, 22 Sep 2021 10:27:45 GMT, Jaikiran Pai wrote:
>> The commit in this PR implements the proposal for enhancement that was
>> discussed in the core-libs-dev mailing list recently[1], for
>> https://bugs.openjdk.java.net/browse/JDK-8231640
>>
>> At a high level - the `store()` APIs in
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and "custom" variants to be handled
>
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and "custom" variants to be handled
>
On Tue, 14 Sep 2021 02:30:01 GMT, Jaikiran Pai wrote:
>> The commit in this PR implements the proposal for enhancement that was
>> discussed in the core-libs-dev mailing list recently[1], for
>> https://bugs.openjdk.java.net/browse/JDK-8231640
>>
>> At a high level - the `store()` APIs in
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote:
> Currently, the build system defaults the libjvm.so location to "server".
> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
> need to see if moving the libjvm.so to a proper location breaks anything.
>
>
On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote:
> This change implements a simple web server that can be run on the
> command-line with `java -m jdk.httpserver`.
>
> This is facilitated by adding an entry point for the `jdk.httpserver` module,
> an implementation class whose main method
On Thu, 9 Sep 2021 15:23:45 GMT, Aleksey Shipilev wrote:
>> Sure, that works for me.
>
> While we are at it, do `core` and `custom` even carry their weight? I cannot
> remember if I ever seen anyone using them. Maybe we should "just" drop those
> variants, and leave only "server, client,
On Thu, 9 Sep 2021 14:41:02 GMT, Aleksey Shipilev wrote:
>> I think we should stop these as well from impersonating the server JVM.
>> Preferably in the same fix, so we can remove all the special casing for
>> "server" being anything else but server.
>
> Ok, I agree. Can I do a Zero-specific
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote:
> Currently, the build system defaults the libjvm.so location to "server".
> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
> need to see if moving the libjvm.so to a proper location breaks anything.
>
>
On Thu, 9 Sep 2021 13:14:35 GMT, Aleksey Shipilev wrote:
>> make/autoconf/hotspot.m4 line 86:
>>
>>> 84: fi
>>> 85:
>>> 86: # All "special" variants share the same output directory ("server")
>>
>> I presume "zero" was a special variant? Are there any other variants
>> remaining?
>
>
On 2021-09-09 12:04, Magnus Ihse Bursie wrote:
Let me be more concrete: I suggest adding a new overloaded method,
publicvoidstore(Writerout, Stringcomments, boolean includeTimestamp)
And somehow my email program managed to mess up the code formatting. :-(
The signature I meant was of course
On 2021-09-09 10:27, Jaikiran Pai wrote:
On 31/08/21 7:09 pm, Jaikiran Pai wrote:
Hello Magnus,
On 30/08/21 5:29 pm, Magnus Ihse Bursie wrote:
On 2021-08-28 17:16, Alan Bateman wrote:
On 28/08/2021 05:45, Jaikiran Pai wrote:
I hadn't considered the system property approach to switch
On Wed, 8 Sep 2021 09:54:33 GMT, Jaikiran Pai wrote:
>> The commit in this PR implements the proposal for enhancement that was
>> discussed in the core-libs-dev mailing list recently[1], for
>> https://bugs.openjdk.java.net/browse/JDK-8231640
>>
>> At a high level - the `store()` APIs in
On 2021-08-28 17:16, Alan Bateman wrote:
On 28/08/2021 05:45, Jaikiran Pai wrote:
I hadn't considered the system property approach to switch to old
behaviour in my proposals, so this is a very good input and I
personally think the most logical proposals so far.
Roger may be right that few
On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote:
> When the classlist is generated using build.tools.classlist.HelloClasslist,
> its contents may be non-deterministic due to Java thread execution order.
>
> We should sort the generated classlist to make the JDK image's contents more
>
On 2021-08-25 14:03, Magnus Ihse Bursie wrote:
Hi Jaikiran,
I'm glad to see this issue finally getting some love and attention! :)
I don't fully support those "inclinations" that say that the old API
should not change. I think keeping the old random order of store()
would mea
Hi Jaikiran,
I'm glad to see this issue finally getting some love and attention! :)
I don't fully support those "inclinations" that say that the old API
should not change. I think keeping the old random order of store() would
mean a missed chance to do good, otherwise a lot of Java programs
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Fri, 5 Feb 2021 09:49:11 GMT, Andrew Haley wrote:
>> I reviewed bsd_aarch64.cpp digging bit deeper and left some comments.
>
>> > Umm, so how does patching work? We don't even know if other threads are
>> > executing the code we need to patch.
>>
>> I thought java can handle that scenario
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> make/autoconf/flags.m4 line 140:
>
>> 138: else
>> 139:
On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie wrote:
> We need to regenerate the exported nroff man pages to include the proper
> version string. This will also bring in some recent textual updates to the
> man pages.
This pull request has now been integrated.
Changeset:
We need to regenerate the exported nroff man pages to include the proper
version string. This will also bring in some recent textual updates to the man
pages.
-
Commit messages:
- 8261149: Initial nroff manpage update for JDK 17
Changes:
On Mon, 1 Feb 2021 20:10:58 GMT, Ioi Lam wrote:
>> - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which
>> allowed the same JDK library to use different version of HotSpot. However,
>> HSX is no longer supported so this API should be removed.
>> - Implementations of APIs such
On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote:
> Before RC phase we need to ensure we have the final set of manpage updates
> published in OpenJDK.
This pull request has now been integrated.
Changeset: ed1a7755
Author:Magnus Ihse Bursie
URL: https://git.openjdk.ja
On Mon, 1 Feb 2021 22:46:15 GMT, David Holmes wrote:
>> Before RC phase we need to ensure we have the final set of manpage updates
>> published in OpenJDK.
>
> Thanks for doing this Magnus! I had overlooked the fact we would need to
> re-run this in 2021 regardless of whether there were any
On Mon, 1 Feb 2021 12:35:05 GMT, Alan Hayward
wrote:
> > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>
> Unless there's something I'm missing it only requires a few lines of change
> to src/utils/hsdis/makefile (it already has support for macos x86_64)
I agree
On Fri, 29 Jan 2021 23:06:20 GMT, Alexey Semenyuk wrote:
>> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>>
>> The fix splits Linux app launcher in app launcher and launcher shared lib.
>> App launcher is pure C and doesn't have C++ code. App launcher lib
>> incorporates bulk of
On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote:
> Before RC phase we need to ensure we have the final set of manpage updates
> published in OpenJDK.
These updates have been made automatically from the markdown source files
(which unfortunately is still close
Before RC phase we need to ensure we have the final set of manpage updates
published in OpenJDK.
-
Commit messages:
- 8258378: Final nroff manpage update for JDK 16
Changes: https://git.openjdk.java.net/jdk16/pull/142/files
Webrev:
On Tue, 26 Jan 2021 21:59:03 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik wrote:
>> make/autoconf/build-aux/autoconf-config.guess line 1275:
>>
>>> 1273: UNAME_PROCESSOR="aarch64"
>>> 1274: fi
>>> 1275: fi ;;
>>
>> Almost, but not quite, correct. We cannot change the
On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster
wrote:
>> @luhenry , could you please check this comment, I think SA-agent was MS's
>> job here.
>
> The target is identified by the header file now:
>
On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie wrote:
> For java.base gensrc we do the following:
>
> # Copy two Java files that need no preprocessing.
> $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java:
> $(CHARACTERDATA_TEMPLATES)/%.java.template
> $(call LogInf
On 2021-01-26 13:09, Vladimir Kempik wrote:
On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward
wrote:
AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
ie:
`--with-extra-ldflags='-F
For java.base gensrc we do the following:
# Copy two Java files that need no preprocessing.
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java:
$(CHARACTERDATA_TEMPLATES)/%.java.template
$(call LogInfo, Generating $(@F))
$(call install-file)
GENSRC_CHARACTERDATA +=
On Sat, 23 Jan 2021 07:55:09 GMT, Alan Bateman wrote:
> We should create a separate issue to rename them and get rid of the copying
> in the make file.
I opened https://bugs.openjdk.java.net/browse/JDK-8260406.
-
PR: https://git.openjdk.java.net/jdk/pull/1611
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
@AlanBateman When I moved the charset templates, I found
lved, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desk
On 2021-01-15 19:27, mark.reinh...@oracle.com wrote:
Feature JEPs are living documents until such time as they are delivered.
In this case it would not be appropriate to update JEP 201, which is as
much about the transition from the old source-code layout as it is about
the new layout as of
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
@AlanBateman That sounds like an excellent idea. I'll update
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 ei
On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman wrote:
>> I think this is almost ready to be pushed, but I'd like to have someone from
>> the client team review the changes for java.desktop as well. @prrace Any
>> change you can have a look at this?
>
> I think it will be annoying to have the
On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `character
lved, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [ ] java.desktop
lved, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [ ] java.base
> - [ ] java.desk
On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote:
> Please review a small change that replaces use of objc_msgSend_stret in macOS
> platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64
> support, where objc_msgSend_stret is not available.
Marked as reviewed by ihse
On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote:
> This is for JDK16, as a precursor to fixing JDK-8258002.
>
> While it is good to be using localized strings in the generated output, the
> significance for JDK-8258002 is that the strings are now obtained from a
> resource file, and
On Sun, 13 Dec 2020 00:22:04 GMT, Jonathan Gibbons wrote:
>> This is for JDK16, as a precursor to fixing JDK-8258002.
>>
>> While it is good to be using localized strings in the generated output, the
>> significance for JDK-8258002 is that the strings are now obtained from a
>> resource file,
On Tue, 15 Dec 2020 01:41:07 GMT, Joe Wang wrote:
>> I agree that there is room for improvement here. How about:
>> "...an allow-list too restrictively, or a reject-list too broadly, may..."
>> ?
>
> Your call, I'm not a native English speaker :-) It felt to me it's
> 'restrictive' than
On Tue, 8 Dec 2020 23:23:55 GMT, Joe Darcy wrote:
>> Start of JDK 17 updates.
>
> Joe Darcy 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 14
On Tue, 8 Dec 2020 19:35: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
On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote:
> Please review a small change that replaces use of objc_msgSend_stret in macOS
> platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64
> support, where objc_msgSend_stret is not available.
>From a build PoV this
On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman wrote:
>> The mapping and nr tables, and the *-X.java.template files in
>> make/data/charsetmapping are used to generate source code for the java.base
>> and jdk.charsets modules. The stdcs-$OS files configure the package and
>> module that each
On Tue, 8 Dec 2020 15:25:47 GMT, Weijun Wang wrote:
>> The mapping and nr tables, and the *-X.java.template files in
>> make/data/charsetmapping are used to generate source code for the java.base
>> and jdk.charsets modules. The stdcs-$OS files configure the package and
>> module that each
On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote:
>> Also, to clarify, for me there is a fundamental difference between
>> `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files
>> that are part of the module, owned by the content team, and the `$MODULE`
>> part is
On Tue, 8 Dec 2020 08:27:16 GMT, Magnus Ihse Bursie wrote:
>> Hi Magnus,
>>
>> I see the motivation of moving these build files for better identification
>> of ownership. Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option. Given that skara wi
On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung wrote:
>> I have reviewed all lines in the patch file with or near instances of
>> `jdk.compiler`
>
> Hi Magnus,
>
> I see the motivation of moving these build files for better identification of
> ownership. Placing them under
>
On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie wrote:
>> Regarding the chosen layout. Did you consider following the existing pattern
>> of src//{share,}/data?
>
> @erikj79 Good point, that makes much more sense.
I'm not sure about the formal process for suggesting chan
On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie wrote:
>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered
> JEP, but this is the text I suggest should replace the current definition of
&
lved, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
Magnus Ihse Bursie has updated the pull request incrementally with one
additio
On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson wrote:
>> My understanding of JEPs is that they should be viewed as living documents.
>> In this case, I think it's perfectly valid to update JEP 201 with additional
>> source code layout. Both for this and for the other missing dirs.
>
>
On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman wrote:
>> To facilitate review, here is a list on how the different directories under
>> make/data has moved.
>>
>> **To java.base:**
>> * blacklistedcertsconverter
>> * cacerts
>> * characterdata
>> * charsetmapping
>> * cldr
>> * currency
>> *
On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie wrote:
>> Are you proposing any text or guidelines to be added to JEP 201 as part of
>> this?
>>
>> I think the location of jdwp.spec and its location in the build tree may
>> need to be looked at ag
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote:
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actua
A lot (but not all) of the data in make/data is tied to a specific module. For
instance, the publicsuffixlist is used by java.base, and fontconfig by
java.desktop. (A few directories, like mainmanifest, is *actually* used by make
for the whole build.)
These data files should move to the
On Thu, 26 Nov 2020 20:58:38 GMT, Magnus Ihse Bursie wrote:
> For historical reasons, there exists a variety of different implementations
> of awk: awk (the original implementation), gawk (the GNU version), nawk (new
> awk, iirc) and the lesser known mawk.
>
> Things
For historical reasons, there exists a variety of different implementations of
awk: awk (the original implementation), gawk (the GNU version), nawk (new awk,
iirc) and the lesser known mawk.
Things are complicated by the fact that the original awk is seldom used, but
instead gawk or nawk is
101 - 200 of 405 matches
Mail list logo
