Comments (5)
The only way I am aware of to fix this, is to move the SharedLibraryLoader
to a different package in jnigen. However, this would break every project that uses jnigen and I wouldn't know a way to do it backwards compatible. It's true that modularizing libGDX is inherently broken currently, however modules seem to be very unpopular in libGDX (and maybe in general).
For a workaround for your project, you can either fork jnigen or I assume you can just remove the "jnigen" dependency from your project, and copy over these classes into your project in a favorable package: https://github.com/libgdx/gdx-jnigen/tree/master/gdx-jnigen-loader/src/main/java/com/badlogic/gdx/utils
from gdx-jnigen.
The only way I am aware of to fix this, is to move the
SharedLibraryLoader
to a different package in jnigen. However, this would break every project that uses jnigen and I wouldn't know a way to do it backwards compatible. It's true that modularizing libGDX is inherently broken currently, however modules seem to be very unpopular in libGDX (and maybe in general).
Yeah, I guess moving / renaming existing is essentially the same from a start-of-runtime perspective, and would break anything using the next version if done. Java's JPMS is not very popular that's true, but for my purposes, it would bring me more value than pain to include and is a must for larger projects due to inherent limitations with Java's standard visibility modifiers.
For a workaround for your project, you can either fork jnigen or I assume you can just remove the "jnigen" dependency from your project, and copy over these classes into your project in a favorable package: https://github.com/libgdx/gdx-jnigen/tree/master/gdx-jnigen-loader/src/main/java/com/badlogic/gdx/utils
With the way that the latest release of libgdx is build, jnigen is brought in "implicitly" - as in, I declare no dependency on jnigen myself, but my libgdx dependency does which I can't change. Good idea, putting the SharedLibraryLoader on the classpath myself, I did manage to exclude jnigen explicitly (which ran into the ClassNotFound), so maybe just maybe.
As for shading generally, I'd really rather not - as it would bring no potential value to anyone but myself, and would require me to shade the entirety of libgdx itself as well (updating all jnigen imports).
I do have an alternative, which resolves this issue for a while without breaking any projects: You could pull the contents of jnigen....utils into libgdx...utils when building a jar for a release of libgdx. Maven has a plugin to do this automatically, and gradle probably does too, but this would prevent the dependency from "bubbling up" and causing issues because there would be no dependency on jnigen from libgdx in the first place. I don't know if I could do this from my side, as I don't understand gradle or know exactly what the statements in libgdx' build.gradle "apply plugin: jnigen" does (https://github.com/libgdx/libgdx/blob/master/gdx/build.gradle). But if its some kind of static pre-processing (during build or compile) it shouldn't interfere.
Edit: Clarity, rendundancy.
from gdx-jnigen.
There do be pretty good search and replace tools, and I reckon you could run a simple bash script updating all import statements.
The problem is more complicated in transitive dependency. If jnigen updates the package name, every project that uses jnigen would need to do changes to be compatible again. It would also add a clear compatibilty cut, where two dependencies in different versions are just not compatible. It is preferable to avoid that.
but this would prevent the dependency from "bubbling up" and causing issues because there would be no dependency on jnigen from libgdx in the first place.
We could package the jnigen-loader classes into libGDX and rename the package in jnigen at the same time, which should ensure backwards compatibilty and non-breaking. I don't hate it, but I also don't like this added complexity/duplication in the jar. Not sure what others opinions are on that.
from gdx-jnigen.
The problem is more complicated in transitive dependency. If jnigen updates the package name, every project that uses jnigen would need to do changes to be compatible again. It would also add a clear compatibilty cut, where two dependencies in different versions are just not compatible. It is preferable to avoid that.
I'm aware. Its indeed not preferable. I mean, people could always choose to stay on an earlier version for their own purposes, so nothing is forced upon them - also those using it and libgdx if libgdx swapped to a breaking version. Do you have any knowledge about how many projects would potentially get broken?
We could package the jnigen-loader classes into libGDX and rename the package in jnigen at the same time, which should ensure backwards compatibilty and non-breaking. I don't hate it, but I also don't like this added complexity/duplication in the jar. Not sure what others opinions are on that.
I would appreciate it so much if you did and I'd love to help. It would mean the world to me and the hundreds of people forced to use a very old version of libgdx (way before #2 which is JPMS compatible) during a course I had at university.
If a breaking change is on the horizon, I reckon one could use the opportunity to modularize, or partially modularize libgdx itself. (Which isn't a breaking change necessarily, but a structural change which could cascade).
from gdx-jnigen.
Update:
I've finally come back around to this after forking jnigen and trying some different things.
First attempt:
Setting some manifest attributes to attempt to have jnigen be picked up by the java runtime as declared module. This did not fool the automatic module resolution, and made no difference.
Second attempt:
Forking and adding a module-info file. This actually worked to a degree and the gdx-jnigen-loader was picked up as a declared module:
PS E:\GitHub\MELANGE\jnigen> jar --describe-module --file=gdx-jnigen-loader-2.5.1-SNAPSHOT.jar
gdx.jnigen.amtest.gdx.jnigen.loader.main jar:file:///E:/GitHub/MELANGE/jnigen/gdx-jnigen-loader-2.5.1-SNAPSHOT.jar!/module-info.class
exports com.badlogic.gdx.utils
requires java.base mandated
But ran straight into the the same issue as gdx itself is not modularized either:
java: the unnamed module reads package com.badlogic.gdx.utils from both gdx and gdx.jnigen.amtest.gdx.jnigen.loader.main
java: module melange.example reads package com.badlogic.gdx.utils from both gdx and gdx.jnigen.amtest.gdx.jnigen.loader.main
Admittedly I've got a lot of dependencies going in the project where I ran this (mono branch of Melange), but not only did it cause issues for me, but also spring and reflections which where also present.
from gdx-jnigen.
Related Issues (20)
- AntScriptGenerator does not allow to specify an absolute libsDir HOT 4
- Jnigen does not have compiler suffix, and resets it every build HOT 3
- Desktop native outputs are relative to Gradle daemon working directory. HOT 5
- Problem with SharedLibraryLoader#mapLibraryName on Android? HOT 1
- Making it optional to build for 32-bit (armv7) iOS?
- macos 2.3.1 error
- Bitcode is deprecated on XCode14
- Header files not detected properly. HOT 1
- Non UTF-8 encoding can lead to task freeze
- Silent failure, if "has-compiler" evaluates to false
- Failed to find MinGW Compiler HOT 2
- Windows Cross-Compile
- Is there a way to not "clean" on every build?
- Add new CPU architecture HOT 4
- Add instructions on how to use it with gradle kotlin DSL HOT 2
- gdx: Android: Build ELFs to support 16kB page size
- Android ignores `libraries` field
- Android: Add support for adding arbitrary strings into Android.mk
- Improve support for symbolication
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gdx-jnigen.