[patch] Bugs with Java 9

[Roger Leigh-2]

The first problem is that it's not possible to build with Java 9.  It
has a minimum supported version of 1.6 for javac.  This change is
required to build:

--- source.orig/build.xml       2017-09-04 00:43:40.000000000 +0100
+++ source/build.xml    2017-09-26 10:34:20.137316398 +0100
@@ -6,7 +6,7 @@
      <!-- First, ensure the build directory exists. -->
      <mkdir dir="build" />
      <!-- Build everything; add debug="on" to debug -->
-    <javac srcdir="./ij" destdir="build" optimize="on" source="1.5"
target="1.5" debug="on" includeantruntime="false" encoding="utf-8">
+    <javac srcdir="./ij" destdir="build" optimize="on" source="1.6"
target="1.6" debug="on" includeantruntime="false" encoding="utf-8">
      </javac>
    </target>

Though it could be increased to be 1.8 if we were less conservative.

The second problem is that it's not possible to start up ImageJ with
Java9 (Oracle JRE):

% cd /tmp/ImageJ
% ./run
Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
begin 0, end 3, length 1
         at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
         at java.base/java.lang.String.substring(String.java:1885)
         at ij.ImageJ.main(ImageJ.java:682)

         public static void main(String args[]) {
                 if
(System.getProperty("java.version").substring(0,3).compareTo("1.5")<0) {

This check makes a broken assumption that the string returned by
"System.getProperty("java.version")" will always be at least three
characters in length.  With Oracle JDK9, it's returning the string "9"
which is only one character long.

I'd suggest removing this check entirely, because the minimum version
supported is already encoded in the jar and checked by the JRE.

I'm investigating some additional problems, and I'll follow up once I've
learned more.


Regards,
Roger

--
Dr Roger Leigh -- Open Microscopy Environment
Wellcome Trust Centre for Gene Regulation and Expression,
College of Life Sciences, University of Dundee, Dow Street,
Dundee DD1 5EH Scotland UK   Tel: [phone]

The University of Dundee is a registered Scottish Charity, No: SC015096

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Roger,

it's definitely a good project to fix issues with ImageJ under Java 9,
but it would be nice if one could still build ImageJ for Java 1.5 if
required.

We have several computers that cannot be updated because of old data
acquisition hardware that requires an old operating system.
On these old systems (usually running old versions of Windows XP), Java
1.5 is the latest that works.
Maybe other users have similar systems.

When building ImageJ for Jave 1.5, it would not hurt to edit build.xml,
but it would be nice to keep ImageJ compatible with Java 1.5 for some time.

Best,

Michael
________________________________________________________________
On 26/09/2017 12:04, Roger Leigh wrote:

> The first problem is that it's not possible to build with Java 9.  It
> has a minimum supported version of 1.6 for javac.  This change is
> required to build:
>
> --- source.orig/build.xml       2017-09-04 00:43:40.000000000 +0100
> +++ source/build.xml    2017-09-26 10:34:20.137316398 +0100
> @@ -6,7 +6,7 @@
>       <!-- First, ensure the build directory exists. -->
>       <mkdir dir="build" />
>       <!-- Build everything; add debug="on" to debug -->
> -    <javac srcdir="./ij" destdir="build" optimize="on" source="1.5"
> target="1.5" debug="on" includeantruntime="false" encoding="utf-8">
> +    <javac srcdir="./ij" destdir="build" optimize="on" source="1.6"
> target="1.6" debug="on" includeantruntime="false" encoding="utf-8">
>       </javac>
>     </target>
>
> Though it could be increased to be 1.8 if we were less conservative.
>
> The second problem is that it's not possible to start up ImageJ with
> Java9 (Oracle JRE):
>
> % cd /tmp/ImageJ
> % ./run
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
> begin 0, end 3, length 1
>          at
> java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
>          at java.base/java.lang.String.substring(String.java:1885)
>          at ij.ImageJ.main(ImageJ.java:682)
>
>          public static void main(String args[]) {
>                  if
> (System.getProperty("java.version").substring(0,3).compareTo("1.5")<0) {
>
> This check makes a broken assumption that the string returned by
> "System.getProperty("java.version")" will always be at least three
> characters in length.  With Oracle JDK9, it's returning the string "9"
> which is only one character long.
>
> I'd suggest removing this check entirely, because the minimum version
> supported is already encoded in the jar and checked by the JRE.
>
> I'm investigating some additional problems, and I'll follow up once I've
> learned more.
>
>
> Regards,
> Roger
>
> --
> Dr Roger Leigh -- Open Microscopy Environment
> Wellcome Trust Centre for Gene Regulation and Expression,
> College of Life Sciences, University of Dundee, Dow Street,
> Dundee DD1 5EH Scotland UK   Tel: [phone]
>
> The University of Dundee is a registered Scottish Charity, No: SC015096
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Saalfeld, Stephan]

Hi Michael,

wouldn't it be sufficient to build an 'old' version of ImageJ on such
an old computer, i.e. the current version?  I agree that a reasonable
level of conservatism is necessary to guarantee continuity and
reliability but there is a point where it hinders important progress
(such as e.g. proper support of high resolution displays).  Old
hardware can run old software (and shouldn't be connected to the
Internet ;)).

Best,
Stephan


On Tue, 2017-09-26 at 14:03 +0200, Michael Schmid wrote:

> Hi Roger,
>
> it's definitely a good project to fix issues with ImageJ under Java
> 9, 
> but it would be nice if one could still build ImageJ for Java 1.5 if 
> required.
>
> We have several computers that cannot be updated because of old data 
> acquisition hardware that requires an old operating system.
> On these old systems (usually running old versions of Windows XP),
> Java 
> 1.5 is the latest that works.
> Maybe other users have similar systems.
>
> When building ImageJ for Jave 1.5, it would not hurt to edit
> build.xml, 
> but it would be nice to keep ImageJ compatible with Java 1.5 for some
> time.
>
> Best,
>
> Michael
> ________________________________________________________________
> On 26/09/2017 12:04, Roger Leigh wrote:
> >
> > The first problem is that it's not possible to build with Java 9. 
> > It
> > has a minimum supported version of 1.6 for javac.  This change is
> > required to build:
> >
> > --- source.orig/build.xml       2017-09-04 00:43:40.000000000 +0100
> > +++ source/build.xml    2017-09-26 10:34:20.137316398 +0100
> > @@ -6,7 +6,7 @@
> >       <!-- First, ensure the build directory exists. -->
> >       <mkdir dir="build" />
> >       <!-- Build everything; add debug="on" to debug -->
> > -    <javac srcdir="./ij" destdir="build" optimize="on"
> > source="1.5"
> > target="1.5" debug="on" includeantruntime="false" encoding="utf-8">
> > +    <javac srcdir="./ij" destdir="build" optimize="on"
> > source="1.6"
> > target="1.6" debug="on" includeantruntime="false" encoding="utf-8">
> >       </javac>
> >     </target>
> >
> > Though it could be increased to be 1.8 if we were less
> > conservative.
> >
> > The second problem is that it's not possible to start up ImageJ
> > with
> > Java9 (Oracle JRE):
> >
> > % cd /tmp/ImageJ
> > % ./run
> > Exception in thread "main"
> > java.lang.StringIndexOutOfBoundsException:
> > begin 0, end 3, length 1
> >          at 
> > java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
> >          at java.base/java.lang.String.substring(String.java:1885)
> >          at ij.ImageJ.main(ImageJ.java:682)
> >
> >          public static void main(String args[]) {
> >                  if
> > (System.getProperty("java.version").substring(0,3).compareTo("1.5")
> > <0) {
> >
> > This check makes a broken assumption that the string returned by
> > "System.getProperty("java.version")" will always be at least three
> > characters in length.  With Oracle JDK9, it's returning the string
> > "9"
> > which is only one character long.
> >
> > I'd suggest removing this check entirely, because the minimum
> > version
> > supported is already encoded in the jar and checked by the JRE.
> >
> > I'm investigating some additional problems, and I'll follow up once
> > I've
> > learned more.
> >
> >
> > Regards,
> > Roger
> >
> > -- 
> > Dr Roger Leigh -- Open Microscopy Environment
> > Wellcome Trust Centre for Gene Regulation and Expression,
> > College of Life Sciences, University of Dundee, Dow Street,
> > Dundee DD1 5EH Scotland UK   Tel: [phone]
> >
> > The University of Dundee is a registered Scottish Charity, No:
> > SC015096
> >

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Roger Leigh-2]

On 26/09/17 11:04, Roger Leigh wrote:
> I'm investigating some additional problems, and I'll follow up once I've
> learned more.

Please find attached three patches to make ImageJ build and start up
with Java 9.  The list rejects attachments, so I've included them below.

0001 - build with a minimum version of 1.6
0002 - remove startup check for 1.5; looked redundant in any case
0003 - make JVM version check portable, using functional testing of
available JVM features rather than fragile string parsing

With all three, there are no longer exceptions thrown at runtime as a
result of substring range errors.

There may be additional more subtle changes with Java 9, but I haven't
tested it in depth yet.  This is the minimal set of changes for people
to start playing with ImageJ and Java 9.


Kind regards,
Roger



 From 8b569f9ed3ecab40c9296062e279854d6a25b44d Mon Sep 17 00:00:00 2001
From: Roger Leigh <[hidden email]>
Date: Tue, 26 Sep 2017 12:20:04 +0100
Subject: [PATCH 1/3] build: Minimum source version is 1.6

---
  build.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build.xml b/build.xml
index e0ebc78..daa301f 100644
--- a/build.xml
+++ b/build.xml
@@ -6,7 +6,7 @@
      <!-- First, ensure the build directory exists. -->

      <mkdir dir="build" />

      <!-- Build everything; add debug="on" to debug -->

-    <javac srcdir="./ij" destdir="build" optimize="on" source="1.5"
target="1.5" debug="on" includeantruntime="false" encoding="utf-8">

+    <javac srcdir="./ij" destdir="build" optimize="on" source="1.6"
target="1.6" debug="on" includeantruntime="false" encoding="utf-8">

      </javac>

    </target>



--
2.14.1


 From c0aacc3f67494ff59092d87c4091403de7ee259e Mon Sep 17 00:00:00 2001
From: Roger Leigh <[hidden email]>
Date: Tue, 26 Sep 2017 15:53:00 +0100
Subject: [PATCH 2/3] ImageJ: Remove redundant Java 1.5 check

Given that only a 1.5 JVM or later could run the bytecode, this
codepath was exceedingly unlikely to be triggered since a 1.4 or
earlier JVM would not be able to run it to trigger the error
action.
---
  ij/ImageJ.java | 4 ----
  1 file changed, 4 deletions(-)

diff --git a/ij/ImageJ.java b/ij/ImageJ.java
index a30f5ff..6b0ccd4 100644
--- a/ij/ImageJ.java
+++ b/ij/ImageJ.java
@@ -678,10 +678,6 @@ public class ImageJ extends Frame implements
ActionListener,
        }

        public static void main(String args[]) {
-               if
(System.getProperty("java.version").substring(0,3).compareTo("1.5")<0) {
-                       javax.swing.JOptionPane.showMessageDialog(null,"ImageJ "+VERSION+"
requires Java 1.5 or later.");
-                       System.exit(0);
-               }
                boolean noGUI = false;
                int mode = STANDALONE;
                arguments = args;
--
2.14.1


 From 2d26ea571c3b2f02a84c207a04382f78bdbbb029 Mon Sep 17 00:00:00 2001
From: Roger Leigh <[hidden email]>
Date: Tue, 26 Sep 2017 16:34:03 +0100
Subject: [PATCH 3/3] IJ: Use portable feature tests to determine JVM version

---
  ij/IJ.java | 33 ++++++++++++++++++++++++---------
  1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/ij/IJ.java b/ij/IJ.java
index f70cd67..a61079f 100644
--- a/ij/IJ.java
+++ b/ij/IJ.java
@@ -49,7 +49,7 @@ public class IJ {
        private static ProgressBar progressBar;
        private static TextPanel textPanel;
        private static String osname, osarch;
-       private static boolean isMac, isWin, isJava16, isJava17, isJava18,
isJava19, isLinux, is64Bit;
+       private static boolean isMac, isWin, isJava17, isJava18, isJava19,
isLinux, is64Bit;
        private static boolean controlDown, altDown, spaceDown, shiftDown;
        private static boolean macroRunning;
        private static Thread previousThread;
@@ -75,13 +75,28 @@ public class IJ {
                isWin = osname.startsWith("Windows");
                isMac = !isWin && osname.startsWith("Mac");
                isLinux = osname.startsWith("Linux");
-               String version = System.getProperty("java.version").substring(0,3);
-               if (version.compareTo("2.9")<=0) {  // JVM on Sharp Zaurus PDA claims
to be "3.1"!
-                       isJava16 = version.compareTo("1.5")>0;
-                       isJava17 = version.compareTo("1.6")>0;
-                       isJava18 = version.compareTo("1.7")>0;
-                       isJava19 = version.compareTo("1.8")>0;
+
+               isJava17 = false;
+               try {
+                       Class<?> klass = Class.forName("java.util.Objects");
+                       isJava17 = true;
+               } catch (ClassNotFoundException e) {
+               }
+
+               isJava18 = false;
+               try {
+                       Class<?> klass = Class.forName("java.util.stream.IntStream");
+                       isJava18 = true;
+               } catch (ClassNotFoundException e) {
                }
+
+               isJava19 = false;
+               try {
+                       Class<?> klass = Class.forName("java.util.zip.CRC32C");
+                       isJava19 = true;
+               } catch (ClassNotFoundException e) {
+               }
+
                dfs = new DecimalFormatSymbols(Locale.US);
                df = new DecimalFormat[10];
                df[0] = new DecimalFormat("0", dfs);
@@ -971,9 +986,9 @@ public class IJ {
                return true;
        }

-       /** Returns true if ImageJ is running on a Java 1.6 or greater JVM. */
+       /** Always returns true. */
        public static boolean isJava16() {
-               return isJava16;
+               return true;
        }

        /** Returns true if ImageJ is running on a Java 1.7 or greater JVM. */
--
2.14.1


--
Dr Roger Leigh -- Open Microscopy Environment
Wellcome Trust Centre for Gene Regulation and Expression,
College of Life Sciences, University of Dundee, Dow Street,
Dundee DD1 5EH Scotland UK   Tel: [phone]


The University of Dundee is a registered Scottish Charity, No: SC015096

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Stefan,

well, ImageJ 1 is still evolving and it would be nice to have a recent
version also on our old computers for data acquisition (of course, we
don't have them accessible on the Internet).
Also, if I write a macro or plugin that we need there, and I have the
old versions there, it would be more troublesome to make sure it works
on the old machines.

But maybe I am one of very few dinosaurs who have accidentally survived
the meteor impact (or the only one)  ;-)

Michael
________________________________________________________________
On 26/09/2017 14:28, Saalfeld, Stephan wrote:

> Hi Michael,
>
> wouldn't it be sufficient to build an 'old' version of ImageJ on such
> an old computer, i.e. the current version?  I agree that a reasonable
> level of conservatism is necessary to guarantee continuity and
> reliability but there is a point where it hinders important progress
> (such as e.g. proper support of high resolution displays).  Old
> hardware can run old software (and shouldn't be connected to the
> Internet ;)).
>
> Best,
> Stephan
>
>
> On Tue, 2017-09-26 at 14:03 +0200, Michael Schmid wrote:
>> Hi Roger,
>>
>> it's definitely a good project to fix issues with ImageJ under Java
>> 9,
>> but it would be nice if one could still build ImageJ for Java 1.5 if
>> required.
>>
>> We have several computers that cannot be updated because of old data
>> acquisition hardware that requires an old operating system.
>> On these old systems (usually running old versions of Windows XP),
>> Java
>> 1.5 is the latest that works.
>> Maybe other users have similar systems.
>>
>> When building ImageJ for Jave 1.5, it would not hurt to edit
>> build.xml,
>> but it would be nice to keep ImageJ compatible with Java 1.5 for some
>> time.
>>
>> Best,
>>
>> Michael
>> ________________________________________________________________
>> On 26/09/2017 12:04, Roger Leigh wrote:
>>>
>>> The first problem is that it's not possible to build with Java 9.
>>> It
>>> has a minimum supported version of 1.6 for javac.  This change is
>>> required to build:
>>>
>>> --- source.orig/build.xml       2017-09-04 00:43:40.000000000 +0100
>>> +++ source/build.xml    2017-09-26 10:34:20.137316398 +0100
>>> @@ -6,7 +6,7 @@
>>>        <!-- First, ensure the build directory exists. -->
>>>        <mkdir dir="build" />
>>>        <!-- Build everything; add debug="on" to debug -->
>>> -    <javac srcdir="./ij" destdir="build" optimize="on"
>>> source="1.5"
>>> target="1.5" debug="on" includeantruntime="false" encoding="utf-8">
>>> +    <javac srcdir="./ij" destdir="build" optimize="on"
>>> source="1.6"
>>> target="1.6" debug="on" includeantruntime="false" encoding="utf-8">
>>>        </javac>
>>>      </target>
>>>
>>> Though it could be increased to be 1.8 if we were less
>>> conservative.
>>>
>>> The second problem is that it's not possible to start up ImageJ
>>> with
>>> Java9 (Oracle JRE):
>>>
>>> % cd /tmp/ImageJ
>>> % ./run
>>> Exception in thread "main"
>>> java.lang.StringIndexOutOfBoundsException:
>>> begin 0, end 3, length 1
>>>           at
>>> java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
>>>           at java.base/java.lang.String.substring(String.java:1885)
>>>           at ij.ImageJ.main(ImageJ.java:682)
>>>
>>>           public static void main(String args[]) {
>>>                   if
>>> (System.getProperty("java.version").substring(0,3).compareTo("1.5")
>>> <0) {
>>>
>>> This check makes a broken assumption that the string returned by
>>> "System.getProperty("java.version")" will always be at least three
>>> characters in length.  With Oracle JDK9, it's returning the string
>>> "9"
>>> which is only one character long.
>>>
>>> I'd suggest removing this check entirely, because the minimum
>>> version
>>> supported is already encoded in the jar and checked by the JRE.
>>>
>>> I'm investigating some additional problems, and I'll follow up once
>>> I've
>>> learned more.
>>>
>>>
>>> Regards,
>>> Roger
>>>
>>> --
>>> Dr Roger Leigh -- Open Microscopy Environment
>>> Wellcome Trust Centre for Gene Regulation and Expression,
>>> College of Life Sciences, University of Dundee, Dow Street,
>>> Dundee DD1 5EH Scotland UK   Tel: [phone]
>>>
>>> The University of Dundee is a registered Scottish Charity, No:
>>> SC015096
>>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Wayne Rasband-2]

> On Sep 26, 2017, at 12:22 PM, Roger Leigh <[hidden email]> wrote:
>
> On 26/09/17 11:04, Roger Leigh wrote:
>> I'm investigating some additional problems, and I'll follow up once I've
>> learned more.
>
> Please find attached three patches to make ImageJ build and start up
> with Java 9.  The list rejects attachments, so I've included them below.
>
> 0001 - build with a minimum version of 1.6
> 0002 - remove startup check for 1.5; looked redundant in any case
> 0003 - make JVM version check portable, using functional testing of
> available JVM features rather than fragile string parsing

These fixes are in the latest ImageJ daily build (1.51r6). Users that need to use Java 1.5 can build ImageJ from the source code, available at <http://wsr.imagej.net/src/src.zip>.

-wayne

> With all three, there are no longer exceptions thrown at runtime as a
> result of substring range errors.
>
> There may be additional more subtle changes with Java 9, but I haven't
> tested it in depth yet.  This is the minimal set of changes for people
> to start playing with ImageJ and Java 9.
>
>
> Kind regards,
> Roger
>
>
>
> From 8b569f9ed3ecab40c9296062e279854d6a25b44d Mon Sep 17 00:00:00 2001
> From: Roger Leigh <[hidden email]>
> Date: Tue, 26 Sep 2017 12:20:04 +0100
> Subject: [PATCH 1/3] build: Minimum source version is 1.6
>
> ---
> build.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/build.xml b/build.xml
> index e0ebc78..daa301f 100644
> --- a/build.xml
> +++ b/build.xml
> @@ -6,7 +6,7 @@
>     <!-- First, ensure the build directory exists. -->
>
>     <mkdir dir="build" />
>
>     <!-- Build everything; add debug="on" to debug -->
>
> -    <javac srcdir="./ij" destdir="build" optimize="on" source="1.5"
> target="1.5" debug="on" includeantruntime="false" encoding="utf-8">
>
> +    <javac srcdir="./ij" destdir="build" optimize="on" source="1.6"
> target="1.6" debug="on" includeantruntime="false" encoding="utf-8">
>
>     </javac>
>
>   </target>
>
>
>
> --
> 2.14.1
>
>
> From c0aacc3f67494ff59092d87c4091403de7ee259e Mon Sep 17 00:00:00 2001
> From: Roger Leigh <[hidden email]>
> Date: Tue, 26 Sep 2017 15:53:00 +0100
> Subject: [PATCH 2/3] ImageJ: Remove redundant Java 1.5 check
>
> Given that only a 1.5 JVM or later could run the bytecode, this
> codepath was exceedingly unlikely to be triggered since a 1.4 or
> earlier JVM would not be able to run it to trigger the error
> action.
> ---
> ij/ImageJ.java | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/ij/ImageJ.java b/ij/ImageJ.java
> index a30f5ff..6b0ccd4 100644
> --- a/ij/ImageJ.java
> +++ b/ij/ImageJ.java
> @@ -678,10 +678,6 @@ public class ImageJ extends Frame implements
> ActionListener,
>       }
>
>       public static void main(String args[]) {
> -               if
> (System.getProperty("java.version").substring(0,3).compareTo("1.5")<0) {
> -                       javax.swing.JOptionPane.showMessageDialog(null,"ImageJ "+VERSION+"
> requires Java 1.5 or later.");
> -                       System.exit(0);
> -               }
>               boolean noGUI = false;
>               int mode = STANDALONE;
>               arguments = args;
> --
> 2.14.1
>
>
> From 2d26ea571c3b2f02a84c207a04382f78bdbbb029 Mon Sep 17 00:00:00 2001
> From: Roger Leigh <[hidden email]>
> Date: Tue, 26 Sep 2017 16:34:03 +0100
> Subject: [PATCH 3/3] IJ: Use portable feature tests to determine JVM version
>
> ---
> ij/IJ.java | 33 ++++++++++++++++++++++++---------
> 1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/ij/IJ.java b/ij/IJ.java
> index f70cd67..a61079f 100644
> --- a/ij/IJ.java
> +++ b/ij/IJ.java
> @@ -49,7 +49,7 @@ public class IJ {
>       private static ProgressBar progressBar;
>       private static TextPanel textPanel;
>       private static String osname, osarch;
> -       private static boolean isMac, isWin, isJava16, isJava17, isJava18,
> isJava19, isLinux, is64Bit;
> +       private static boolean isMac, isWin, isJava17, isJava18, isJava19,
> isLinux, is64Bit;
>       private static boolean controlDown, altDown, spaceDown, shiftDown;
>       private static boolean macroRunning;
>       private static Thread previousThread;
> @@ -75,13 +75,28 @@ public class IJ {
>               isWin = osname.startsWith("Windows");
>               isMac = !isWin && osname.startsWith("Mac");
>               isLinux = osname.startsWith("Linux");
> -               String version = System.getProperty("java.version").substring(0,3);
> -               if (version.compareTo("2.9")<=0) {  // JVM on Sharp Zaurus PDA claims
> to be "3.1"!
> -                       isJava16 = version.compareTo("1.5")>0;
> -                       isJava17 = version.compareTo("1.6")>0;
> -                       isJava18 = version.compareTo("1.7")>0;
> -                       isJava19 = version.compareTo("1.8")>0;
> +
> +               isJava17 = false;
> +               try {
> +                       Class<?> klass = Class.forName("java.util.Objects");
> +                       isJava17 = true;
> +               } catch (ClassNotFoundException e) {
> +               }
> +
> +               isJava18 = false;
> +               try {
> +                       Class<?> klass = Class.forName("java.util.stream.IntStream");
> +                       isJava18 = true;
> +               } catch (ClassNotFoundException e) {
>               }
> +
> +               isJava19 = false;
> +               try {
> +                       Class<?> klass = Class.forName("java.util.zip.CRC32C");
> +                       isJava19 = true;
> +               } catch (ClassNotFoundException e) {
> +               }
> +
>               dfs = new DecimalFormatSymbols(Locale.US);
>               df = new DecimalFormat[10];
>               df[0] = new DecimalFormat("0", dfs);
> @@ -971,9 +986,9 @@ public class IJ {
>               return true;
>       }
>
> -       /** Returns true if ImageJ is running on a Java 1.6 or greater JVM. */
> +       /** Always returns true. */
>       public static boolean isJava16() {
> -               return isJava16;
> +               return true;
>       }
>
>       /** Returns true if ImageJ is running on a Java 1.7 or greater JVM. */
> --
> 2.14.1
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie]

Michael,

for many reasons I support your view.

Herbie

::::::::::::::::::::::::::::::::::::::::::::
Am 26.09.17 um 20:01 schrieb Michael Schmid:

> Hi Stefan,
>
> well, ImageJ 1 is still evolving and it would be nice to have a recent
> version also on our old computers for data acquisition (of course, we
> don't have them accessible on the Internet).
> Also, if I write a macro or plugin that we need there, and I have the
> old versions there, it would be more troublesome to make sure it works
> on the old machines.
>
> But maybe I am one of very few dinosaurs who have accidentally survived
> the meteor impact (or the only one)  ;-)
>
> Michael
> ________________________________________________________________
> On 26/09/2017 14:28, Saalfeld, Stephan wrote:
>> Hi Michael,
>>
>> wouldn't it be sufficient to build an 'old' version of ImageJ on such
>> an old computer, i.e. the current version?  I agree that a reasonable
>> level of conservatism is necessary to guarantee continuity and
>> reliability but there is a point where it hinders important progress
>> (such as e.g. proper support of high resolution displays).  Old
>> hardware can run old software (and shouldn't be connected to the
>> Internet ;)).
>>
>> Best,
>> Stephan
>>
>>
>> On Tue, 2017-09-26 at 14:03 +0200, Michael Schmid wrote:
>>> Hi Roger,
>>>
>>> it's definitely a good project to fix issues with ImageJ under Java
>>> 9,
>>> but it would be nice if one could still build ImageJ for Java 1.5 if
>>> required.
>>>
>>> We have several computers that cannot be updated because of old data
>>> acquisition hardware that requires an old operating system.
>>> On these old systems (usually running old versions of Windows XP),
>>> Java
>>> 1.5 is the latest that works.
>>> Maybe other users have similar systems.
>>>
>>> When building ImageJ for Jave 1.5, it would not hurt to edit
>>> build.xml,
>>> but it would be nice to keep ImageJ compatible with Java 1.5 for some
>>> time.
>>>
>>> Best,
>>>
>>> Michael
>>> ________________________________________________________________
>>> On 26/09/2017 12:04, Roger Leigh wrote:
>>>>
>>>> The first problem is that it's not possible to build with Java 9.
>>>> It
>>>> has a minimum supported version of 1.6 for javac.  This change is
>>>> required to build:
>>>>
>>>> --- source.orig/build.xml       2017-09-04 00:43:40.000000000 +0100
>>>> +++ source/build.xml    2017-09-26 10:34:20.137316398 +0100
>>>> @@ -6,7 +6,7 @@
>>>>        <!-- First, ensure the build directory exists. -->
>>>>        <mkdir dir="build" />
>>>>        <!-- Build everything; add debug="on" to debug -->
>>>> -    <javac srcdir="./ij" destdir="build" optimize="on"
>>>> source="1.5"
>>>> target="1.5" debug="on" includeantruntime="false" encoding="utf-8">
>>>> +    <javac srcdir="./ij" destdir="build" optimize="on"
>>>> source="1.6"
>>>> target="1.6" debug="on" includeantruntime="false" encoding="utf-8">
>>>>        </javac>
>>>>      </target>
>>>>
>>>> Though it could be increased to be 1.8 if we were less
>>>> conservative.
>>>>
>>>> The second problem is that it's not possible to start up ImageJ
>>>> with
>>>> Java9 (Oracle JRE):
>>>>
>>>> % cd /tmp/ImageJ
>>>> % ./run
>>>> Exception in thread "main"
>>>> java.lang.StringIndexOutOfBoundsException:
>>>> begin 0, end 3, length 1
>>>>           at
>>>> java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
>>>>           at java.base/java.lang.String.substring(String.java:1885)
>>>>           at ij.ImageJ.main(ImageJ.java:682)
>>>>
>>>>           public static void main(String args[]) {
>>>>                   if
>>>> (System.getProperty("java.version").substring(0,3).compareTo("1.5")
>>>> <0) {
>>>>
>>>> This check makes a broken assumption that the string returned by
>>>> "System.getProperty("java.version")" will always be at least three
>>>> characters in length.  With Oracle JDK9, it's returning the string
>>>> "9"
>>>> which is only one character long.
>>>>
>>>> I'd suggest removing this check entirely, because the minimum
>>>> version
>>>> supported is already encoded in the jar and checked by the JRE.
>>>>
>>>> I'm investigating some additional problems, and I'll follow up once
>>>> I've
>>>> learned more.
>>>>
>>>>
>>>> Regards,
>>>> Roger
>>>>
>>>> --
>>>> Dr Roger Leigh -- Open Microscopy Environment
>>>> Wellcome Trust Centre for Gene Regulation and Expression,
>>>> College of Life Sciences, University of Dundee, Dow Street,
>>>> Dundee DD1 5EH Scotland UK   Tel: [phone]
>>>>
>>>> The University of Dundee is a registered Scottish Charity, No:
>>>> SC015096
>>>>
>>
>> --
>> 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

[Robert Dougherty]

Michael,

There are several of us out there.

Bob

On Sep 26, 2017, at 11:01 AM, Michael Schmid wrote:

> Hi Stefan,
>
> well, ImageJ 1 is still evolving and it would be nice to have a recent version also on our old computers for data acquisition (of course, we don't have them accessible on the Internet).
> Also, if I write a macro or plugin that we need there, and I have the old versions there, it would be more troublesome to make sure it works on the old machines.
>
> But maybe I am one of very few dinosaurs who have accidentally survived the meteor impact (or the only one)  ;-)
>
> Michael
>

Robert Dougherty, Ph.D.
President, OptiNav, Inc.
1414 127th Place NE #106
Bellevue, WA 98005
Tel. [phone]
FAX [phone]
www.optinav.com
[hidden email]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Hi,

I do support Stephan Saalfeld’s view on this. Sooner or later, it doesn’t make sense to support completely outdated systems -- if it makes running the same software on modern systems impractical. Whatever one decides for, one will loose people on either side of the spectrum. And I think better support of new systems just makes more sense. Especially since it is possible to simply combine old acquisition systems with new ones by just putting a second 300EUR computer next to it and sharing the local drive.

Also, Windows XP still runs Java 8 just fine, I use it on my virtual machine to test things. It would have to be WindowsME, Windows98 or Windows95  to not be supported anymore.

Just my 5 cents, all the best,
Stephan
---

Dr. Stephan Preibisch
Group Leader

Berlin Institute for Medical Systems Biology (BIMSB), Max Delbrück Center for Molecular Medicine (MDC)
Building 89, 1.08b

email: [hidden email]<mailto:[hidden email]>
web: http://preibischlab.mdc-berlin.de

On 26. Sep 2017, at 23:34, Robert Dougherty <[hidden email]<mailto:[hidden email]>> wrote:

Michael,

There are several of us out there.

Bob

On Sep 26, 2017, at 11:01 AM, Michael Schmid wrote:

Hi Stefan,

well, ImageJ 1 is still evolving and it would be nice to have a recent version also on our old computers for data acquisition (of course, we don't have them accessible on the Internet).
Also, if I write a macro or plugin that we need there, and I have the old versions there, it would be more troublesome to make sure it works on the old machines.

But maybe I am one of very few dinosaurs who have accidentally survived the meteor impact (or the only one)  ;-)

Michael


Robert Dougherty, Ph.D.
President, OptiNav, Inc.
1414 127th Place NE #106
Bellevue, WA 98005
Tel. [phone]
FAX [phone]
www.optinav.com<http://www.optinav.com>
[hidden email]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

Hi,
Unfortunately at some point things will not be supported anymore, but it is
not just buying a 300 Euro machine... sometimes one gets stuck with other
acquisition software that does not work with a new OS version and which
controls expensive hardware. Camera acquisition software is the typical
example.

Not directly related, but while I do not use 1.5,  I occasionally use 1.6
because of a large difference (nearly x10) in performace in some IJ functions
under linux between 1.6 and all other subsequent versions (Oracle or OpenJDK).  
I have reported this here before. For example compare the the non-batch mode
timings across Java versions:

setBatchMode(true);
run("MRI Stack (528K)");
t=getTime();
run("Stack to Images");
print ("Batch mode: "+getTime()-t);
run("Images to Stack", "name=Stack title=[] use");
setBatchMode(false);
t2=getTime();
run("Stack to Images");
print ("Normal mode: "+getTime()-t2);
run("Images to Stack", "name=Stack title=[] use");

So I hope support for 1.6 could be continued until that performance issue is
resolved.

Cheers

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Gabriel,

> So I hope support for 1.6 could be continued until that performance
> issue is resolved.

For ImageJ 1.x core, this should continue to be doable for a while yet.

For the ecosystem of ImageJ and Fiji plugins adding value to the scientific
community, it is infeasible.

For a (long but not comprehensive) list of reasons why, see this issue:
   https://github.com/imagej/imagej/issues/135

It is unfortunate when newer versions of a technology have regressions or
limitations not imposed by previous versions—e.g., performance issues
present when running with Java 8. But in this case, the motivation to use a
newer Java is overwhelming despite these issues.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Wed, Sep 27, 2017 at 10:40 AM, Gabriel Landini <[hidden email]>
wrote:

> Hi,
> Unfortunately at some point things will not be supported anymore, but it is
> not just buying a 300 Euro machine... sometimes one gets stuck with other
> acquisition software that does not work with a new OS version and which
> controls expensive hardware. Camera acquisition software is the typical
> example.
>
> Not directly related, but while I do not use 1.5,  I occasionally use 1.6
> because of a large difference (nearly x10) in performace in some IJ
> functions
> under linux between 1.6 and all other subsequent versions (Oracle or
> OpenJDK).
> I have reported this here before. For example compare the the non-batch
> mode
> timings across Java versions:
>
> setBatchMode(true);
> run("MRI Stack (528K)");
> t=getTime();
> run("Stack to Images");
> print ("Batch mode: "+getTime()-t);
> run("Images to Stack", "name=Stack title=[] use");
> setBatchMode(false);
> t2=getTime();
> run("Stack to Images");
> print ("Normal mode: "+getTime()-t2);
> run("Images to Stack", "name=Stack title=[] use");
>
> So I hope support for 1.6 could be continued until that performance issue
> is
> resolved.
>
> Cheers
>
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie]

 >> So I hope support for 1.6 could be continued until that performance
 >> issue is resolved.
 >
 > For ImageJ 1.x core, this should continue to be doable for a while
 > yet.

For a while? Any details available?

Herbie

:::::::::::::::::::::::::::::::::::::::::::
Am 27.09.17 um 11:28 schrieb Curtis Rueden:

> Hi Gabriel,
>
>> So I hope support for 1.6 could be continued until that performance
>> issue is resolved.
>
> For ImageJ 1.x core, this should continue to be doable for a while yet.
>
> For the ecosystem of ImageJ and Fiji plugins adding value to the scientific
> community, it is infeasible.
>
> For a (long but not comprehensive) list of reasons why, see this issue:
>     https://github.com/imagej/imagej/issues/135
>
> It is unfortunate when newer versions of a technology have regressions or
> limitations not imposed by previous versions—e.g., performance issues
> present when running with Java 8. But in this case, the motivation to use a
> newer Java is overwhelming despite these issues.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Wed, Sep 27, 2017 at 10:40 AM, Gabriel Landini <[hidden email]>
> wrote:
>
>> Hi,
>> Unfortunately at some point things will not be supported anymore, but it is
>> not just buying a 300 Euro machine... sometimes one gets stuck with other
>> acquisition software that does not work with a new OS version and which
>> controls expensive hardware. Camera acquisition software is the typical
>> example.
>>
>> Not directly related, but while I do not use 1.5,  I occasionally use 1.6
>> because of a large difference (nearly x10) in performace in some IJ
>> functions
>> under linux between 1.6 and all other subsequent versions (Oracle or
>> OpenJDK).
>> I have reported this here before. For example compare the the non-batch
>> mode
>> timings across Java versions:
>>
>> setBatchMode(true);
>> run("MRI Stack (528K)");
>> t=getTime();
>> run("Stack to Images");
>> print ("Batch mode: "+getTime()-t);
>> run("Images to Stack", "name=Stack title=[] use");
>> setBatchMode(false);
>> t2=getTime();
>> run("Stack to Images");
>> print ("Normal mode: "+getTime()-t2);
>> run("Images to Stack", "name=Stack title=[] use");
>>
>> So I hope support for 1.6 could be continued until that performance issue
>> is
>> resolved.
>>
>> Cheers
>>
>> Gabriel
>>
>> --
>> 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

[Roger Leigh-2]

On 26/09/17 19:01, Michael Schmid wrote:

> Hi Stefan,
>
> well, ImageJ 1 is still evolving and it would be nice to have a recent
> version also on our old computers for data acquisition (of course, we
> don't have them accessible on the Internet).
> Also, if I write a macro or plugin that we need there, and I have the
> old versions there, it would be more troublesome to make sure it works
> on the old machines.
>
> But maybe I am one of very few dinosaurs who have accidentally survived
> the meteor impact (or the only one)  ;-)

Maybe I can provide some context.  This is the recent release history of
Java:

   Version  Release   End of Life
   5        Sep 2004  Nov 2009
   6        Dec 2006  Apr 2013
   7        Jul 2011  Apr 2015
   8        Mar 2014  -
   9        Sep 2017  -

Note the end of life dates.  Java 5 has had no public updates for nearly
*8 years*.  Java 6 for 4.5 years.  And Java 7 for 2.5 years.

Curtis' points about the drivers for adopting new JVM versions are very
important.  And it's also important to appreciate the real *cost* for
supporting multiple versions.  Every additional version costs time and
effort and money for people and testing resources to ensure it is
functional.  It is not fair or realistic to expect others to write,
build, test and do quality assurance for software which is 13 years old,
and which was abandoned 8 years ago.  While it's possible to run code on
Java 5 today, the reality is most software will have been built and
tested on a newer JVM.  Who knows what bugs you might run into, or
whether you even get the same results.  It might be fine, but there's no
certainty of that since it's largely untested.  It wasn't easy to make
Java 5 run on a current platform 5 years ago; it's even harder today.
It's long dead.

For the Bio-Formats plugin, we dropped Java 5 at the end of 2013.  Usage
had already declined to nearly zero by that point, with everyone using
Java 6 or 7.  We dropped Java 6 in early 2016, three years after support
had ended.  Java 6 was retained primarily due to the Java support for
MacOS X, or it would have been dropped earlier.  We will drop support
for Java 7 when the last blockers for doing so are removed (primarily
Matlab), since it is also going to be 3 years out of support by the time
we do so.  Also, Java 8 usage is around 98% with 2% on Java 7.  When the
usage nears zero, there's little incentive to expend resources on
something no one is using.

Java 8 is what the vast majority of the world is using *today*.  Java 9
is what the vast majority will be using in a few months time once the
Windows and MacOS X Java updaters upgrade people en masse.  Ubuntu 17.10
adds OpenJDK9, but defaults to OpenJDK8 for now.  The default might be
switched to 9 for 18.04.  The future is Java 9, and when you have to
trade off continued support for the long-obsolete Java 5 (and 6 and 7)
vs what will be adopted by the majority from now onwards, the choice is
quite clear.  I'm sorry if this is problematic for the few individuals
who are stuck with obsolete systems, but you also have to account for
the many *thousands* more who are using current systems who would
collectively be disadvantaged vastly more if we didn't support them.


Kind regards,
Roger

--
Dr Roger Leigh -- Open Microscopy Environment
Wellcome Trust Centre for Gene Regulation and Expression,
College of Life Sciences, University of Dundee, Dow Street,
Dundee DD1 5EH Scotland UK   Tel: [phone]

The University of Dundee is a registered Scottish Charity, No: SC015096

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html