Repository navigation
Using JPL with Java 8 on Mac OS X issues #2
Description
Activity
As it seems the jpl build is now broken on my machine and it merely includes the old version, this seems a good time to look into this. The first question is which version of Java one is supposed to install how on MacOS? Somehow, my El Captain as a "Java for OS X 2015-001" disk on the desktop. Trying to install it results in some warnings that this is a legacy old version and one should download Java from java.com. Is that what I should be doing for building JPL? Is that what people who actually use Java on MacOS do?
If I get it build, I might be able to add code to jpl.pl that automates the step above to fix the link target for libjpl.dylib.
On 07/12/2015 16:30, Jan Wielemaker wrote:
As it seems the jpl build is now broken on my machine and it merely
includes the old version, this seems a good time to look into this.
The first question is which version of Java one is supposed to install
how on MacOS? Somehow, my El Captain as a "Java for OS X 2015-001"
disk on the desktop. Trying to install it results in some warnings
that this is a legacy old version and one should download Java from
java.com. Is that what I should be doing for building JPL?Of "Java for OS X 2015-001", Apple say:
This package is exclusively intended for support of legacy software
and installs the same deprecated version of Java 6 included in the
014-001 and 2013-005 releases.If you need Java, download the latest version of Java for OS X
directly from Oracle https://www.java.comOracle's is kinda the reference implementation.
For now, JPL should work fine with Java 6.
Is that what people who actually use Java on MacOS do?
Yes if they take Apple's advice ;-) but I guess some will install the
"deprecated version of Java 6" because they (think they) need it, or
because it's easier, then not install any newer version.If I get it build, I might be able to add code to jpl.pl that
automates the step above to fix the link target for libjpl.dylib.Are you aiming to (be able to) build a binary SWI Prolog for Mac OS X
x64 which happily links to either legacy Java 6 or recent Oracle/Sun
Java 8?I have received an early Xmas prezzie of a 7 yr old MacBook Pro on
which I have a fresh El Capitan OS X - can I help?Paul Singleton
I pushed some stuff that may hopefully resolve this. Building on the Mac now finds and uses the Oracle Java. There is a library for the Mac jpl_config.pl that provides
jpl_config_dylib/0that updateslibjpl.dylib. The check_installation/0 linked help page is updated and if JPL fails to load it points atjpl_config_dylib/0if you are using a Mac.I hope that is enough ...
After git pull, deleting my installed version, and rebuilding, I get:
% Loading library(jpl) ......................... FAILED Warning: Cannot load required shared library Warning: See http://www.swi-prolog.org/build/issues/jpl.htmlCalling the
jpl_config_dylib/0indeed fixes the problem for all subsequent runs.Thanks for testing. Should we consider this `good enough' or is there an easy way to make this better? Note that we might not be able to write to libjpl.dylib, there may be no Java at all, etc. If you think this is good enough, please close.
Any reason to not automate calling the
jpl_config_dylib/0predicate when building on macOS?I'm still encountering this with Java 9. However, it looks like it may in fact be a regression in the JDK itself, as apparently earlier Java 8 JDKs would trigger the "No Java runtime present" dialog when started via JNI (JDK-7131356).
That seems unrelated. This topic was about finding the Java .dylibs. As the path to find them must be compiled into libjpl.dylib binary distributions need to go through a process of finding the right JDK and updating libjpl.dylib.
There's still an issue with
jpl_config_dylib/0not checking the Java 9libjvm.dyliblocation, but I don't know enough Prolog to make it check both locations. (Instead I manually edited the file to only check the Java 9 location.) However it still fails with the "No Java runtime present, requesting install." terminal message. By usingDYLD_PRINT_LIBRARIESI can verify it is loading the right JVM, and then blowing up anyway.As I understand it, Java9 dropped
jrefrom the path? I can fix that injpl_config_dylib/0. Otherwise, I don't know.Correct. As far as I can tell JPL works under Java 9, but so far I've only been able to use it from the Java side - trying to use JPL within SWI-Prolog directly causes the "No Java runtime present" message.
Update
jpl_config_dylib/0. That, as I understand, won't fix the problem. I have no clue about that though.I'm fairly certain at this point that the problem is within the JDK itself. I just realized that the majority of the examples use Swing, and when I run
examples/prolog/jpl_versions_demo.pl, everything runs just fine. So as of now, JPL works under Java 9, as long as you don't try and run something that uses Swing. (And possibly other parts of the JDK.) This is definitely not a JPL issue, but it's something people should probably be aware of.Might be an Apple Java issue. There have been problems with swing this in the past too. Shall we close this?
As long as you don't touch AWT, this appears to work. The latest version also solves the problem I had where Homebrew wasn't building JPL with the
--with-jplflag: it was attempting it, but it would fail, and then the SWI-Prolog build would just skip JPL.As far as I can tell, everything now "works" with JPL and Java 9 under macOS, minus an internal macOS JDK bug that can be triggered if you call any code that uses AWT (which includes Swing):
$ java --version java 9.0.1 Java(TM) SE Runtime Environment (build 9.0.1+11) Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode) $ swipl --version SWI-Prolog version 7.6.3 for x86_64-darwin16.7.0 $ swipl Welcome to SWI-Prolog (threaded, 64 bits, version 7.6.3) SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software. Please run ?- license. for legal details. For online help and background, visit http://www.swi-prolog.org For built-in help, use ?- help(Topic). or ?- apropos(Word). ?- use_module(library(jpl)). true. ?- jpl_new('java.awt.Frame', ['Hello AWT'], F). No Java runtime present, requesting install. $However, if you avoid AWT, it works fine:
?- use_module(library(jpl)). true. ?- jpl_new('java.io.File', ['demo.pl'], F), jpl_call(F, toPath, [], P), jpl_call('java.nio.charset.Charset', forName, ['UTF-8'], Utf), jpl_call('java.nio.file.Files', readAllLines, [P,Utf], Ls), jpl_call(Ls, get, [ 0 ], L). F = <jref>(0x7f915869c810), P = <jref>(0x7f915869c818), Utf = <jref>(0x7f91584c3358), Ls = <jref>(0x7f915869c820), L = ':- asserta(file_search_path(foreign, \'.\')).'.Reacted by Sebastian SardinaIs this true Jan? My students taking the course now (Sept 2018) said that:
"As the homebrew version does not come with the JPL library (an issue on the homebrew github as been opened about this), the second step is therefore to buid the library from source. Alternatively, you can download the already compiled libjpl.dylib and copy it in:"
I am asking because your post is from Dec 2017
I do not have a Mac but they (students) devised this plan to make it work:
https://github.com/ssardina-research/packages-jpl/wiki/JPL-under-Mac-OS
MacPorts is an alternative to Homebrew for installation on macOS. Did you tried it to check if it also have an issue with JPL? I'm the maintainer of the portfile. But, as I use the git version, there have been quite some time since I last used the MacPorts install.
Is this true Jan? My students taking the course now (Sept 2018) said that:
It is true that you can just graph a libjpl.dylib, jpl.pl and jpl.jar from some version and dump it into another with quite a wide variety of versions as both the C API of Prolog and Java are pretty stable. As your student describes, notably on the Mac you have to do some fiddling with the link paths though. On Windows, just make sure the dll and exe are all in the same dir. On Linux it will typically also wok out of the box.
On Mac OS X there is a command,
java_home, that returns the path for the user's enabled and preferred JVMs in the Java Preferences application. This command is Apple's advised way of defining the JAVA_HOME environment variable. On my system I get:The user can add to its
~/.profilefile (or equivalent) the line:SWI-Prolog build script picks the value of the
JAVA_HOMEenvironment variable but there's a problem. The generatedlibjpl.dyliblooks into the wrong place as you can check by typing:This can be corrected by typing:
Still, if you try a JPL call (e.g.
jpl:jpl_call/4), your SWI-Prolog process will end with an error that "No Java runtime present, requesting install." and a system prompt to install Java 6! If you sigh, throw your hands in the air, surrender, and install Java 6 then JPL will happily work using Java 8. I suspect some lingering linking issue that the fix above is not enough to correct. Is possible that the problem is in the following line in the JPL Makefile:But I have no idea how to fix and still generate a
.dylib. Any hints?