Dynamisches casten

[Alex04]

Hallo,
ich würde gern wissen ob man in java dynamisch casten kann.
Warum zeig ich euch:

Diese Methode liest ein Objekt aus einem file (binär):

static public Object readBinaryFile(String pHandler, String pClass) throws Exception {
		Object lResult = null;
		if(!mMap.containsKey(pHandler)) {
			throw new Exception("Can not read binary-file for handler " + pHandler + " because handler does not exist!");
		}
		else {
			FileInputStream lFileInput = new FileInputStream(mMap.get(pHandler));
			ObjectInputStream lObjectInput = new ObjectInputStream(lFileInput);
			lResult = lObjectInput.readObject();
			
			lObjectInput.close();
			lFileInput.close();
		}

		return lResult;

	}

So in lResult ist also das gelesene Objekt vorhanden.
Problem ist, dass diese Methode von einer anderen Sprache aufgerufen wird in der es keine Castings gibt.
D.h. ich muss innerhalb dieser Methode casten und das richtige Objekt zurückliefern.
Um welche Klasse es sich handelt wird in dem Parameter pClass mit übergeben.

Ist sowas überhaupt möglich?
Also umgangssprachlich formuliert:
[Java]
pClass lErgebnis = (pClass) lResult;
[/code]

Natürlich muss die Methode auch entsprechend variable typen zurückgeben...

Wäre wirklich dankbar für eure Hilfe!

Mfg
Alex

 

[bygones]

@SuppressWarning("unchecked")
static public <T> T readBinaryFile(String pHandler, String pClass) throws Exception {
// code
return (T)lResult;

 

[Alex04]

Einwandfrei, vielen lieben Dank!

 

[Atze]

biste dir sicher, bygones?
jetzt wird doch nicht anhand von pClass entschieden, welcher typ das ist, oder steh ich aufm schlauch?
müsste doch wenn dann

Class classDefinition = Class.forName(pClass);
Object object = classDefinition.newInstance();

static public <T> T readBinaryFile(String pHandler, T object) throws Exception {
// code
return (T)lResult;

heißen, aber dann müsste er den typ übergeben, so in der art? oder hab ich zuwenig geschlafen??

 

[SlaterB]

der Typ richtet sich nach dem Wunsch des Aufrufers:

String test = loadObject(handler); // funktioniert allein mit <T>

String test = loadObject(handler, String.class);
String test = loadObject(handler, Integer.class); // ginge beides auch, aber unnötig, Parameter wird eh ignoriert

natürlich kann man auch voraussetzen dass der Parameter passt (Class<T>), aber das ist doch eher unnötig

 

[bygones]

hab mir die methode nicht richtig angeschaut... stimmt - der 2. Parameter ist dann nutzlos

 

[Alex04]

Jop, hätt ich vielleicht dazu sagen sollen, die Methode sieht so aus:

static public <T> T readBinaryFile(String pHandler) throws Exception {
.......
			lResult = lObjectInput.readObject();
			lObjectInput.close();
			lFileInput.close();
........

		return (T)lResult;

	}

 

[Atze]

aber woher weiß der interpreter, was T ist??
ich hab gelernt, dass das einem übergebenen objekt bestimmt wird.

ich rall es einfach nicht

 

[maki]

aber woher weiß der interpreter, was T ist??

Für den "Interpreter", also JVM, ist jeder generische typ ein Object -> Type erasure

Der Compiler kann allerdings durch Type Inference feststellen, ob der Typ passt

 

[Atze]

ja, dass generics nur zur compilezeit feststehen ist schon klar, aber ich check den ablauf zur laufzeit nicht

wenn ich zur laufzeit (..., T object) mitgebe, weiß er durch T == T, dass er auch den selben typ zum cast nutzen soll. wenn ich aber nichts übergebe, und er bekommt nichts, woher weiß er dann, worauf gecastet werden soll?

 

[maki]

static public <T> T readBinaryFile(String pHandler) throws Exception

Dafür ist <T> da

 

[SlaterB]

richtig erklären kann man das wohl zumindest mit einfachen Mitteln (ohne tiefe Regelwerke) nicht,
das <T> bedeutet, dass Java hier mal den Typ gut raten/ ableiten soll

public class Test
{
    static <T>T getT()
    {
        return null;
    }

    public String getString1()
    {
        String st = getT();  // geht
        return st;
    }

    public String getString2()
    {
        return getT(); // geht
    }

    public X getString3()
    {
        X x = new X(getT());  // geht leider nicht

        String st = getT();
        X y = new X(st);  // geht
    }

    class X
    {
        public X(String st) {}
    }
}

 

[Atze]

jaaa, das sag ich doch, das T object (aus meiner Version) ist ja dort nicht drin und es funzt, aber wie, kann mir einer die "schritte" aufzeigen?

bei meiner version erkläre ich mir das so:

t object kommt zu laufzeit und er hat den typ
typ wird für die rückgabe verwendet

bei der anderen:
keine übergabe, keine information
wo kommt die info her, aus der zuweisung beim aufruf?

ich glaub steh wirklich auf dem schlauch. gibts da ne nachvollziehbare erklärung, oder muss ich das einfach so hinnehmen?

*danke@slater: ich nehm das dann mal so hin*

*Update*
neue frage, wie ruft man die methode auf? worauf weißt man sie zu, wenn man nichts übergibt?
bei meiner version bekomme ich das raus, was ich als 2 parameter reingebe (zb methode zum verarbeiten von versch. typen)

aber wem weißt man diese methode auf? object?

wäre "eure" lösung nicht vollkommen äquivalent zu:

static public Object readBinaryFile(String pHandler) throws Exception {
.......
            lResult = lObjectInput.readObject();
            lObjectInput.close();
            lFileInput.close();
........
 
        return lResult;
 
    }

???
dann kann ich auch auf die generics verzichten und er wäre am anfang

 

[bygones]

neue frage, wie ruft man die methode auf? worauf weißt man sie zu, wenn man nichts übergibt?
bei meiner version bekomme ich das raus, was ich als 2 parameter reingebe (zb methode zum verarbeiten von versch. typen)

man muss nix machen... java erledigt das - siehe Slaters bsp. Wenn ich das Ergebnis als String speicher ist T == String, wenn mans als Integer speicher T == INteger

 

[Atze]

ok, also dann doch am aufruf, dann hab ich ja was handfestes danke bygones
aber gewonnen hab ich ja dadurch auch keine dynamik, da ich ja dann die zuweisung "hart codieren" muss, und damit die rückgabe festlege das problem ist damit nur verlagert, oder? hätte mir nur das casten gespart

*edit* ups, darum gings ja wohl! egal, wenns ihm hilft! hab nur nicht verstanden, dass es am aufruf stimmt wird. danke für eure infos

 

[maki]

ok, also dann doch am aufruf, dann hab ich ja was handfestes danke bygones
aber gewonnen hab ich ja dadurch auch keine dynamik, da ich ja dann die zuweisung "hart codieren" muss, und damit die rückgabe festlege das problem ist damit nur verlagert, oder? hätte mir nur das casten gespart

Nein, dynamisch ist es nicht, aber trotzdem sicherer als mit einem Cast, den bei einem Cast kann der Compiler nicht überprüfen ob das so auch geht

 

[Atze]

ja, ist schon richtig! hab nur die dynamik vermisst! aber jetzt ist alles gut, danke

 

[Atze]

ihhh, smiley-suppe pause, ich geh eine rauchen

 

[bygones]

es muss nicht immer alles ueber dynamisch sein ;-)

 

[Atze]

bin ja schon ruhig