No, Oracle Java only works on OS X 10.7 "Lion" and later. Users of 10.6
> lot since years. If I've encountered a problem it was due to my coding
As I said, we have seen many JVM crashes with Java 6. These are bugs in
8 (as far as I know). So there is little disadvantage to users, with major
> Hi all,
>
> I'd like to interject with a bit of my anecdotal understanding because I
> think the problems with newer Java's on OS X are being unfairly misplaced
> on Oracle. My understanding is that Apple originally insisted on keeping
> some of the JRE implementation related to OS X graphics closed source. This
> would include drawing images, 3D graphics, and windows that IJ uses
> extensively. So, they told Oracle they would take Oracle's reference
> implementation, sprinkle in the OS X-specific graphical bits so that things
> were optimized [probably using undocumented APIs], and distribute it
> themselves. In recent versions of OS X, for whatever reason, they no longer
> want to play nice with Oracle and have left Java-dependent people at the
> mercy of Oracle's poorer, more general, implementations. And frankly, from
> Apple's POV that may make sense because the only graphically-intense Java
> application I use is ImageJ, and I imagine most Apple users use even less
> than I/us.
>
> Without changing Apple's practices, the only practical long-term way
> forward in my view is to jump to the newer Oracle version and vigilantly
> report JRE bugs and hope they get fixed ASAP. It's not very satisfying
> though -- fortunately, unlike Windows PCs, there should be a relatively
> limited number of Apple hardware/software platforms to accommodate.
>
> All that said, I'm still on OS X 10.6.8 and JDK 1.6.0_65 and only plan on
> upgrading after a lot of kicking and screaming. :)
>
> P.S.: The only compelling reason I have heard to force an upgrade to the
> newer Java versions is the gaping security holes in Java 6, but I _think_
> they primarily would affect Java browser plugins or people that already had
> physical access to our computers.
>
> Best regards,
>
> John
>
> Le 20 juil. 2015 à 17:32, Herbie a écrit :
>
> > Dear Curtis,
> >
> > thanks for clarifying at least part of the previously rather foggy area.
> > In the first place I mean Apple's statement which, taking into account
> previous abrupt and severe changes, doesn't surprise much and must even be
> called comparably moderate.
> >
> > "[...] unfortunate reality of small development teams."
> > I'm sure you aren't speaking of the small development team at Oracle.
> > Why can't a large and terribly wealthy company provide ripe bananas?
> Maybe they aren't interested in Java any more and green bananas are an
> elegant way out of the situation?
> > No, because Java is still one of the most used languages -- but who
> cares...
> >
> > Metaphorically addressed to Oracle (because I'm not even a small
> development team):
> > We all know that image processing most often means big data, at least
> for personal computers, and I'm really shocked that one of the finest
> software packages that is available for free is to suffer from people who
> evidently don't think of the user's needs but of what they think is
> innovation. Well, nothing against fixing bugs, but that won't affect
> execution speed.
> >
> > I've no experience with Java 7.
> >
> > _Are there any speed penalties compared to Java 6?_
> >
> > As far as I understand the situation with Apple and Java support,
> Oracle's Java should run on Macs independent of Apple's OS version.
> > So Java 7 looks appealing -- does it?
> >
> > Curtis, is your and the team's work on ImageJ-2 still, at least
> partially, funded by national agencies?
> > If yes, this could be a lever to be pulled -- no?
> >
> > I can't remember a single ImageJ-1 crash under Java 6 and I use it a lot
> since years. If I've encountered a problem it was due to my coding but
> perhaps my projects deal with toy problems.
> >
> > Anyhow, if Java 8 is unripe and if there is realistic hope that it will
> mature, why not stick with Java 7 for the time being, even if it's going to
> be a long time.
> > Perhaps Oracle is unhappy that nobody uses Java 8 or Oracle is unhappy
> that nobody does the debugging for them -- or both.
> >
> > Who needs Java 8? Oracle?
> >
> > Enough speculations for tonight.
> >
> > Best
> >
> > Herbie
> >
> > :::::::::::::::::::::::::::::::::::::::::::
> > Am 20.07.15 um 22:09 schrieb Curtis Rueden:
> >> Hi Herbie,
> >>
> >>> ...you agree that it is ok that software is comparable to green
> >>> bananas and that the user is responsible for debugging.
> >>> Isn't this a bit strange?
> >>
> >> To an extent, yes. I wouldn't call it strange, so much as an unfortunate
> >> reality of small development teams.
> >>
> >>> Does that mean that you can't run Java 6 under the latest Mac OS? I
> >>> don't think that this holds true.
> >>
> >>> From Apple's release notes [1]: "OS X El Capitan is the last major
> release
> >> of OS X that will support the previously deprecated Java 6 runtime and
> >> tools provided by Apple. Applications or features that depend upon Java
> 6
> >> may not function properly or will not launch when Java 6 is removed.
> >> Developers should move to a newer version of Java as provided by
> Oracle."
> >>
> >>> What's wrong with running Java 6 on an up-to-date personal computer,
> >>> especially if code, such as ImageJ, runs much smoother and faster?
> >>
> >> Nothing at all. I would encourage users to use whatever version of Java
> >> best fits their needs. That said, Java 7 fixes many, many bugs that were
> >> never backported to Java 6. Our group's personal experience is that
> ImageJ
> >> crashes under Java 6 much more often than with Java 7—e.g., when
> performing
> >> image stitching operations taking many hours.
> >>
> >> But if your workflows in ImageJ work well in Java 6, then by all means
> >> stick with it as long as you can.
> >>
> >> Regards,
> >> Curtis
> >>
> >> [1]
> >>
>
https://developer.apple.com/library/prerelease/mac/releasenotes/General/rn-osx-10.11/> >>
> >> On Mon, Jul 20, 2015 at 2:52 PM, Herbie <
[hidden email]> wrote:
> >>
> >>> Good day Curtis,
> >>>
> >>> by stating...
> >>>
> >>> [...] Java 8 still has some problems, the only way they will
> realistically
> >>> be addressed is to do the migration and deal with the fallout."
> >>>
> >>> ...you agree that it is ok that software is comparable to green bananas
> >>> and that the user is responsible for debugging.
> >>> Isn't this a bit strange?
> >>>
> >>> Michael Ellis wrote:
> >>> "Beyond this all I wish to add is a note to anyone involved in ImageJ
> >>> development that moving to newer JVM’s becomes increasingly important
> as
> >>> the older JVMs become increasingly difficult to get support for on the
> >>> Apple platform [...]"
> >>>
> >>> Does that mean that you can't run Java 6 under the latest Mac OS?
> >>> I don't think that this holds true.
> >>>
> >>> What's wrong with running Java 6 on an up-to-date personal computer,
> >>> especially if code, such as ImageJ, runs much smoother and faster?
> >>>
> >>> Just my 1 Euro Cent questions
> >>>
> >>> Herbie
> >>>
> >>> ::::::::::::::::::::::::::::::::::::::::::::
> >>> Am 20.07.15 um 18:03 schrieb Curtis Rueden:
> >>>
> >>> Hi Michael,
> >>>>
> >>>> Beyond this all I wish to add is a note to anyone involved in ImageJ
> >>>>> development that moving to newer JVM’s becomes increasingly important
> >>>>> as the older JVMs become increasingly difficult to get support for on
> >>>>> the Apple platform and also that anyone doing any development for
> >>>>> plugins is increasingly likely to be tooled up to reply on Java 8.
> >>>>>
> >>>>
> >>>> Indeed, the ImageJ team at LOCI 100% agrees with you, and as announced
> >>>> earlier we do plan to migrate to Java 8 by the end of the summer:
> >>>>
> >>>>
http://imagej.net/2015-06-15_-_Major_updates_in_the_works> >>>>
> >>>> We are definitely feeling the same pain you describe—especially as
> more
> >>>> and
> >>>> more underlying libraries raise their minimum requirements—and even
> though
> >>>> Java 8 still has some problems, the only way they will realistically
> be
> >>>> addressed is to do the migration and deal with the fallout. But of
> course
> >>>> we being as careful as we can to minimize the chances of backwards
> >>>> incompatible updates.
> >>>>
> >>>> Regards,
> >>>> Curtis
> >>>>
> >>>> On Mon, Jul 20, 2015 at 10:33 AM, Michael Ellis <
>
[hidden email]>
> >>>> wrote:
> >>>>
> >>>> I too rely on plugins that require Java 8 (lne we build ourselves)
> and
> >>>>> have also found some problems with ImageJ under Java 8 (slow image
> >>>>> updates
> >>>>> used to be a big problem). These problems seem to have been improving
> >>>>> with
> >>>>> ImageJ releases and also with Java 8 releases.
> >>>>>
> >>>>> I would make sure you have the latests Java 8 installed (some early
> >>>>> versions had show stopping bugs which have since been fixed).
> >>>>>
> >>>>> Beyond this all I wish to add is a note to anyone involved in ImageJ
> >>>>> development that moving to newer JVM’s becomes increasingly
> important as
> >>>>> the older JVMs become increasingly difficult to get support for on
> the
> >>>>> Apple platform and also that anyone doing any development for
> plugins is
> >>>>> increasingly likely to be tooled up to reply on Java 8.
> >>>>>
> >>>>> I understand that desire for backwards compatibility but there’s
> always
> >>>>> going to be tradeoff!
> >>>>>
> >>>>> — Michael Ellis
> >>>>>
> >>>>> --
> >>>>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> >>>>>
> >>>>>
> >>>> --
> >>>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> >>>>
> >>>>
> >>> --
> >>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> >>>
> >>
> >> --
> >> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> >>
> >
> > --
> > ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>