Compile-time check of "static interface"

Discussion in 'Java' started by Ian Pilcher, Jan 26, 2004.

  1. Ian Pilcher

    Ian Pilcher Guest

    I'm working on application that uses plug-in classes to handle various
    data formats. No matter how I look at the problem, each plug-in class
    has to implement a constructor (or static "factory" method) that takes
    the appropriate agruments and another static method that checks the
    compatibility of the class with a given data stream.

    I'm using the reflection stuff in java.lang.reflect to check each class
    when it's "registered". It's cumbersome, but it works.

    The challenge comes from the "default" plug-in class. Just like it
    sounds, it accepts any data format, and the program it written with the
    assumption that it will always be present. Currently, it gets
    registered during program startup, at which time the normal checks are
    done -- with a RuntimeException thrown if I've forgotten to update the
    default plug-in for a change in the required static method/constructor.

    By all rights, this should be checked at compile-time. After all, the
    default plug-in is part of the application. Is there any clean way to
    do this?

    Thanks!

    --
    ========================================================================
    Ian Pilcher
    ========================================================================
     
    Ian Pilcher, Jan 26, 2004
    #1
    1. Advertising

  2. Ian Pilcher

    Chris Smith Guest

    Ian Pilcher wrote:
    > By all rights, this should be checked at compile-time. After all, the
    > default plug-in is part of the application. Is there any clean way to
    > do this?


    To get a compile-time check of an API element, you need to have
    something for it to conform to. That's not possible with either static
    methods or constructors. So, you're looking at revamping the system to
    use an instance method there. But that just pushes back the problem...
    how do you create the instance so that you can call the instance method?

    The answer is to use an interface that *won't* change for this
    bootstrapping class. Specifically, require it to have a no-argument
    constructor. The framework looks like this:

    interface HandlerFactory
    {
    public Handler getHandler(Type1 param1, Type2 param2);
    }

    interface Handler
    {
    ...
    }

    class DefaultHandlerFactory implements HandlerFactory
    {
    public Handler getHandler(Type1 param1, Type2 param2)
    {
    return new DefaultHandler(param1, param2);
    }
    }

    class DefaultHandler implements Handler
    {
    public DefaultHandler(Type1 param1, Type2 param2)
    {
    ...
    }

    ...
    }

    So yes, you've still got an API element (the implicit no-argument
    constructor to DefaultHandlerFactory) that has to match a specific
    signature that is not checked at compile-time. However, you have no
    need or desire to change that API element... and it's a simple one,
    which even makes creating the factory easy from JNI code. The more
    volatile code benefits from the compiler checks.

    Does that fit your needs?

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Jan 27, 2004
    #2
    1. Advertising

  3. Ian Pilcher

    Ian Pilcher Guest

    Chris Smith wrote:
    > So yes, you've still got an API element (the implicit no-argument
    > constructor to DefaultHandlerFactory) that has to match a specific
    > signature that is not checked at compile-time. However, you have no
    > need or desire to change that API element... and it's a simple one,
    > which even makes creating the factory easy from JNI code. The more
    > volatile code benefits from the compiler checks.


    I like the no-argument constructor idea. It allows me to move the
    initialization into an instance method, which can be in the interface.
    (I've got that why didn't I think of that feeling now.)

    I was about to write that that still leaves me with the static
    compatability checker, but, of course, that can be an instance method
    too now, since instantiating the class will be so lightweight.

    Great suggestion!

    > Does that fit your needs?


    What I really "need" is static methods in interfaces. This will
    certainly get me by for now.

    Thanks!

    --
    ========================================================================
    Ian Pilcher
    ========================================================================
     
    Ian Pilcher, Jan 27, 2004
    #3
  4. Ian Pilcher wrote:
    >
    > Chris Smith wrote:
    > > Does that fit your needs?

    >
    > What I really "need" is static methods in interfaces. This will
    > certainly get me by for now.


    You're not going to "get" static methods in interfaces. Google this group for the
    reasons, and for workarounds.

    --
    Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
    ==============================================================
    * The Ultimate DBMS is here!
    * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
     
    Lee Fesperman, Jan 27, 2004
    #4
  5. Ian Pilcher

    Ian Pilcher Guest

    Lee Fesperman wrote:
    >
    > You're not going to "get" static methods in interfaces. Google this group for the
    > reasons, and for workarounds.
    >


    Next you're going to tell me that Santa Claus doesn't really exist!

    --
    ========================================================================
    Ian Pilcher
    ========================================================================
     
    Ian Pilcher, Jan 28, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kai-Uwe Bux
    Replies:
    5
    Views:
    469
    Kai-Uwe Bux
    Aug 16, 2004
  2. Lodewijk Smit

    namespace check on compile time

    Lodewijk Smit, May 1, 2004, in forum: C Programming
    Replies:
    4
    Views:
    511
    Keith Thompson
    May 4, 2004
  3. flamesrock
    Replies:
    8
    Views:
    478
    Hendrik van Rooyen
    Nov 24, 2006
  4. Nagaraj
    Replies:
    1
    Views:
    879
    Lionel B
    Mar 1, 2007
  5. Carter
    Replies:
    2
    Views:
    510
    Carter
    Mar 4, 2009
Loading...

Share This Page