list. The information would certainly benefit many other users.
> Curtis, Rex, John, Michael, and Aryeh,
>
> thanks for all your comments that appear to be partly contradictory, but
> maybe this is due to different platforms or to my limited understanding.
>
> So, I've learned that Java 7 and 8 are faster executing than Java 6 but
> others report speed problems with Java 8 on Macs and that's what I feel is
> rather bad.
>
> ------------------------------------------------------------------------
> So, is ImageJ generally speedier under Java 8 or not?
> Are the reported speed problems Mac-specific?
> Are the problems ImageJ-2 specific or do they concern ImageJ-1 as well?
> ------------------------------------------------------------------------
>
> Of course I know about the Java-history of Apple and the general change in
> Apple's strategy. (Yes, there had been day when Apple promised to
> extensively support Java as one of its favorite programming systems.)
>
> What I meant by...
>
> "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?"
>
> ...are of course the more modern MacOSs (those after the transition to
> Oracle's Java) and those to come.
>
>
> "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]."
>
> I've never understood what that launcher business is about but perhaps it
> is something not required by Mac users. I am and always was able to start
> the ij.jar by double-clicking.
>
> "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."
>
> If there are really speed problems with Java 8, than there _is_ a big
> disadvantage for users and I don't think there are coding tasks that can't
> be solved without Java 8.
> This appears pretty much an informatics-centered not user-centered
> argument.
>
> "lever to be pulled."
> At least in some countries, if funded by the tax payer you have a better
> standing with respect to companies and their products...
>
> I've now learned that there is presently no more national funding of
> ImageJ-2, a situation that I deeply regret, especially when thinking of
> Wayne's work that had been payed (as I understand it) by the NIH for
> decades. I still don't understand why the NIH lost interest in this widely
> used software package after supporting it for such a long period of time.
>
> Now I'm looking forward to replies concerning the three questions above
> that appear to be of general importance for us ImageJ-users.
>
> Best
>
> Herbie
>
> :::::::::::::::::::::::::::::::::::::::::::
> Am 21.07.15 um 04:09 schrieb Curtis Rueden:
>
> 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>>
>>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>