make the MacroExtensionAutoCompletionService initialize the lazy way

[haesleinhuepf]

Hey @ctrueden ,

here you go: Lazy initialization of the service. I see the point of making context initialization as fast as possible and thus, initialize services as this the lazy way. I was just wondering, if the initialize method is non-final and thus can be overridden, what would be a good scenario, where you have to initialize a service with it?

Thanks!

Cheers, Robert

[ctrueden]

Thanks @haesleinhuepf.

The initialize method is for cases where lazy initialization does not happen soon enough. For example: the DefaultCommandService adds the list of command plugins to the ModuleService's list of available modules. Another example: the SLF4JLogService of scijava-log-slf4j registers itself as the default uncaught exception handler right away.

Ideally I'd like to do away with the initialize() method in SciJava 3, but I am not yet sure whether this will be feasible.

[haesleinhuepf]

Cool. Thanks a lot @ctrueden . Let me know if I can help with maintaining imagej-legacy or scijava script-editor. I think in a mid-to-long-term perspective it might make sense for me to support efforts in these repositories as they are the base for scripting, macro extensions and auto-completion code. I'm dreaming of a macro language that is as powerful as groovy or javascript. Alternatively, a javascript interpreter which runs all pre-existing macros might make sense. Let's chat on an upcoming hackathon what's necessary to make this happen. I know there have been efforts in the past. I would like to know where developers got stuck in more detail.

Happy holidays! Cheers, Robert