Mac OS X: X11 installation is required to start app about packr HOT 38 CLOSED

What exact version of the Java VM are you using? I remember we had this happen with the unofficial 1.7.0-u40 build (I made a comment in #10 about it).

from packr.

It is latest available from suggested repository:
openjdk-1.7.0-u60-unofficial-macosx-x86_64-image.zip

from packr.

Looks like the X11 requirement is some special issue with OpenJDK on OS X:
https://bugs.openjdk.java.net/browse/JDK-8031568
http://mail.openjdk.java.net/pipermail/build-dev/2014-January/011520.html

You might try to use the 1.7.0-u45 build. We are shipping that one and it doesn't complain about X11 on a clean OS X (VM). It probably will complain about installing Java 6 though, which was discussed in #10 too.

from packr.

Beg a pardon for a stupid question. Could you please explain why we should use "unofficial jdk" instead of just official JRE from Oracle (http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880261.html)? Just tried and it works perfectly with packer. Without any requirements for X11 or Java 6. And off course the game start smoothly with it (its the primary target).

So what is the reason? Licensing for redistribution? Now rights to exclude some parts (reduce size)?

from packr.

A good question, actually. If it works for you - why not? From what I read at in the Java SE README Files (http://www.oracle.com/technetwork/java/javase/terms/readme/index.html), you are very much limited by Oracle about what you are required to redistribute, and what files you are allowed to exclude. Other than that I don't see any legal impediments.

Maybe @badlogic can shed some light on other reasons to go with the unofficial builds.

from packr.

@titovmaxim Actually, I would rather ask the opposite question, why would you like to use Oracle Java instead of OpenJDK? You can build OpenJDK by yourself, Oracle Java and OpenJDK share more than 97% of source code but the latter has more permissive terms of use, it's possible to use OpenJDK with OpenJFX if your game requires JavaFX. My game starts smoothly with OpenJDK and I succeeded in running it under Mac OS X Yosemite (not sure about 10.6.8).

As far as I know, you are allowed to remove everything from /lib/ext (but it might break NIO 2, especially JAR and ZIP support), the Java Plugin 2 and JavaFX. If you keep JavaFX, you have to respect the terms of the Oracle Binary Code License Agreement which are very annoying especially for commercial applications:
http://www.oracle.com/technetwork/java/javase/terms/license/index.html

from packr.

I'm experiencing this issue as well, using the latest Packr build on Maven and running on OS X 10.10.3

Oracle JRE 7u80 and unofficial OpenJDK builds 1.7.0u45 and 1.7.0u60 have all created prompts for installing Apple's Java 6 and X11.

Has anyone found a specific JRE version that plays nicely with OS X 10.10?

from packr.

@blair1618 Do you reproduce this bug when replacing the native launcher by a bash script? I'd like to determine whether it comes from Java itself or from the launcher. I can't upgrade the only Macbook Pro I can use (Macbook Pro 3.1).

from packr.

We need to modify the Info.plist and add a VMOptions section. Look i to
IDEAs Info.plist as an example.
On Apr 27, 2015 8:05 AM, "Julien Gouesse" [email protected] wrote:

@blair1618 https://github.com/blair1618 Do you reproduce this bug when
replacing the native launcher by a bash script? I'd like to determine
whether it comes from Java itself or from the launcher. I can't upgrade the
only Macbook Pro I can use (Macbook Pro 3.1).

—
Reply to this email directly or view it on GitHub
#29 (comment).

from packr.

@badlogic How would it help? https://developer.apple.com/library/mac/documentation/Java/Reference/Java_InfoplistRef/Articles/JavaDictionaryInfo.plistKeys.html

I assume that IDEA Info.plist relies on the system JDK, doesn't it?

Would this kind of change help a bit?
https://www.snip2code.com/Snippet/10374/Forcing-RubyMine-to-use-JDK-1-8-on-OSX-

from packr.

I'll try to fix this one tonight.
On Apr 27, 2015 11:59 AM, "Julien Gouesse" [email protected] wrote:

@badlogic https://github.com/badlogic How would it help?
https://developer.apple.com/library/mac/documentation/Java/Reference/Java_InfoplistRef/Articles/JavaDictionaryInfo.plistKeys.html

I assume that IDEA Info.plist relies on the system JDK, doesn't it?

Would this kind of change help a bit?

https://www.snip2code.com/Snippet/10374/Forcing-RubyMine-to-use-JDK-1-8-on-OSX-

—
Reply to this email directly or view it on GitHub
#29 (comment).

from packr.

@gouessej I have no trouble running a self-contained JRE if I specifically run my jar with the java executable from the JRE's bin folder. The trick seems to be in launching the JVM the right way...

from packr.

Right now I'm just testing the simple bash replacement for the launcher. I hope it should eliminate the problem. Unfortunately I do not have non-development machine nearby (without Java installed). Something like:

#!/usr/bin/env bash
cd "${0%/*}"
JAVA="jre/bin/java"
chmod +x "${JAVA}"
exec "${JAVA}" \
    -Xdock:icon="../Resources/AppIcon.icns" \
    -Xmx1G \
    -Dfile.encoding=UTF-8 \
    -jar "desktop.jar"

from packr.

I've tested this version with a simple script as launcher and Oracle JVM. Works perfectly without any promts for X11 or Java installation. Will stick to this solution. Parsing of config.json is not important for me in this case.

from packr.

@titovmaxim Does it work with OpenJDK 1.7 too? My own replacement in my Ant script produces a more robust bash script and includes the options contained in the JSON file. Is the "-Xdock:icon" option really necessary? I already obtain a similar effect without it, my icon appears in the dock:
http://sourceforge.net/projects/tuer/files/tuer/tuer-0.0.0/tuer-0.0.0-0.macosx.universal.tar.bz2/download

I use something very close to this script:
http://stackoverflow.com/a/246128

from packr.

@gouessej. Yes Xdock is really necessary. Otherwise the initially correct icon is changed by Java one. For me a single script file without json is even better. But a more universal script would be better for general use.

OpenJDK asks to install X11 as usually :( So I use an Oracle one.

from packr.

Of course I don't know your requirements, but please note that using such a shell script will partially break Steam compatibility. When I tried something similar, Steam overlays stopped working.

from packr.

I completely agree. The best way would be to fix the native launcher. Shell script just shows that it is possible. However I do not have enough experience to understand which line of the launcher requires Java installation. I neither have a non-developer machine (on which we can see the problem) to debug it step-by-step and find the problem part...

from packr.

@titovmaxim Thank you. What happens when you use the same version of Oracle Java with the native launcher? Do you get the same prompt to install X11? Which version of Oracle Java do you use? Maybe our problem has nothing to do with the native launcher.

from packr.

@gouessej. Just checked again now with version 7u80 form (https://edelivery.oracle.com/otn-pub/java/jdk/7u80-b15/jre-7u80-macosx-x64.tar.gz). Works just fine with script launcher.

from packr.

@titovmaxim If Oracle Java 1.7 update 80 works just fine with the script but not with the native launcher, then the latter is to blame.

X11 was necessary to build OpenJDK under Mac but I'm not sure that it is still the case now.

Edit.: It's still necessary: https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port#MacOSXPort-Minimumrequirementstorun

from packr.

Thanks for the tip about launching with a script, @titovmaxim! Do you put a copy of bash in the bundle and point CFBundleExecutable at that? Or does it work to point CFBundleExecutable directly at a .sh file?

I also agree that running from the native launcher is a better solution in the long run. I've stepped through launcher.cpp in Xcode and the Java install prompt occurs here https://github.com/libgdx/packr/blob/master/native/src/launcher.cpp#L105 where it calls the function pointer to JNI_CreateJavaVM.

Here's a crazy idea: What if OS X has a 'fake' libjvm loaded already? They could have symbols loaded for all of libjvm's functions that just point to this install prompt, as a way of handling programs that try to use Java when no JVM is present. If this is the case, then dlopen won't load symbols from the user-provided libjvm (since those symbols are already loaded) and JNI_CreateJavaVM will point to Apple's fake version, creating the install prompt instead of launching the JVM. Does this seem remotely possible? And if this is the case, what could we do to circumvent it?

from packr.

@blair1618, I just named a script file like the loader was and replace it (so CFBundleExecutable points at it). I did not put a copy of bash inside.

I also agree about the point when the native loader promts for the installation. Crazy idea (i'm far from Mac OS library management). What if we just rename 'libjvm' file of the bundled JRE to something crazy ('bunldled_libjvm') to avoid such collision? At least for test.

from packr.

Guys, i think your are going down the wrong path. As i said, modifying the
Info.plist file should be all that's needed.
On Apr 28, 2015 5:20 PM, "titovmaxim" [email protected] wrote:

@blair1618 https://github.com/blair1618, I just named a script file
like the loader was and replace it (so CFBundleExecutable points at it). I
did not put a copy of bash inside.

I also agree about the point when the native loader promts for the
installation. Crazy idea (i'm far from Mac OS library management). What if
we just rename 'libjvm' file of the bundled JRE to something crazy
('bunldled_libjvm') to avoid such collision? At least for test.

—
Reply to this email directly or view it on GitHub
#29 (comment).

from packr.

@badlogic Which options should be put into VMOptions to fix this bug? In my humble opinion, X11 shouldn't be required at runtime as I don't use AWT. I don't get why Oracle Java and OpenJDK would behave differently whereas they use exactly the same implementation of AWT.

from packr.

I think even if such option will work it could only fix (remove) Java
installation promt. Like the bash script does. The initial topic of
the issue - X11 - is solved by using Oracle JRE. The is nothing to do at
the launcher side.

However let us fix at least one problem. I'm curious which and how
VMOptions could help. In my understanding these options are read and used
by launcher, not by OS. So these options are used as config.json in our
case.

@badlogic, what was your idea? Which option should we use?

from packr.

I have found some articles about Java 6 installation popup dialog. Seems to be a bug, but there are several ways to overcome it. For example to use CFBundle API instead of dlopen. More details here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=411361

from packr.

In my humble opinion, setting CFBundleExecutable to a .sh file instead of bin/java and avoiding to use any option (-Xdock:icon?) requiring AWT should be enough even with OpenJDK.

@titovmaxim Thank you very much for investigating, this change set might be helpful:
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R3_9_maintenance&id=91dd10447c73ae7e45dc6d6bb4336f02f4e9ff4d

from packr.

@gouessej, @badlogic

I think I've found the solution (to avoid Java installation promt. The simplest solution is just to dlopen 'libjli.dylib' instead of 'libjvm.dylib' on Mac. No other changers required. This helps to avoid the Mac OS X bug according to http://stackoverflow.com/questions/14105575/eclipse-on-mac-10-8-installed-1-7-0-jre-jdk-but-eclipse-wont-launch#comment38546699_21766432)

So I just replace the line:

std::string jre = execDir + std::string("/jre/lib/server/libjvm.dylib");

with

std::string jre = execDir + std::string("/jre/lib/jli/libjli.dylib");

And it works now. I think this solution is better than a script file since the third-party loaders/packers/protectors/ads can work then.

from packr.

@titovmaxim Just tried your suggestion and it works flawlessly. I'll be happy to get rid of the script hack I've been using :)

from packr.

@badlogic Was it what you meant about info.plist? http://stackoverflow.com/a/19605234 joeferner/node-java#90 (comment)

from packr.

I've seen this already. But these things are about modification of system files (e.g. under /Library/Java/JavaVirtualMachines/...) and not about our own app .plist file. So I do not know how to use them in our case.

Here I'm talking solely about using a bundled jre, not a system one.

from packr.

@titovmaxim It's possible to modify the file info.plist that we provide, this is what I suggest:
https://github.com/libgdx/packr/blob/master/src/main/resources/Info.plist

from packr.

@gouessej. Beg a pardon. I understand the idea of fixing the app's .plist. But I could not understand which exact lines should be added to fix the problem. All my tryings with .plist modification have failed.

Could you please post the entire .plist which solves the problem? I really want to test is ASAP.

from packr.

@titovmaxim It should be enough and you don't have to modify the executable:

<key>JVMCapabilities</key>
            <array>
                    <string>CommandLine</string>
                    <string>JNI</string>
                    <string>BundledApp</string>
            </array>

from packr.

@gouessej. I've already tried this (before modifying the source code). Does not work. I've also tried to put this lines inside JavaVM dictionary. Does not work either. Actually just no effect.

I think it is something wrong from my side. Could you post the ENTIRE .plist which works as an example?

from packr.

@titovmaxim as a workaround you can use an older JRE. This one worked for me: https://bitbucket.org/alexkasko/openjdk-unofficial-builds/downloads/openjdk-1.7.0-u45-unofficial-icedtea-2.4.3-macosx-x86_64-image.zip

from packr.

This issue drove me crazy! Had to rollback to u45 now - I hope this gets fixed soon with a newer unofficial openjdk release. u80 seems broken then. Also the fix by @badlogic doesn't seem to help with u80, since it still tries to lookup /etc/X11

from packr.