> 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

Reply via email to