Outsider's opinion
Gábor Bakos
I am not part of the ImageJ developer community (just a non-regular user of ImageJ), so sorry if my observations, suggestions are not relevant/wrong. (I have investigated to integrate VisBio's user interface to KNIME, which has similar structure as ImageJ's. None of them is suitable for my task, but hope the result of this project efforts might be applicable there.)
I have seen some concerns in this list about the performance of usage of generics with numerical computations. I think this (@specialized annotation in Scala 2.8.x (to be released this year)), can be used to avoid performance problems, and keep writing generic algorithms. (blog, Numeric trait, discussion). (I am not sure, maybe Johan Hendriksson has been already solved this problem using pure Java. In that case I would be interested how, and is it available somewhere?)
(Regarding abstract classes <-> interfaces - In Scala you can use traits for interfaces and those can hold implementations too.)
I have also looked at the Fiji's imagecontainer1 branch. I think it is more modular, flexible than ImageJ, maybe the way to the future. (Although using public int in the Type class is not so good solution in my humble opinion.)
I have seen a suggestion of OSGi. I think it is tested by many people, flexible and would be a good option. About the complaint against the core plugins option: you can sign the core plugins and based on the presence or absence of that signature you can give more or less permissions (for example to access the menu/toolbox/...) for the plugins. I would definitely go on this way (I mean to have even some of the core functionalities as plugin(s)). The plus side of OSGi that you can have multiple versions of a bundle loaded to your application, so if there is an incompatibility between versions you can have more loaded.
(Dependency injection might ease the instantiation of SPIs.)
Have you considered a compatibility layer to 1.x ImageJ? It would give you design freedom for the new version, and would be a good test about the flexibility of the new design whether it is flexible enough or not. (I have to admit it is also possible that this is impossible, I have not tried to do it.)
It would be really cool if there were an option to use -if available- OpenCL for computations/transformations... (JOCL)
What I would really like:
- separation of UI from other parts,
- no singletons,
- nice GUI,
- easy to understand API.
Bests, gabor
PS.: I will not get hurt if my requests/suggestions will not find their way to the new developments, I know that you have to focus on your needs. In the meantime I will provide a simpler, less feature rich UI for the users (maybe based on JavaFX), this would be (will be?) an additional bonus. ;)
Thanks Grant for the links on SPI/API.
--
Success is the ability to go from one failure to another with no loss of enthusiasm. ~~~ Wins...
Johan Henriksson
> Hello,
>
> I am not part of the ImageJ developer community (just a non-regular user of
> ImageJ), so sorry if my observations, suggestions are not relevant/wrong. (I
> have investigated to integrate VisBio's user interface to
> which has similar structure as ImageJ's. None of them is suitable for my
> task, but hope the result of this project efforts might be applicable
> there.)
>
> I have seen some concerns in this list about the performance of usage of
> generics with numerical computations. I think
> annotation in
> Scala <http://www.scala-lang.org> 2.8.x (to be released this year)), can be
> used to avoid performance problems, and keep writing generic algorithms. (
> Numeric trait<http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Numeric.scala>,
> discussion<http://www.nabble.com/2D-3D-vector-math-package----design-choices,-and-where-should-it-go--td25072286.html>).
> (I am not sure, maybe Johan Hendriksson has been already solved this problem
> using pure Java. In that case I would be interested how, and is it available
> somewhere?)
>
issue is not as high priority as when I started coding.
indeed the solution in java is to code @specialized, most likely with
javassist.
http://www.csg.is.titech.ac.jp/~chiba/javassist/
it provides run-time specialization
+ no need to recompile to support new datatypes
+ smaller binaries
- slower startup
while I'm a die hard fan of functional programming (haskell in
particular), these hyped languages cost a lot to use:
* typically poor tool support (IDEs)
* at minimum, refactoring tools are still weak for Scala
* tools to refactor code in multiple languages does AFAIK not exist at all
* not a problem for scala, but python/perl/ruby all have dynamic typing.
these are unsuitable for large scale programming or code you want to be
able to read
but the worst problem is that we are building a tower of babel by using
additional languages for minimal gains, that does not provide any gains
for larger programs (no surprise, I've veto'ed the addition of
jython/clojure/whatever-support for my tool Endrov). I consider Fiji the
prime worst example, with Clojure, JRuby, Javascript and Jython. great,
so now biologists have to know 5 languages instead of 1 to be able to
read and modify all the scripts/code out there. hackers who fight over
syntax might like that but I have trouble enough convincing my coworkers
to just look at java...
</sidetrip>
> I have seen a suggestion of OSGi. I think it is tested by many people,
> flexible and would be a good option. About the complaint against the core
> plugins option: you can sign the core plugins and based on the presence or
> absence of that signature you can give more or less permissions (for example
> to access the menu/toolbox/...) for the plugins. I would definitely go on
> this way (I mean to have even some of the core functionalities as
> plugin(s)). The plus side of OSGi that you can have multiple versions of a
> bundle loaded to your application, so if there is an incompatibility between
> versions you can have more loaded.
>
I have seen complaints against OSGi for being very heavy-weight
(disclaimer: I have not used it). in fact, I think the plugin hysteria
has been taken a bit too far in many cases; most of the time you just
want code to be modular and easy to add. things like loading/unloading
plugins during runtime might cost more in terms of work than it
provides. after all, this is something that has to be coded into each
plugin so it's not a pay-once cost.
given how many features you can squeeze into 1MB code (vs 10GB images),
it's hard to even motivate why you would like to download plugins
separately rather than the entire project in one go. that cuts away the
need for a plugin manager and yet another automatic updating system
(that has to be made secure).
check java 1.7 super packages if you haven't already.
> It would be really cool if there were an option to use -if available-
> OpenCL<http://en.wikipedia.org/wiki/OpenCL>for
> computations/transformations... (
> JOCL <http://www.jocl.org/>)
>
you can also use the OpenCL bindings I have written for Endrov.
http://sourceforge.net/projects/jopencl/
unlike JOCL, it's open source
/Johan
aborg
Comments inside. (A bit offtopic, so if you or others think this is
not the proper place to discuss these we can continue privately.
Although I think at least some parts might be interesting to others
too.)
On Oct 23, 10:38 pm, Johan Henriksson <he.jo...@gmail.com> wrote:
> no implementation yet. I'm using double precision for everything so the
> issue is not as high priority as when I started coding.
> indeed the solution in java is to code @specialized, most likely with
> + no need to recompile to support new datatypes
> + smaller binaries
> - slower startup
bundles, because KNIME is based on eclipse.)
> while I'm a die hard fan of functional programming (haskell in
> particular), these hyped languages cost a lot to use:
> * typically poor tool support (IDEs)
> * at minimum, refactoring tools are still weak for Scala
> * tools to refactor code in multiple languages does AFAIK not exist at all
> * not a problem for scala, but python/perl/ruby all have dynamic typing.
> these are unsuitable for large scale programming or code you want to be
> able to read
as I know it a little bit more then the other alternatives- some of
them is no longer true. (I cannot comment the first, you might want to
check this page: http://www.jetbrains.net/confluence/display/SCA/Scala+Plugin+0.2+features
.)
I am not sure which languages should be in your multiple selection.
The IDEA plugin allows you to refactor between Java/Scala sources. (I
tried this and it looks working well.) Other combinations I am afraid
might not be possible.
I think the new versions of eclipse, NetBeans plugins also brings new
refactorings, I am not sure about the multiple languages refactorings.
> ...
> </sidetrip>
> I have seen complaints against OSGi for being very heavy-weight
> (disclaimer: I have not used it). in fact, I think the plugin hysteria
> has been taken a bit too far in many cases; most of the time you just
> want code to be modular and easy to add.
further constraints.
> things like loading/unloading
> plugins during runtime might cost more in terms of work than it
> provides. after all, this is something that has to be coded into each
> plugin so it's not a pay-once cost.
only once for all projects. (Yes, it requires a little house-keeping
near releases and development, although it is not so much work.)
> given how many features you can squeeze into 1MB code (vs 10GB images),
> it's hard to even motivate why you would like to download plugins
> separately rather than the entire project in one go. that cuts away the
> need for a plugin manager and yet another automatic updating system
> (that has to be made secure).
the other part's configuration/deployment/testing requirements.
Naturally plugins can be distributed together, so I do not see the
separation of plugins as a huge problem.
> check java 1.7 super packages if you haven't already.
(early 2010?).
> you can also use the OpenCL bindings I have written for Endrov.http://sourceforge.net/projects/jopencl/
code.google.com/p/nativelibs4java/wiki/OpenCL) too. Could you get a
comparision on differences? As I see your licence is more liberal,
although it looks a little bit lower level.)
> /Johan
Thanks, gabor