tada
Support Java 1.6 on Mac
Java 1.6 is only provided for Mac through Apple. When configuring pljava to use the provided libjvm.dylib, an architecture mismatch is reported. The library is 32-bit, while a 64-bit version is required. 64-bit versions of libjvm for Java 1.6 are not available for Mac.
Hmm. From what I can see, Apple does provide 1.6 for Mac, but strongly deprecated. It might help to know more about your situation:
Will you be using a 32-bit build of PostgreSQL?
Is there something in your Java codebase that absolutely, positively, cannot run in 1.7 or 1.8?
In case it helps, that only has to mean your PL/Java codebase. If there is other software on the Mac in question that cannot be migrated from 1.6, you may be able (check me, but I would hope) to install 1.7 or 1.8 from Oracle additionally, or in a custom location, and point PL/Java at that, without disturbing other uses of Java that require 1.6.
The early commits on PL/Java post-1.5.x have already removed Java 1.6 support and made 1.7 the minimum. PL/Java 1.5.x does purport to support Java 1.6 ... but that is quite old in 2017, and whether 'support' also means 'support on a platform where it can only be had in a deprecated, 32-bit build' is a delicate question....
I am trying to move an Adempiere May Day release (http://www.adempiere.com/Release_320) installation currently running on Fedora Core 1 to a modern Mac. That release requires Java 1.6, so I am using the legacy one provided by Apple. It is supposed to be 64-bit, but the libjvm.dylib library is only 32-bit. PostgreSQL is the latest installation 9.6.2 (assumably 64-bit). It required using the branch of pljava that supports 9.6. Pljava built fine, and all other components run fine as well, with the only remaining issue being installing pljava into the DB. When trying to configure with the version of libjvm I have, it complains about it being only 32-bit. I don't know why that library only has a 32-bit version. Other libraries in that installation are 64-bit, and Java 1.6 is supposed to require 64-bit as a minimum as I understand it.
I recall getting misleading messages about requiring Java 1.6 on a Mac unless a proper Java is installed. It's unlikely that a software should actually require that particular version and not accept more modern ones. Especially since later releases are backward compatible.
- thomas
On Sat, Apr 15, 2017 at 6:18 AM, gyltefors [email protected] wrote:
I am trying to move an Adempiere May Day release ( http://www.adempiere.com/Release_320) installation currently running on Fedora Core 1 to a modern Mac. That release requires Java 1.6, so I am using the legacy one provided by Apple. It is supposed to be 64-bit, but the libjvm.dylib library is only 32-bit. PostgreSQL is the latest installation 9.6.2 (assumably 64-bit). It required using the branch of pljava that supports 9.6. Pljava built fine, and all other components run fine as well, with the only remaining issue being installing pljava into the DB. When trying to configure with the version of libjvm I have, it complains about it being only 32-bit. I don't know why that library only has a 32-bit version. Other libraries in that installation are 64-bit, and Java 1.6 is supposed to require 64-bit as a minimum as I understand it.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tada/pljava/issues/118#issuecomment-294271075, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMyVxNfXz09HfYkIpgLiMKWKkhqhp89ks5rwEUhgaJpZM4M9epg .
I looked briefly at the adempiere wiki, but I did not find a requirements section insisting on Java 1.6. That does not mean it isn't there, only that I didn't find it right away.
I do remember, as Thomas points out, that OS X could put up misleading dialogs about needing to download 1.6. There are some notes in the PL/Java Building on Mac OS X page about that, culminating in the recommendation to point to libjli.dylib rather than libjvm.dylib (which entails using Java 1.7 or 1.8, as 1.6 doesn't have libjli). Have you tried that? Is it absolutely certain that ADempiere requires 1.6?
@gyltefors have you had a chance to try 1.7 or 1.8 and pointing to libjli? Or, have you confirmed that ADempiere absolutely requires 1.6 (and requires it specifically for PL/Java procedures, not just for other parts of ADempiere that do not run in the database; those will always be running in a different JVM than the PL/Java code)? Have you found that documented somewhere?
Regards, -Chap
Adempiere complains about the Java version during installation if it is not 1.6, as discussed here:
https://sourceforge.net/p/adempiere/discussion/610547/thread/0dda9a4d/
I did some testing using 1.7/libjli for pljava, but didn't get that to work. If it would be safe to mix versions, I could try that again, and see what went wrong.
I think it would not hurt to explore getting a nice Oracle 1.8 JDK on there in addition to the Apple 1.6, if not in place of it. (At the moment, I do not remember if the Oracle installer made it hard to install 1.8 without clobbering earlier versions. There is certainly nothing in principle difficult about having more than one Java version installed, unless the Oracle installer for Mac somehow goes out of its way to object.)
Assuming that goes well, you could have a Mac where you can run a 1.6 or 1.8 Java VM just by choosing which command you run, and then you could go about installing PL/Java pointed at the new one. (It does work, unless something broke recently; 1.5.0 was definitely tested on Macs with 1.8.)
I'll assume you can then have PL/Java working in PostgreSQL and using the 1.8 JVM, and running the usual PL/Java examples. Then, for ADempiere....
I see where the message you referred to comes from, an explicit test around lines 86–104 in an installer class. They are only testing for 1.5.0 or 1.6.0, and my first guess is that it's not because they have any particular reason to believe their code won't run in 1.7 or 1.8. My first guess is because that class dates from 2007 when there wouldn't even be a Java 1.7 for five more years. :)
So (you probably knew this already) you're using a really old version of that software here. You've probably already looked at the more recent, apparently actively developed IDempiere? It contains a similar class that makes a similar test, but in its more current version, it is testing for Java 1.7 or 1.8.
If you are stuck with that really old ADempiere release because of difficulty upgrading, I would not be at all surprised if you could just compile a version of that class with the silly test removed, replace that .class file in the installer jar, and have it all still work under a newer JVM. (Of course if that breaks anything, you never heard that from me.) Or, you could end up with the front/middle ends of the software running in 1.6, and the PL/Java bits in 1.8; I bet there is no extra silly test to stop you from doing that, and there's no inherent problem with it (besides taste).