Updating to Apache Commons Lang 3#5
Conversation
|
@jahlborn Can this pull request be accepted? Or do I need to figure out how to submit it on SourceForge? |
|
Sorry, this is effectively a breaking change for current users of the library. This would have to be rolled into a non-minor release. I've contemplated making such a change, but haven't been ready to pull the trigger yet. |
|
@jahlborn I'm surprised that there are still users who are using pre-Java 5 code. Or is it a breaking change for some other reason? |
|
it's a breaking change because a simple upgrade of the jackcess would fail unless you updated the dependent libraries (which may or may not cause other issues). i try very hard to keep minor versions "drop-in" compatible. |
|
Wouldn't Maven or Gradle or whatever they're using automatically pull down the new version? Or do clients still just drop jars into a libs folder? If it won't be included in the next version, will it be included in any future version? |
|
not everybody uses something with automatic dependency management. also, pulling in new dependencies can have other negative affects if it causes other conflicts. i will probably look to do this at some point in time in a non-patch release. honestly, though, if i'm going to make changes like that, i have to weigh the cost of breaking changes like that with little benefit vs. making a significant jump and going java 6+ (or 7+) only. |
|
Robert Munteanu recently opened https://issues.apache.org/jira/browse/TIKA-2756 to ask that we remove our dependency on commons-lang. Jackcess is our only dependency that requires it. Is upgrading to lang3 still a non-starter for Jackcess? Thank you! |
|
I'm in the midst of some expression evaluation changes right now. after that stuff is settled, i'll try to evaluate the upgrade dependencies and/or upgrade java versions situation. |
|
There is always the option of embedding the dependencies in your jar and renaming to avoid conflicts using the maven shade plugin. I can whip up a pull request if that's a direction you're willing to explore. |
@rombert I'd prefer that we not try to embed dependencies inside jars. That means that consumers have no control over whether or not the jar is included, and if a security vulnerability were discovered in Commons Lang 2.x, then the user can't do anything about it (I've had that happen with jars embedding libraries with high-risk CVEs, and us being frustrated that we can't do anything about it). In the mean time, I've updated this PR so that it can merge cleanly into master. Upgrading Jackcess to use Apache Commons Lang 3.1+ would be the best solution in my opinion. (As an FYI, I had to downgrade my JDK to 8 because JDK 11 can't compile to Java 5. I do hope that we increase the minimum at some point in the future). |
|
Thanks for the quick turnaround @Thunderforge ! I was only suggestiong the shade option to make it easier to upgrade. If you're OK with switching to commons-lang3 that is even better for us. |
That’s why I created this PR in the first place over a year ago 😉Hopefully the project maintainers agree. |
|
Apache commons-lang does not work on java10. It's SystemUtils tries to parse java version and fails. That is the reason why we do not want to have it anywhere in our dependency chain and jackcess is the only reason we still have it! |
|
Sorry, i forgot about this pull request. Short answer is that this will be fixed in Jackcess 3.0. Please follow the feature request here: https://sourceforge.net/p/jackcess/feature-requests/35/ |
5 participants
I've set it to Apache Commons Lang 3.1 because that's the last version to support Java 5, and the Jackcess FAQ says that's a requirement. I suppose this means that it will break the patches that allow it to work on Java 1.4.
When this project requires Java 6 or 7, upgrading to newer versions of Apache Commons Lang 3.x will be as easy as updating the pom.xml file.