On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu wrote:
> Please review this PR which contains the open L10n drop changes for RDP1.
>
> I recommend viewing the improved diffs which are built out by Jon's tool
> here: https://cr.openjdk.org/~jlu/output/. As always, I can not confirm the
> correctnes
On Tue, 10 Dec 2024 00:05:45 GMT, Henry Jen wrote:
>> Oh you're right. That's odd though. But the translations aren't wrong then.
>
> `每个 是\n限定的程序包名称.`
> We use here, but the args format is using Chinese translation,`=
> [-]<程序包>(,[-]<程序包>)*`
>
> Should that be consistent?
Regarding `''` - p
On Tue, 8 Oct 2024 15:38:01 GMT, Magnus Ihse Bursie wrote:
> Yay! This looks so much better than the default blob. I think you are on the
> right track, but the actual message can do with some fine tuning. For
> instance, `` seems a bit ... untypically non-formal. What
> about just ``?
I am n
Currently, running `java` without any parameters will lead to an output that is
a full `--help`, which is over 100 lines (on my computer at least), and it
feels overwhelming. And many people might actually want to run JShell/REPL, not
the `java` launcher, but it is difficult find out about JShel
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
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
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
> 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 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
> 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 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
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 Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote:
>> Enhance the Java programming language with string templates, which are
>> similar to string literals but contain embedded expressions. A string
>> template is interpreted at run time by replacing each expression with the
>> result of evalu
17 matches
Mail list logo
