-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package name utils breaks modularized projects that doesn't employ jnigen #60
Comments
The only way I am aware of to fix this, is to move the 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 |
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.
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. 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. |
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.
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'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?
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. |
Update: Second attempt:
But ran straight into the the same issue as gdx itself is not modularized either:
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. |
Hi,
I opened an issue in libgdx/libgdx while trying to find a work around to a split package issue (this one: libgdx/libgdx#7355) and would like to ask if it was possible to change the gdx-jnigen-loader package com.badlogic.gdx.utils name to anything else?
TL:DR; Since gdx (v1.12.1) depends on jnigen (v. 2.4.1), and gdx itself is not modularized, even if you're not using jnigen yourself, jnigen becomes a transitive dependency (I think that's the word for it) and causes problems for your project either way.
Nothing prevents gdx from being used in a modular application as far as I can tell, as java can automatically infer it as a module if put on the module path. However, gdx requires jnigen to be present as well, which is why I haven't been able to find a workaround.
Admittedly, I don't have a full comprehension of what this will cause of problems for libgdx itself, but I'm hoping it could be a part of the next release cycle (https://github.com/libgdx/libgdx/milestone/6) and I should personally like to help in any way I can.
Edit: I went through the closed issues to see when if this had been brought up before, and it kind of has: #2 <- the SharedLibraryLoader-merger (the class that causes a ClassNotFoundException if jnigen isn't included as a module in a modular project). I'm not sure the split package issue didn't exist then, but it sounds like what I'm experiencing is an accident following that merger.
The text was updated successfully, but these errors were encountered: