F21 System Wide Change: Headless Java

[Stanislav Ochotnicky]

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?
        - No? - good! you can probably use headless
        - Yes? - not good! use full Java VM
    * Did you get any backtraces when running the app that are not normally
      there?
        - No? - good! you can use headless
        - Yes? - not good! use full Java VM

For obvious reasons this is not something we'll be turning into a separate
project. Autorequires/provides don't work on source code but bytecode.

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

Call me silly but I expect maintainers to know what their packages actually do.
Seriously though if you really can't figure it out, just ask on java-devel@ (or
#fedora-java on freenode). You can't have more than a handful of Java packages.

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

Nobody is going to write a reliable detection if it should be headless requires
or not. Much less integrate it into all different Java build systems so that it
actually makes sense to spend time on. 


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

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