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)
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
We can publish JMODs, or any other binaries for that matter, on Maven
repositories, for example, here's a random one I've just pulled out:
https://search.maven.org/artifact/com.github.nullterminated/trylambda/1.4/jmod
But why do we need to maintain 2 different sets of archives containing
essen
We do have jmods available for download, but not in maven central. I'm
not well-versed enough with maven / gradle support for jmods to know
whether it would even be an option, but even we do have them, we still
need the modular jars for the cases where the developer doesn't end up
running jlink
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).
>
On 15/09/2021 09:45, Johan Vos wrote:
Hi,
There have been discussions in the past about how to deal with
platform-specific parts (java code, native code, resources) in modules.
There is no standard for this, and afaik no recommendation. In the OpenJFX
project, we upload jars with module info to
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,
There have been discussions in the past about how to deal with
platform-specific parts (java code, native code, resources) in modules.
There is no standard for this, and afaik no recommendation. In the OpenJFX
project, we upload jars with module info to maven central, and we have
plugins for m
21 matches
Mail list logo
