On 06/05/2022 12:26, Alex Orlov wrote:
Hello.
Please, consider the following situation. We have /home/user/temp/foo.jar that is used in dynamically created jpms
layer bar.
Could anyone say if it is safe to do the following: destroy layer bar, update /home/user/temp/foo.jar (modify some cod
- Original Message -
> From: "Alan Bateman"
> To: "Julian Waters" , "jigsaw-dev"
>
> Sent: Sunday, April 3, 2022 4:13:53 PM
> Subject: Re: Current Project Status
> On 03/04/2022 09:26, Julian Waters wrote:
>> Out of curiosity
On 03/04/2022 09:26, Julian Waters wrote:
Out of curiosity, is the Jigsaw project still active in the background
today, seeing that this mailing list is still up?
The features developed by this project were integrated in JDK 9. The
mailing list lives on, it is used periodically for questions, b
Merging jmod on different platforms sounds like an attractive idea.
However, I don't care about it during this time, because I need some
architectures whose ports are not in OpenJDK main-line as jlink targets, so
I can't get JDK from only one provider.
Mike Hearn 于2022年2月9日周三 05:01写道：
> Hi Glavo
> I noticed that a copy of everything in jmod already exists in the JDK
> folder.
> In fact, jmod of JDK core module only needs to store a file list (List of
> paths of all native libraries, executable files and legal files),
> original content backup of some modifiable content (e.g. co
Hi Glavo,
My company is currently working on something you can think of
as jpackage++. Amongst other tasks it invokes jlink to create a JDK
distribution for each targeted operating system. It has JPMS support so
I'll post about it on this list when a release is available for public
download.
We h
all native libraries, executable files and legal files),
original content backup of some modifiable content (e.g. conf files), and
the name of module.
We can re extract the complete jmod file from JDK through these meta
information, the size of these meta information is completely negligible.
I&#
> On 3 Dec 2021, at 15:33, Alan Bateman wrote:
>
> On 03/12/2021 13:39, Michał Kłeczek wrote:
>> Am I missing something?
>>
> I think you understand it correctly. The notion of multi-parent configuration
> and layers is something that was added for those that were focused on interop
> with o
> On 3 Dec 2021, at 14:39, Michał Kłeczek wrote:
>
>
> 2. Is there a way to handle it today?
> (Ab)using transitive dependencies might work - I could introduce artificial
> module M ---(transitive)-->Y2 and make Z require M (so that resolution would
> replace Y1 found by DFS with Y2 required
On 03/12/2021 13:39, Michał Kłeczek wrote:
Am I missing something?
I think you understand it correctly. The notion of multi-parent
configuration and layers is something that was added for those that were
focused on interop with other class loader based systems. It was tracked
as issue #NonHie
> On 29 Nov 2021, at 10:29, Alan Bateman wrote:
>>
>> It looks like ML.Controller.addExport(source, pn, target) does not update
>> the target module ClassLoader view of exported packages in the default
>> ClassLoader implementation (jdk.internal.loader.Loader).
>> What is the reasoning behind
On 28/11/2021 22:29, Michał Kłeczek wrote:
:
It looks like ML.Controller.addExport(source, pn, target) does not update the
target module ClassLoader view of exported packages in the default ClassLoader
implementation (jdk.internal.loader.Loader).
What is the reasoning behind such implementation
> On 24 Nov 2021, at 21:01, Alan Bateman wrote:
>
> On 24/11/2021 18:14, Michał Kłeczek wrote:
>>
>>
>> For sure it’s fun :)
>>
>> Regardless of “smart proxies” the lifetime of ML.Controller should be - if
>> not fixed - at least be documented IMHO. Right now it’s a minefield.
>
> It's al
On 24/11/2021 18:14, Michał Kłeczek wrote:
For sure it’s fun :)
Regardless of “smart proxies” the lifetime of ML.Controller should be
- if not fixed - at least be documented IMHO. Right now it’s a minefield.
It's also somewhat unusual so I think we'll need to think if this is the
right thi
> On 24 Nov 2021, at 13:33, Alan Bateman wrote:
>>
>> 1. Controller is created upon ML construction and returned from static
>> ML.defineModules methods.
>> 2. Created two controller liveness tests (they rely on System.gc() though -
>> not sure if there are some tricks to test it reliably).
>
On 24/11/2021 12:19, Michał Kłeczek wrote:
Hi Alan,
(Disregard previous message - fat fingers)
Attached is a first draft of the patch:
1. Controller is created upon ML construction and returned from static
ML.defineModules methods.
2. Created two controller liveness tests (they rely on System
Hi Alan,
(Disregard previous message - fat fingers)
Attached is a first draft of the patch:
1. Controller is created upon ML construction and returned from static
ML.defineModules methods.
2. Created two controller liveness tests (they rely on System.gc() though - not
sure if there are some t
Hi Alan,
Attached is a first draft of the patch.
Controller is created upon ML construction and returned from static
ML.defineModules methods.
> On 22 Nov 2021, at 21:37, Alan Bateman wrote:
>>
> Assuming it's not exposed, and that there is no reference to the
> ML.Controller for the boot lay
Hi Alan,
> On 22 Nov 2021, at 21:37, Alan Bateman wrote:
>
> On 22/11/2021 07:23, Michał Kłeczek wrote:
>>
>> Would it be too much to ask for accepting a patch adding a reference to
>> ML.Controller to ModuleLayer?
>> It wouldn’t require changes to the spec I think as the lifetime of
>> ML.Co
On 22/11/2021 07:23, Michał Kłeczek wrote:
Would it be too much to ask for accepting a patch adding a reference
to ML.Controller to ModuleLayer?
It wouldn’t require changes to the spec I think as the lifetime of
ML.Controller is unspecified.
Assuming it's not exposed, and that there is no re
From OpenJDK discuss:
> On 21 Nov 2021, at 21:55, Alan Bateman wrote:
>
> On 21/11/2021 13:27, Michał Kłeczek wrote:
>> Hello All,
>>
>> I am looking for a way to associate ModuleLayer.Controller with a Module (or
>> ModuleLayer) in such a way that it won’t disable garbage collection of
>> Mo
This issue has now been fixed through
https://bugs.openjdk.java.net/browse/JDK-8275509
-Jaikiran
Yes, that kind of thing, Mike, thanks for the good example! I'm doing
something very similar with JavaCPP, but at the library level rather
than at the application level.
Ok, Dalibor, I'll try to stay technical, so here's a couple of technical
question I have for at least you and Ioi. There's a
On 10/14/21 9:49 AM, Glavo wrote:
There's no requirements that a module must be stored in a JAR file. In
fact, your program will not work if it was packaged into an image
produced by jlink. That's why we have the ModuleReader::list() API.
I understand this, but it is not uncommon f
>
> There's no requirements that a module must be stored in a JAR file. In
> fact, your program will not work if it was packaged into an image
> produced by jlink. That's why we have the ModuleReader::list() API.
I understand this, but it is not uncommon for code that has made such
assumptions. M
Removing the jdk-...@openjdk.java.net mailing list.
This topic should be discussed on jigsaw-dev@openjdk.java.net only.
Thanks
- Ioi
On 10/14/21 9:06 AM, Ioi Lam wrote:
On 10/14/21 8:29 AM, Glavo wrote:
In fact, I don't understand why people started packing JAR files
inside
JAR
On 10/14/21 8:29 AM, Glavo wrote:
In fact, I don't understand why people started packing JAR files
inside
JAR files. Maybe there were some esoteric reasons (related to
Class-Path: attribute in manifest files???).
Sometimes it's necessary to keep jars intact and distribute them
>
> In fact, I don't understand why people started packing JAR files inside
> JAR files. Maybe there were some esoteric reasons (related to
> Class-Path: attribute in manifest files???).
>
Sometimes it's necessary to keep jars intact and distribute them as
they are. In fact, a program I just deve
ClassLoader level separation as individual jars is required for versioning. I
have sometimes needed to include the old and new version of a class to
deserialize with the old class to get data for one app that then passes a
textual version (json or XML ETC.) to somewhere else that serialized wit
On 14.10.2021 08:39, Samuel Audet wrote:> Please try to make your >
bosses understand that it would be wiser to leave the money where it's >
needed. :)
Let's keep the posts on this mailing list focused on technical
discussion about Project Jigsaw, please, in line with its purpose. [0]
Thanks,
It's worth noting that before he worked on Loom, Ron Pressler wrote
Capsule, which is a kind of uber-fat-jar system that embeds JARs within
JARs:
https://github.com/puniverse/capsule
The website is offline now but it had a lot of features, including the
ability to extract shared libraries from th
Hi, Ioi,
Thanks for the update! This is starting to look interesting indeed.
Now, the main problem I personally have with the JDK is that it provides
no way to manage native libraries packaged in JAR files. It provides
some limited support for modules packaged in JMOD files, but nothing for
m
Hi Glavo,
I have simplified my prototype so now there's no need to implement new
URL handlers.
https://github.com/iklam/tools/tree/main/jigsaw/uberjar
Please see the "Super-JAR Demo" section.
The new demo uses standard features supported by the JDK's built-in
"jar:" URL handler. The onl
I mistakenly believe that the implementation of the filesystem corresponds
exactly to the URL. The problem I really want to express is that JDK
does not support URLs of nested jar file systems. It seems that this
problem still exists in JDK 17. To make matters worse, we can use toUri()
to convert t
On 11/10/2021 15:09, Glavo wrote:
I think this is a great prototype. Based on it, I think such requirements
can also be realized by enhancing jar in these aspects:
1. Nested jar file system (The ujar file system seems unnecessary.
I never understand why jar file systems cannot be nested
t; Mike Hearn 于2021年10月7日周四 下午7:31写道：
> >>>
> >>>> Thanks for your insightful reply, Glavo. Here are some thoughts. I
> >>>> should
> >>>> note that I don't work for Oracle or on OpenJDK, in case that wasn't
> >>>> al
On 06/10/2021 18:24, Glavo wrote:
For a long time, unpacking and repackaging all dependencies into a file
called fatJar was the first choice for single file distribution of Java
programs. However, the compatibility of this solution with JPMS is very
poor - it breaks up all the modules and works w
work for Oracle or on OpenJDK, in case that
wasn't
>>>> already clear.
>>>>
>>>> *Forum.* Although it's logical that you ended up on this list,
>>>> realistically the JPMS is "done" and not being worked on
since Java
>>>&
On 09/10/2021 05:34, Samuel Audet wrote:
One problem is that frameworks like Spring Boot need to scan the classes
that are available in a module, to get a list of the names of all the
classes, among other things. The JDK provides no standard way to do that.
For example, how would you implement a
> >>> Our average income level also lags behind that of developed countries,
>> >>> so we will pay more attention to the cost of bandwidth.
>> >>>
>> >>> Mike Hearn 于2021年10月7日周四 下午7:31写道：
>> >>>
>> >>>> Than
t; >>>> Thanks for your insightful reply, Glavo. Here are some thoughts. I
> >>>> should
> >>>> note that I don't work for Oracle or on OpenJDK, in case that wasn't
> >>>> already clear.
> >>>>
> >>>> *Forum.* A
s have to come from the user community so
it may
make more sense to have this discussion on Reddit, or some other
Java forum.
*Alternative approach. *Given this constraint, it can make sense to
think
wider or bigger than just updating previous approaches. Would your
needs be
met or even
sense to have this discussion on Reddit, or some other Java forum.
*Alternative approach. *Given this constraint, it can make sense to think
wider or bigger than just updating previous approaches. Would your needs be
met or even met better by a re-imagining of Web Start, but one suitable for
lutions or improvements have to come from the user community so it may
>> make more sense to have this discussion on Reddit, or some other Java forum.
>>
>> *Alternative approach. *Given this constraint, it can make sense to think
>> wider or bigger than just updating previous approache
the user community so it may
> make more sense to have this discussion on Reddit, or some other Java forum.
>
> *Alternative approach. *Given this constraint, it can make sense to think
> wider or bigger than just updating previous approaches. Would your needs be
> met or even met
Desktop apps have long been passed around as single jars. I have done all
kinds of things to pack fatjars full of things that needed recursive unpacking.
Including JNI shared libraries that I could then load to provide missing OS
support functions not in Java.
Sent from my iPhone
> On Oct 7,
ches. Would your needs be
met or even met better by a re-imagining of Web Start, but one suitable for
servers and the CLI? For example:
$ alias glavos="jrun glavos-cool-app.com"
$ glavos --flag --another-flag
Here an imaginary "jrun" command (re)downloads an app and store
Of course, this is feasible and will not introduce many new problems
like jlink. It's just not that convenient. It just introduces some
additional deployment steps, which is not so convenient. I believe that
it is very attractive to only distribute and deploy a single file,
which is proved by the p
I am a tad bit confused. How come packaging everything into a regular zip
file and extracting it during deployment is not feasable solution? If
anything, you retain ability to do partial updates to your deployments.
Such approach also removes the need for special classloader that is capable
of load
Emmm... My words caused some misunderstanding. I should say that jpackage
is good, but without it, we can easily achieve the same function in
other ways, so it doesn't cause real trouble. What really causes trouble
and needs to be solved by fatjar is a different problem. It is difficult
for me to a
On 10/6/21 12:45 PM, Glavo wrote:
I know this doesn't remotely satisfy all your requirements, but are you
aware you can jpackage an app *without* bundling a JRE?
Ah, this is what I missed, but it won't solve any of my problems, otherwise
I have implemented a similar function by myself.
Doe
Hi,
There are many reasons why modules have not become popular, but this is
a new interesting perspective. Thanks for bringing this up! I also
believe modules need to support uber JARs to become relevant...
Samuel
On 10/7/21 2:24 AM, Glavo wrote:
For a long time, unpacking and repackaging a
>
> I know this doesn't remotely satisfy all your requirements, but are you
> aware you can jpackage an app *without* bundling a JRE?
>
Ah, this is what I missed, but it won't solve any of my problems, otherwise
I have implemented a similar function by myself.
Sebastian Stenzel 于2021年10月7日周四 上午2
>
> 1. Why do you need it to be a single file?
Because it's convenient. In any case, a single file is more convenient
than multiple files. I believe this is the reason why fatjar is popular.
A single file is more robust (easier to ensure integrity), easier to
distribute, easier to deploy, easier
Interesting topic and I'm keen to know what is the answer to the general
problem of modular fat or shaded jars.
I know this doesn't remotely satisfy all your requirements, but are you aware
you can jpackage an app *without* bundling a JRE?
> Am 06.10.2021 um 19:25 schrieb Glavo :
>
> For a lo
-jdk-dev
I'm currently working on a new packaging product for JVM apps so this sort
of request is of interest. However it produces platform native packages,
not uber-jars. May I ask:
1. Why do you need it to be a single file?
2. Why an installable jlinked image doesn't meet your workflow
requirem
Hi Mike,
It's possible to do some pretty cool stuff with Maven, as Hervé points
out, and also be sure to check out the plugins I created for Gradle:
https://github.com/bytedeco/gradle-javacpp
But Gradle is the same as OpenJDK: They do not care about native
libraries. It's great that Gradle al
Le 28/09/2021 à 08:52, Johan Vos a écrit :
Having said that, I really want to focus on the original technical
questions. I appreciate the concerns about the general position of Java,
but in an OpenJDK context, I believe it is best to stick to the
technical "details" and just make it happen.
To get back to technical aspects, the sub-question of native code loading
from JMODs/JARs has come up before. In 2018 I did some experiments with
loading native code directly from memory (i.e. a JAR) on different
operating systems, and wrote up the results here:
https://mail.openjdk.java.net/piper
Hi Gregg,
I am afraid that train is long gone. Once OpenJDK decided the preferred
distribution mechanism for Java applications is to embed the runtime, the
notion of Java Platform that would allow installation/execution of platform
neutral software packages is gone.
Bytecode is no longer fashio
Hi Sam,
1. This is an OpenJDK mailinglist. I typically don't look at the company
names when someone writes to the list. If they have a role in OpenJDK, I'm
already happy. There are Google engineers with OpenJDK roles, so I'd be
happy if they participate. But we talk about technical things here, no
In the end, much of what happened after JDK8 has served to do more at
separating and fragmenting the Java platform than even Android does with a
different runtime for the same textual programming constructs. I’d be
extremely interested in seeing the community focus on getting back to the focus
Android actually includes OpenJDK these days, still only OpenJDK 8 at
the moment, but it is a project downstream to OpenJDK, so in my opinion
Google should definitively be part of the discussion.
That said, it's not only Google's fault here, and let's not get into the
politics here, but even i
I'd be happy to see Google joining the discussion, but Android (as in the
Java "clone") is totally unrelated to OpenJDK so I think it is unlikely to
see relevant input from that side.
However, OpenJDK works great on Android-devices (and can be used to create
Android apps and upload them to stores)
Thanks Alan,
Please see the last two comments on the related issue:
https://github.com/sparrowwallet/sparrow/issues/197
Craig
On Tue, Sep 21, 2021 at 9:21 AM Alan Bateman
wrote:
> On 20/09/2021 12:07, Craig Raw wrote:
> > Sure - I'm using the Gradle badass-jlink-plugin. The command it is
> > e
On 20/09/2021 23:15, Rob Bygrave wrote:
/:/
In case it's interesting, one thing that I hit when migrating to
module-info was that a number of the modules are only used in maven
test scope - as such they don't get a /requires/ clause in
src/main/java/module-info. Currently when running tests v
On 20/09/2021 12:07, Craig Raw wrote:
Sure - I'm using the Gradle badass-jlink-plugin. The command it is
executing is:
/Users/craigraw/.sdkman/candidates/java/16.0.1.hs-adpt/bin/jlink -v
--strip-debug --compress 2 --no-header-files --no-man-pages
--ignore-signing-information --exclude-files *
*> is that you expect code outside of your module to locate these resources*
That's right, the external module reading the resources is not application
specific but a library (its job is to "run database migrations" - open
source, published to maven central etc).
The background is that I have an
Sure - I'm using the Gradle badass-jlink-plugin. The command it is
executing is:
/Users/craigraw/.sdkman/candidates/java/16.0.1.hs-adpt/bin/jlink -v
--strip-debug --compress 2 --no-header-files --no-man-pages
--ignore-signing-information --exclude-files **.png --exclude-resources
glob:/com.sparrow
On 20/09/2021 11:13, Rob Bygrave wrote:
Well ok, silly me really because I think it is now clear that the
"proper answer" is that the module really needs to open the
subdirectories.
opens dbmigration.postgres; opens dbmigration.mysql;
So thanks and apologies Alan. It's all making sense to me n
Well ok, silly me really because I think it is now clear that the "proper
answer" is that the module really needs to open the subdirectories.
opens dbmigration.postgres;
opens dbmigration.mysql;
So thanks and apologies Alan. It's all making sense to me now,
unfortunately I got muddled by that er
*> "dbmigration" resources have not been copied into target/classes?*
target/classes/dbmigration exists *BUT* ... now I noticed that dbmigration
only contained other sub-directories (which then contain the resources). So
putting an empty junk.txt file into dbmigration fixes the problem.
So if the
On 20/09/2021 07:52, Craig Raw wrote:
Hi,
While I've noticed significant improvements in making reproducible builds
with JDK 16, there is a remaining issue I'm stumped by. The issue is this:
Using jlink invokes the SystemModulesPlugin, which creates .class files
containing module descriptors fo
On 20/09/2021 09:55, Rob Bygrave wrote:
Hi,
I have a case where I believe I have a module where I would like to use:
opens {package};
... *where {package} only contains resources*, there are no .class files in
{package}. Currently when {package} only contains resources, we get an
InvalidModuleD
I certainly hope so! But I don't see anyone, for example, from Google
representing Android, so what do we hope to accomplish, exactly? Let's
start by making the goals clear.
Samuel
On Thu, Sep 16, 2021, 16:35 Johan Vos wrote:
>
>
> On Thu, Sep 16, 2021 at 2:55 AM Samuel Audet
> wrote:
>
>>
>>
A simple approach would be to teach the app classloader to read JMODs and
extract native libraries on the fly, and to preferentially check a certain
sub-directory for classes before others (for OS-specific class files).
The original Jigsaw JEPs put that out of scope but it's what people make
their
On Thu, Sep 16, 2021 at 2:55 AM Samuel Audet wrote:
>
> If it wants to remain relevant, OpenJDK should really consider having a
> broader discussion about this.
>
...
> Please, please, do consider fixing the JDK instead of talking about
> coming up with incompatible "solutions"!
>
I totally agr
Right, I didn't even mention multi-platform builds.
That is a very valid concern, and it makes the situation a bit more complex.
We currently have different jar files for every different
platform/architecture combination. There is an exception though: we have 1
build for all iOS combinations: {32/
Indeed, I didn't make it clear that we distribute JavaFX in 2 ways: the
"standalone SDK" and the "maven artifacts". There are no issues with the
standalone SDK approach, and I should have mentioned that.
But apart for the core JDK modules, the SDK approach makes it much harder
for developers to ma
and afaik no recommendation. In the OpenJFX
project, we upload jars with module info to maven central, and we have
plugins for maven and gradle to deal with them at compiletime and at
runtime.
Project Panama and the foreign linker API may be another motivation to
re-visit this topic. One general concer
dation. In the
OpenJFX
project, we upload jars with module info to maven central, and we have
plugins for maven and gradle to deal with them at compiletime and at
runtime.
Project Panama and the foreign linker API may be another motivation to
re-visit this topic. One general concern is a
If we do eventually have to go with multiple, differently-named modules,
this would seem a sensible approach. I think it's roughly what Johan was
alluding to when he spoke of extending option 2 to use an SPI. In this
case, we would refactor the platform-specific code into different named
module
Thanks for starting this discussion.
One thing to point out is that for JavaFX we actually use two different
approaches depending on whether you are talking about the maven
artifacts or the downloadable artifacts.
The maven artifacts, which is what Johan was primarily referring to, use
optio
Hi,
Thank you Johan for starting this discussion. The current situation
is indeed problematic and a (de facto or not) standard should emerge.
IMO, beyond being easy to use, the selected mechanism should allow to
build multi-platform images (for instance for MacOSX on both aarch64
and x86_64).
>
maven central, and we have
plugins for maven and gradle to deal with them at compiletime and at
runtime.
Project Panama and the foreign linker API may be another motivation to
re-visit this topic. One general concern is adding more complexity to
the JAR format. I could imagine platform specific
Hi,
Hi,
There is another option:
API module and multiple platform specific modules (different names like
javafx.graphics.linux.aarch64) that require API module and provide services.
API module does not “require” any platform specific module but uses
ServiceLoader to find a proper implementati
Hi Gunnar,
I skimmed your post briefly and will read it in detail later -- though I
wonder
whether my over 4 years old SO question is answered as a side-effect by
your findings.
https://stackoverflow.com/questions/44167502/how-to-configure-resourcebundle-no-fallback-control-in-java-9
Cheers,
Chr
Hi all,
I've written a quick blog post about my experiences with
ResourceBundleProvider et al.:
https://www.morling.dev/blog/resource-bundle-lookups-in-modular-java-applications/
The scenario I'm describing is that of a "well-structured monolith", with
each module contributing its own resource
On 7/23/21 4:17 AM, Gunnar Morling wrote:
Thanks a lot for your replies, Mandy and Alan!
> I assume the class path is running on JDK <= 8, right? Otherwise
Is there something missing after "Otherwise"?
It was a typo (I should have taken it out).
In fact, I'm looking for a way to run this
On 23/07/2021 18:23, Gunnar Morling wrote:
:
Yes, I'm quite sure, unless I'm doing something really stupid :)
Here's the steps for reproducing:
git clone g...@github.com:gunnarmorling/resource-bundle-test.git
git checkout split-package
cd resource-bundle-test
mvn clean install
jar -tf german/
> Are you sure this always puts
dev/morling/greeter/fr/GreetingMessages_de.properties into
> resourceloading-test-german-1.0-SNAPSHOT.jar? I'm quite sure the JAR file
above doesn't
> have the fr resource but the JAR file in your previous mail seems to
include it.
Yes, I'm quite sure, unless I'm do
On 23/07/2021 16:58, Gunnar Morling wrote:
:
Yes, there is such resource which I had created for demo purposes (see
the jar -tf output above):
dev/morling/greeter/fr/GreetingMessages_de.properties
Here's the output you requested:
jar --describe-module --file
german/target/resourceloading
Am Fr., 23. Juli 2021 um 15:05 Uhr schrieb Alan Bateman <
alan.bate...@oracle.com>:
> On 23/07/2021 12:17, Gunnar Morling wrote:
> > :
> >
> > > For the migration scenario where the resources are in .properties
> > format then the simplest may be to just deploy the JAR files on the
> > module path
On 23/07/2021 12:17, Gunnar Morling wrote:
:
> For the migration scenario where the resources are in .properties
format then the simplest may be to just deploy the JAR files on the
module path where they will be treated as automatic modules.
In the scenario I have in mind (for educational pu
Thanks a lot for your replies, Mandy and Alan!
> I assume the class path is running on JDK <= 8, right? Otherwise
Is there something missing after "Otherwise"? In fact, I'm looking for a
way to run this
- Java 1.8 on classpath
- Java 9+ on classpath
- Java 9+ on module path
As I've learned by
On 22/07/2021 23:30, Mandy Chung wrote:
I assume the class path is running on JDK <= 8, right? Otherwise
This is a reasonable approach for the resource bundles to load from
both class path and module path when the resource bundles of a given
name is packaged in multiple modules/JARs.
We con
On 7/22/21 12:23 PM, Gunnar Morling wrote:
Hi all,
I'm trying to figure out how a modular application should handle
cross-module resource bundle look-ups, supporting running on both the
module path and the class path. At a first look, resource bundle semantics
in the two modes are at odds wit
Presumably this is a javac lint warning about how types referenced from
an exported API (e.g., the return type of an exported public method)
should themselves be exported.
It's hard to tell from
https://docs.oracle.com/en/java/javase/16/docs/specs/man/javac.html#option-Xlint-custom
exactly wh
On 28/06/2021 09:49, Christian Beikov wrote:
Hello experts,
I am in the process of modularizing one of my projects and hit some
rather annoying limitations that requires me to change parts of my
build and dependencies due to the way the Java module system works.
I usually have modules like x
Thanks for the quick answer and the hint about service, but as you can
imagine, services don't really help here since I am trying to use CDI
which does it's own discovery.
I understand the point about "99,999 other modules", that's why I asked
specifically if such a module is even "visible" so
1 - 100 of 7693 matches
Mail list logo
