I have been successfully Compile&Run(ing) a Java plugin from the ImageJ editor. At one point the plugin seemed to be in an infinite loop (using massive CPU and not responding to gui interactions). I killed the ImageJ process, and then restarted ImageJ. Now imagej only runs the version of the program, i.e., class files, that existed when I start imagej.
I can make changes and 'Compile and Run...' . The java program(s) will compile. Although the program, i.e., class files, that is run is the one that existed when imagej started I suspect that imagej is caching the class files for some reason, but the cache is prevented from being updated. Where is this cache or how to get imagej to compile and RUN the program from the editor? Thanks in advance, Fred -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
You need to restart ImageJ or run Refresh Menus, (although I seem to remember
somebody commenting that restarting is better). Cheers Gabriel On Tuesday, 19 September 2017 04:04:26 BST you wrote: > I have been successfully Compile&Run(ing) a Java plugin from the ImageJ > editor. At one point the plugin seemed to be in an infinite loop (using > massive CPU and not responding to gui interactions). I killed the ImageJ > process, and then restarted ImageJ. Now imagej only runs the version of > the program, i.e., class files, that existed when I start imagej. > > I can make changes and 'Compile and Run...' . The java program(s) will > compile. Although the program, i.e., class files, that is run is the one > that existed when imagej started I suspect that imagej is caching the > class files for some reason, but the cache is prevented from being updated. > Where is this cache or how to get imagej to compile and RUN the program > from the editor? > > Thanks in advance, > > Fred > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
The whole point is that I should not have to restart imagej every time I need
to recompile a Java plugin. And up to the point that I needed to kill imagej I did not need to restart. Help->Refresh Menus does not cause the newer version of the plugin to be used. Thanks, Fred On Tue, September 19, 2017 10:33 am, Gabriel Landini wrote: > You need to restart ImageJ or run Refresh Menus, (although I seem to remember > somebody commenting that restarting is better). > Cheers > > Gabriel > > > On Tuesday, 19 September 2017 04:04:26 BST you wrote: >> I have been successfully Compile&Run(ing) a Java plugin from the ImageJ >> editor. At one point the plugin seemed to be in an infinite loop (using >> massive CPU and not responding to gui interactions). I killed the ImageJ >> process, and then restarted ImageJ. Now imagej only runs the version of >> the program, i.e., class files, that existed when I start imagej. >> >> I can make changes and 'Compile and Run...' . The java program(s) will >> compile. Although the program, i.e., class files, that is run is the one >> that existed when imagej started I suspect that imagej is caching the >> class files for some reason, but the cache is prevented from being updated. >> Where is this cache or how to get imagej to compile and RUN the program >> from the editor? >> >> Thanks in advance, >> >> Fred >> >> -- >> 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 Fred Damen
Hi Fred,
in my experience, 'Compile&Run' recompiles source files that are newer than the corresponding .class files. This is true for all classes that are called from the main class (the one you select with 'Compile&Run'), not recursively for others. So if you have My_Plugin, calling SubClass1, calling SubClass2 and My_Plugin has no reference to SubClass2, then ImageJ won't compile SubClass2, even if SubClass2.java is newer than SubClass2.class. To make sure, just delete all .class files, then ImageJ will recompile all. Michael ________________________________________________________________ On 19/09/2017 05:04, Fred wrote: > I have been successfully Compile&Run(ing) a Java plugin from the ImageJ editor. At one point the plugin seemed to be in an infinite loop (using massive CPU and not responding to gui interactions). I killed the ImageJ process, and then restarted ImageJ. Now imagej only runs the version of the program, i.e., class files, that existed when I start imagej. > > I can make changes and 'Compile and Run...' . The java program(s) will compile. Although the program, i.e., class files, that is run is the one that existed when imagej started I suspect that imagej is caching the class files for some reason, but the cache is prevented from being updated. Where is this cache or how to get imagej to compile and RUN the program from the editor? > > Thanks in advance, > > Fred -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
In reply to this post by Fred Damen
On Tuesday, 19 September 2017 16:56:01 BST [hidden email] wrote:
> The whole point is that I should not have to restart imagej every time I > need to recompile a Java plugin. And up to the point that I needed to kill > imagej I did not need to restart. Help->Refresh Menus does not cause the > newer version of the plugin to be used. So you mean that the program was modified AND compiled, but the code that runs is the old one? I would check the date of the class file. Maybe the last time it did no compile? Or maybe there is more than one installation of IJ (I have seen that several times, people copying plugins in the plugin folder but which never appear in the menu... and then realise that there were 2 copies of IJ! Cheers Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Greetings Gabriel,
There is only one copy of ImageJ. The problem did not exist before I killed imagej while it was stuck. The problem existed after and no other changes have been made, except to the source code of the plugin in question. The plugin recompiles, timestamps of the class files and java files are when I hit Ctrl-R. As tests, I inserted a syntax error into the source, hit Ctrl-R, and the error window pops up correctly identifying the syntax error; I erased the .class files while imagej is running and ran the plugin from the Plugins menu and the version that existed when imagej started was run; *without the .class files in the plugins directory*. This leads me to believe that there is a cache somewhere; which I can not find. When I start imagej with the .class files in the plugins directory the .class files seem to get placed in some cache somewhere, once they are there they do not get updated. Running the Help->Refresh Menus with the .class files cached the version that runs is not updated. As a new test I tried, exiting imagej, erase .class files, start imagej; the plugin does not show up in the Plugins menu; then I update the plugin, i.e., change a string in a IJ.log, Ctrl-R, Help->Refresh Menus; the plugin now shows up in the Plugins menu and it runs the current version. Make another update, Ctrl-R, and it runs the previous version. Fred On Tue, September 19, 2017 11:42 am, Gabriel Landini wrote: > On Tuesday, 19 September 2017 16:56:01 BST [hidden email] wrote: >> The whole point is that I should not have to restart imagej every time I >> need to recompile a Java plugin. And up to the point that I needed to kill >> imagej I did not need to restart. Help->Refresh Menus does not cause the >> newer version of the plugin to be used. > > So you mean that the program was modified AND compiled, but the code that runs > is the old one? > I would check the date of the class file. Maybe the last time it did no > compile? Or maybe there is more than one installation of IJ (I have seen that > several times, people copying plugins in the plugin folder but which never > appear in the menu... and then realise that there were 2 copies of IJ! > > Cheers > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
I read a little imagej code and came upon:
/** This version of the constructor is used when ImageJ is launched using Java WebStart. */ public PluginClassLoader(String path, boolean callSuper) { super(new URL[0], Thread.currentThread().getContextClassLoader()); init(path); } Which seems like it might be using a cache class loader if 'Java WebStart' is turned on. How do I tell if it is on and how can it be turned off? Thanks, Fred On Tue, September 19, 2017 12:33 pm, Fred Damen wrote: > Greetings Gabriel, > > There is only one copy of ImageJ. The problem did not exist before I killed > imagej while it was stuck. The problem existed after and no other changes have > been made, except to the source code of the plugin in question. > > The plugin recompiles, timestamps of the class files and java files are when I > hit Ctrl-R. As tests, I inserted a syntax error into the source, hit Ctrl-R, > and the error window pops up correctly identifying the syntax error; I erased > the .class files while imagej is running and ran the plugin from the Plugins > menu and the version that existed when imagej started was run; *without the > .class files in the plugins directory*. This leads me to believe that there > is a cache somewhere; which I can not find. > > When I start imagej with the .class files in the plugins directory the .class > files seem to get placed in some cache somewhere, once they are there they do > not get updated. Running the Help->Refresh Menus with the .class files cached > the version that runs is not updated. As a new test I tried, exiting imagej, > erase .class files, start imagej; the plugin does not show up in the Plugins > menu; then I update the plugin, i.e., change a string in a IJ.log, Ctrl-R, > Help->Refresh Menus; the plugin now shows up in the Plugins menu and it runs > the current version. Make another update, Ctrl-R, and it runs the previous > version. > > Fred > > > On Tue, September 19, 2017 11:42 am, Gabriel Landini wrote: >> On Tuesday, 19 September 2017 16:56:01 BST [hidden email] wrote: >>> The whole point is that I should not have to restart imagej every time I >>> need to recompile a Java plugin. And up to the point that I needed to kill >>> imagej I did not need to restart. Help->Refresh Menus does not cause the >>> newer version of the plugin to be used. >> >> So you mean that the program was modified AND compiled, but the code that >> runs >> is the old one? >> I would check the date of the class file. Maybe the last time it did no >> compile? Or maybe there is more than one installation of IJ (I have seen >> that >> several times, people copying plugins in the plugin folder but which never >> appear in the menu... and then realise that there were 2 copies of IJ! >> >> 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 |
Hi Fred,
ok, I see, it looks like some misconfiguration. Things you could try: - Delete or rename the ImageJ preferences file IJ_Prefs.txt (on Macs in /Library/Preferences, otherwise in a hidden .imagej folder the users's home directory). Then restart ImageJ. - If this does not help, to diagnose the problem further you could run Plugins>Utilties>ImageJ properties and look at the result. Important properties in this context are: user.dir: should be the path to ImageJ IJ.getDir("plugins"): should be the path to ImageJ/plugins Menus.getPlugInsPath: should be the path to ImageJ/plugins Prefs.getImageJDir: should be the path to ImageJ Prefs dir: directory of IJ_Prefs.txt is found, see above ij.dir, imagej.dir: should be the path to ImageJ user.home: should be your home directory plugins.dir: should be the path to ImageJ java.class.path: should be the path to the ij.jar file There should be nothing with 'applet' in the list. I nothing helps, I fear the only solution would be reinstalling ImageJ. Michael ________________________________________________________________ On 19/09/2017 22:20, Fred Damen wrote: > I read a little imagej code and came upon: > /** This version of the constructor is used when ImageJ is launched using Java > WebStart. */ > public PluginClassLoader(String path, boolean callSuper) { > super(new URL[0], Thread.currentThread().getContextClassLoader()); > init(path); > } > > Which seems like it might be using a cache class loader if 'Java WebStart' is > turned on. How do I tell if it is on and how can it be turned off? > > Thanks, > > Fred > > On Tue, September 19, 2017 12:33 pm, Fred Damen wrote: >> Greetings Gabriel, >> >> There is only one copy of ImageJ. The problem did not exist before I killed >> imagej while it was stuck. The problem existed after and no other changes have >> been made, except to the source code of the plugin in question. >> >> The plugin recompiles, timestamps of the class files and java files are when I >> hit Ctrl-R. As tests, I inserted a syntax error into the source, hit Ctrl-R, >> and the error window pops up correctly identifying the syntax error; I erased >> the .class files while imagej is running and ran the plugin from the Plugins >> menu and the version that existed when imagej started was run; *without the >> .class files in the plugins directory*. This leads me to believe that there >> is a cache somewhere; which I can not find. >> >> When I start imagej with the .class files in the plugins directory the .class >> files seem to get placed in some cache somewhere, once they are there they do >> not get updated. Running the Help->Refresh Menus with the .class files cached >> the version that runs is not updated. As a new test I tried, exiting imagej, >> erase .class files, start imagej; the plugin does not show up in the Plugins >> menu; then I update the plugin, i.e., change a string in a IJ.log, Ctrl-R, >> Help->Refresh Menus; the plugin now shows up in the Plugins menu and it runs >> the current version. Make another update, Ctrl-R, and it runs the previous >> version. >> >> Fred >> >> >> On Tue, September 19, 2017 11:42 am, Gabriel Landini wrote: >>> On Tuesday, 19 September 2017 16:56:01 BST [hidden email] wrote: >>>> The whole point is that I should not have to restart imagej every time I >>>> need to recompile a Java plugin. And up to the point that I needed to kill >>>> imagej I did not need to restart. Help->Refresh Menus does not cause the >>>> newer version of the plugin to be used. >>> >>> So you mean that the program was modified AND compiled, but the code that >>> runs >>> is the old one? >>> I would check the date of the class file. Maybe the last time it did no >>> compile? Or maybe there is more than one installation of IJ (I have seen >>> that >>> several times, people copying plugins in the plugin folder but which never >>> appear in the menu... and then realise that there were 2 copies of IJ! >>> >>> 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 > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Greetings Michael,
I tried exiting imagej, erasing IJ_Prefs.txt, starting imagej, and this did not seem to help. Then I tried exiting imagej, renaming .imagej directory (linux), starting imagej, and a new .imagej directory was created for me, then I was able to edit / compile&run about a dozen or two times until the problem resurfaced. This time there was no notable event between working and not working. Then I did the renaming .imagej dir trick again and was able to work again. While it wasn't working, I had checked the parameters for the plugins directory and they were pointing to ~/.imagej/plugins . Later today I will try and swap the bad .imagej directory back and check all the parameters you suggest. Should plugins.dir below be ImageJ/plugins? Thanks, Fred On Wed, September 20, 2017 4:26 am, Michael Schmid wrote: > Hi Fred, > > ok, I see, it looks like some misconfiguration. > Things you could try: > > - Delete or rename the ImageJ preferences file IJ_Prefs.txt (on Macs in > /Library/Preferences, otherwise in a hidden .imagej folder the users's > home directory). Then restart ImageJ. > > - If this does not help, to diagnose the problem further you could run > Plugins>Utilties>ImageJ properties and look at the result. > Important properties in this context are: > > user.dir: should be the path to ImageJ > IJ.getDir("plugins"): should be the path to ImageJ/plugins > Menus.getPlugInsPath: should be the path to ImageJ/plugins > Prefs.getImageJDir: should be the path to ImageJ > Prefs dir: directory of IJ_Prefs.txt is found, see above > ij.dir, imagej.dir: should be the path to ImageJ > user.home: should be your home directory > plugins.dir: should be the path to ImageJ > java.class.path: should be the path to the ij.jar file > > There should be nothing with 'applet' in the list. > > > I nothing helps, I fear the only solution would be reinstalling ImageJ. > > > Michael > ________________________________________________________________ > On 19/09/2017 22:20, Fred Damen wrote: >> I read a little imagej code and came upon: >> /** This version of the constructor is used when ImageJ is launched using >> Java >> WebStart. */ >> public PluginClassLoader(String path, boolean callSuper) { >> super(new URL[0], Thread.currentThread().getContextClassLoader()); >> init(path); >> } >> >> Which seems like it might be using a cache class loader if 'Java WebStart' >> is >> turned on. How do I tell if it is on and how can it be turned off? >> >> Thanks, >> >> Fred >> >> On Tue, September 19, 2017 12:33 pm, Fred Damen wrote: >>> Greetings Gabriel, >>> >>> There is only one copy of ImageJ. The problem did not exist before I >>> killed >>> imagej while it was stuck. The problem existed after and no other changes >>> have >>> been made, except to the source code of the plugin in question. >>> >>> The plugin recompiles, timestamps of the class files and java files are >>> when I >>> hit Ctrl-R. As tests, I inserted a syntax error into the source, hit >>> Ctrl-R, >>> and the error window pops up correctly identifying the syntax error; I >>> erased >>> the .class files while imagej is running and ran the plugin from the >>> Plugins >>> menu and the version that existed when imagej started was run; *without the >>> .class files in the plugins directory*. This leads me to believe that >>> there >>> is a cache somewhere; which I can not find. >>> >>> When I start imagej with the .class files in the plugins directory the >>> .class >>> files seem to get placed in some cache somewhere, once they are there they >>> do >>> not get updated. Running the Help->Refresh Menus with the .class files >>> cached >>> the version that runs is not updated. As a new test I tried, exiting >>> imagej, >>> erase .class files, start imagej; the plugin does not show up in the >>> Plugins >>> menu; then I update the plugin, i.e., change a string in a IJ.log, Ctrl-R, >>> Help->Refresh Menus; the plugin now shows up in the Plugins menu and it >>> runs >>> the current version. Make another update, Ctrl-R, and it runs the previous >>> version. >>> >>> Fred >>> >>> >>> On Tue, September 19, 2017 11:42 am, Gabriel Landini wrote: >>>> On Tuesday, 19 September 2017 16:56:01 BST [hidden email] wrote: >>>>> The whole point is that I should not have to restart imagej every time I >>>>> need to recompile a Java plugin. And up to the point that I needed to >>>>> kill >>>>> imagej I did not need to restart. Help->Refresh Menus does not cause the >>>>> newer version of the plugin to be used. >>>> >>>> So you mean that the program was modified AND compiled, but the code that >>>> runs >>>> is the old one? >>>> I would check the date of the class file. Maybe the last time it did no >>>> compile? Or maybe there is more than one installation of IJ (I have seen >>>> that >>>> several times, people copying plugins in the plugin folder but which never >>>> appear in the menu... and then realise that there were 2 copies of IJ! >>>> >>>> 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 >> > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Fred,
hummm, I must admit I don't fully understand the relevant code in ImageJ, but anyhow: The Java property 'plugins.dir' is set from the ImageJ Launcher; you don't get it when calling the ij.jar from the command line, e.g. like this (linux): DIRECTORY=~/ImageJ # wherever you have the ImageJ folder cd $DIRECTORY $DIRECTORY/jre/bin/java -jar $DIRECTORY/ij.jar Nevertheless, when I call ImageJ this way on my computer, compiling does not show the problems you reported, so having no Java property 'plugins.dir' does not hurt. In this case ImageJ uses the Java property 'user.dir', which is the working directory when java is started. No problem if ImageJ gets started in its own folder like in the shell commands above. In any case, 'plugins.dir' (if it exists) and 'user.dir'is the path of the ImageJ folder (with no slash at the end), not the plugins folder. The relevant code is at IJ.java, lines 2118-2139. You get the problem if Menus.jnlp is set; the relevant code for this is in Menus.java lines 924-948. There is seems that you need a pluginsDir with the String "user.home" to make ImageJ believe it runs from an applet. I have no idea where it should get this from (maybe search for that String in Plugins>Utilties>ImageJ properties) You can also check what ImageJ considers its own directory with the following macro: call("ij.Prefs.getHomeDir"); Again, it should give you the path of the ImageJ folder, without slash at the end. I also don't see how this should be related to the ~/.imagej directory where the IJ_prefs.txt are located. Still puzzled, Michael ________________________________________________________________ On 20/09/2017 17:00, Fred Damen wrote: > Greetings Michael, > > I tried exiting imagej, erasing IJ_Prefs.txt, starting imagej, and this did > not seem to help. Then I tried exiting imagej, renaming .imagej directory > (linux), starting imagej, and a new .imagej directory was created for me, then > I was able to edit / compile&run about a dozen or two times until the problem > resurfaced. This time there was no notable event between working and not > working. Then I did the renaming .imagej dir trick again and was able to work > again. > > While it wasn't working, I had checked the parameters for the plugins > directory and they were pointing to ~/.imagej/plugins . Later today I will > try and swap the bad .imagej directory back and check all the parameters you > suggest. > > Should plugins.dir below be ImageJ/plugins? > > Thanks, > > Fred > > On Wed, September 20, 2017 4:26 am, Michael Schmid wrote: >> Hi Fred, >> >> ok, I see, it looks like some misconfiguration. >> Things you could try: >> >> - Delete or rename the ImageJ preferences file IJ_Prefs.txt (on Macs in >> /Library/Preferences, otherwise in a hidden .imagej folder the users's >> home directory). Then restart ImageJ. >> >> - If this does not help, to diagnose the problem further you could run >> Plugins>Utilties>ImageJ properties and look at the result. >> Important properties in this context are: >> >> user.dir: should be the path to ImageJ >> IJ.getDir("plugins"): should be the path to ImageJ/plugins >> Menus.getPlugInsPath: should be the path to ImageJ/plugins >> Prefs.getImageJDir: should be the path to ImageJ >> Prefs dir: directory of IJ_Prefs.txt is found, see above >> ij.dir, imagej.dir: should be the path to ImageJ >> user.home: should be your home directory >> plugins.dir: should be the path to ImageJ >> java.class.path: should be the path to the ij.jar file >> >> There should be nothing with 'applet' in the list. >> >> >> I nothing helps, I fear the only solution would be reinstalling ImageJ. >> >> >> Michael >> ________________________________________________________________ >> On 19/09/2017 22:20, Fred Damen wrote: >>> I read a little imagej code and came upon: >>> /** This version of the constructor is used when ImageJ is launched using >>> Java >>> WebStart. */ >>> public PluginClassLoader(String path, boolean callSuper) { >>> super(new URL[0], Thread.currentThread().getContextClassLoader()); >>> init(path); >>> } >>> >>> Which seems like it might be using a cache class loader if 'Java WebStart' >>> is >>> turned on. How do I tell if it is on and how can it be turned off? >>> >>> Thanks, >>> >>> Fred >>> >>> On Tue, September 19, 2017 12:33 pm, Fred Damen wrote: >>>> Greetings Gabriel, >>>> >>>> There is only one copy of ImageJ. The problem did not exist before I >>>> killed >>>> imagej while it was stuck. The problem existed after and no other changes >>>> have >>>> been made, except to the source code of the plugin in question. >>>> >>>> The plugin recompiles, timestamps of the class files and java files are >>>> when I >>>> hit Ctrl-R. As tests, I inserted a syntax error into the source, hit >>>> Ctrl-R, >>>> and the error window pops up correctly identifying the syntax error; I >>>> erased >>>> the .class files while imagej is running and ran the plugin from the >>>> Plugins >>>> menu and the version that existed when imagej started was run; *without the >>>> .class files in the plugins directory*. This leads me to believe that >>>> there >>>> is a cache somewhere; which I can not find. >>>> >>>> When I start imagej with the .class files in the plugins directory the >>>> .class >>>> files seem to get placed in some cache somewhere, once they are there they >>>> do >>>> not get updated. Running the Help->Refresh Menus with the .class files >>>> cached >>>> the version that runs is not updated. As a new test I tried, exiting >>>> imagej, >>>> erase .class files, start imagej; the plugin does not show up in the >>>> Plugins >>>> menu; then I update the plugin, i.e., change a string in a IJ.log, Ctrl-R, >>>> Help->Refresh Menus; the plugin now shows up in the Plugins menu and it >>>> runs >>>> the current version. Make another update, Ctrl-R, and it runs the previous >>>> version. >>>> >>>> Fred >>>> >>>> >>>> On Tue, September 19, 2017 11:42 am, Gabriel Landini wrote: >>>>> On Tuesday, 19 September 2017 16:56:01 BST [hidden email] wrote: >>>>>> The whole point is that I should not have to restart imagej every time I >>>>>> need to recompile a Java plugin. And up to the point that I needed to >>>>>> kill >>>>>> imagej I did not need to restart. Help->Refresh Menus does not cause the >>>>>> newer version of the plugin to be used. >>>>> >>>>> So you mean that the program was modified AND compiled, but the code that >>>>> runs >>>>> is the old one? >>>>> I would check the date of the class file. Maybe the last time it did no >>>>> compile? Or maybe there is more than one installation of IJ (I have seen >>>>> that >>>>> several times, people copying plugins in the plugin folder but which never >>>>> appear in the menu... and then realise that there were 2 copies of IJ! >>>>> >>>>> 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 >>> >> >> -- >> 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 Fred Damen
Hi Fred,
Another option would be to prototype your code using a Java-like scripting language [1] such as Groovy [2] or BeanShell [3], in the Script Editor [4] of ImageJ2. This would give you the rapid development iterations you desire, without the pain of Compile&Run and related Java class loading issues. Once the code works, you could paste it into a Java plugin as needed, with minimal or no changes. Regards, Curtis [1] https://imagej.net/Scripting [2] https://imagej.net/Groovy [3] https://imagej.net/BeanShell [4] https://imagej.net/Script_Editor -- 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 Mon, Sep 18, 2017 at 10:04 PM, Fred <[hidden email]> wrote: > I have been successfully Compile&Run(ing) a Java plugin from the ImageJ > editor. At one point the plugin seemed to be in an infinite loop (using > massive CPU and not responding to gui interactions). I killed the ImageJ > process, and then restarted ImageJ. Now imagej only runs the version of > the program, i.e., class files, that existed when I start imagej. > > I can make changes and 'Compile and Run...' . The java program(s) will > compile. Although the program, i.e., class files, that is run is the one > that existed when imagej started I suspect that imagej is caching the > class files for some reason, but the cache is prevented from being > updated. Where is this cache or how to get imagej to compile and RUN the > program from the editor? > > Thanks in advance, > > Fred > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Free forum by Nabble | Edit this page |