Dropping 32-bit support (was Branches)

[Mike Swingler]

It is also perfectly plausible to build 32/64 Universal, and then use "lipo" on built Mach-o products to strip out the architecture you don't need/want/support in a post-build step.

I think it's also a good idea to brainstorm/document some ways to strip down a JRE for developers who are bundling the runtime inside their app. Shipping only the JRE (instead the JDK) and thinning the Mach-o binaries is a good start, but are there tools or well known procedures for trimming rt.jar? Obviously this gets easier once Jigsaw becomes available, but before then many developers will want to deploy on OpenJDK 7.

Regards,
Mike Swingler
Apple Inc.

On Feb 27, 2012, at 3:25 PM, Paul Hohensee wrote:

> Imo, it's very unlikely that 64-bit build footprint will ever be an issue, and
> 32-bit build footprint would be an issue on memory-limited devices, of
> which there are none that run OSX.  The real utility of 32-bit is compatibility.
> 
> I'd just go with universal binaries and not bother with 32/64 options.
> 
> I don't speak for Oracle, of course.  Personal opinion only. :)
> 
> Paul
> 
> On 2/27/12 6:13 PM, John Yeary wrote:
>> Personally I like the idea of a default with "Universal" binaries, and the options for 32/64 for the reasons you mentioned. I think it is important to be inclusive vs. exclusive.
>> 
>> John
>> 
>> Sent from my iPhone
>> 
>> On Feb 27, 2012, at 6:09 PM, Artem Ananiev<artem.ananiev at oracle.com>  wrote:
>> 
>>> Alternatively, we can completely ignore ARCH_DATA_MODEL on Mac and always build universal binaries. As far as I remember, we did exactly this when Mac OS X Port was a standalone OpenJDK project. Of course, in this case we'll lose an ability to build 32-bit and 64-bit only builds, which may be useful in cases when JDK/JRE size is important.
>>> 
>>> Thanks,
>>> 
>>> Artem
>>> 
>>> On 2/22/2012 1:51 AM, Michael McMahon wrote:
>>>> Jim,
>>>> 
>>>> If the Hotspot openjdk build is changed to produce both 32/64 bit binaries
>>>> then the JDK build can be changed to do the same. The only reason why
>>>> 32 bit support was removed in the JDK libs was because it wasn't
>>>> available in Hotspot
>>>> at the time. This seemed to align with Oracle's (and Apple's)
>>>> views/plans at the time also.
>>>> 
>>>> However, it's clear there is a demand for at least the Openjdk source to
>>>> be buildable for
>>>> 32/64 bit. How about if ARCH_DATA_MODEL=universal then we build both on
>>>> Mac OS X?
>>>> 
>>>> We can do this in jdk7u-dev (post 7u4) and in jdk8. I don't see any need
>>>> to get it into
>>>> 7u4 because Oracle won't be supporting it in our JDK anyway.
>>>> 
>>>> - Michael
>>>> 
>>>> On 21/02/12 22:45, James Melvin wrote:
>>>>> One caveat...
>>>>> 
>>>>> For the JVM, we've preserved 32/64-bit universal builds. Currently, the
>>>>> JVM universal build only includes 64-bit support. Additionally including
>>>>> 32-bit requires 3 Makefile uncomments. However, there may likely be
>>>>> additional work on the JDK side to fully support the same.
>>>>> 
>>>>> - Jim
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2/21/12 5:21 PM, Mike Swingler wrote:
>>>>>> On Feb 21, 2012, at 12:18 AM, Henri Gomez wrote:
>>>>>> 
>>>>>>> Another question for you guys about OSX.
>>>>>>> 
>>>>>>> 32 bits support as been removed some weeks ago without further notice
>>>>>>> on OSX version.
>>>>>>> 
>>>>>>> * Why such decision ?
>>>>>>> 
>>>>>>> * How could we bring back 32 bits support, especially -d32 support ?
>>>>>>> 
>>>>>>> * Where is the correct location to enter a bug report on this
>>>>>>> (bugreport.sun.com ?)
>>>>>> Dalibor&  Mark,
>>>>>> 
>>>>>> Henri raises some good points here, since the ability to build
>>>>>> OpenJDK 32/64 Universal was lost in the merge from the macosx-port
>>>>>> repository to the jdk7u-osx repository with no public discussion.
>>>>>> 
>>>>>> I thought the ability to build 32/64 Universal was preserved, and
>>>>>> Oracle was simply going to support 64-bit only in it's proprietary
>>>>>> builds.
>>>>>> 
>>>>>> What is the best path to fixing this?
>>>>>> 
>>>>>> Mike Swingler
>>>>>> Apple Inc.
>>>>>>