>> On Jul 21, 2015, at 11:54 AM, Curtis Rueden <
[hidden email]> wrote:
>>
>> 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.
>
> ImageJ using Java 8 performs GUI operations, like opening and closing windows, a lot slower on Macs. The macro at
>
>
http://imagej.nih.gov/ij/macros/RegressionTests.txt>
> takes more than twice as long to run using 1.8.0_51 as it does using Java 1.6.0_65. On Windows, Java 1.8 takes 13% longer to run this macro.
>
> -wayne
>
>
>> 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>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>