> On Mar 12, 2018, at 1:13 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >> On Mar 12, 2018, at 9:27 AM, Jörg Schaible <joerg.schai...@gmx.de> wrote: >> >> Hi Ralph, >> >> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote: >>> >>> Actually, you really do need to use a multi-release jar to include a >>> module-info class file. Otherwise it may be sitting alongside of classes >>> compiled for an earlier java release and various tools will fail becaus of >>> it. >> >> Not necessarily. XStream contains for more than a decade class files >> targeting different Java versions. Works normally fine as long as nobody >> tries to load a class that cannot handled by the current runtime. Android >> has its problems with it, but it has already problems with Java 8 ;-) > > You statement just proved my point. “Works fine as long as …”. So as soon as > you want to support those various tools you have to stop doing that. > > Ralph
Is there actually a standard list of tools or other build apparatus that is to be supported by Commons releases? I can name lots and lots of tools that won't work with Java 7 or even earlier versions. Most of them don't matter at all. I'm not making a claim about any particular tool or toolchain (including Android), but a general point. I'd like to understand when "if we try X, our artifacts won't work on Y" is a valid blocker for a Commons project. In this case, the project (as has been repeatedly explained) aims to do nothing more than understand the conditions for using X and how to meet them, so I don't see how Android's (or any other specific project's) problems are a blocker at all. If anything, concern with problems for Android usage should be assuaged by a project that will help turn up more data about those problems. Adam Soroka ; aj...@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
