F21 System Wide Change: Headless Java

[Stanislav Ochotnicky]

Quoting Miloslav Trmač (2013-11-21 20:57:38)
> > 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.

The crash will be noticeable in the same way that unsetting DISPLAY variable is
for any other GUI app.

Maybe there's a console app that creates X window only in some cases (batik
comes to mind as a possible candidate here). But that's not normal modus
operandi even in Java world.

> >> 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.)

As if I spent 3 years making Java packaging more manual...

> >> 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?

In most cases, but I can imagine cases where a genric toolkit library with
support for multiple backends didn't want to force-pull full java for a specific
use case.

> > 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...

I don't even dare guess how many false positives you'd get by doing that. Oh and
let's see how fast we can make this. Otherwise autorequires generator is going to
waste a lot of developer time in by doing bytecode analysis on each single class
file.

Regardless..what I meant to say: Nobody - as in I don't see anyone jumping up
and down and volunteering to do the work and maintain the code, provide ways to
workaround those inevitable false positives etc. I have asked and received a
clear "no" from people who actually work on OpenJDK codebase. If anybody things
they are smarted go ahead: prove them wrong

-- 
Stanislav Ochotnicky <sochotnicky at redhat.com>
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com