in Apple's strategy. (Yes, there had been day when Apple promised to
it is something not required by Mac users. I am and always was able to
decades. I still don't understand why the NIH lost interest in this
> Hi Herbie, John and everyone,
>
> Herbie wrote:
>> _Are there any speed penalties compared to Java 6?_
>
> As Rex pointed out, Java 7 and 8 are significantly faster than 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.
>
> No, Oracle Java only works on OS X 10.7 "Lion" and later. Users of 10.6
> "Snow Leopard" and earlier will be unable to update ImageJ2 once it
> switches to Java 8.
>
>> 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?
>
> The funding of ImageJ2 and related projects is described on the web site:
>
http://imagej.net/Funding>
> I do not understand what you mean by "lever to be pulled."
>
>> 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
>
> As I said, we have seen many JVM crashes with Java 6. These are bugs in
> Java itself -- it should not be possible to cause such crashes no matter
> how buggy the Java code is.
>
>> 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.
>
> One reason we are moving to Java 8 is so that we can retire the ImageJ
> Launcher component, in favor of Java 8's built-in JavaFX-based deployment,
> using self-contained application bundles [1].
>
> Another reason is that all platforms which support Java 7 also support Java
> 8 (as far as I know). So there is little disadvantage to users, with major
> benefit to plugin developers, since Java 8 introduces many new language
> features such as better support for functional programming.
>
> John wrote:
>> 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.
>
> Yes, Java's security issues are almost entirely irrelevant to ImageJ,
> since it is primarily a desktop application rather than an applet.
>
> Regards,
> Curtis
>
> [1] If you are curious, here is one relevant thread:
>
http://imagej.net/pipermail/imagej-devel/2015-June/002596.html>
>
> On Mon, Jul 20, 2015 at 5:15 PM, John Hayes <
[hidden email]> wrote:
>
>> 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>>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>