On Fri, 15 Aug 2025 06:36:46 GMT, Manuel Hässig wrote:
>> This PR adds a basic configuration for the [Oracle Java VSCode
>> extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java)
>> to the `vscode-project-*` targets.
>
> Manuel Hässig has updated the pull request inc
On Wed, 13 Aug 2025 14:24:28 GMT, Manuel Hässig wrote:
> > I would suggest to drop: `"jdk.advanced.disable.nbjavac": true,`
>
> Can you elaborate on the surprising results? When developing the JDK we will
> most probably use features not supported by the `nbjavac`.
In general, it can be anythi
On Wed, 13 Aug 2025 13:22:21 GMT, Manuel Hässig wrote:
> This PR adds a basic configuration for the [Oracle Java VSCode
> extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java)
> to the `vscode-project-*` targets.
Looks like a reasonable direction to me. I would sug
On Thu, 24 Jul 2025 07:21:12 GMT, Jan Lahoda wrote:
> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is
> the target Symbol type. Only targets right now are `TypeSymbol`s,
&g
the `build` label for now, until discussion on javac level is
> done, and will re-add it if we decide the goal to autogenerate the FlagsEnum
> makes sense.)
Jan Lahoda has updated the pull request incrementally with three additional
commits since the last revision:
- Merge remote-tr
On Mon, 28 Jul 2025 21:10:24 GMT, Chen Liang wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reverting runtime checks, as suggested.
>
> make/langtools/tools/flagsgenerator/FlagsGe
the `build` label for now, until discussion on javac level is
> done, and will re-add it if we decide the goal to autogenerate the FlagsEnum
> makes sense.)
Jan Lahoda has updated the pull request incrementally with one additional
commit since the last revision:
Up
On Fri, 25 Jul 2025 14:38:18 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Fixing toString value for flags that have ACC_ overloaded flags.
>> - Revi
On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda wrote:
> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and
> adds support for `@RequiresIdentity` to `--release`.
>
> Important parts of the patch:
> - `CreateSymbols` now keeps
> `RuntimeInvisibleTypeAn
gt; same for the `@RequiresIdentity+Annotation`
> - for type variables, the synthetic annotation is filtered out in the API
> method
Jan Lahoda has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 42 commits:
- Merge remote-tracki
gt; same for the `@RequiresIdentity+Annotation`
> - for type variables, the synthetic annotation is filtered out in the API
> method
Jan Lahoda has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 41 commits:
- Cleanup.
- Fixing buil
This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds
support for `@RequiresIdentity` to `--release`.
Important parts of the patch:
- `CreateSymbols` now keeps
`RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute`
annotations
- for `ct.sym
On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change in the JDK build tool class
> `CreateSymbols` which addresses an issue related to the reproducibility of
> the generated `ct.sym` file? This addresses
> https://bugs.openjdk.org/browse/JDK-8327466.
l.le`
> backend with a simple escape code interpreter, that only handles a handful of
> keys/codes (left/right arrow, home, end, delete, backspace, enter), and
> ignores the rest. The goal is to have something simple with less surprising
> behavior.
Jan Lahoda has updated the pull
On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang wrote:
>> With all dependencies of com.sun.tools.classfile in the JDK converted to the
>> ClassFile API, we can remove this legacy library for release 25 like how we
>> removed ASM.
>>
>> Testing: built locally, running tier 1-3 tests
>>
>> Don't kn
On Tue, 8 Apr 2025 20:33:33 GMT, Chen Liang wrote:
>> Migrates the CreateSymbols tool to use the ClassFile API, away from
>> com.sun.tools.classfile.
>>
>> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but
>> this is open to reviews.
>>
>> Together with #24206, the old
On Mon, 31 Mar 2025 17:22:45 GMT, David M. Lloyd wrote:
>> The `java.io.Console` has several backends: a simple on in `java.base`, a
>> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
>> and one for JShell.
>>
>> The backend based on JLine is proving to be a somewha
l.le`
> backend with a simple escape code interpreter, that only handles a handful of
> keys/codes (left/right arrow, home, end, delete, backspace, enter), and
> ignores the rest. The goal is to have something simple with less surprising
> behavior.
Jan Lahoda has updated the pull req
On Thu, 3 Apr 2025 17:59:52 GMT, Jan Lahoda wrote:
>> The `java.io.Console` has several backends: a simple on in `java.base`, a
>> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
>> and one for JShell.
>>
>> The backend based on JLi
l.le`
> backend with a simple escape code interpreter, that only handles a handful of
> keys/codes (left/right arrow, home, end, delete, backspace, enter), and
> ignores the rest. The goal is to have something simple with less surprising
> behavior.
Jan Lahoda has updated the pull r
On Mon, 31 Mar 2025 12:43:26 GMT, Magnus Ihse Bursie wrote:
>> The `java.io.Console` has several backends: a simple on in `java.base`, a
>> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
>> and one for JShell.
>>
>> The backend based on JLine is proving to be a som
On Thu, 27 Mar 2025 20:48:22 GMT, Naoto Sato wrote:
>> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java
>> line 198:
>>
>>> 196:
>>> 197: if (it.hasNext()) {
>>> 198: out.append("\n\r");
>>
>> I understand this is a simple console, bu
On Thu, 27 Mar 2025 18:28:17 GMT, Naoto Sato wrote:
>> The `java.io.Console` has several backends: a simple on in `java.base`, a
>> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
>> and one for JShell.
>>
>> The backend based on JLine is proving to be a somewhat pr
On Wed, 26 Mar 2025 08:59:39 GMT, Alan Bateman wrote:
>> The `java.io.Console` has several backends: a simple on in `java.base`, a
>> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
>> and one for JShell.
>>
>> The backend based on JLine is proving to be a somewhat
On Wed, 26 Mar 2025 08:55:09 GMT, Alan Bateman wrote:
> Can you coordinate with Naoto on this? There is a CSR in progress to switch
> Console back to using the java.base implementation by default.
Right - but that still keeps the existing JLine-based provider, and so the
problems it has still
The `java.io.Console` has several backends: a simple on in `java.base`, a more
convenient one in `jdk.internal.le` (with line-reading based on JLine) and one
for JShell.
The backend based on JLine is proving to be a somewhat problematic - JLine is
very powerful, possibly too powerful and comple
On Fri, 13 Dec 2024 05:46:28 GMT, Jan Lahoda wrote:
> The microbenchmarks build generates a considerable amount of (generated)
> sources using an annotation processor. This, by itself, is not a problem.
> But, it generates them into the class output, and after the microbenchmarks
&g
The microbenchmarks build generates a considerable amount of (generated)
sources using an annotation processor. This, by itself, is not a problem. But,
it generates them into the class output, and after the microbenchmarks build
has been updated to be (somewhat) incremental, the class output has
On Thu, 5 Dec 2024 08:55:19 GMT, Maurizio Cimadamore
wrote:
>> This PR tightens up the logic by which javac reports lint warnings.
>> Currently, lint warnings are typically emitted using the following idiom:
>>
>>
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>> log.warning(LintCategory.D
On Thu, 30 May 2024 18:39:19 GMT, Chen Liang wrote:
>> Get JDK 24 underway.
>
> src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt line 1:
>
>> 1: #
>
> Just curious, does CreateSymbols not track module migrations, now that
> jdk.incubator.foreign is completely merged into jav
On Wed, 9 Oct 2024 19:22:01 GMT, Jan Lahoda wrote:
> This is a current patch for module imports declarations, second preview. At
> least the JEP number and preview revision will need to be updated in
> `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is
&
odule imports can be shadowed using on-demand
> imports. So, for example, having:
>
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
>
> but:
>
> import module java.base;
> import module java.desktop;
> import java.util.*;
&
This is a current patch for module imports declarations, second preview. At
least the JEP number and preview revision will need to be updated in
`jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is
ready to receive feedback.
The main changes are:
- `requires transitive j
On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda wrote:
> Currently incremental builds for the microbenchmarks may take notable amount
> of time, like:
>
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java;
> time make test TEST=jaxp:tier1
> Buildin
0 0 0
> ==
> TEST SUCCESS
>
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>
> real0m7,505s
> user0m14,128s
> sys 0m3,158s
Jan Lahoda has updated the pull request
0 0 0
> ==
> TEST SUCCESS
>
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>
> real0m7,505s
> user0m14,128s
> sys 0m3,158s
Jan Lahoda has updated the pull request increm
On Tue, 20 Aug 2024 09:02:18 GMT, Daniel Jeliński wrote:
>> Currently incremental builds for the microbenchmarks may take notable amount
>> of time, like:
>>
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java;
>> time make test TEST=jaxp:tier1
>> Building target 'test'
Currently incremental builds for the microbenchmarks may take notable amount of
time, like:
$ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time
make test TEST=jaxp:tier1
Building target 'test' in configuration 'linux-x86_64-server-release'
Compiling up to 656 files for
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Fri, 21 Jun 2024 18:37:01 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java line 417:
>>
>>> 415: return false;
>>> 416: }
>>> 417: JavaFileManager fm =
>>> pp.getPlatformTrusted(release).getFileManager();
>>
>>
On Thu, 20 Jun 2024 16:58:55 GMT, Alan Bateman wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java
>> line 93:
>>
>>> 91: }
>>> 92:
>>> 93: public PlatformDescription getPlatformTrusted(String platformName) {
>>
>> I noticed that `getPlatform
On Thu, 20 Jun 2024 17:44:54 GMT, Alan Bateman wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
>> line 113:
>>
>>> 111: // Class-Path attribute specifies that jars that
>>> 112: // are not found are simply ignored. Do
On Thu, 20 Jun 2024 19:45:29 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Thu, 30 May 2024 18:39:19 GMT, Chen Liang wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update symbol files for JDK 23 build 25.
>
> src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt line 1:
>
On Wed, 6 Mar 2024 21:20:50 GMT, Jan Lahoda wrote:
> This is a patch that:
> a) upgrades the JLine inside the JDK to 3.25.1
> b) since the new version of JLine has a FFM backend, our custom native
> backends are removed, and replaced with the FFM backend
>
> Some changes had
t; rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff
Jan Lahoda has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 32 commits:
- Merge branch 'master' into jline
On Fri, 3 May 2024 07:21:27 GMT, Jan Lahoda wrote:
>> This is a patch that:
>> a) upgrades the JLine inside the JDK to 3.25.1
>> b) since the new version of JLine has a FFM backend, our custom native
>> backends are removed, and replaced with the FFM backend
>>
t; rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff
Jan Lahoda has updated the pull request incrementally with one additional
commit since the last revision:
Removing trailing whitespace.
-
Changes:
- all: https://git
t; rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff
Jan Lahoda has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 30 commits:
- Fixing test.
- Cleanup.
- Upgrade to 3.26.
On Wed, 1 May 2024 11:18:36 GMT, Jan Lahoda wrote:
> When writing the `ModuleMainClass` attribute, `CreateSymbols` uses an UTF8
> entry (incorrect), instead of a Class_info (correct). This patch fixes that.
This pull request has now been integrated.
Changeset: 8771015d
Author: Jan
On Thu, 2 May 2024 07:03:20 GMT, Adam Sotona wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing unnecessary directory cleanup.
>
> test/langtools/tools/javac/platform/createsymb
> When writing the `ModuleMainClass` attribute, `CreateSymbols` uses an UTF8
> entry (incorrect), instead of a Class_info (correct). This patch fixes that.
Jan Lahoda has updated the pull request incrementally with one additional
commit since the last revision:
Removing unnecessary dir
When writing the `ModuleMainClass` attribute, `CreateSymbols` uses an UTF8
entry (incorrect), instead of a Class_info (correct). This patch fixes that.
-
Commit messages:
- 8331027: JDK's ct.sym file packs corrupted module-info classes
Changes: https://git.openjdk.org/jdk/pull/1903
t; rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff
Jan Lahoda has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 26 commits:
- Merge branch 'master' into jline
t; rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff
Jan Lahoda has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 25 commits:
- Merge branch 'master' into jline-
On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to r
t; rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff
Jan Lahoda has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 24 commits:
- Merge branch 'native-access-modules1&#x
On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda wrote:
> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
> automatically granted the native access. I am working on an upgrade of JLine
> inside the `jdk.internal.le` module, and I would like to replace th
> This patch introduces an explicit list of modules that will automatically be
> granted the native access. Note this patch is not yet intended to change the
> end behavior - the list of modules granted native access is supposed to be
> the same as modules in the boot and platform Cl
On Thu, 7 Mar 2024 09:30:41 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/native-access-modules1' into
>> native
On Thu, 7 Mar 2024 12:11:19 GMT, ExE Boss wrote:
>> This is a patch that:
>> a) upgrades the JLine inside the JDK to 3.25.1
>> b) since the new version of JLine has a FFM backend, our custom native
>> backends are removed, and replaced with the FFM backend
>>
>> Some changes had to be made to t
This is a patch that:
a) upgrades the JLine inside the JDK to 3.25.1
b) since the new version of JLine has a FFM backend, our custom native backends
are removed, and replaced with the FFM backend
Some changes had to be made to the original JLine in order to fit into the JDK.
Most of them were al
On Tue, 5 Mar 2024 18:54:55 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 <38
> This patch introduces an explicit list of modules that will automatically be
> granted the native access. Note this patch is not yet intended to change the
> end behavior - the list of modules granted native access is supposed to be
> the same as modules in the boot and platform Cl
On Wed, 6 Mar 2024 09:19:44 GMT, Alan Bateman wrote:
>> Many of these modules do not need native access in the current
>> implementation. Should this list be trimmed to list the ones that need
>> native access in the current implementation?
>
>> Many of these modules do not need native access
On Tue, 5 Mar 2024 13:58:50 GMT, Jaikiran Pai 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 <38
On Tue, 5 Mar 2024 14:14:15 GMT, Jaikiran Pai wrote:
>>> to make the intention clear as well as reduce the chances of missing some
>>> boot or platform module in this NATIVE_ACCESS_MODULES?
>>
>> The list to be be granted native access is a subset, it shouldn't be granted
>> all modules mapped
On Tue, 5 Mar 2024 12:41:18 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to r
> This patch introduces an explicit list of modules that will automatically be
> granted the native access. Note this patch is not yet intended to change the
> end behavior - the list of modules granted native access is supposed to be
> the same as modules in the boot and platform Cl
Currently, JDK modules load by the bootstrap and platform ClassLoaders are
automatically granted the native access. I am working on an upgrade of JLine
inside the `jdk.internal.le` module, and I would like to replace the current
native bindings with FFM-based bindings (which are now somewhat pro
On Tue, 6 Feb 2024 01:36:58 GMT, Jonathan Gibbons wrote:
>> Please review a patch to add support for Markdown syntax in documentation
>> comments, as described in the associated JEP.
>>
>> Notable features:
>>
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jd
On Thu, 18 Jan 2024 07:34:31 GMT, Magnus Ihse Bursie wrote:
>> In [JDK-8318913](https://bugs.openjdk.org/browse/JDK-8318913), the
>> symbolgenerator started to look at current sources as well. This means that
>> the gensrc stage needs to be completed before this is run. A dependency was
>> add
On Wed, 17 Jan 2024 19:14:01 GMT, Erik Joelsson wrote:
>> Thanks, in that case I think both of these should be depending on
>> `$(GENSRC_TARGETS)` instead.
>
> I take that back, jdk.javadoc-gendata should depend on `$(GENSRC_TARGETS)`,
> jdk.compiler-gendata still needs `$(JAVA_TARGETS)` as the
On Tue, 16 Jan 2024 18:53:23 GMT, Erik Joelsson wrote:
>> I think it might operate on both, but I'm not sure. But my thinking was that
>> JAVA_TARGETS depended on GENSRC_TARGETS, which in turn would make sure that
>> all source code was properly generated.
>>
>> Am I missing something?
>
> Unn
On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda wrote:
> As part of:
> https://github.com/openjdk/jdk/pull/16505
>
> there are new symbol files for JDK 22, and @jddarcy noted the content looks
> weird.
>
> I was investigating, and found a few problems, some introduced by
ted subclasses was happening too late, not on the `header` line. Note
> that when fixing this, we now must store some of the non-exported elements,
> which are reachable through the permitted subclasses, so that casting works
> as expected. Also, since the historical record is incorrect
On Mon, 4 Dec 2023 11:39:04 GMT, Magnus Ihse Bursie wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from
>>
ted subclasses was happening too late, not on the `header` line. Note
> that when fixing this, we now must store some of the non-exported elements,
> which are reachable through the permitted subclasses, so that casting works
> as expected. Also, since the historical record is incorrect he
As part of:
https://github.com/openjdk/jdk/pull/16505
there are new symbol files for JDK 22, and @jddarcy noted the content looks
weird.
I was investigating, and found a few problems, some introduced by
https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b,
some pre-ex
On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote:
> Consider a simple module, like:
>
> module test {}
>
>
> And compile it with JDK 22 and JDK 21 using:
> javac --release 21
>
> The results of the compilations will differ: when compiling with JDK 21, the
>
On Fri, 10 Nov 2023 00:42:43 GMT, Magnus Ihse Bursie wrote:
> The build changes almost look good. Just remove the extra added lines at the
> end.
>
> I think this point too still remains:
>
> > 1. TransitiveDependencies seems to be unused now. I assume this is
> > intended. But maybe the java
ges, compiling with `--release N` should record the same
> dependency versions in `module-info` on JDK N and JDK N + 1.
Jan Lahoda has updated the pull request incrementally with one additional
commit since the last revision:
Reflecting review comment - removing unnecessary lines.
ges, compiling with `--release N` should record the same
> dependency versions in `module-info` on JDK N and JDK N + 1.
Jan Lahoda has updated the pull request incrementally with one additional
commit since the last revision:
Removing TransitiveDependencies, as suggested.
-
ges, compiling with `--release N` should record the same
> dependency versions in `module-info` on JDK N and JDK N + 1.
Jan Lahoda has updated the pull request incrementally with four additional
commits since the last revision:
- Fixing tests.
- Merge remote-tracking bran
On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote:
> Consider a simple module, like:
>
> module test {}
>
>
> And compile it with JDK 22 and JDK 21 using:
> javac --release 21
>
> The results of the compilations will differ: when compiling with JDK 21, the
>
On Tue, 7 Nov 2023 15:36:46 GMT, Mark Reinhold wrote:
> Will this patch preserve the pre-release identifier (e.g., `-ea` or
> `-internal`), which was the behavior prior to JDK 22? If not, then it’s an
> incompatible change.
Hm, no, the current version will always use the specification version.
Consider a simple module, like:
module test {}
And compile it with JDK 22 and JDK 21 using:
javac --release 21
The results of the compilations will differ: when compiling with JDK 21, the
mandated java.base dependency will get a version, possibly like "21-internal".
When compiling with JDK 22
On Tue, 30 May 2023 22:16:08 GMT, Joe Darcy wrote:
>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The pull request now contains 24 commits:
>
> - Merge branch 'master' into JDK-8306584
> - Merge branch 'master'
On Thu, 27 Apr 2023 11:21:04 GMT, Jan Lahoda wrote:
> To support JShell and other usecases, the JDK uses JLine, which provides
> line-editing functionality inside a terminal.
>
> JLine has several ways to work with the terminal, based on various additional
> libraries and tool
On Thu, 11 May 2023 15:15:02 GMT, Vicente Romero wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflecting review feedback.
>
> src/jdk.internal.le/linux/classes/jdk/internal/org
for Linux and Mac OS/X, there are platform-specific implementations based
> on the corresponding code from JLine, with the hand-written JNI-based
> implementation of the JNA-based existing interfaces. They also have an
> implementation of `JDKNativePty`, which just delegates to the giv
On Tue, 9 May 2023 20:49:16 GMT, Brian Burkhalter wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adjusting build script as suggested on the review.
>
> src/jdk.internal.le/linux/nati
e reasons for this organization are: limiting duplication, mostly adhering
> to the JDK's platform specific build (which is different from the normal
> JLine's platform-neutral build) and limiting the difference between standard
> JLine and JLine inside JDK, to he
To support JShell and other usecases, the JDK uses JLine, which provides
line-editing functionality inside a terminal.
JLine has several ways to work with the terminal, based on various additional
libraries and tools. Most of them are not directly usable inside the JDK, so
currently, on non-Win
On Fri, 28 Apr 2023 13:01:33 GMT, Jan Lahoda wrote:
>> I see that logic in JavaCompiler - I wonder if that's just the way it is, or
>> if there's a deeper reason as to why the sourcefile is set on the toplevel
>> unit *after* parsing (I don't think I can
On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey wrote:
>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge
> or a rebase. The pull request now contains 14 commits:
>
> - Merge branch 'maste
On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey wrote:
>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge
> or a rebase. The pull request now contains 14 commits:
>
> - Merge branch 'maste
On Thu, 27 Apr 2023 20:34:44 GMT, Maurizio Cimadamore
wrote:
>> The source file name is not available until after parsing.
>
> I see that logic in JavaCompiler - I wonder if that's just the way it is, or
> if there's a deeper reason as to why the sourcefile is set on the toplevel
> unit *after
On Mon, 20 Mar 2023 14:50:01 GMT, Jan Lahoda wrote:
> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for
> the ant-based langtools-only build as well.
This pull request has now been integrated.
Changeset: c4df9b5f
Author: Jan Lahoda
URL:
> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for
> the ant-based langtools-only build as well.
Jan Lahoda 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
1 - 100 of 124 matches
Mail list logo
