Java 7 for Mac OSX

Johannes Schindelin Johannes.Schindelin at
Mon Feb 20 15:19:13 PST 2012

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

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

Slightly worried,

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.

More information about the macosx-port-dev mailing list