Java 7 for Mac OSX

[Gregg Wonderly]

On 2/20/2012 5:19 PM, Johannes Schindelin wrote:
> Hi Mike,
>
> On Mon, 20 Feb 2012, Mike Swingler wrote:
>
>> On Feb 20, 2012, at 11:08 AM, Johannes Schindelin wrote:
>>
>>> On Mon, 20 Feb 2012, Mike Swingler wrote:
>>>
>>>> On Feb 20, 2012, at 3:29 AM, Henri Gomez wrote:
>>>>
>>>>>> One question:
>>>>>>
>>>>>> By adding 32-bit support, do you mean the binary will be runnable
>>>>>> on a 32-bit machine? Or, the sources can be built on a 32-bit
>>>>>> machine?
>>>>> To me 32 bit support means you could use -d32 flag to have JVM works
>>>>> in a 32bit land, so safe memory in many cases.
>>>> Supporting a second architecture effectively doubles the testing
>>>> overhead, and basically doubles the budget you need to spend on QA.
>>>> What is the benefit to Oracle Corp for supporting a legacy
>>>> architecture?
>>>>
>>>> This is a serious question,
>>> Thanks for keeping the discussion civilized :-)
>>>
>>> In my line of work, it is extremely important that Java -- especially
>>> on MacOSX -- continues to work in 32-bit mode. The reason is that we
>>> frequently need to connect to microscope vendors' native libraries to
>>> control their hardware, and for some reason most of these vendors are
>>> unwilling or unable to provide 64-bit libraries.
>>>
>>> To a lesser extent, the increased memory-requirements of 64-bit Java
>>> would hurt, too; I suspect a few of the Java components we use to
>>> allocate, and forget about, metric tons of objects per second.
>>>
>>> Without having Java/32-bit working on MacOSX, my colleagues all over
>>> the planet and me would be stuck in a very uncomfortable situation of
>>> having to use outdated and unmaintained Java.
>> Since you'll have to bundle the JRE in your app anyway, would it be
>> sufficient to simply compile the JRE for 32-bit from the OpenJDK
>> sources? Is there a reason you need Oracle's proprietary binary?
> There are a range of good reasons against your suggestion:
>
> 1) first and foremost, I disagree passionately that every Java application
> should bring their own JRE. If you have 50 Java applications you use
> regularly, it would be a waste of resources (also time: you'd have to
> update everyone of them should a security flaw be fixed).
>
> 2) I already maintain 3 software packages, so I fear I already have enough
> on my plate. I am certainly not the only Java programmer who shares that
> problem.
>
> 3) Even if I were to accept the honor to maintain my own JRE, there is no
> way in hell I could do the quality assurance. Time is one problem. An
> worse problem is -- as you know all too well -- the JCK.
>
> 4) By taking over Java from Sun, Oracle is the natural maintainer of it,
> including the JRE/JDK.
>
> 5) I am not even sure whether I'd be entitled to call that thing Java.
> Trademark fun.
>
> 6) If I were to ship my self-compiled JRE, users might very well ask why I
> did that, and not exactly trust that unofficial JRE. Quite frankly, as a
> user *I* would not. Would you?
>
> If you tempt me, I am sure I could complete the dozen.
>
> By the way, I did not get the impression that you even acknowledged my
> arguments as to the need for 32-bit support, let alone your agreement.  It
> would be a sad waste of my time if you indeed still thought it would be a
> good idea from the point of view of all the users and developers of Java
> software to skip support of something that was clearly supported only a
> couple of days ago, seemlingly with little effort. Do you want to tell me
> now that the resources it took were an undue burden on Apple and/or
> Oracle?
>
> Slightly worried,
> Johannes
>
> P.S.: I am now really slightly worried of the direction this whole
> Java/MacOSX thing takes. It already started when you explained why the
> MacOSX port now requires Snow Leopard (and probably soon even Mountain
> Lion, when Java 6 clearly worked with Leopard's API versions) -- leaving
> me with the impression that the burden with future MacOSX Java is
> unilaterally and clearly shifted from the developers to the users,
> something I would not allow developers working for me to do. I hope you
> understand that these concerns are serious and valid, and that you are not
> happy to just brush them aside.
>
Having the appropriate JRE installed for users to run my Java software, is also 
a big deal for me.   If we really do need to ship the "appropriate" JRE with 
every application, then it seems like we need to turn the whole compilation 
process upside down, and remove the JIT, and just have a complete native 
application built, instead of a jar.   All of the dynamic binding properties of 
Java, allow me, as a developer, to let you guys, the providers of Java, fix your 
issues, independent of me.

Mike, can you provide some kind of a "position" on this issue, that is framed 
around the ideas of "open source"?  If I have to "build" with "your release" in 
order to create "my release", that provides a huge "problem" for me, to 
distribute my Java application when I may not have a "place" to build for a 
particular OS that my users want to use the application on.

The portability and dynamic binding properties of Java are key to my desire to 
want to continue to use it.  If everyone really thinks that the JRE/JDK can not 
be separate from the applications that use it, then there is no longer any 
advantage to using Java.

Perhaps that's the intent?  Are we just hammering nails in the coffin now?

Gregg Wonderly