You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order for this library to be usable in a modular Java application that is distributed with a jlink image, it needs to be made modular.
It is possible to do that and still keep compatibility with Java 8 and earlier versions, if that's something that may be keeping you from modularizing this library, by using a multi-version jar.
When I try to use the latest version of this library on my modular Java app, I get this error from jlink:
Error: automatic module cannot be used with jlink: org.json from file:///.../libs/json-20190722.jar
As this library does not seem to have external dependencies, making it modular should be almost trivial. If you do not have time to do it, would you accept a pull request?
You've been discussing this change for 2 years?! I just skimmed through the huge discussions, but are they saying that putting a module-info class file in META-INF/ breaks some tools?? I've seen a few widely popular libs doing this and I assumed most libraries can do that... I would be very surprised if anything at all in META-INF/ breaks stuff, as you could have arbitrary assets in that directory and any JVM tool should know that!?
Yes the questions and the issue items and all the rest of the concerns on the pull request (that is the second one btw, the first one was a year long) are very very - questionable.
You're more than welcome to continue them - i keep closing it but they keep reopenning it, maybe there is simply something there that they just don't like xD
Larger libraries like prime faces and the likes have already moved across to my maven coordinates, so you're more than welcome and secure in doing so, it is always 100% in sync with this owning repository.
The package provided under https://search.maven.org/artifact/com.guicedee.services/json saved my day. It is exactly that org.json should provide. I mean Java 9 is around since September 2017 and Gradle 6.4 finally support building module natively. It is time to add module support to all cool packages such as org.json, isn't it?
You could make two versions: one legacy for the ones using unsupported JDK and one for the up to date teams.
@marcelbaumann the maintenance and management of this root project is nothing short of appalling. I really hope it is something that they look at and improve upon soon -
But even that pull request has hit the org.json limbo hell xD I really hope they fix their processes
It's starting to get there hey, really happy to start seeing the massive uptake in modules and AMD in the java space -, and the performance upshoot (nothing under 68%) from modular with java native imaging, selling the new java world as a full replacement for older technologies has never been so easy xD xD xD
Activity
GedMarc commentedon Apr 25, 2020
Hey
I tried to go down this road #431
You can also carry on the attempt into this library over here
#451
If you just want to get up and running - this is the active running coordinates
https://search.maven.org/artifact/com.guicedee.services/json
100% maintained - version bumps with the owning library www.guicedee.com
GedMarc commentedon Apr 25, 2020
you can carry on the pull request or whatever on this one BGehrels#4
renatoathaydes commentedon Apr 25, 2020
You've been discussing this change for 2 years?! I just skimmed through the huge discussions, but are they saying that putting a
module-infoclass file inMETA-INF/breaks some tools?? I've seen a few widely popular libs doing this and I assumed most libraries can do that... I would be very surprised if anything at all inMETA-INF/breaks stuff, as you could have arbitrary assets in that directory and any JVM tool should know that!?GedMarc commentedon Apr 25, 2020
XD Hence why I just walked away
Yes the questions and the issue items and all the rest of the concerns on the pull request (that is the second one btw, the first one was a year long) are very very - questionable.
You're more than welcome to continue them - i keep closing it but they keep reopenning it, maybe there is simply something there that they just don't like xD
Larger libraries like prime faces and the likes have already moved across to my maven coordinates, so you're more than welcome and secure in doing so, it is always 100% in sync with this owning repository.
marcelbaumann commentedon May 12, 2020
The package provided under https://search.maven.org/artifact/com.guicedee.services/json saved my day. It is exactly that org.json should provide. I mean Java 9 is around since September 2017 and Gradle 6.4 finally support building module natively. It is time to add module support to all cool packages such as org.json, isn't it?
You could make two versions: one legacy for the ones using unsupported JDK and one for the up to date teams.
GedMarc commentedon May 12, 2020
@marcelbaumann the maintenance and management of this root project is nothing short of appalling. I really hope it is something that they look at and improve upon soon -
But even that pull request has hit the org.json limbo hell xD I really hope they fix their processes
#515
It's starting to get there hey, really happy to start seeing the massive uptake in modules and AMD in the java space -, and the performance upshoot (nothing under 68%) from modular with java native imaging, selling the new java world as a full replacement for older technologies has never been so easy xD xD xD
stleary commentedon May 12, 2020
Please read the Wiki.