3. Java nach C++

Java nach C++

  • ?

    Hi,
    ich arbeite momentan an einer Arbeit über die Umsetzung von
    Java-Quelltexten
    nach C++-Quelltexten.
    Mich würde mal interessieren ob und wie ihr dass benutzen würden wenn eine
    Umsetzung fehlerfrei und ohne jeden Funktionalitätsverlust funktionieren
    würde.

    Da ich gerne aus euren Antworten in der Arbeit zitieren würde, währe es
    schön wenn ihr mir die Antworten per Mail zuschicken würdet (incl. Name und
    Position innerhalb der Firma)
    Ich verspreche dass ich die Adressen nicht weitergeben und als kleines
    Dankeschön kann ich auf Wunsch dann auch die Arbeit zuschicken.

    mfg
    Beutelratte

    0
  • G

    Beutelratte schrieb:

    wenn eine
    Umsetzung fehlerfrei und ohne jeden Funktionalitätsverlust funktionieren
    würde.

    Ich bin diesbezüglich sehr skeptisch. Kannst du mal zeigen, wie eine fehlerfreie Umsetzung nach C++ ohne jeden Funktionalitätsverlust bei folgendem kleinen Stück Javacode aussehen würde?!

    import java.lang.reflect.*;

public class ReflectTest
{
   public static void main(String[] args)
   {
      Method[] methods = getMethods(new Integer(0));
      for (int i = 0 ; i < methods.length ; ++i)
      {
         System.out.println(methods[i]);
      }
   }

   public static Method[] getMethods (final Object o)
   {
      Class clazz = o.getClass();
      return clazz.getMethods();
   }
}

    Der Output des Programms ist übrigens folgender:

    public int java.lang.Integer.hashCode()
public int java.lang.Integer.compareTo(java.lang.Integer)
public volatile int java.lang.Integer.compareTo(java.lang.Object)
public boolean java.lang.Integer.equals(java.lang.Object)
public static java.lang.String java.lang.Integer.toHexString(int)
public static java.lang.String java.lang.Integer.toString(int,int)
public static java.lang.String java.lang.Integer.toString(int)
public java.lang.String java.lang.Integer.toString()
public static java.lang.Integer java.lang.Integer.decode(java.lang.String) throws java.lang.NumberFormatException
public static java.lang.Integer java.lang.Integer.valueOf(java.lang.String,int) throws java.lang.NumberFormatException
public static java.lang.Integer java.lang.Integer.valueOf(java.lang.String) throws java.lang.NumberFormatException
public static java.lang.Integer java.lang.Integer.valueOf(int)
public static int java.lang.Integer.reverse(int)
public static int java.lang.Integer.reverseBytes(int)
public byte java.lang.Integer.byteValue()
public double java.lang.Integer.doubleValue()
public float java.lang.Integer.floatValue()
public int java.lang.Integer.intValue()
public long java.lang.Integer.longValue()
public short java.lang.Integer.shortValue()
public static int java.lang.Integer.parseInt(java.lang.String,int) throws java.lang.NumberFormatException
public static int java.lang.Integer.parseInt(java.lang.String) throws java.lang.NumberFormatException
public static int java.lang.Integer.bitCount(int)
public static java.lang.Integer java.lang.Integer.getInteger(java.lang.String)
public static java.lang.Integer java.lang.Integer.getInteger(java.lang.String,int)
public static java.lang.Integer java.lang.Integer.getInteger(java.lang.String,java.lang.Integer)
public static int java.lang.Integer.highestOneBit(int)
public static int java.lang.Integer.lowestOneBit(int)
public static int java.lang.Integer.numberOfLeadingZeros(int)
public static int java.lang.Integer.numberOfTrailingZeros(int)
public static int java.lang.Integer.rotateLeft(int,int)
public static int java.lang.Integer.rotateRight(int,int)
public static int java.lang.Integer.signum(int)
public static java.lang.String java.lang.Integer.toBinaryString(int)
public static java.lang.String java.lang.Integer.toOctalString(int)
public final native java.lang.Class java.lang.Object.getClass()
public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException
public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException
public final void java.lang.Object.wait() throws java.lang.InterruptedException
public final native void java.lang.Object.notify()
public final native void java.lang.Object.notifyAll()
    0
  • I

    Da kann ich Gregor nur zustimmen. Reflection wirst du nicht hinbekommen. Du bist dir schon im klaren, dass dein Vorhaben verdammt kompliziert ist?

    0
  • O

    wenn man mal vond er reflection absehen würde,es könnte doch gehen, oder?

    0
  • G

    otze schrieb:

    wenn man mal vond er reflection absehen würde,es könnte doch gehen, oder?

    Dein Vorschlag hört sich so an, als ob du denkst, dass Reflection ein unbedeutendes Sprachmittel ist, welches eh keiner nutzt. Das ist falsch. Reflection ist ein zentraler Bestandteil der Sprache, der mit den ab 5.0 verfügbaren Metadaten noch einmal an Relevanz zunimmt. Auch die etwas unschöne Implementierung der Generics wird die Nutzung von Reflection weiter erhöhen. Das heißt, dass es kein größeres Javaprogramm gibt bzw. geben wird, auf das die Einschränkung "keine Reflection" zutrifft. ...und wenn man doch so ein Programm findet, dann wird dieses Teile der Standardbibliothek nutzen, die Reflection brauchen.

    0
  • ?

    Reflections brauch man nicht.

    0
  • G

    Java Profi schrieb:

    Reflections brauch man nicht.

    Ok, du Java Profi. Dann schreib mal folgende triviale generische Java 5.0er Methode ohne Reflection:

    public static <T> T[] arrayTest(T testObject)
{
   return (T[]) Array.newInstance(testObject.getClass(),10);
}
    0
  • ?

    Java Profi schrieb:

    Reflections brauch man nicht.

    <ironie>Genau! Schleifen braucht man auch nicht. Kann man schön über Rekursion lösen! </ironie>

    0
  • ?

    Die Frage wurde doch vor einiger Zeit haargenau so in de.comp.lang.iso-c++ gepostet. Daher Troll oder Crossposter...

    0
  • D

    Reflection nachbauen ist nicht so schwierig, nur aufwendig, da du jede Methode der Reflection API neu schreiben musst.
    Man muss halt für jede Klasse alle nötigen Informationen, die man für Reflections braucht, irgendwo speichern, damit man dann zur Laufzeit drauf zu greifen kann.

    Es geht mit Sicherheit. Die Frage ist nur ob es Sinn macht, da man zum Nachbau der kompletten Funktionalität wahrscheinlich einige ineffiziente Verfahren verwenden muss, die die Performance senken. Ausserdem müsste man entweder den Bytecode oder den Quellcode der Java Runtime ebenfalls kompilieren, was eventuell gegen Suns Lizenzbedingungen verstösst.

    Ich sehe da keine Vorteile, ausser dass man Reverse Engineering erschwert.

    0
  • G

    DrZoidberg schrieb:

    Reflection nachbauen ist nicht so schwierig, nur aufwendig, da du jede Methode der Reflection API neu schreiben musst.
    Man muss halt für jede Klasse alle nötigen Informationen, die man für Reflections braucht, irgendwo speichern, damit man dann zur Laufzeit drauf zu greifen kann.

    Es geht mit Sicherheit. Die Frage ist nur ob es Sinn macht, da man zum Nachbau der kompletten Funktionalität wahrscheinlich einige ineffiziente Verfahren verwenden muss, die die Performance senken. Ausserdem müsste man entweder den Bytecode oder den Quellcode der Java Runtime ebenfalls kompilieren, was eventuell gegen Suns Lizenzbedingungen verstösst.

    Ich sehe da keine Vorteile, ausser dass man Reverse Engineering erschwert.

    Schön und gut. Die Lösung, Java nach C++ umzusetzen ist, irgendwelche Eweiterungen zu C++ hinzuzufügen, so dass es am Schluss nicht mehr C++ ist und ein einfaches Kompilieren mit einem C++ Compiler nicht mehr ausreicht (du brauchst zum Beispiel mindestens irgendeine Vorstufe beim Kompilieren, um die Informationen über die Klassen usw. zu erzeugen, die du irgendwo abspeichern möchtest). Mit anderen Worten: Man erzeugt dann keinen C++ Code mehr, sondern baut sich eine neue Sprache, für die man dann Code erhält. Das ist ja auch nicht die einzige Erweiterung, die man braucht. Man muss irgendwelche Bibliotheken zum C++ Standard hinzufügen, die einem die Funktionalität der Java Standardbibliothek (z.B. Threads usw.) zur Verfügung stellen, man benötigt vermutlich einen GC, man benötigt einen Java-Bytecode-To-Native-Code-Compiler und ab Java 6.0 einen Java-Code-To-Native-Code-Compiler usw.! Mit den ganzen Dingen, die man nachbauen muss, wird am Schluss etwas wirklich grausames rauskommen. Etwas, was für keinen Menschen mehr nutzbar ist, was dafür aber extrem komplex ist und einen riesigen Overhead mitbringt.

    ...und wofür das alles?! Ehrlich gesagt habe ich keine Ahnung, was man sich davon verspricht. Performance vielleicht? Die kriegt man dadurch niemals.

    @DrZoidberg: Bezüglich des ReverseEngineerings: Spielst du darauf an, dass Java-Bytecode relativ leicht in Java-Code zurücktransformiert werden kann? Wenn ja: Es gibt Obfuscator und Java-Native-Compiler.

    0
  • D

    Gregor schrieb:

    Schön und gut. Die Lösung, Java nach C++ umzusetzen ist, irgendwelche Eweiterungen zu C++ hinzuzufügen, so dass es am Schluss nicht mehr C++ ist und ein einfaches Kompilieren mit einem C++ Compiler nicht mehr ausreicht (du brauchst zum Beispiel mindestens irgendeine Vorstufe beim Kompilieren, um die Informationen über die Klassen usw. zu erzeugen, die du irgendwo abspeichern möchtest). Mit anderen Worten: Man erzeugt dann keinen C++ Code mehr, sondern baut sich eine neue Sprache, für die man dann Code erhält.

    Nein. Vom Erstellen einer neuen Sprache habe ich nicht geredet. Das Ergebnis sollte schon standardkonformer C++ Code sein.
    Die Informationen über die Klassen erzeugt der Java nach C++ Übersetzer und fügt sie in den C++ Quellcode ein.

    Das ist ja auch nicht die einzige Erweiterung, die man braucht. Man muss irgendwelche Bibliotheken zum C++ Standard hinzufügen,

    Muss man doch bei fast allen C++ Programmen.
    Im Ansi C++ Standard sind schliesslich nicht mal GUI Elemente enthalten.

    , man benötigt vermutlich einen GC, man benötigt einen Java-Bytecode-To-Native-Code-Compiler und ab Java 6.0 einen Java-Code-To-Native-Code-Compiler usw.! Mit den ganzen Dingen, die man nachbauen muss, wird am Schluss etwas wirklich grausames rauskommen. Etwas, was für keinen Menschen mehr nutzbar ist, was dafür aber extrem komplex ist und einen riesigen Overhead mitbringt.

    schon möglich. Ich muss das glücklicherweise nicht schreiben.

    @DrZoidberg: Bezüglich des ReverseEngineerings: Spielst du darauf an, dass Java-Bytecode relativ leicht in Java-Code zurücktransformiert werden kann? Wenn ja: Es gibt Obfuscator und Java-Native-Compiler.

    Mit nem Java-Native-Compiler hat man aber wieder ähnliche Probleme, wie mit einem Java-C++ Übersetzer. Aber immerhin muss ich das Teil dann nicht selbst schreiben.

    0
  • G

    DrZoidberg schrieb:

    Die Informationen über die Klassen erzeugt der Java nach C++ Übersetzer und fügt sie in den C++ Quellcode ein.

    Ich habe so wenig Vorstellungskraft. Zeig mal an einem einfachen Beispiel, wie das aussehen soll.

    0
  • ?

    kann der gjc reflections?

    0
  • ?

    Soll das ne Diplom/Doktorarbeit werden?
    Denn genau in diesem Schwierigkeitsbereich wäre das einzuordnen

    0
  • D

    Gregor schrieb:

    DrZoidberg schrieb:

    Die Informationen über die Klassen erzeugt der Java nach C++ Übersetzer und fügt sie in den C++ Quellcode ein.

    Ich habe so wenig Vorstellungskraft. Zeig mal an einem einfachen Beispiel, wie das aussehen soll.

    Also erstmal halte ich eine Umsetzung nach C für sinnvoller als nach C++. Da sich Klassen, Templates usw. in C++ sowieso anders verhalten als in Java, muss man es eh selbst implementieren.
    Was ich im Sinn habe ist eher ein Java Compiler, der aber anstelle von ASM/Maschinencode C-Code produziert und dadurch den Vorteil hat, dass er leichter zu portieren ist und dass man die meisten Optimierungen, die eines der aufwendigsten Teile eines Compilers sind, nicht selbst schreiben muss.

    Man könnte für jede Klasse und jedes Objekt jeweils ein Struct anlegen. Ein Objekt enthält unter anderem einen Zeiger auf ein Class Object, das ebenfalls als Struct gespeichert wird. Das Class Objekt enthält einen Zeiger auf ein Array, das alle Methodennamen enthält.

    0
  • G

    Soll der Compiler denn nur compilierbaren C++-Code erzeugen, oder C++-Code, der zur Weiterprogrammierung geeignet sein soll?
    Willst Du das gesamte Java-Framework (API) neu implementieren, oder weiterhin dagegen linken?

    0
  • ?

    Beutelratte schrieb:

    Hi,
    ich arbeite momentan an einer Arbeit über die Umsetzung von
    Java-Quelltexten
    nach C++-Quelltexten.
    Mich würde mal interessieren ob und wie ihr dass benutzen würden wenn eine
    Umsetzung fehlerfrei und ohne jeden Funktionalitätsverlust funktionieren
    würde.

    ACDK koennte genau das sein, was Du suchst:

    http://acdk.sourceforge.net

    Eine Liste der Features:
    http://acdk.sourceforge.net/acdk/docs/hb/intro/acdk_about_features.html

    0
Anmelden zum Antworten