Kümmer ihr euch um Free-Java Kompatibilität?

**bischi** · 22-03-2005, 21:45

Mal so ne Frage (hab mich bis jetzt noch nicht damit beschäftigt): Was muss ich mir eigentlich genau unter C# vorstellen? Wie ist die Sprache aufgebaut? Gibt es eine so schöne Doku wie für Java? Oder ist das ganze wieder einmal auf C aufgebaut und somit so schön "gebastelt" wie C++ (Nein - kein Java C++-Flame - aber C++ ist nun einmal weniger systematisch aufgebaut, man denke da nur an die mühsame OOP-Implementation...).

MfG Bischi

**BeS** · 22-03-2005, 22:30

Zitat von bischi

Mal so ne Frage (hab mich bis jetzt noch nicht damit beschäftigt): Was muss ich mir eigentlich genau unter C# vorstellen? Wie ist die Sprache aufgebaut? Gibt es eine so schöne Doku wie für Java? Oder ist das ganze wieder einmal auf C aufgebaut und somit so schön "gebastelt" wie C++ (Nein - kein Java C++-Flame - aber C++ ist nun einmal weniger systematisch aufgebaut, man denke da nur an die mühsame OOP-Implementation...).

C# ist eigentlich mehr Java als C oder C++.

Hier zwei Links die C# mit Java vergleichen:
http://www.25hoursaday.com/CsharpVsJava.html
http://genamics.com/developer/csharp_comparative.htm

oder ein Online-Buch zu C# wenn du dir etwas code ansehen willst:
http://www.galileocomputing.de/openbook/csharp/

Das meiste sollte einem java Programmierer ziemlich bekannt vorkommen.
Die Doku finde ich von monodoc eigentlich ganz gut (wobei es natürlich auch noch lücken gibt), da habe ich bisher immer alles gefunden was ich gesucht habe. MS wird sicher auch eine Doku haben, die habe ich mir aber noch nicht angesehen.

**peschmae** · 23-03-2005, 06:18

Ich habe kürzlich (auf DFde war das glaubich) ein ganz simples C# Programm nach Java portiert.
Das beschränkte sich auf ersetzen von Ausgabemethoden durch system.out.println und abändern der Deklaration von Arrays. Der Rest war ziemlich genau gleich.

MfG Peschmä

**anda_skoa** · 23-03-2005, 13:40

Zitat von BeS

Naja, das Marketing ist Novell sein Problem und mir als Anwender eigentlich relativ egal.

Für dich als Entwickler, der den Unterschied kennt, wohl war.

Die meisten in der windows Welt unterscheiden halt nicht groß und kennen nur .Net und denen sagt man dann halt das Mono eine Plattformunabhängige .Net implementierung ist. Darunter kann sich der windows-user was vorstellen und damit ist das Ziel erreicht.

Genau das ist aber der Anfang vom Problem. Der weniger informierte, besonderes irgendwelche "Entscheider", sollten auf keinen Fall Mono als .Net Implementierun sehen.

Wenn er sich dann mit Mono beschäftigt, dann wird er schon die Vor- und Nachteile kennen lernen.

Wenn er sich damit beschäftigt wäre das kein Problem.
Die Teufelei ist die unwidersprochene Behauptung, Mono sei .Net nur crossplatform.

Dadurch erhalten Entwickler und Entscheider den falschen Eindruck, nämlich durch Entwicklung auf der .Net Plattform in Zukunft offen für andere Plattformen zu sein, was aber bekanntlich nicht der Fall ist.

Umgekehrt wäre das natürlich richtig, eine Software auf Mono Basis wird mit nahe 100% Wahrscheinlichkeit auch unter .Net laufen.

Durch die Unachtsamkeit im derzeitigen Monomarketing ensteht leider der Eindruck, daß das auch andersrum gilt. Dieser Eindruck hilft aber einzig und alleine nur Micosoft.

Die werden das tun, was sie bei Java schon versucht haben: ihre Plattform durch Classlibs zu erweitern, die nur sie zur Verfügung stellen können oder dürfen, aber durch die Inklusion in ihren SDK so aussehen lassen, als wären es Standardkomponenten.

Der weniger informierte Entwickler ist dann trotz seiner ursprüngliche Intention an eine Platform gebunden, bzw. hat einen großen bis enormen Aufwand seine Software davon wieder zu lösen.

Inwiefern es als Mono langfristig hilft wenn die einzige CLI Implementation die benutz wird die von .Net ist, ist mir ziemlich schleierhaft, aber vermutlich ist längerfristige Planung in den USA nicht so in.

Das ist ähnlich wie wenn man mit jemand das erstemal über GNU/Linux redet, dann wird GNU, Freie Software, Open Source und die ganze Philosophie auch meistens weg gelassen oder nur sehr verkürzt und bildlich dargestellt.

Das ist nicht vergleichbar, so sehr die Philosphie in diesne Fällen ansich wichtig wäre, macht sie für die Zielgruppe vielleicht keinen Unterschied.
Für die Zielgruppe Windowsentwickler in der Evaluierungsphase für eine neue Entwicklungsbasis hat der Unterschied zwischen "eine .Net Implementation" und "eine zu .Net ähnliche Implementation der EMCA CLI" sehr wohl eine Bedeutung.

Für mich ist Mono mit der C# Implementierung, der CLI, GTk#, gst#,... ,ASP.NET, ADO.NET

Wenn das korrekt ist, wäre das vermutlich eher angebracht als dieses derzeitige in die Falle locken.

Mehr brauch ich nicht. Wenn in ASP.NET die letzten 3 Funktionen der MS Version noch nicht implementiert sind, dann ist mit das ziemlich egal, da ich sie eh nicht kenne

Wie gesagt bist du nicht gefährdet, weil du aus der anderen Richtung kommst.

Wenn jetzt z.B. jemand Server Systeme mit windows und GNU/Linux hat, was wird er nehmen?

Zu dem Zeitpunkt an dem diese Entscheidung zum Beispiel auf Grund eines Kundenwunsches ensteht, hat der .Net gebundene Hersteller diese Wahl nicht mehr.

Durch Mono hat man aber auch die Option Mono/.Net. Dann kann man unter Mono entwickeln und die Programme dann unter Mono auf den GNU/Linux Systemen laufen lassen und unter windows .Net oder auch Mono verwenden.

Vollkommen deiner Meinung.
Durch die Ungenauigkeiten im derzeitigen Mono Marketing existiert diese Alternative auf Dauer nur für Monobasierte Entwickler, nicht mehr für die blauäugig in die Falle getappten .Net basierten Entwickler unter Windows.

MS hat dadurch auch nur Vorteile.

Absolut!
Nur ist mir noch nicht klar, warum die Monoentwickler versuchem zum Schaden andere Plattformen Microsoft Vorteile zu verschaffen.

Ciao,
_

**BeS** · 23-03-2005, 16:49

Zitat von anda_skoa

Absolut!
Nur ist mir noch nicht klar, warum die Monoentwickler versuchem zum Schaden andere Plattformen Microsoft Vorteile zu verschaffen.

Ich denke wir sind uns da im großen und ganzen ziemlich einig.
Den Schaden sehe ich aber nicht.
Meiner Meinung nach macht Novell zwei Sachen:
1. Sie bieten der Freien Softwareentwicklung ein neues und durchaus interessantes Werkzeug an, dass auch einem offenen Standard basiert. Das ist doch erstmal toll und damit sind wir zu 100% bedient.
2. Sie wollen auch Kunden auf dem MS Markt gewinnen, damit diese auch Mono anstelle von .Net nehmen und Novell damit Kunden bekommt. Das machen sie indem sie ihnen eine "Plattformunabhängige .Net Technologie" verkaufen. Das ziel von Novell ist aber nicht eine .Net/Mono Mischkultur sondern sie wollen natürlich nur Mono verkaufen und das erreichen sie mit dieser Strategie. Der Kunde hat schon was von .Net gehört und hört jetzt von einem plattformunabhängigen Mono und sagt toll, jetzt habe ich die Auswahl zwischen java, .Net und Mono, da er mehrere Plattformen bedienen will fällt .Net weg und mit etwas Glück (für Novell) wird er sich für Mono entscheiden.
Ein Schaden für Punkt 1 entsteht daraus in meinen Augen nicht.

**anda_skoa** · 23-03-2005, 20:23

Zitat von BeS

1. Sie bieten der Freien Softwareentwicklung ein neues und durchaus interessantes Werkzeug an, dass auch einem offenen Standard basiert. Das ist doch erstmal toll und damit sind wir zu 100% bedient.

Soweit ok

2. Sie wollen auch Kunden auf dem MS Markt gewinnen, damit diese auch Mono anstelle von .Net nehmen und Novell damit Kunden bekommt. Das machen sie indem sie ihnen eine "Plattformunabhängige .Net Technologie" verkaufen.

Indem sie ihnen vorgaukeln, Mono wäre .Net, nur halt nicht von Microsoft.

Das ziel von Novell ist aber nicht eine .Net/Mono Mischkultur sondern sie wollen natürlich nur Mono verkaufen und das erreichen sie mit dieser Strategie.

Sie erreichen damit das .Net eine gewisse Legitimation erhält, weil es ja eh mittels Mono von einem anderen Hersteller auf anderen Plattformen verfügbar ist.
Ist es aber nicht.

Der Kunde hat schon was von .Net gehört und hört jetzt von einem plattformunabhängigen Mono und sagt toll, jetzt habe ich die Auswahl zwischen java, .Net und Mono, da er mehrere Plattformen bedienen will fällt .Net weg und mit etwas Glück (für Novell) wird er sich für Mono entscheiden.

Da nichts gegen den Eindruck Mono == .Net unternommen wird, hat der Kunde aus seiner Sicht die Auswahl zwischen Java und .Net
Mono ist für ihn nur eine andere Implementierung von .Net, die er zum Beispiel derzeit nicht braucht, weil er eh unter Windows entwickelt.

Das seine ursprüngliche und von Mono geduldete Annahme, Mono == .Net, nicht der Wahrheit entspricht, sieht er erst, wenn es zu spät ist, wenn er .Net Technologien eingesetzt hat, die Mono nicht zur Verfügung stellen kann.

D.h. wenn seine Intention ansich war, seine Software oder einen Teil davon auf anderen Plattformen anbieten zu können, kann das jetzt vergessen.
Hätte er Java oder Mono genommen, hätte er diese Möglichkeit noch.

Nur wird ihm bewußt die Tatsache verschleiert, daß es eine Wahl zwischen drei Optionen ist.

Ein Schaden für Punkt 1 entsteht daraus in meinen Augen nicht.

Für Mono oder Monobasierte Entwickler entsteht auch kein Schaden, die können schließlich auch unter Windows entwickeln und vertreiben, der Schaden entsteht für die Plattformen != Windows, weil dort .Net nicht geht.

Es wäre für Mono vielleicht bishen weniger Marketing wenn sie diese Bauernfängerei nicht ausnutzen, aber sie wenigstens nicht stillschweigend den zukünftigen Windows Lock-In der .Net Entwickler hinnehmen.

Es wäre viel besser, wenn explizit klar gestellt werden würde, daß .Net Wissen auf Mono anwendbar ist und Mono die Entwickung für mehr als eine Plattform ermöglicht, während .Net das nicht tut.

**Lin728** · 25-03-2005, 14:33

Muss mich da anda_skoa leider anschließen.

Mono hat 70% seiner Popularität dem Umstand zu verdanken, dass sie als ".net für Linux" gehandelt werden - sonst wär in dien vielen Zeitschriften bei weitem nicht so viel drüber zu lesen gewesen.
Ich brauch mir nur angeblich seriöse Zeitschriften wie das Linux-Magazin ansehen und die Artikelzahl von Parrot mit der von Mono vergleichen.
Oder wenn man sich im Netz umschaut, tausende Berichte wie toll Mono nicht ist, weil da kann man mit VS.NET entwickeln und alles einfach rüberziehem und funtzt.

Ich bin wirklich der Meinung dass die GNU-Welt bessere Tools braucht (vor allem eine gut definierte, einheitliche API), aber ich bin doch etwas verunsichert dass es so abläuft wie eben jetzt.

**BeS** · 25-03-2005, 16:24

Zitat von ceisserer

Mono hat 70% seiner Popularität dem Umstand zu verdanken, dass sie als ".net für Linux" gehandelt werden - sonst wär in dien vielen Zeitschriften bei weitem nicht so viel drüber zu lesen gewesen.

sehe ich eigentlich nicht so. Für die popularität in der Free Software Community ist dieser Umstand wahrscheinlich sogar eher schädlich.
Und so populär ist Mono ausserhalb von der Free Software Community auch nicht.

O.T.: GTK+-2.0 sucks by design! Total über-synchronisiert ALLES, drum ists auch so langsam - Wahnsinn!

man darf nicht vergessen, dass Gtk+2 fast schon eine Neuentwicklung war, was da alles geändert wurde.
Seitdem gibt es von Release zu Release deutliche verbesserungen. In der nächsten Version werden einige Verbesserungen im Speicherverbrauch kommen und der komplette Desktop soll mit Cairo gerendert werden, d.h. ein Hardwarebeschleunigter Desktop!
Ich bin auf jedenfall schon darauf gespannt.

**Lin728** · 25-03-2005, 19:16

sehe ich eigentlich nicht so. Für die popularität in der Free Software Community ist dieser Umstand wahrscheinlich sogar eher schädlich.
Und so populär ist Mono ausserhalb von der Free Software Community auch nicht.

Sehe ich auch eher schädlich - ist wahrscheinlich falsch rübergekommen, sollte nur anda_skoa's statement noch untertreichen...

man darf nicht vergessen, dass Gtk+2 fast schon eine Neuentwicklung war, was da alles geändert wurde.
Seitdem gibt es von Release zu Release deutliche verbesserungen. In der nächsten Version werden einige Verbesserungen im Speicherverbrauch kommen und der

Naja, so lange Sie den Anspruch erheben, thread-safe zu sein sehe ich mehr oder weniger schwarz - das fox-toolkit (fox-toolkit.org) basiert rein auf X11 und outperformt GTK2 um den faktor 3-10.

komplette Desktop soll mit Cairo gerendert werden, d.h. ein Hardwarebeschleunigter Desktop!
Ich bin auf jedenfall schon darauf gespannt.

Naja, HW-beschleunigt ist X11 ja auch.

**BeS** · 25-03-2005, 23:35

Zitat von ceisserer

Naja, so lange Sie den Anspruch erheben, thread-safe zu sein sehe ich mehr oder weniger schwarz

wie kommst du darauf? Also mir ist es neu, dass Gtk+ thread-safe sein soll.

Naja, HW-beschleunigt ist X11 ja auch.

Was heißt X11 ist Hardwarebeschleunigt? Das hört sich so an, als ob alles was auf X11 läuft automatisch HW-beleunigung nutzt. Richtig ist das Grafikkartentreiber unter X11 zum Teil HW-beschleunigung ermöglichen. Es liegt dann aber an jedem Programm selber das zu nutzen oder nicht. Meistens sind das heute Spiele (z.B. tuxracer) die das nutzen. Ein Toolkit oder Desktop kenne ich nicht, dass wird jetzt mit Cairo aber möglich. Cairo soll mit der nächsten Gtk+ und Gnome Version implementiert sein und es erlauben den kompletten Desktop (alle Gtk+ aktivitäten)
mit HW-beschleunigung zu nutzen. Bei Qt plant man ja afaik auch nach der Qt4 release Cairo einzubauen.

Ich bin eher gespannt, was aus Cairo wird. Hat viel Potential, die API wird aber im Vergleich zu Java2D doch eher etwas "zusammengepfuscht".

Also ich weiß nicht was du mit der API hast.
Ich halte sowohl die Gtk+ als auch die Qt API für sehr gelungen und für mit das beste, was es derzeit auf dem Markt gibt. Klar ist Gtk+ etwas mehr "Gewöhnungsbedürftig", dass liegt aber eher an der Sprache als am Toolkit. Mit C++, C#, java oder Python ist die Gtk API auch schon viel freundlicher.

Wir sind mittlerweile aber wirklich sehr off-topic.

**Lin728** · 26-03-2005, 11:00

Was heißt X11 ist Hardwarebeschleunigt? Das hört sich so an, als ob alles was auf X11 läuft automatisch HW-beleunigung nutzt

X11 ist Hardware-beschleunigt. Jede Linie die du zeichnest, (fast) jedes image das du blittest und was sonst noch alles, wird vom Grafikkarten-Treiber realisiert und nicht in Software-Schleifen (es sei denn du verwendest generische Treiber wie den vesafb-treiber).
Mit XRender sind sogar kompliziertere Sachen möglich, dabei werden die für den Treiber zu komplizierten Aufgaben, in mehrere einfache zerlegt.

Ein definitiv sehr grosser Nachteil von OpenGL unter Linux ist, dass es kein Render-To-Texture gibt, d.h. es muss das ganze backbuffering in pbuffer gemacht werden, wo wir enormen Speicherverbrauch und OpenGL-Context-Switches haben ;-)
Hoffentlich kommt bald RTT unter OGL...
Was du dir dabei sparst ist das Protokoll-Parsen und die Context-Switches.
Also eine Linie in X11 ist nicht weniger beschleunigt wie eine in OpenGL, drum nützt auch jedes Toolkit diese Beschleunigung aus ;-)

Also ich weiß nicht was du mit der API hast.

Hab die Cairo-API gemeint. Nichts desto trotz wünsch ich den Cairo-Jungs alles gute, ich hoffe das wird was gescheits ;-)

**Lin728** · 26-03-2005, 11:44

Noch was zur Mono-Publicity:

http://www.heise.de/newsticker/meldung/57935

**oracle2025** · 29-03-2005, 12:52

Nochwas zum Thema Java, C#, etc.

Ich glaube schon, das es unbedingt nötig ist eine Programmiersprache zu haben, die die üblichen Schwächen von C/C++ ausräumt. (c-strings, array out of bounds, bufferoverflows, kein Garbage-Collection etc.)

Aber es muss nicht unbedingt Java bzw. C# sein. D ist nämlich auch ein vielversprechender Kandidat, den man immer dann verwenden kann wenn man eine kompilierte Sprache braucht:

http://www.digitalmars.com/d/ (Website anscheinend grad down)

http://c2.com/cgi/wiki?DeeLanguage

Es gibt neben dem DigitalMars D Compiler für Linux auch ein Frontend für die GNU Compiler Collection.

**anda_skoa** · 29-03-2005, 14:24

Zitat von oracle2025

die üblichen Schwächen von C/C++ ausräumt. (c-strings, array out of bounds, bufferoverflows, kein Garbage-Collection etc.)

Nunja, C und C++ sind ja nicht eine Sprache sondern zwei, haben also getrennte Schwächen.
So sind c-strings ein C Problem, array out of bounds praktisch auch bzw in C++ nur dann wenn man es sich explizit so aussucht.

Garbage Collection bzw das Nichtvorhanden sein ist keine Schwäche, sondern einfach eine Designentscheidung.
Garbage Collectors haben leider oft den Nachteil, daß sie schwer zu steuern sind

Ciao,
_

**Lin728** · 29-03-2005, 18:10

So sind c-strings ein C Problem, array out of bounds praktisch auch bzw in C++ nur dann wenn man es sich explizit so aussucht.

Gibts C++ Compiler die bounds-checks unterstützen?
Eine große Stärke bei Java finde ich ist, dass Exceptions relativ sicher abgefangen weden können. Bei C++ kann man oft nur mehr schnell irgendwelche Daten sichern und sich dann vertschüssn.

Garbage Collection bzw das Nichtvorhanden sein ist keine Schwäche, sondern einfach eine Designentscheidung.
Garbage Collectors haben leider oft den Nachteil, daß sie schwer zu steuern sind

Ich finde ein GC-Interface sollte definitv ins Bertriensystem übernommen werden!
Diese Mega(giga)-Byte großen Heap-Ungetüme bringen doch nur die ganzen Virtual-Memory Systeme zum kollabieren.
Würde das OS die Kontrolle über den GC und auch einen gemeinsamen Heap haben, wäre ein viel effizienteres Memory-Management möglich, da z.B. das OS feststellen könnte welche Speicherbereiche (Objecte) eher selten benützt werden, und diese könnten ausgelagert werden.
Derzeit ist der Heap einfach ein riesiger Bereich auf den nahezu wahlfrei zugegriffen wird, also nix mit effizientem Memory-Management :-(
Aber bis sich da ein Kompromiss zwischen den Kernel-Entwiclern finden lässt, vergeht wohl noch ein Weilchen ;-)