http://imagej.273.s1.nabble.com/ImageJ-Compile-Run-compiles-java-program-in-editor-but-runs-from-cache-How-to-fix-tp5019392p5019414.html
don't get it when calling the ij.jar from the command line, e.g. like
'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
commands above.
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
924-948.
make ImageJ believe it runs from an applet. I have no idea where it
at the end.
where the IJ_prefs.txt are located.
> 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>