Java 8 is not particularly "unripe" any more. All software is when first
conditions as you find among a large user-base. But Java 8 is getting
not sure the rest of your argument is valid. Also, a lot of people use
people have _not_ generally reported performance problems with Java 8. If
> 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>