Wow, this sounds really ambitious. A lot of this overlaps with what
Graal, LLVM, and Panama are trying to do.
Which is great, but we /really/ need to come up with some sort of
roadmap and get everyone on the same page...
Anyway, here's what else is in JavaCPP today that works and provides a
go
Hi,
Thanks for your interest! I'm always trying to do all that I can, but
I'm pretty much just one guy working on this part-time...
Besides, this is the kind of thing that should be standardized in the
JDK, and Oracle isn't exactly low in resources ($9 billion net income
last year, wow), so
The issue isn't just about /loading/ shared libraries, it's also about
/linking/ with these libraries using native toolchains. That usually
requires at least the header files, and possibly other files for
pkg-config and what not. Unless we really want to revamp how GCC, Clang,
and MSVC work as
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
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 Sa
rs dealing with platform-specific (native and
Java) code. It would be great if there was support at the specification
level for this best-practice, but that is probably something for the longer
term, as it will require more resources and lots of analysis, to make sure
backward compatibility is not bro
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
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
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?
https://github.com/sp
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 Spr
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
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
12 matches
Mail list logo
