[ImageJ-devel] Bug in ImageJ2 ?

[Curtis Rueden]

Hi Michael,

Sorry to hear that the POM version detection is not working for KNIME. If
the problem is *only* with the deprecated static VERSION, we plan to
eliminate that soon anyway. But if the ImageJ#getVersion() method always
returns null, that is a bad thing and we will need to fix it.

To debug this, I would need to set up a KNIP developer environment on my
machine here so that I can reproduce and debug the issue. Are there
instructions for doing that online?

Thanks,
Curtis

P.S. Please CC imagej-devel on replies. Sometimes other developers may
reply more quickly than I do, so it may save you time.


On Mon, Sep 17, 2012 at 2:15 AM, Michael Zinsmaier <michael.zinsmaier at gmx.de
> wrote:

>  Hi Curtis,
>
> thanks for your reply and the explenation. Unfortunately I have already a
> new issue. We tried to migrate the KNIME Image Extension
> to the beta 4 version of ImageJ and we have some problems with the
> introduced integration of the POM file. The getPOM method
> does not work in the plugin/eclipse environment that is used by KNIME I
> think this might be related to some OSGI stuff having separate
> class loaders for each plugin...
> In any case getPOM does not find the POM file although it is packed into
> the ImageJ jar file. Especially the static loading of the version number
> causes therefore some problems for us.
>
>     /** @deprecated Use {@link ImageJ#getVersion()} instead. */
>     @Deprecated
>     public static final String VERSION = POM.getPOM(ImageJ.class,
> "net.imagej", "ij-core").getVersion();
>
> Do you have an idea how this could be resolved?
>
> Best regards,
> Michael
>
>  Hi Michael,
>
>
>> There seems to be an issue with the InputHarvester and the SwingPanel if
>> the object types of primitive java types are used as input parameters (e.g.
>> Boolean instead of boolean).
>
>
>  Sorry for the delay in my reply. I fixed the bug shortly after sending
> my first mail, but was waiting to reply back until I did some more thorough
> investigation of the widget framework.
>
>  In short, the NPE is fixed, and both plugins will work now.
>
>  The long story is that despite that, there is one remaining issue of
> sorts with certain types of widgets. The toggle widget (with big B
> Booleans) is one of them, and the choice widget is another. The issue is
> that in some cases, the widget is not totally capable of reflecting the
> model state.
>
>  In the case of Boolean, the widget model may begin with a null value,
> but the toggle widget is only capable of displaying false or true. It will
> display unchecked for null, and if the user presses OK right away, the
> Boolean will be null (the widget changes nothing right now). But if you
> check and then uncheck the box again, the parameter value goes from null to
> true, and then from true to false. There is no way to set it back to null.
>
>  In the case of the choice widget, the model may begin with a value that
> is not on the list of allowed choices (again, null in particular is a big
> offender here). The choice widget immediately constrains the dropdown box
> to the first item on the list and overwrites the model. So the widget ends
> up being the reason the parameter doesn't end up with an (invalid) null
> value.
>
>  This behavior is inconsistent, and ideally the model itself would
> enforce value constraints, and the widgets would not overwrite them.
>
>  However, given the amount of time needed to correct this admittedly
> rather trivial inconsistency/deficiency, we are not going to worry about it
> for the time being.
>
>  Please let us know if you have any other questions or problems with
> ImageJ2!
>
>  Regards,
> Curtis
>
>
> On Thu, Aug 23, 2012 at 9:57 AM, Curtis Rueden <ctrueden at wisc.edu> wrote:
>
>> Hi Michael,
>>
>>
>>> There seems to be an issue with the InputHarvester and the SwingPanel if
>>> the object types of primitive java types are used as input parameters (e.g.
>>> Boolean instead of boolean).
>>
>>
>>  Thanks for the report. It's definitely a bug due to our recent
>> refactoring of the widget system. Both Boolean and boolean are supposed to
>> work. I'll look into fixing it today.
>>
>>  -Curtis
>>
>>  P.S. Hopefully I will have time to respond to your ImgLib mail from
>> yesterday, too. I really appreciate you taking the time to look at and
>> improve the Projector logic. We did the minimum necessary at the time to
>> get something working, but currently everything is planar, and there is no
>> built-in (i.e., ImgLib2) zoom capability, which we will eventually need.
>>
>>
>> On Thu, Aug 23, 2012 at 8:24 AM, Michael Zinsmaier <
>> michael.zinsmaier at gmx.de> wrote:
>>
>>>  Hi Curtis,
>>>
>>> I try currently to integrate the new imglib and ImageJ2 version (stuff
>>> from yesterday) into the KNIME ImageJ2 plugin.
>>> There seems to be an issue with the InputHarvester and the SwingPanel if
>>> the object types of primitive java types are
>>> used as input parameters (e.g. Boolean instead of boolean).
>>>
>>> The following plugin works fine:
>>>
>>> @Plugin(menu = {@Menu(label = "works")},
>>>          headless=true)
>>> public class Working<T extends RealType<T>> implements RunnablePlugin {
>>>
>>>     @Parameter(type = ItemIO.INPUT)
>>>     private boolean test;
>>>
>>>     @Parameter(type = ItemIO.OUTPUT)
>>>     private String output;
>>>
>>>     public void run() {
>>>             if (test) {
>>>                     output = "plugins can be defined as fragments of
>>> imagej.core";
>>>             }
>>>     }
>>>
>>> }
>>>
>>>
>>> while this plugin (Boolean instead of boolean) cannot be executed and
>>> results in a null pointer exception.
>>>
>>>
>>> @Plugin(menu = {@Menu(label = "works not")},
>>>          headless=true)
>>> public class NotWorking<T extends RealType<T>> implements RunnablePlugin
>>> {
>>>
>>>     @Parameter(type = ItemIO.INPUT)
>>>     private Boolean test;
>>>
>>>     @Parameter(type = ItemIO.OUTPUT)
>>>     private String output;
>>>
>>>     public void run() {
>>>             if (test) {
>>>                     output = "plugins can be defined as fragments of
>>> imagej.core";
>>>             }
>>>     }
>>>
>>> }
>>>
>>> Are only primitive types supported or is it a bug?
>>>
>>> Regards
>>> Michael
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120920/bc229010/attachment.html>