the latest OSs. Furthermore, I'm not willing to install several Java VMs
Fiji are concerned. We shall see if the issue is more related to ImageJ-2.
> Hi Herbie,
>
>> 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?
>
> I do not know, but you are welcome to investigate and report back to the
> list. The information would certainly benefit many other users.
>
> Regards,
> Curtis
>
> On Tue, Jul 21, 2015 at 2:58 AM, Herbie <
[hidden email]> wrote:
>
>> 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>>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>