java 8 and OSX
Locked
12
12
 
|
I recently switched to Java 8 because one of the plugins I use no longer
runs under Java 6. It works, but I see that the monitor memory window no longer displays anything. I also found that occasionally the ROI manager no longer responds (eg -- I select an ROI but no outline appears on the image or I toggle show-all but nothing happens). Sometimes Fiji becomes very slow, especially when making selections or closing windows (through the GUI). The memory window issue is reproducible, but I have not been able to find a set of circumstances which trigger the other issues, other than time (memory leak?). I wonder if others using Java 8 and OSX are experiencing these issues? --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
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 |
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
Herbie,
Java 8 is not particularly "unripe" any more. All software is when first released, as it is not practical to debug it under as widely varied conditions as you find among a large user-base. But Java 8 is getting close to a year and a half old now, which has given Oracle time enough to fix the not-entirely-trivial bugs they shipped on release date (yeah, that's a bit sketchy), plus find others and fix them. Unless you know the source of the slowdowns when running under Java 8, I'm not sure the rest of your argument is valid. Also, a lot of people use Java for a lot of heavy lifting that is not image processing, and those people have _not_ generally reported performance problems with Java 8. If anything, the opposite. See, for instance, http://www.optaplanner.org/blog/2014/03/20/HowMuchFasterIsJava8.html --Rex On Mon, Jul 20, 2015 at 2:32 PM, Herbie <[hidden email]> wrote: > 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 |
|
|
In reply to this post by Herbie
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 |
|
|
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 |
|
|
In reply to this post by Michael P Ellis
Thanks to all who have replied to my post. It is good to know that I
have company... On 7/20/15 6:33 PM, Michael Ellis 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). > I have 1.8.0_51 (64 bit) downloaded two days ago. > 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. > To aid in this effort, I will try to find some pattern in these problems. I run Fiji with ImageJ 1.50a20 (daily build) under OSX 10.10.4, 12GB (out of 16GB) assigned to Fiji, and Java 1.8.0_51. So far, the biggest problem is indeed slow update, but more so, failure to respond to certain actions in the ROI manger (actions which involve some kind of update -- eg select ROI or show-all). Also, it can take a really longtime for the menu to redisplay when selecting images (this is probably OSX specific because it needs to update the menu every time a different application or even a different image window is selected). In is often hard to distinguish between a failure, or something that will happen if one waits long enough. I try to use the memory monitor to see if something is happening, but that does not display anything. In any case, for the ROI manager, I was able to save the ROI set, close the ROI manager window, and then reload it. The reloaded ROI manager worked ok for a while. Closing and restarting Fiji temporarily resolves the problems. Also , I am working with large images (about 15k x 15k pixels, 16 bit). Hope this provides some clues... > I understand that desire for backwards compatibility but there’s always going to be tradeoff! > > — Michael Ellis Best regards, --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by ctrueden
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 |
|
|
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 |
|
|
Thanks Curtis,
but I think this investigation is beyond my possibilities regarding software and hardware. I don't have access to PCs and on my Mac, for good reasons, I never run the latest OSs. Furthermore, I'm not willing to install several Java VMs and various flavors of ImageJ. Presently, it looks as if Java 8 on Macs under more recent OSs running Fiji are concerned. We shall see if the issue is more related to ImageJ-2. Best Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 21.07.15 um 17:54 schrieb Curtis Rueden: > 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 > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: java 8 and OSX
|
|
In reply to this post by ctrueden
> 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 |
|
|
In reply to this post by Aryeh Weiss
Dear all,
ImageJ1 starts without any problem in C:\APPLIC~1\ImageJ\ C:\jdk18\bin\javaw.exe -Xmx1024m -cp ij.jar;C:\APPLIC~1\ImageJ\ij.jar ij.ImageJ java.version: 1.8.0_45 java.vendor: Oracle Corporation os.name: Windows 7 os.version: 6.1 os.arch: amd64 I have just updated to IJ 1.50a IJ.getVersion: 1.50a IJ.getFullVersion: 1.50a99 IJ.isJava17: true IJ.isJava18: true IJ.isLinux: false IJ.isMacintosh: false IJ.isMacOSX: false IJ.isWindows: true IJ.is64Bit: true Personally, I am in favor of migrating to Java 8. For Win7 there are no problems using it so far but of course this has to be verified in all major OS. best regards, Dimiter -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Rasband, Wayne (NIH/NIMH) [E]
Dear Wayne,
thanks a lot for this clear-cut answer! I shall stick with Java 6 for the time being... All the best Herbie :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Am 22.07.15 um 00:31 schrieb Rasband, Wayne (NIH/NIMH) [E]: >> 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 > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Aryeh Weiss
On 7/21/15 6:59 AM, Aryeh Weiss wrote:
> > I have 1.8.0_51 (64 bit) downloaded two days ago. > >> 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. >> > > To aid in this effort, I will try to find some pattern in these > problems. I run Fiji with ImageJ 1.50a20 (daily build) under OSX > 10.10.4, 12GB (out of 16GB) assigned to Fiji, and Java 1.8.0_51. > > So far, the biggest problem is indeed slow update, but more so, failure > to respond to certain actions in the ROI manger (actions which involve > some kind of update -- eg select ROI or show-all). Also, it can take a > really longtime for the menu to redisplay when selecting images (this is > probably OSX specific because it needs to update the menu every time a > different application or even a different image window is selected). > > In is often hard to distinguish between a failure, or something that > will happen if one waits long enough. > I try to use the memory monitor to see if something is happening, but > that does not display anything. > > In any case, for the ROI manager, I was able to save the ROI set, close > the ROI manager window, and then reload it. The reloaded ROI manager > worked ok for a while. > Closing and restarting Fiji temporarily resolves the problems. > Also , I am working with large images (about 15k x 15k pixels, 16 bit). > I found some patterns in the problems. The ROI manager is associated with updating at least some windows. I have a macro that creates an ROI list in the ROI manager. After that runs, I will often (but not always) not be able to toggle the show-all checkbox. When this happens, if I open Help>About ImageJ, a window of the correct size will pop up, but it will be white, and will not update. As soon as I close the ROI manager, it will immediately update and display as expected. Similarly, when the ROI show-all is not working, I also cannot draw a selection in the image. Closing the ROI manager will immediately make it possible to draw the selection. This is reproducible -- I hope it helps to point in the direction of where the problem(s) are. --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Rasband, Wayne (NIH/NIMH) [E]
On Tuesday 21 Jul 2015 22:31:01 Wayne wrote:
> 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 For some reason I do not seem to be able to find the "RegressionTest.js" file which is called in the 2nd line. Where can I download that from? If I remove that line, sometimes the macro aborts with the embryos image under java 1.6.0, claiming that there should be a stack to process (there is one called embryos-1.jpg) the error is "Convert Stack to Images requires a stack". Could this be a race condition? Anyway, the first run of the macro before that error, which shows the progress bar and stops for some secs shows "filter tester successful" Java 1.6.0_35: -> 37 sec then if it does not abort, total: 47 sec to the end. openkdk 1.7 : -> 508 sec total 522 to the end, Java 1.8.0_51: -> 703 sec, total: 714 sec to the end. 15 times slower?? I am running linux 64bit in a very fast machine (the Ultilities>Benchmark Test runs in 0.25 sec for any of the Java versions above, so I am puzzled by the results above. I wonder what other users get. Cheers Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
On 7/22/15 1:43 PM, Gabriel Landini wrote:
> On Tuesday 21 Jul 2015 22:31:01 Wayne wrote: >> 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 > For some reason I do not seem to be able to find the "RegressionTest.js" file > which is called in the 2nd line. Where can I download that from? > > If I remove that line, sometimes the macro aborts with the embryos image under > java 1.6.0, claiming that there should be a stack to process (there is one > called embryos-1.jpg) the error is "Convert Stack to Images requires a stack". > Could this be a race condition? > > Anyway, the first run of the macro before that error, which shows the progress > bar and stops for some secs shows "filter tester successful" > > Java 1.6.0_35: -> 37 sec then if it does not abort, total: 47 sec to the end. > openkdk 1.7 : -> 508 sec total 522 to the end, > Java 1.8.0_51: -> 703 sec, total: 714 sec to the end. > > 15 times slower?? > Fiji under OSX (10.10.4). I found this, but it does not work for me (to be fair, it says it will not work...) I have Java 1.6 in: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk and /usr/bin/java and java 1.8 lives in: /Library/Internet Plug-Ins/JavaAppletPlugin.plugin Can someone out there tell me how to launch with java 6 without my having to remove java 8? Thanks in advance --aryeh -- Aryeh Weiss Faculty of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Gabriel Landini
I took a guess and the js file is here:
http://imagej.nih.gov/ij/macros/RegressionTests.js On Wed, Jul 22, 2015 at 3:43 AM, Gabriel Landini <[hidden email]> wrote: > On Tuesday 21 Jul 2015 22:31:01 Wayne wrote: > > 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 > > For some reason I do not seem to be able to find the "RegressionTest.js" > file > which is called in the 2nd line. Where can I download that from? > > If I remove that line, sometimes the macro aborts with the embryos image > under > java 1.6.0, claiming that there should be a stack to process (there is one > called embryos-1.jpg) the error is "Convert Stack to Images requires a > stack". > Could this be a race condition? > > Anyway, the first run of the macro before that error, which shows the > progress > bar and stops for some secs shows "filter tester successful" > > Java 1.6.0_35: -> 37 sec then if it does not abort, total: 47 sec to the > end. > openkdk 1.7 : -> 508 sec total 522 to the end, > Java 1.8.0_51: -> 703 sec, total: 714 sec to the end. > > 15 times slower?? > > I am running linux 64bit in a very fast machine (the Ultilities>Benchmark > Test > runs in 0.25 sec for any of the Java versions above, so I am puzzled by the > results above. I wonder what other users get. > > Cheers > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |