F21 System Wide Change: Headless Java

[Miloslav Trmač]

On Thu, Nov 21, 2013 at 8:46 PM, Stanislav Ochotnicky
<sochotnicky at redhat.com> wrote:
> Quoting Jerry James (2013-11-21 17:01:07)
>> On Thu, Nov 21, 2013 at 5:33 AM, Miloslav Trmač <mitr at volny.cz> wrote:
>> > (IIRC somewhere in the thread it's been suggested that software can't
>> > know which one to use: how would the maintainers know then?)
>>
>> Yes, I raised that question early on in this thread.  The response I
>> got was to read this:
>>
>> http://www.oracle.com/technetwork/articles/javase/headless-136834.html
>>
>> which is a 7 year old article about setting up a headless system with
>> Java 6, and doesn't mention audio anywhere.  I am willing to do the
>> work to figure out which of my packages need full java and which can
>> get by with java-headless, but I need a very clear set of criteria to
>> work from.  I don't think this article qualifies, nor have I yet seen
>> such a clear set of criteria.
>
> I linked to that article because it's relevant. If you read it you know that:
>     * java.awt. classes are a problem for headless (except Canvas, Panel and
>       Image as mentioned in the article)
>
> Other than that a simple grep for one of following will give you a smoking gun:
>     * import javax.sound.
>
> But if you want a simpler guide:
>     * Install your app with headless Java
>     * Run it
>     * Did it crash?
These two steps make it rather non-"simple"; one would also determine
which parts of the code base have not been exercised.


>> And Mirek's question bears repeating: if software can't figure this
>> out reliably, how do you expect us fallible humans to do so?
>
> Software can't reliably detect licenses in packages, yet we routinely do license
> review manually as part of Package Review process. It's really not that uncommon
> for people to be better than computers at fuzzy tasks.
This is not really that kind of a fuzzy question, and getting licenses
wrong has a potentially much higher cost.

> Call me silly but I expect maintainers to know what their packages actually do.
Call me silly but I expect computers to do routine tasks, not people.
(... under the assumption that somebody really wants to do a
comprehensive conversion and get this applied to all future Java
packages; I understand that this may not actually be what $you really
want to achieve and spend time on.)

>> Apparently it is not as easy as "if your software uses these packages
>> and/or classes, it needs full java, otherwise java-headless is
>> enough".  Why not?  What else could cause a dependency on full java?
>
> It is as easy as "if your software uses these packages and/or classes" but it's
> almost impossible to say if your software uses them due to nature of Java/JVM
> itself. There's too many ways to use parts of JVM. Interfaces, intermediate
> libraries, various classloading tricks.
Intermediate libraries would carry the non-headless dependency
themselves, so their users wouldn't have to, would they?

> Nobody is going to write a reliable detection if it should be headless requires
> or not.
I suppose this will show how hopelessly naive I am, but wouldn't "byte
code refers to any class from $list or contains a string constant that
starts with any class name from $list" be sufficently accurate?  Not
provably correct, certainly, but if it got us from 30 unknown false
positives to 1-2 unknown false positives _and_ eliminated a manual
packaging/review step...
     Mirek