Cooper, ObjectPascal für Java...o.O

[Memnarch]

Tag allerseits.
Ich glaube ich habe gerade eben das erste mal was über Cooper gelesen.
Kann mir das einer genauer erklären wie das funktioniert?

Also wird ObjectPascal als scriptsprache benutzt und interpretiert, oder gibts es da eine art Compiler der das ganze nach java übersetzt?

MFG
Memnarch

[Phoenix]

Cooper ist technisch gesehen einfach ein neues Backend für den Oxygene-Compiler aus Delphi Prism. Nur anstelle .NET Assemblies zu konsumieren und hinten IL rauszuwerden konsumiert er eben .jar Files und schreibt hinten echten Java-Bytecode.

Es ist also ein echter Object Pascal (Oxygene-Language) Compiler für die Java Runtime (und die Java-basierte Dalvik-Runtime für Android).

Dass das wirklich funktioniert sieht man z.B. hier: http://www.remobjects.com/tv/oxygene...ne-06-cooper3d
Am besten schaust Du auf dem Oxygene-Channel mal alle Cooper-Videos an. Sind nur ein paar Minuten :)

[Memnarch]

Bin gerade auf der arbeit, deswegen hatte ich nur mal kurz 1/2 videos überflogen.
Interressant ist es schon. Bin ja sowieso ein Fan von Java^^(da muss ich mir als entwickler keine sorgen um die OS implementierung machen, das übernimmt Oracle(früher SUN).

Und da es ja auch die JMonkeyengine gibt(die dort ja auch gezeigt wird), hat java sogar ne flotte OpenGL anbindung, was es auch für spielereien ansprechbar macht(ach wie schön...ein game 1mal programmieren, auf X-Platformen ausführen)

[Memnarch]

Tschuldige doppelpost aber den comment auf der seite weiter unten finde ich geil:

http://blogs.remobjects.com/blogs/jim/2011/04/22/p2324

Zitat:

The .NET Dependency is because the compiler itself is written in Oxygene (Object Pascal for .NET). Once the compiler is finished then it could be used to recompile itself as a Java jar file. When that happens then it will no longer have any .NET dependencies.

DAs ist doch mal ne metamorphose :D.
Natürlich ist es eine logischere schlussfolgerung wenn OPascal für .Net und OPascal für Java den selben standarts folgen, aber es ist einfach

Zitat:

Zitat von Spok

Faszinierend

MFG
Memnarch

[Phoenix]

Zitat:

Zitat von Memnarch (Beitrag 1109132)

Zitat:

The .NET Dependency is because the compiler itself is written in Oxygene (Object Pascal for .NET). Once the compiler is finished then it could be used to recompile itself as a Java jar file. When that happens then it will no longer have any .NET dependencies.

DAs ist doch mal ne metamorphose :D.

Das wird so schnell aber wohl nicht passieren. Schliesslich benutzt der Compiler ziemlich viel an .NET Klassen. Natürlich könnte man die Dictionaries etc. alle nochmal plattformunabhängig wegkapseln, aber das ist natürlich nochmal ein zusätzlicher Aufwand. So schnell wird es also keinen Java-Basierten Compiler geben. Ist aber auch nicht nötig, weil der Compiler dank Mono ja eh auf jeder Plattform läuft.

Darüber hinaus wird es aber auch noch zusätzliche Libraries geben, die gängige .NET Klassen für Java bereitstellen. So ähnlich wie ShineOn einige RTL-Funktionen für .NET bereitstellt wird "xxx" (Aktueller Codename in der Beta: Twin Peaks) z.B. den StringBuilder oder generische Listen etc. Schnittstellenkompatibel zu den .NET Framework-Klassen in Java bereitstellen.

[hanspeter]

Zitat:

Zitat von Phoenix (Beitrag 1109124)

Cooper ist technisch gesehen einfach ein neues Backend für den Oxygene-Compiler aus Delphi Prism. Nur anstelle .NET Assemblies zu konsumieren und hinten IL rauszuwerden konsumiert er eben .jar Files und schreibt hinten echten Java-Bytecode.

Was jetzt noch fehlt ist ein Backend für native Pogramme, die gegen die VCL, QT, WPF oder ein ähnliches Framework für die Oberfläche compiliert werden.
Dann hätte man eine moderne Pascal Sprachbasis, so stört die mangelnde Sprachkompatibilität zwischen Delphi und Prism achon ein wenig.

Peter

[mkinzler]

Dann würde man aber die Rückwärtskompatibilität verlieren

[Phoenix]

Also wenn Du Gtk benutzt geht das. Musst nur den Full-Ahead-Of-Time compiler von Mono über das Ergebnis laufen lassen und hast eine einzige .exe die läuft. So wie bei Delphi mit einkompilierter RTL&VCL wird dann das benötigte Zeug direkt durchkompiliert und läuft ohne Prereqs auf dem Zielsystem. Wird halt was größer, ist aber letzlich so native wie es nur sein kann.