NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #1183 (closed task: fixed)

Opened 2012-05-16T10:41:37-05:00

Last modified 2012-09-04T16:51:10-05:00

Finish splitting service interfaces & implementations

Reported by: curtis Owned by: curtis
Priority: minor Milestone: imagej2-b4-plugins
Component: Core Version:
Severity: minor Keywords:
Cc: Blocked By:
Blocking: #1323


Many services now have separate interface and default implementation classes, to make it as easy as possible for developers to override the behavior of each service's public API. There are still a few services that have not been split, though. These services should be similarly split in two.

In particular, splitting IOService would eliminate the annoying T generic parameter from the IOService interface (maintaining it only for the DefaultIOService implementation until we complete work on the  imgopener-generics branch), and hence eliminate warnings on "raw" usage of IOService in various plugins such as OpenImage.

Change History

comment:1 Changed 2012-06-16T01:28:09-05:00 by curtis

IOService has been split in 8bebbe2a. UIService has been split in 44ce883b.

comment:2 Changed 2012-06-25T15:05:55-05:00 by curtis

  • Blocking 1209 added

comment:3 Changed 2012-07-12T09:49:41-05:00 by curtis

  • Blocking 1323 added

comment:4 Changed 2012-07-12T09:50:14-05:00 by curtis

  • Blocking 1209 removed
  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4

comment:5 Changed 2012-09-04T16:51:10-05:00 by curtis

  • Status changed from new to closed
  • Resolution set to fixed

More service interface/implementation splits:

With that, all the core services have an associated interface. The only exceptions are:

  • Services in the imagej.core.commands subtree.
  • Services in UI-specific projects (e.g., JHotDrawService).

So I'm going to call this one "good enough"!