vy commented on PR #490: URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1973262056
@elharo, I am confused with your remarks given @ppkarwasz stated that it works and it is backward compatible. I see [your objections in the mailing list due to JPMS issues](https://lists.apache.org/thread/jx8ot7c7xmf8ld0wjd1xhmdo7qvqtkxt): > A classpath MUST NOT have the same fully package qualified name in > more than one JAR. This is a hard requirement in Java 9+ with JPMS. > The JVM will not run a program that violates this. It is a very > important requirement in Java 8. [But as @ppkarwasz responded](https://lists.apache.org/thread/ywmzh47pjk554mzjj835jm8hxlvnf1bh) > JPMS does not really care which module has which package. As long as > they are disjoint it will be fine AFAIK about JPMS, Piotr is right. > As written, this does not work and cannot be shipped. The fundamental problem is that it moves classes from the commons-compress artifact to the commons-compress-core artifact without changing the Java package or class names. I am not able to see the problem here. Could you give a concrete example where this change will break the application? > This breaks existing code, even of projects that do not depend directly on commons-compress, and will cause a lot of needless pain in the Java community. Could you elaborate on your reasoning a bit, please? It is really difficult to come up with a fix when you only say _"this breaks existing code"_. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
