GUI focus stolen due to epubcheck launching window-less “Checker” empty GUI app

[elmimmo]

Running epubcheck from the command-line still launches a window-less GUI app named Checker that claims the GUI’s focus. The app stays open until epubcheck finishes its thing, at which point it kills itself (returning the focus it stole if the user did not claim it back).

It thus becomes impossible to run epubcheck in the background while the user works on something else, specially when running batch-checks of lots of EPUBs (which involves calling epubcheck once per ebook, therefore causing that dreaded GUI app to launch repeatedly), since the user is then constantly taken away from whatever app he or she is using.

Observed on OS X Yosemite 10.10.5 (14F27) and JRE 1.8.

[JSCrawford54]

How are you calling epubcheck? When I run it from the command line I don't get a GUI coming up for every EPUB.

[elmimmo]

$ JAVA_HOME="/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home"
$ epubcheck "$PATH_TO_EPUB"

JRE 1.8 installed by installing the browser plugin from http://java.com. epubcheck installed via Homebrew.

[JSCrawford54]

If you don't already have it or know where to find it, download the jar file and put it somewhere on your computer you can access it. I keep mine in the applications folder for the sake of ease. At that point you can run a simple for loop through terminal or create an executable script or Automator app that can run it for you. Just throw it into a for loop, e.g.

for EPUB in <path/to/dir/with/epubs>/*.epub; do
    java -jar /path/to/epubcheck.jar $EPUB | tee -a /path/to/outputfile.txt
done
open /path/to/outputfile.txt

I like to pipe my results into tee just to make them prettier and easier to read.

[rdeltour]

It seems to be an issue specific to the Homebrew build. @tofi86, any idea?

[tofi86]

I can confirm the issue with the homebrew epubcheck.
However, I've no idea why this happens...

Homebrew pull the release package directly from this projects GitHub releases page and unzips it to /usr/local/Cellar/epubcheck/4.0.1/libexec/

The epubcheck command is a shellscript in /usr/local/bin/epubcheck:

→ cat /usr/local/bin/epubcheck
#!/bin/bash
exec java  -jar /usr/local/Cellar/epubcheck/4.0.1/libexec/epubcheck.jar "$@"

[tofi86]

Ahhh, darn it!
I can also confirm it on my Mac with Java 8 with a fresh maven build from current master!

So at least it has nothing to do with Homebrew...

[tofi86]

Also happens with 4.0.1 and Java 7 (tested jdk1.7.0_79)

[elmimmo]

If ran with Apple’s Java 1.6, the name of the app is com.adobe.epubcheck.tool.Checker instead.

Again, com.Adobe??

[tofi86]

@elmimmo that's the package identifier for EpubCheck: com.adobe.epubcheck
Also see here: https://github.com/IDPF/epubcheck/tree/master/src/main/java

That's because initial development of EpubCheck was largely done by Adobe and they created the project in their namespace...

[tofi86]

Observations:

• it doesn't happen with every EPUB...
  • there's no issue with src/test/resources/20/epub/Issue95.epub for example
  • but it occurs with src/test/resources/20/epub/Issue25.epub...
• the "gui-app" doesn't get started immediately when running epubcheck
  • seems to kick in when running the RSC, OPF or NCX tests
• It also happens when launching com.adobe.epubcheck.tool.Checker from within Eclipse.

Can someone confirm that?

I haven't found a clue yet why this happens and don't have time to do a debug session in Eclipse this evening...

[mclow]

I can confirm that this happens (a GUI app named Checker is launched) on a Mac running El Capitan w/o Homebrew.

$ java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

$ java -jar ~/bin/ePubCheck/4.0.1/epubcheck.jar *.epub
Validating using EPUB version 3.0.1 rules.
No errors or warnings detected.
epubcheck completed

[sci-phi]

Have you tried using the " -Djava.awt.headless=true" flag?

[mclow]

I just tried that, and it works. Thanks!
That's a great workaround until this bug is fixed

[tofi86]

Alright, this was quite an intense debugging session but I found the cause for the window-less GUI app on Mac OS X:

com.adobe.epubcheck.bitmap.BitmapChecker line 122:

ImageInputStream imageInputStream = ImageIO.createImageInputStream(tempFile);

It's the ImageIO.createImageInputStream() which seem to have problems with headless mode on OS X.
There are several other threads when searching on Google, e.g.:

• Apple JWT Java VM Issue joeferner/node-java#1
• https://community.oracle.com/thread/1690614?start=0&tstart=0
• ...

Unfortunately it's always the same solution: setting java system property -Djava.awt.headless=true

Which doesn't help in our case because it can't be set during runtime but must be passed to the JVM on startup...

@rdeltour I remember other / earlier problems with the ImageIO library and we partly switched to/from the TwelveMonkeys library. Any chance that this caused the trouble?

Contributions and help very welcome!
Guys, feel free to provide alternative solutions for the problem or for the image checking...

[tofi86]

com.adobe.epubcheck.bitmap.BitmapChecker line 122:

ImageInputStream imageInputStream = ImageIO.createImageInputStream(tempFile);

Of course, when debugging this you need to uncomment lines 122 and following and add an additional return statement for public ImageHeuristics getImageSizes()

I tested with file src/test/resources/20/epub/Issue25.epub from the repository and error doesn't occur when commenting out lines 122 ff

[tofi86]

This issue has been resolved with 66cf217 in PullRequest #732. Waiting for review and merge.

[tofi86]

Has anyone in this thread tried my patch from PR #732 yet? Does it work? Any feedback?