On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing wrote:
> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest
There are a few C++ tests under `test/jdk/java/foreign` as well.
-
PR: https://git.openjdk.java.net/jdk/pull/9010
On Fri, 3 Jun 2022 22:40:52 GMT, Tim Prinzing wrote:
>> make/test/JtregNativeJdk.gmk line 67:
>>
>>> 65: BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeNullCallerTest := $(LIBCXX)
>>> jvm.lib
>>> 66: BUILD_JDK_JTREG_EXECUTABLES_LIBS_exerevokeall := advapi32.lib
>>> 67:
On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing wrote:
> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest
Thanks for doing the run, Dan.
-
PR: https://git.openjdk.java.net/jdk/pull/9010
On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing wrote:
> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest
Marked as reviewed by mchung (Reviewer).
make/test/JtregNativeJdk.gmk line 67:
> 65: BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeNullCallerTest := $(LIBCXX) jvm.lib
> 66:
On Wed, 1 Jun 2022 19:27:33 GMT, Tim Prinzing wrote:
>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates
>> a test module with some resources in it for the actual tests that occur at
>> the native level. The native part was switched to c++ instead of c to make
>>
On Wed, 1 Jun 2022 03:01:35 GMT, Tim Prinzing wrote:
>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates
>> a test module with some resources in it for the actual tests that occur at
>> the native level. The native part was switched to c++ instead of c to make
>>
On Wed, 1 Jun 2022 00:59:33 GMT, Tim Prinzing wrote:
>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates
>> a test module with some resources in it for the actual tests that occur at
>> the native level. The native part was switched to c++ instead of c to make
>>
On Mon, 30 May 2022 05:37:16 GMT, Alan Bateman wrote:
> I don't think jdk/nullCaller is right location for this. Maybe jni/nullCaller
> could work. You'll probably need to add the location to an appropriate
> group/tier in test/jdk/TEST.groups, otherwise it won't be run.
I also think
On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing wrote:
>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates
>> a test module with some resources in it for the actual tests that occur at
>> the native level. The native part was switched to c++ instead of c to make
>>
On Fri, 6 May 2022 16:48:11 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-424 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Thu, 5 May 2022 20:54:53 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-424 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Thu, 5 May 2022 16:22:41 GMT, Mandy Chung wrote:
>> Looking deeper, `System::loadLibrary` seems to search the boot loader
>> libraries when invoked with a `null` caller class, so replicating that
>> behavior should be safe.
>
> `BootLoader` is what you want i
On Wed, 4 May 2022 23:44:08 GMT, Maurizio Cimadamore
wrote:
>> Another option would be to treat calls to `ensureNativeAccess` with `null`
>> caller class as coming from unnamed module.
>
> Looking deeper, `System::loadLibrary` seems to search the boot loader
> libraries when invoked with a
On Wed, 20 Apr 2022 01:03:23 GMT, Tim Prinzing wrote:
>> Created a test called NullCallerGetResource to test
>> Module::getResourceAsStream and Class::getResourceAsStream from the native
>> level.
>>
>> At the java level the test builds a test module called 'n' which opens the
>> package
On Mon, 11 Apr 2022 00:48:34 GMT, Tim Prinzing wrote:
>> Created a test called NullCallerGetResource to test
>> Module::getResourceAsStream and Class::getResourceAsStream from the native
>> level.
>>
>> At the java level the test builds a test module called 'n' which opens the
>> package
On Thu, 14 Apr 2022 13:59:57 GMT, Claes Redestad wrote:
>> This patch examines and optimizes `Wrapper` lookups.
>>
>> First wrote a few simple microbenchmarks to verify there are actual speedups
>> from using perfect hash tables in `sun.invoke.util.Wrapper` compared to
>> simpler lookup
On Mon, 21 Mar 2022 16:29:25 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 *actually* used by
On Thu, 3 Mar 2022 16:55:46 GMT, Tim Prinzing wrote:
>> The caller class returned by Reflection::getCallerClass was used to gain
>> access to it's module in most cases and class loader in one case. I added a
>> method to translate the caller class to caller module so that the decision
>> of
On Wed, 2 Mar 2022 21:53:01 GMT, Tim Prinzing wrote:
>> The caller class returned by Reflection::getCallerClass was used to gain
>> access to it's module in most cases and class loader in one case. I added a
>> method to translate the caller class to caller module so that the decision
>> of
On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing wrote:
> The caller class returned by Reflection::getCallerClass was used to gain
> access to it's module in most cases and class loader in one case. I added a
> method to translate the caller class to caller module so that the decision of
> what
On Wed, 16 Feb 2022 21:39:20 GMT, Tim Prinzing wrote:
>> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is
>> null
>
> Tim Prinzing has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 10 commits:
>
> - Merge
On Tue, 15 Feb 2022 23:05:30 GMT, Mandy Chung wrote:
>> Tim Prinzing has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changes from feedback.
>>
>> - Copyright dates fixed
>> - Illegal
On Tue, 15 Feb 2022 22:17:53 GMT, Tim Prinzing wrote:
>> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is
>> null
>
> Tim Prinzing has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Changes from feedback.
>
> -
On Tue, 15 Feb 2022 00:10:44 GMT, Tim Prinzing wrote:
>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> Tim Prinzing has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove excess description
Looks good.
On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
This needs a CSR and the spec needs update.
The test name could be shortened to
`s/exeNullCallerMethodHandlesLookup/exeNullCallerLookup/`.
On Mon, 14 Feb 2022 18:28:09 GMT, Mandy Chung wrote:
>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
>
>> 119: Class c = Reflection.getCallerClass();
>> 120:
On Mon, 14 Feb 2022 11:56:16 GMT, Alan Bateman wrote:
>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
>
>> 119: Class c = Reflection.getCallerClass();
>> 120: if (c == null) {
>>
On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote:
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is
> null
Thanks for taking on these null caller issue.
To give more context to this issue, the spec of
`ClassLoader::isRegisteredAsParallelCapable` returns true if
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
>
On Fri, 24 Sep 2021 23:07:33 GMT, Mandy Chung wrote:
> GenGraphs tool generates the module graph. It currently supports the
> configuration via javadoc-graphs.properties. However,
> `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only
> documents two propertie
GenGraphs tool generates the module graph. It currently supports the
configuration via javadoc-graphs.properties. However,
`make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only
documents two properties. It should be updated to cover all configurable
properties.
There are a
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>>
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`
On Mon, 17 May 2021 18:23:41 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.
>
On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote:
> [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes
> removed sources and also removed JVMCI compiler from list of upgradable
> modules. JVMCI compiler modules should be upgradable in JDK to work with
> GraalVM.
>
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for
On Wed, 16 Dec 2020 18:36:25 GMT, Magnus Ihse Bursie wrote:
>> The hard-coded list of modules in `make/common/Modules.gmk` has always been
>> a wart in the build system. We pride ourself on using discovery instead of
>> hard-coded list. In this case, it is not possible to do do auto-discovery,
On Wed, 16 Dec 2020 14:40:14 GMT, Alan Bateman wrote:
> javadoc-modules.conf is probably okay although someone finding this in the
> repo might initially think it's the configuration for the javadoc modules.
> That plus it sets DOCS_MODULES, so maybe it should be apidocs-modules.conf.
I'm
On Tue, 15 Dec 2020 22:58:47 GMT, Mandy Chung wrote:
>> `JRE_TOOL_MODULES` started with more than one modules in JDK 9:
>>
>> JRE_TOOL_MODULES += \
>> jdk.jdwp.agent \
>> jdk.pack \
>> jdk.scripting.nashorn.shell \
>> #
>>
&
On Tue, 15 Dec 2020 22:47:16 GMT, Mandy Chung wrote:
>> As for `JRE_TOOL_MODULES`, I understand what you mean but it is at least
>> kind of a "sibling" to the others. After all, we use these sets of modules
>> together to form the set of modules for the JRE:
&g
On Tue, 15 Dec 2020 20:32:05 GMT, Magnus Ihse Bursie wrote:
>> I thought it was a consistent and clear naming scheme. :-) But I guess to
>> each their own...
>>
>> Would `classloader-modules.conf`, `docs-modules.conf` and
>> `build-modules.con` be better? Otherwise you'll need to come up with
On Tue, 8 Dec 2020 17:10:30 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 12
On Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung wrote:
>> @wangweij Moving build tools is a related, but separate, question, which is
>> addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
>>
>> I send out a review earlier this year (see
>> https://m
On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie wrote:
>> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into
>> java.base as well?
>>
>> Update: I see all subdirs in tools are still there.
>
> @wangweij Moving build tools is a related, but separate, question, which is
>
On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons 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
>
> I have reviewed all lines in the patch file with or
On Wed, 4 Nov 2020 10:13:59 GMT, Kim Barrett wrote:
>> Hello!
>>
>> As an IDE developer, I'm thinking about IDE inspection that may suggest the
>> new method. My idea is to suggest replacing every `ref.get() == obj` with
>> `ref.refersTo(obj)`. Is this a good idea or there are cases when
On Tue, 20 Oct 2020 05:22:57 GMT, Kim Barrett wrote:
>> @kimbarrett your reworded text is okay. I think "if it initially had some
>> other referent value" can be dropped.
>>
>> For a `Reference` constructed with a `null` referent, we can clarify in the
>> spec that such reference object
On Sat, 10 Oct 2020 00:08:26 GMT, Yumin Qi wrote:
>> This patch is reorganized after 8252725, which is separated from this patch
>> to refactor jlink glugin code. The previous
>> webrev with hg can be found at:
>> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
>>
On Tue, 6 Oct 2020 20:46:17 GMT, Yumin Qi wrote:
>> This patch is reorganized after 8252725, which is separated from this patch
>> to refactor jlink glugin code. The previous
>> webrev with hg can be found at:
>> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
>>
On Tue, 6 Oct 2020 17:35:18 GMT, Yumin Qi wrote:
>> This patch is reorganized after 8252725, which is separated from this patch
>> to refactor jlink glugin code. The previous
>> webrev with hg can be found at:
>> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
>>
On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote:
> This patch is a REDO for JDK-8253208 which was backed out since it caused
> runtime/cds/DeterministicDump.java failed,
> see JDK-8253495. Since the failure is another issue and only triggered by
> this patch, the test case now is put on
>
On Mon, 21 Sep 2020 22:24:15 GMT, Yumin Qi wrote:
>> With more CDS related code added to VM, it is time to move CDS code to a
>> separate class. CDS is the new class which is
>> specific to CDS.
>> Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional
>
On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote:
>> With more CDS related code added to VM, it is time to move CDS code to a
>> separate class. CDS is the new class which is
>> specific to CDS.
>> Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional
>
src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
367 /** 368 * called from vm to generate MethodHandle holder classes 369
* @return @code { Object[] } if holder classes can be generated. 370 *
@param lines the output lines from @code { VM.cdsTraceResolve } 371 */
Looks good.
Mandy
On 4/28/20 7:19 AM, Magnus Ihse Bursie wrote:
The last remaining "WARNING" that is printed while building the JDK
stems from jlink. This is due to the fact that jmod is run with the
flag --warn-if-resolved=incubating, which will cause future processing
of the jmod to print
This looks okay to me.
Can you add the bug ID next to @ignore that will make it easier to find
the JBS issue? These test bugs are filed with P4 but I think they
should be fixed in 15.
Mandy
On 4/15/20 8:56 AM, sundararajan.athijegannat...@oracle.com wrote:
Please review.
Nashorn script
().
So what do you think of this version:
http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/
<http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/> ?
Thanks
Christoph
*From:* Mandy Chung
*Sent:* Dienstag, 31. März 2020 19:34
*To:* Langer, Christoph ;
core-libs-...@openjdk.java.ne
On 3/31/20 7:56 AM, Langer, Christoph wrote:
Hi,
please review a small fix that updates two comments.
The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks about handling of a property
"vm.vendor" in VersionProps.java.template. However, there is no property
Hi Magnus,
On 3/24/20 4:16 AM, Magnus Ihse Bursie wrote:
At the core, we'd like to "invert" the current structure where we have
files like:
make/lib/Lib-java.base.gmk
make/lib/Lib-java.desktop.gmk
make/gensrc/Gensrc-java.base.gmk
make/gensrc/Gensrc-java.desktop.gmk
... etc
and instead have
Hi Magnus,
Modularizing the build tools is a good move. This patch suggests to
place the build tools under
src/$MODULE/share/tools/$PACKAGE/*.java
I think the modular source location of the build tools needs more
discussion, including jigsaw-dev for this discussion.
The JDK source
On 12/5/19 12:41 AM, Alan Bateman wrote:
On 05/12/2019 08:16, Henry Jen wrote:
Hi,
Updated webrev[1] reflect comments since last webrev. Vicente had
done all the heavy-lifting and hand over to me to finish up.
Changes to symbols is reverted, as we expect that only need to be
updated in
On 11/22/19 1:30 PM, Vicente Romero wrote:
[1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/
make/lib/Lib-jdk.pack.gmk should be removed.
make/scripts/compare_exceptions.sh.incl
Should ./lib/libunpack.so also be removed?
make/scripts/compare.sh
line 535-543 invokes
CSR needs to mention that jar -n option is removed. I made minor edit
to the CSR to state that jdk.pack module is removed.
Mandy
On 11/21/19 2:22 PM, Vicente Romero wrote:
please wait, I found some additional dependencies on module jdk.pack,
will submit another webrev, sorry
Vicente
On
On 10/22/19 3:37 PM, mark.reinh...@oracle.com wrote:
2019/10/22 14:12:18 -0700, mandy.ch...@oracle.com:
On 10/21/19 8:22 PM, mark.reinh...@oracle.com wrote:
RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
Webrev:
On 10/21/19 8:22 PM, mark.reinh...@oracle.com wrote:
RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
Looks good to me. One minor comment:
AddResourcePlugin isn't really a
Looks good to me.
Mandy
On 10/18/19 3:12 PM, Jonathan Gibbons wrote:
Please review a small change in the build, to use .svg files instead
of .png files,
for the generated module graph images.
The underlying generator, GraphViz, already supports .svg output.
In the proposed patch, the
Looks okay to me.
Mandy
On 10/8/19 12:24 PM, Erik Joelsson wrote:
In certain Oracle build configurations, the common legal output
directory is never created, because there are no legal files to put in
it. This should not make the build fail. This patch makes adding the
--legal-notices
This looks right to me.
Mandy
On 9/20/19 11:11 AM, Erik Joelsson wrote:
This patch adds the currently missing dependencies between the top
level meta-targets for each module (named just $module). Currently, we
only add dependencies between the java targets for each module (as
those are the
jabswitch is a windows-only tool and so no need for nroff page.
Otherwise looks fine.
Mandy
On 7/23/19 10:40 AM, Jonathan Gibbons wrote:
Please review an update to the nroff pages for JDK 13.
(There are 3 new pages and 2 modified pages.)
This is noreg-doc, so no further approvals are
+1. Missed this in the review.
Mandy
On 6/7/19 4:36 PM, Jonathan Gibbons wrote:
The fix for JDK-8224257 had a transposition typo, putting a ';'
outside a quoted string instead of inside it.
JBS: https://bugs.openjdk.java.net/browse/JDK-8225496
-- Jon
$ hg diff -R open
diff -r
This patch looks fine to me. Nothing is obviously not right. I picked
a couple of specs to sanity check and they look right to me.
Mandy
On 6/7/19 1:58 PM, Jonathan Gibbons wrote:
Please review an update to the tool used to post-process files
generated by pandoc.
In HTML 5, it is not
Bringing these pages to more recent version is better than
the current so outdated version even it's just a snapshot.
The list of new pages look okay (but I didn't validate the
content.)
Mandy
On 5/31/19 2:02 PM, Jonathan Gibbons wrote:
Please review a change to refresh the content of the man
+1
Mandy
On 5/30/19 10:54 AM, Jonathan Gibbons wrote:
In creating the changeset for JDK-8224257, I forgot to 'hg add' a new
file.
Please review this changeset to add the file; the content of the file
were previously reviewed as part of JDK-8224257.
JBS:
Looks good to me.
Mandy
On 5/25/19 1:49 PM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8224790
webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/
Before Java 7 the Xusage.txt file was used to print the "java -X" help
information in English. From Java 7 this
On 2/13/19 1:04 AM, Severin Gehwolf wrote:
--strip-native-debug-symbols no-keep-debuginfo
--strip-native-debug-symbols strip-debuginfo
--strip-native-debug-symbols remove-debuginfo
It would avoid using negation.
What about 'omit', i.e.
--strip-native-debug-symbols omit-debuginfo
On 2/12/19 11:52 AM, Severin Gehwolf wrote:
Hi Mandy, Alan,
Please find the proposal for CLI option of --strip-native-debug-symbols
below.
The current implementation here has the following options:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/
[i]
On 2/12/19 12:05 PM, Severin Gehwolf wrote:
Hi Mandy,
Thanks for the review!
OK. Here is the summary:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-February/014132.html
Personally, I find --strip-native-debug-info or --strip-native-debug-
symbols clearer than just
On 2/8/19 2:08 AM, Alan Bateman wrote:
I agree with Mandy that the CLI options need examination. The proposed
`--strip-native-debug-symbols` seems reasonable but it will be
inconsistent with the existing `--strip-debug` option. Mandy - what you
would think about renaming the existing option
Hi Severin,
Using the plugin specific ResourceBundle is good. Thanks for making
the change.
I see that Alan's comment [1] on the plugin options and I assume
you will investigate the plugin options and bring back a proposal.
Did I miss the discussion on these options?
Option:
On 1/28/19 1:26 AM, Severin Gehwolf wrote:
Hi Alan, Mandy,
On Sun, 2019-01-27 at 08:14 +, Alan Bateman wrote:
On 26/01/2019 00:06, Mandy Chung wrote:
Hi Severin,
Another alternative would be to support per-jlink-plugin resource
bundle to avoid merging .properties files at build time
Hi Severin,
Another alternative would be to support per-jlink-plugin resource
bundle to avoid merging .properties files at build time. The
plugin-specific messages should only be used by the plugin itself
and it would be cleaner for each plugin to manage its resource bundle.
Mandy
On 1/25/19
Looks good.
Mandy
On 12/5/18 9:28 AM, joe darcy wrote:
Hello,
With the inception of JDK 13 right around the corner, please review
the build-related changes of the update:
http://cr.openjdk.java.net/~darcy/jdk13-fork.2
As usual, javac defines a new -source/-target 13 which is used in
included more than
the major version.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/
Thanks, Roger
On 12/04/2018 01:41 PM, Mandy Chung wrote:
On 12/4/18 8:16 AM, Roger Riggs wrote:
Please review correctly setting the java.specification.version property
with only
On 12/4/18 8:16 AM, Roger Riggs wrote:
Please review correctly setting the java.specification.version property
with only the major version number. A test is added to ensure the
java spec version agrees with the major version.
The symptoms are that jtreg would fail with a full version
Looks good to me.
Mandy
On 11/27/18 1:00 PM, Roger Riggs wrote:
Hi,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw-4/index.html
- Updated defaults for VENDOR, VENDOR_URL, VENDOR_URL_BUG to:
COMPANY_NAME=N/A
VENDOR_URL=https://openjdk.java.net/
Hi Roger,
Looking good. I have a few small comments:
I assume VM.saveAndRemoveProperties will be a separate cleanup.
SystemProps::cmdProperties adds the system properties that can
skip adding these internal properties to the Properties object.
In fact, these internal properties are the
://cr.openjdk.java.net/~redestad/8061281_8061282.01/
Thanks!
/Claes
On 2018-11-15 23:50, Mandy Chung wrote:
Hi Claes,
It's good to see this JEP targeted and integrate the microbenchmarks
to colocate with JDK. Overall the work looks good.
The copyright headers need update to GPL. There are some super
On 11/8/18 12:37 PM, dean.l...@oracle.com wrote:
On 11/8/18 11:49 AM, Mandy Chung wrote:
This is strange. upgrade module path precedes the application module
path in the search path. I would not expect --module-path would help.
Sorry, the error is if I remove both --upgrade-module-path
--upgrade-module-path, so I can remove that.
dl
On 11/7/18 8:12 PM, Mandy Chung wrote:
Hi Dean,
On 11/7/18 7:56 PM, dean.l...@oracle.com wrote:
https://bugs.openjdk.java.net/browse/JDK-8213348
https://bugs.openjdk.java.net/browse/JDK-8211781
http://cr.openjdk.java.net/~dlong/8213348/webrev/
108
Hi Dean,
On 11/7/18 7:56 PM, dean.l...@oracle.com wrote:
https://bugs.openjdk.java.net/browse/JDK-8213348
https://bugs.openjdk.java.net/browse/JDK-8211781
http://cr.openjdk.java.net/~dlong/8213348/webrev/
108 --module-path $(JDK_OUTPUTDIR)/modules \
109 --upgrade-module-path
+1
Mandy
On 10/29/18 11:57 AM, 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
+1
Mandy
On 10/2/18 11:17 AM, Mikael Vidstedt wrote:
Thanks for the reviews. I’ve reverted the changes related to Helper
and “just” adjusted the comments instead.
webrev:
http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/
On 10/2/18 12:21 AM, Mikael Vidstedt wrote:
Please review this change which removes support for, and references to, the
(Oracle internal) JPRT system.
bug: https://bugs.openjdk.java.net/browse/JDK-8211350
webrev:
http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/
Looks okay to me.
Mandy
P.S. I cc'ed compiler-dev since I think you meant to cc compiler-dev
instead of hotspot-compiler-dev.
On 9/13/18 3:20 PM, Magnus Ihse Bursie wrote:
The file make/langtools/tools/propertiesparser/PropertiesParser.java
On 9/13/18 1:46 AM, Magnus Ihse Bursie wrote:
On 2018-09-13 10:35, Magnus Ihse Bursie wrote:
The two build tools hasher and jarreorder is not used in the build
anymore and should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210704
WebRev:
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
Hi Vladimir,
This looks good. I verified with my patch that enforces non-duplicate
provides check and it builds successfully. Thanks for fixing it.
thanks
Mandy
On 8/13/18 5:06 PM, Vladimir Kozlov wrote:
https://bugs.openjdk.java.net/browse/JDK-8208463
Before we did not care how
GenModuleInfoSource build tool augments module-info.java to include
platform-specific qualified exports/opens and uses/provides services.
This fixes the build tool to catch syntax errors as closely as javac
does. The build tool remains to allow duplicated provides until
JDK-8208463 is resolved.
+1
Mandy
On 7/9/18 9:40 AM, Erik Joelsson wrote:
Hello,
The docs bundle is missing some of the legal notices from the
jdk.javadoc module. It should just include all the legal files from that
module. This patch removes the explicit list and uses wildcard to get
all the files instead.
Bug:
Hi Jiangli,
On 6/28/18 4:15 PM, Jiangli Zhou wrote:> webrev:
http://cr.openjdk.java.net/~jiangli/8202035/webrev.00/
RFE: https://bugs.openjdk.java.net/browse/JDK-8202035?filter=14921
Good work. I'm glad to see a pretty good startup improvement.
I reviewed java.base change that looks good.
1 - 100 of 410 matches
Mail list logo
