Hi! I created a PR which aims to fix commons-lang behaviour which is broken since quite a few years. To be more precise: commons-lang doesn't fully support anything beyond Java8 due to not acknowledging the java module system (leading to InaccessibleObjectException). And no, adding --add-opens is NOT a viable solution for most developers!
https://github.com/apache/commons-lang/pull/1328/ Yes, the comments seems to get reflected to issues@ but I'd like to discuss this on a broader level: Do we like to support anything beyond Java8 in commons-lang or not? It boils down to the fact that there are a few people who like to see commons-lang move forward, and others who want to stick to pre 2017 code. > Note that this PR is worse than I thought because we already have a feature > to bypass reflection! Use > `EqualsBuilder.setBypassReflectionClasses(List<Class<?>>)`. This is not really a viable solution for this very case. a) you'd have to add tons of classes all over again for each usage. We are talking about 30++ classes? For every usage... b) You'd need to do this extra miles when running with Java9++ in comparison to Java8. So you have to change user code when moving from one Java version to the other? That's stupid imo! c) try using this on a class which contains e.g. an ArrayList, a Set or a Map. It will e.g. use List#equals() which also does equals() on it's items (btw, I explained this to you already...). Which is NOT what users expect. Instead it should iterate over the List and use ReflectionEquals on the elements. This is exactly what the PR does (amongst other things). Let's face it: if commons-lang does not obey basic Java rules (in this case Java9++), it will be kicked out of projects down the road. And yes, I right now have this question whether to keep commons-lang in customer projects or replace it. That's the reason why I did invest a few days to provide suggestions for a way forward. We need to provide this functionality somehow. JIRA is full with respective tickets and bug reports (e.g. LANG-1685). And I don't care whether we change the existing code, duplicate the functionality over to a new package or even create commons-lang4. But being ignorant to the requirement to support Java9++ out of the box will make commons-lang go the way of the dodo, I fear. Happy to discuss the way HOW we move forward. But we should move forward. LieGrue, strub
