Apologies in advance, I felt necessary to send up some smoke signals on
this 32 bit feature decision.
I am grateful for this hard working and diligent Java community and for
Java itself, I'm a staunch Java supporter and long time Java programmer. If
one considers marketing and product placement of Java, the removal of 32
bit Java for Mac OSX creates a perceived limitation of a platform that is
supposed to be write once, run anywhere, and a real limitation for
developers who rely on the Java platform to integrate with libraries that
are used in other applications. The removal of a 32 bit option seems to be
counter culture to the Java community and "write once, run anywhere" brand.
Java 1.9 is the only version that works properly for us on Mac OSX at the
moment, the migration of 32 bit Java to legacy has been a sales killer for
our little company, so these types of decisions are never without any
consequences. Instead of designing killer apps Mac OSX using Java, I have
to write installer code and spend time helping upset customers navigate
through these moving goal posts.
Whew!! .. OK rant complete the smoke is starting to clear and we will make
it through this ;-)
PJ
On Mon, Jan 12, 2015 at 8:40 PM, David Holmes <david.hol...@oracle.com>
wrote:
> On 13/01/2015 5:20 AM, Alex Strange wrote:
>
>>
>> On Jan 12, 2015, at 3:26 AM, David Holmes <david.hol...@oracle.com>
>>> wrote:
>>>
>>> cc'ing macosx-port-dev and hotspot-dev
>>>
>>> On 12/01/2015 8:41 PM, Erik Joelsson wrote:
>>>
>>>>
>>>> On 2015-01-12 00:02, David Holmes wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> On 10/01/2015 2:00 AM, David DeHaven wrote:
>>>>>
>>>>>>
>>>>>> We have this nice little comment in common/autoconf/jdk-options.m4:
>>>>>> # On Macosx universal binaries are produced, but they only contain
>>>>>> # 64 bit intel. This invalidates control of which jvms are built
>>>>>> # from configure, but only server is valid anyway. Fix this
>>>>>> # when hotspot makefiles are rewritten.
>>>>>> if test "x$MACOSX_UNIVERSAL" = xtrue; then
>>>>>> HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>>>>>> fi
>>>>>>
>>>>>>
>>>>>> So.. I turned it off:
>>>>>> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
>>>>>> # MACOSX_UNIVERSAL="true"
>>>>>> MACOSX_UNIVERSAL="false"
>>>>>> fi
>>>>>>
>>>>>> And in hotspot/make/bsd/makefiles/defs.make:
>>>>>> # Universal build settings
>>>>>> ifeq ($(OS_VENDOR), Darwin)
>>>>>> # Build universal binaries by default on Mac OS X
>>>>>> # MACOSX_UNIVERSAL = true
>>>>>> MACOSX_UNIVERSAL = false
>>>>>> ifneq ($(ALT_MACOSX_UNIVERSAL),)
>>>>>>
>>>>>> hotspot still seems to build happily (I'm kicking off tests now). Is
>>>>>> there are particular reason this hasn't been done yet? I'd like to
>>>>>> know before I pursue this as a means of eliminating our dependency on
>>>>>> lipo which is causing an inordinate amount of grief when trying to
>>>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some
>>>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't
>>>>>> help later in some "other" build target that ends up using '-arch
>>>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc
>>>>>> to do the fattening itself and so it fails even though I've gone to
>>>>>> the effort of working around the broken lipo (and it isn't necessary
>>>>>> anyways because it doesn't even build the i386 binaries even though
>>>>>> it's supposed to be "universal").
>>>>>>
>>>>>
>>>>> The hotspot makefiles still haven't been rewritten (though Magnus had
>>>>> been working on it).
>>>>>
>>>>> Also I was under the impression that we used the universal stuff
>>>>> because we had to deliver in a particular way on OSX. But I don't know
>>>>> the details and the people who dealt with the original OSX port effort
>>>>> are no longer here.
>>>>>
>>>>> I don't know why Hotspot is packaged as a universal binary. In the
>>>> jdk,
>>>> only libJObjC was built as a universal binary and that lib was removed
>>>> before JDK 8 shipped. What part of Macosx would need to interact
>>>> directly with libjvm.dylib in a way that required a (fake) universal
>>>> format, but no other libs in the jdk? I would say go ahead and change
>>>> it.
>>>>
>>>
>>> In the spirit of "never take down a fence until you know why it was put
>>> up in the first place" I've cc'd macosx-port-dev to see if there is anyone
>>> around who recalls why hotspot is using the universal binary feature.
>>>
>>> David H.
>>> -------
>>>
>>
>> I did the original universal binary work for hotspot when bringing up
>> macosx-port.
>>
>> At the time we were building and testing JDK 7 as universal (i386+x86-64)
>> since e.g. some apps had JNI code that was only built 32-bit.
>> The other jdk components didn't need any makefile work, because the
>> compiler can build them universal by itself, but hotspot autogenerates a
>> lot of arch-specific code and it was easier to build it twice and glue them
>> together in the makefile.
>>
>> As long as Java is only been shipped 64-bit these days, I personally
>> don't see a reason to keep it.
>>
>
> Thanks for the info Alex. Based on that and Dan's response this proposed
> change seems good to go ahead.
>
> David H.
>
>
>
>> /Erik
>>>
>>>>
>>>> David H.
>>>>>
>>>>>
>>>>>> Quite frankly I'd rather just remove all the universal binary stuff
>>>>>> from hotspot, but I'm trying my best to minimize the changes there...
>>>>>> the "other" problem I can handle easily.
>>>>>>
>>>>>> -DrD-
>>>>>>
>>>>>>
>>>>
>>
--
Senior Software Developer / IT Administrator
Work: (416) 466-9283
Fax : (866) 855-2605
<http://www.wavedna.com/>
<https://www.facebook.com/waveDNA> <http://www.twitter.com/wavedna>
<http://www.youtube.com/wavedna> <http://www.soundcloud.com/wavedna>
<https://plus.google.com/+Wavedna/posts> <http://instagram.com/wavedna>
<http://www.linkedin.com/company/wavedna>
