On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona wrote:
>> Classfile API is an internal library under package `jdk.internal.classfile`
>> in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves
>> it into `java.lang.classfile`.
>> It repackages all uses across JDK a
On Thu, 26 Oct 2023 17:53:12 GMT, Jonathan Gibbons wrote:
>> Please review an update to the way that `javadoc` handles the default legal
>> notices when generating docs.
>>
>> Previously, the default notices were taken from the module's `legal`
>> directory (`$JAVA_HOME/legal/jdk.javadoc`), bu
On Tue, 31 Oct 2023 20:58:04 GMT, Jonathan Gibbons wrote:
>> Please review an update to the way that `javadoc` handles the default legal
>> notices when generating docs.
>>
>> Previously, the default notices were taken from the module's `legal`
>> directory (`$JAVA_HOME/legal/jdk.javadoc`), bu
Tool modules can be created via `jmod --main-class` option such that
`ModuleMainClass` attribute will be added in `module-info.class` and the
module's main class can be launched via `java -m ` without
specifying the name of the main class.
In addition, for modules with `ModuleMainClass` attribu
On Thu, 2 Nov 2023 07:41:27 GMT, Alan Bateman wrote:
>> Tool modules can be created via `jmod --main-class` option such that
>> `ModuleMainClass` attribute will be added in `module-info.class` and the
>> module's main class can be launched via `java -m ` without
>> specifying the name of the m
jlink
> optimization. For example, `java -m jdk.jpackage` will be launched using
> the pre-resolved module graph.
>
> Verified manually by running `java -m $MODULE` on the modules with main class.
Mandy Chung has updated the pull request incrementally with one additional
commit since the
On Wed, 1 Nov 2023 19:58:07 GMT, Mandy Chung wrote:
> Tool modules can be created via `jmod --main-class` option such that
> `ModuleMainClass` attribute will be added in `module-info.class` and the
> module's main class can be launched via `java -m ` without
> specifying the
On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt wrote:
> Graphviz (aka. dotty/dot) is used when building "full" docs, and in
> particular for creating various module graph images (.svg). This change
> upgrades the Graphviz version used to 9.0.0 (latest).
>
> In particular, the change:
>
> *
On Tue, 5 Mar 2024 18:43:44 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply suggestions from code review
>>
>> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
>> Co
On Wed, 6 Mar 2024 15:02:07 GMT, Jan Lahoda wrote:
>>> Many of these modules do not need native access in the current
>>> implementation.
>>
>> In addition this will eventually need jlink support. I view the change to
>> ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules()
On Wed, 6 Mar 2024 19:00:19 GMT, Alan Bateman wrote:
>> Native access is needed for modules which calls restricted methods [1].
>> AFAICT, java.base, java.desktop and jdk.incubator.vector use
>> java.lang.foreign but I don't know if they call restricted methods or not.
>>
>> https://download
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Fri, 8 Mar 2024 17:19:41 GMT, Severin Gehwolf wrote:
>> I tried out the latest commit (a797ea69).
>>
>> The output "The default module path, '$java.home/jmods' not present. Use
>> --verbose to show the full list of plugin options applied" is bit confusing
>> as it looks like jlink failed bu
On Thu, 14 Mar 2024 14:24:57 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Fri, 15 Mar 2024 09:55:15 GMT, Severin Gehwolf wrote:
> > If `--enable-runtime-link-image` is enabled, the JDK image does not include
> > the packaged modules.
>
> That's not true. Right now `--enable-runtime-link-image` modifies how the
> `lib/modules` image looks like (adds a bunch of ext
On Fri, 15 Mar 2024 10:53:29 GMT, Severin Gehwolf wrote:
> Wasn't the intention to make "creating a linkable runtime image" a build only
> decision and make the relevant infrastructure classes build-only artefacts?
Build-only decision means that the linkable runtime image is only produced by
J
On Mon, 18 Mar 2024 13:01:10 GMT, Severin Gehwolf wrote:
> Yes we do. The main reason being that the `jdk` image has more to it than
> just the image. `src.zip`, CDS data, `demo` and so on. We don't want to
> duplicate that. To us, including the `jmods` folder is something that comes
> into pl
On Fri, 15 Mar 2024 15:19:17 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 19 Mar 2024 16:55:14 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Wed, 20 Mar 2024 10:24:23 GMT, Severin Gehwolf wrote:
> What we really want is some form of API to extend/patch an existing jimage
> preserving everything else. Perhaps I should look into that. Would that be
> worth doing?
I think avoiding the plugin pipeline in creating a linkable image is
On Tue, 19 Mar 2024 16:55:14 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtim
On Tue, 20 Dec 2022 21:00:35 GMT, Jonathan Gibbons wrote:
> Please review a trivial accessibility fix for the "draft" header in a couple
> of index files.
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.openjdk.org/jdk20/pull/66
`$JAVA_HOME/release` file currently includes `JAVA_VERSION` which is the
version
number plus the pre-release identifier for example "21-ea".The build number
and additional build information are useful in identifying the information
about a JDK image but not available. This proposes to add
age but not available. This proposes to add a new entry in the
> release file:
>
> JAVA_RUNTIME_VERSION="$(VSTR)"
>
> where `$(VSTR)` is the string represented by `Runtime::version()`.
Mandy Chung has updated the pull request incrementally with one ad
On Wed, 1 Mar 2023 21:20:18 GMT, Erik Joelsson wrote:
> I can't actually find that in the current release file, but that shouldn't
> prevent us from adding the full version string.
`JAVA_VERSION` is added by jlink and not in ReleaseFile.gmk.
-
PR: https://git.openjdk.org/jdk/pull/
On Wed, 1 Mar 2023 20:28:14 GMT, Mandy Chung wrote:
> `$JAVA_HOME/release` file currently includes `JAVA_VERSION` which is the
> version
> number plus the pre-release identifier for example "21-ea".The build
> number
> and additional build information are
On Wed, 1 Mar 2023 20:28:14 GMT, Mandy Chung wrote:
> `$JAVA_HOME/release` file currently includes `JAVA_VERSION` which is the
> version
> number plus the pre-release identifier for example "21-ea".The build
> number
> and additional build information are
On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote:
> Improvements to support OS specific customization for JDK internal use:
> - To select values and code; allowing elimination of unused code and values
> - Optionally evaluated by build processes, compilation, or archiving (i.e.
> CDS)
> - S
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
On Thu, 9 Mar 2023 16:03:37 GMT, Roger Riggs wrote:
On Thu, 9 Mar 2023 17:03:05 GMT, Mandy Chung wrote:
>> The symbol has to match the build usage of OPENJDK_TARGET_OS, not the name.
>
> The one in the template file is independent to the build variables.
> I would argue that we should keep the replacement string matching the make
On Fri, 10 Mar 2023 02:51:43 GMT, David Holmes wrote:
>> Using the naming from the build makes it clearer that there is a dependency
>> between the build names and those in the template.
>
> Don't we have a conditional compilation ability with these template files
> such that we can just genera
On Fri, 10 Mar 2023 14:01:04 GMT, Alan Bateman wrote:
>> Improvements to support OS specific customization for JDK internal use:
>> - To select values and code; allowing elimination of unused code and values
>> - Optionally evaluated by build processes, compilation, or archiving (i.e.
>> CDS)
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Thu, 31 Oct 2024 10:52:22 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Wed, 30 Oct 2024 21:12:42 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Thu, 31 Oct 2024 10:24:34 GMT, Severin Gehwolf wrote:
>> I've changed it to AssertionError, but can change it to UncheckedIOException
>> instead. Will take another pass on this issue tomorrow.
>
> Having looked at this again the patch now consistently uses `AssertionError`
> which should be
On Thu, 31 Oct 2024 22:25:04 GMT, Mandy Chung wrote:
> Many tests failed in compiling test library
> `test/jdk/tools/lib/tests/JImageValidator.java` as it depends on the
> ClassFile API and preview needs to be enabled.
It looks like my environment issue. They all pass f
On Fri, 1 Nov 2024 01:26:44 GMT, Mandy Chung wrote:
> I expect that the jmodless tests will first build an image (say `image1`)
> using jlink `--generate-linkable-runtime` option and then verify
> `image1/bin/jlink` that links from the run-time image. I don't see
> `--
On Fri, 8 Nov 2024 17:07:55 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Wed, 30 Oct 2024 21:17:26 GMT, Severin Gehwolf wrote:
> OK. It's currently part of the JEP, though which should explain what it does.
> Open for suggestions, though. I've taken inspiration from JVM features which
> use a similar `+/-` model.
I think it'd better to make this message human-un
On Thu, 31 Oct 2024 10:52:22 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Thu, 31 Oct 2024 10:52:22 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Thu, 31 Oct 2024 10:52:22 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Fri, 25 Oct 2024 16:29:52 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Wed, 6 Nov 2024 11:24:23 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
On Wed, 6 Nov 2024 11:24:23 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
49 matches
Mail list logo
