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
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
>
> 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.
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
>
> 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
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
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
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
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
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
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
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.)
2. Enhanced manifest to support
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
A module can indicate its main class by setting the ModuleMainClass
attribute in its module-info.class. This can be done by running with
"jar --main-class=xxx" when creating a modular JAR file.
The module system allows you to enumerate all the modules in a
ModuleLayer. For each module, you
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
Well, we can still use ZipInputStream just to list files from a JAR, but
it's not exactly efficient. Would anyone want to make class scanning 10x
slower just to support modules? Probably not
Samuel
On Sat, Oct 9, 2021, 13:34 Samuel Audet wrote:
> One problem is that frameworks like Spring Boot
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 class like this one?
As a proof of concept, I wrote a quick-and-dirty demo that can load
Jigsaw modules from a Uber-JAR file:
https://github.com/iklam/tools/tree/main/jigsaw/uberjar
Glavo, would something like this fit your needs?
I think something like this could be done outside the JDK (in frameworks
like
I am wondering if there are 3rd party solutions that support loading
Jigsaw modules from uber jars. The JDK should have all the APIs to
support such a solution.
E.g., I looked at SpringBoot, which has uber jar support, but it doesn't
seem to support modules ("java.lang.module" doesn't appear
The URL class loader is the easiest way to solve conditional loading. In Jini,
now Apache River, we’ve long used this mechanism to “get” the implementation of
all interfaces that a remote client application needed to talk to a particular
server (versioning makes this necessary and powerfully
>
> *Bandwidth optimization and rare machines.* This is interesting because
> it's a requirement that feels like it may be more common in China than
> elsewhere. I'd be keen to learn more about your bandwidth constraints,
> unless this is more of a theoretical concern?
Ah, in fact, in Chinese
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
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.* Although it's logical that you ended up on this list,
realistically the JPMS is "done" and not being worked on since Java 9. Any
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
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
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
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.
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
>
> 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日周四
>
> 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
-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
34 matches
Mail list logo
