Package switching

[datafiddler]

Szenario:
In einem package my.client werden Objekte/Methoden in einem package my.basepack verwendet.
my.basepack gibt es in zwei Varianten a) direkt b) via RMI.

Im RMI - Fall gibt es einen RMI Server, der selbst Variante basepack (direkt) verwendet, und ein Interface remote.basepack implementiert. Ein Client package verwendet remote.basepack, um damit für my.client my.basepack (via RMI) zu implementieren.

Je nach classpath bzw. Zusammenstellung des jar files wird die eine oder die andere Variante verwendet.

Der Grund: basepack läuft nur auf Windows (mit JNI Komponenten) , client soll plattformunabhängig sein, aber wenn möglich auf den RMI overhead verzichten.

Soweit verständlich? Falls ja: Dringende Kommentare angebracht?


Nun mein Problem:
Es wäre gut, wenn zwischen beiden Varianten erst beim Start und nicht bei der Installation entschieden werden könnte, oder nach dem Start in einer my.client.Init() Methode. Das my.client package sollte aber ansonsten möglichst unverändert bleiben.

Mein Verdacht:
- unterschiedlicher Code sollte (unbedingt?) unterschiedliche package Namen haben ?
- Das my.basepack Interface sollte durch eine Weiche ("SwitchWrapper") implementiert werden, die entweder my.direct.basepack oder my.remote.basepack aufruft ...

Meine Fragen:
1) geht es auch einfacher, eleganter, als durch den "SwitchWrapper" ?
2) bin ich auf einem Holzweg, sind zwei verschiedene jar Dateien der eindeutig bessere Weg ?
3) falls 1) und 2) ja: wie kann ein client eine von mehreren Bibliotheken (mit gleichen Objekten) gezielt laden ?

4) Any other comment ?

 

[mvitz]

Nur nochmal zum besseren Verständnis:

Du hast z.B. eine Klasse
my.basepack.DoSomething

public class DoSomething {
    public void execute() {...}
}

und eine Klasse
my.client.UseDoSomething

public class UseDoSomething {
    public static void main(String[] args) {
        ...
        DoSomething doSomething = ...;
        doSomething.execute();
        ...
    }
}

Jetzt soll DoSomething wenn der Client auf Windows läuft direkt JNI verwenden, und wenn nicht, dann per RMI mit einem Server (der dann auf Windows läuft) kommunizieren?

Wenn das der Fall ist, dann macht man das idr so:
Interface: my.basepack.DoSomething

public interface DoSomething {
    void execute();
}

Klasse: my.basepack.impl.JNIDoSomething

public class JNIDoSomething implements DoSomething {
    public void execute() {
        // use JNI do do something
    }
}

Klasse: my.basepack.impl.RMIDoSomething

public class RMIDoSomething implements DoSomething {
    public void execute() {
        // use RMI do do something
    }
}

Klasse: my.basepack.DoSomethingFactory

public final class DoSomethingFactory {
    private DoSomethingFactory() {}
    public static DoSomething getInstance() {
        if (isWindows) return new JNIDoSomething();
        return RMIDoSomething();
    }
}

Dein Client sähe dann so aus:
Klasse: my.client.UseDoSomething

public class UseDoSomething {
    public static void main(String[] args) {
        ...
        DoSomething doSomething = DoSomethingFactory.getInstance();
        doSomething.execute();
        ...
    }
}

Edit:
Wenn du dann doch verschiedene Dateien für Windows/andere OS machst, dann kannst du dir die Factory sparen und z.B. die passende Implementierung für das Interface mit dem Java ServiceLoader holen ServiceLoader (Java Platform SE 6)

 

[datafiddler]

Ja, mvitz, das ist sehr hilfreich. Danke.
Der Ansatz mit einer Factory statt direkt den c'tor aufzurufen ist schon die richtige Richtung, schätze ich.

ClassLoader "Tricksereien" waren mit bisher zu kompliziert,aber während der Formulierung meiner Frage 3) kam mir der Verdacht, dass ich da mal schauen sollte...
ServiceLoader kenn ich auch (noch) nicht, sollte ich mir aber wohl auch ansehen, danke für den Link

-----------------------
Können wir den Thread hier lassen, oder gehört er ins Anfänger-forum ?

 

[mvitz]

Im Endeffekt erspart dir der ServiceLoader Tricksereien mit eigenen Classloadern indem er dir eben "registrierte" Implementierungen für ein Interface direkt gibt. Im Endeffekt ist es eben die Frage, was bei dir praktischer/einfacher ist.

Zur Laufzeit unterscheiden, auf welchem OS der Code gerade ausgeführt wird oder ein Win und ein Generic Package zu schnüren und der Nutzer lädt dann das richtige package runter. Für Fall 1) eben eine Factory bauen, die zwischen den OSen unterscheidet und die passende Implementierung zurück gibt, für Fall 2 würde ich den ServiceLoader Mechanismus nutzen.

 

[datafiddler]

Im Endeffekt ... ist es eben die Frage, was praktischer/einfacher ist.

...ein Win und ein Generic Package zu schnüren und der Nutzer lädt dann das richtige package runter...

... ist mein derzeitiger Stand

... eben eine Factory bauen, die zwischen den OSen unterscheidet und die passende Implementierung zurück gibt

... müsste auch anders gesteuert werden können, so dass ich auch die RMI Variante auf Windows testen kann.

Auch: Zwar ist ein jar file für alle Fälle viel einfacher als zwei, aber der zugehörige windows rmi server mit jni dll will auch richtig installiert sein.

Auf jeden Fall erstmal unter dem "offiziellen Namen" nur das gemeinsame Interface definieren, und die Implementierungen separieren !


Danke nochmals für die schnellen Tips.

 

[datafiddler]

... ist mein derzeitiger Stand
Auf jeden Fall erstmal unter dem "offiziellen Namen" nur das gemeinsame Interface definieren, und die Implementierungen separieren !

Bei näherer Betrachtung habe ich da Schwierigkeiten. (sollte vielleicht doch ins AnfängerForum ?)

Also: ich habe ein Interface

import java.rmi.Remote;
import java.rmi.RemoteException;
public interface MyClass extends Remote {
  public int myMethod() throws RemoteException ;
}

... dessen Implementierung auf dem RMI Server läuft und, wenn ich ein Remote Objekt über lookup habe, auch von einem Client verwendet werden kann.

Nun will ich eine ähnliche Implementierung auch lokal auf dem Client haben.

Das gemeinsame Interface wäre:

public interface MyClass {
  public int myMethod() ;
}

und das RMI Interface:

import java.rmi.Remote;
import java.rmi.RemoteException;
public interface RMyClass extends Remote, MyClass {
  @Override
  public int myMethod() throws RemoteException;
}

Nun meckert Eclipse, dass entweder die Basis myMethod als "throws RemoteException" deklariert werden soll oder dieser Vermerk im Interface RMyClass entfernt werden muss ???

Aber geht dann ( ohne throws RemoteException ) überhaupt ein als RMyClass implementiertes Object

  MyClass mightbeRemote = getItSomehow();
  int result = mightbeRemote.myMethod();

???

oder muss bereits MyClass.myMethod als "throws RemoteException;" deklariert werden, obwohl direkte Implementierungen überhaupt nichts von RemoteException wissen

???

 

[mvitz]

Das ist das Problem, das RMI Methoden immer diese doofe Exception werfen müssen. Aus diesem Grunde müsste man da vermutlich folgenden Ansatz nehmen:

Dein "wirkliches" Interface

public interface DoSomething {
    int doSomething();
}

Das "RMI" Interface

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface DoSomethingOverRMI extends Remote {
    int doSomething() throws RemoteException;
}

Dann brauchst du für den RMI Dienst ja noch die implementierende Server und Client Klassen:
Client:

public final class RMIDoSomething implements DoSomething {
    @Override
    public int doSomething() {
        try {
            // look up RMI classes
            return rmiInterface.doSomething(); //rmiInterface is of type DoSomethingOverRMI
        } catch (RemoteException ex) {
            throw new RuntimeException("Exception talking with RMI.", ex);
        }
    }
}

Und die RMI Server Variante

public final class DoSomethingRmiServer implements DoSomethingOverRMI {
    @Override
    public int doSomething() throws Exception {
        DoSomething d = new JNDIDoSomething();
        return d.doSomething();
    }
}

 

[datafiddler]

Ein Interface wie dein DoSomethingOverRMI wird in jedem Fall gebraucht, es muss gar nicht

 extends DoSomething

sein.

Allerdings ersetzt dies die RMIException durch eine RuntimeException.

Ein Client, der

DoSomething myObj = getItSomeHow();
myObj.doSomething();

aufruft, muss in jedem Fall damit rechnen, dass eine Exception zuschlägt.
Im lokalen Fall tritt es halt nicht so häufig auf (oder kommt direkt aus dem Native Code)

throws RemoteException

im interface DoSomething zu deklarieren, schadet andererseits auch nicht.

Dadurch würde auf der Client Seite die Klasse RMIDoSomething entfallen. myObj.doSomething() wäre dann bereits Remote.


Danke für dein Feedback und die Anregung.