VS.NET 7.1 dazu bringen normale Java-Programme zu erstellen

Optimizer schrieb:

klar ist das möglich schrieb:

sicher ist das möglich. Du kannst du *.java Source Files mit VS.NET 2003 öffen oder? Dann fügst du einfach einen neues External Tool mit javac hinzu. Die Parameter etc. dafür wirst du wohl selbst hinbekommen.

Nein, ist es nicht. J# ist darauf ausgelegt, dass man Java-Code möglichst leicht darauf portieren kann. Umgekehrt ist das aber sehr aufwändig.
J# bietet Features wie delegates und Proberties, Sachen, die in Java so faktisch nicht vorhanden sind.
Hinzu kommt System.String, System.Object.Equals(), ...

java.lang.Object.equals() gibt's natürlich, ist aber nur etwas, was der Compiler dann durch das .Net Gegenstück ersetzt. Und längst nicht die gesamte Java-Bibliothek ist in J# verfügbar. Die Generics sind auch weniger flexibel, sie sind auf das beschränkt, was auch C# kann.
Du kannst mit J# nicht Java coden. No way.

?? wer redet hier von J#?
man kann doch bei vs.net wenn man auf "open" geht alle dateien auswählen. dann wählt man eine java datei aus, schreibt sein programm und erstellt es durch das externe tool "javac". Das ist das selbe wenn du mit notepad ein java programm erstellt, nur das man halt die vs ide verwendet. kapiert?!

warum umständlich ein plugin schreiben wenn die ausgabe des externen tools auch ins output window umgelenkt wird?

AndreasW

sogesehen hast du schon recht. Viel kann man nicht erwarten, wenn man eine Tool Zweckentfremdet.
Eclipse ist da schon die bessere Wahl
NetBeans hatte mich auch nicht überzeugt. (Naja, Eclipse eigentlich auch nicht. Ist zwar um Längen besser als NetBeans, kommt aber am VS nicht annähernd ran ;))

klar ist es möglich schrieb:

?? wer redet hier von J#?
man kann doch bei vs.net wenn man auf "open" geht alle dateien auswählen. dann wählt man eine java datei aus, schreibt sein programm und erstellt es durch das externe tool "javac". Das ist das selbe wenn du mit notepad ein java programm erstellt, nur das man halt die vs ide verwendet. kapiert?!

warum umständlich ein plugin schreiben wenn die ausgabe des externen tools auch ins output window umgelenkt wird?

Dann nimm doch gleich nen Texteditor und javac. Eine IDE ist das nicht mehr und Sinn sehe ich darin auch keinen.

AndreasW schrieb:

Naja, Eclipse eigentlich auch nicht. Ist zwar um Längen besser als NetBeans, kommt aber am VS nicht annähernd ran

Das ist das, was ich im Java-Forum über eclipse geschrieben habe. Anfangs mag es fast keiner. Man muss sich da erst richtig reinsteigern und am besten auch in ein Buch reinlesen.
(Achtung: Damit will ich niemandem Inkompetenz unterstellen. Ich habe eclipse selber am Anfang oft genug weggeworfen).

Eclipse ist der Hammer, wenn man es checkt und sich damit angefreundet hat. VS kann, ganz nüchtern betrachtet, eigentlich nichts. Jetzt kündigen sie ganz stolz ihr Refactoring für C# an und eigentlich ist das ziemlich mager. Mir gefällt die Oberfläche von VS. Die ist nett, aber sonst kann VS eigentlich nichts. Das muss man schon mal so sehen.
So gut wie alles, was du dir an intelligenten Hilfen vorstellen kannst, findest du in eclipse. Und selbst wenn nicht - dann schreibst dir halt schnell ein Plugin dafür.
(Ich betrachte jetzt eclipse mal kurzzeitig als reine Java-IDE, was natürlich gar nicht stimmt).

AndreasW

das lass ich einfach mal im Raum stehen

Ok.

btw.: Der Link "new language features" zeigt inzwischen in's Nirvana.

Optimizer schrieb:

klar ist es möglich schrieb:

?? wer redet hier von J#?
man kann doch bei vs.net wenn man auf "open" geht alle dateien auswählen. dann wählt man eine java datei aus, schreibt sein programm und erstellt es durch das externe tool "javac". Das ist das selbe wenn du mit notepad ein java programm erstellt, nur das man halt die vs ide verwendet. kapiert?!

warum umständlich ein plugin schreiben wenn die ausgabe des externen tools auch ins output window umgelenkt wird?

Dann nimm doch gleich nen Texteditor und javac. Eine IDE ist das nicht mehr und Sinn sehe ich darin auch

wieso ich? dEUs wollte das doch...

SideWinder

VS kann, ganz nüchtern betrachtet, eigentlich nichts.

Zum VS gehört aber auch das ganze Rundeherum. Alleine was der VC alles an Tools mitbringt um für Windows zu programmieren ist schon sagenhaft :). Aber ich finde selbst die IDE besser als die von Eclipse. Mir gefällt das Projektmanagement mehr als das von Eclipse. Außerdem ist sie übersichtlicher und sieht mehr nach Standard-Windows aus was eine kürzere Anfreundungszeit ermöglicht.

MfG SideWinder

AndreasW

Optimizer schrieb:

btw.: Der Link "new language features" zeigt inzwischen in's Nirvana.

oh, habs nun geändert. Danke für den Hinweis.

Was ist denn das "ganze Rundherum" und die ganzen Tools? Genau davon rede ich doch.
Das Projektmanagement zwischen Eclipse und VS ist seit VS2005 recht ähnlich geworden.
Eclipse erzwingt halt in der Verzeichnisstruktur die Package-Hierarchie, was bei Java aber nun mal einfach so ist. Mir fallen keine wirklich großen Unterschiede jetzt auf.
Das Look & Feel von VS ist schon gut, gar keine Frage. Aber es kann halt nicht viel. Die Formatierungsoptionen sind unzureichend (und damit nicht benutzbar, denn ich kann es nicht so einstellen, wie ich es haben will).

Das Refactoring kann vergleichsweise fast gar nichts. Wenn du in Eclipse extract method machst, sucht er gleich noch andere passende Stellen, die du mit dem Aufruf ersetzen kannst. Du kannst Methodensignaturen beliebig verändern, nicht nur Parameter vertauschen oder streichen. Du kannst Fabriken erstellen lassen. Du kannst Dinge in der Klassenhierarchie nach oben und unten bewegen. Du kannst Typen verallgemeinern oder wann immer möglich Referenzen auf Basisklassen einsetzen lassen.
Die Code Completion scheint bei VC# ein bisschen besser zu sein als bei Eclipse, dafür kann VS fast gar keinen Code automatisch generieren.
Der Compiler von Eclipse hat unglaublich viele Warn-Funktionen, der von VS kann fast nichts dagegen (ich vermisse unused import, unnecessary cast, unused constant field, indirekter Zugriff auf statische Member, unnötiges else, unwirksames finally, ...). Ich hab natürlich auch nicht alles an. Aber vieles macht Sinn und vermisse ich für C#.
Und du kannst im Quelltext nach allem Möglichen suchen, was weit über VS hinausgeht. Beispielsweise kannst du dir Methoden-Ausgänge highlighten lassen, inklusive ungefangener Exceptions.
Du kannst imports optimieren (VS warnt nichtmal, wenn du ein using völlig unnötig hast), delegaten erzeugen lassen, etwas mit try und passenden catch umschließen lassen... Ich könnte ewig so weitermachen.
Zu fast jeder Warnung oder jedem Fehler hat Eclipse eine Reihe von Vorschlägen parat, die man durchführen lassen kann.

Ich beziehe mich jetzt für den Vergleich auf die C# IDE von VS 2005, weil das in meinen Augen noch das beste ist, was VS zu bieten hat. Für C++ funktioniert ja nicht mal die Code Completion zuverlässig.

AndreasW

naja, es gibt ja auch schöne Erweiterungen ( Bei Eclipse ist ja auch nicht alles Standardmäßig drin). Zum Beispiel http://www.visual-paradigm.com/sdevs.php.
Auch möchte ich erwähnen das es bei Eclipse zwar sehr viele AddIns gebt, die aber zu 90% von Möchtegerns entwickelt wurden, die keine Ahnung haben, was die mit ihrer Unwissenheit anstellen. Dementsprechend ist alles sehr Buggy.
Im Visual Studio kann man auch PlugIns einbauen. Auch sind die Macros für Codegenerierung sehr sehr praktisch. Einfacher kann man keine IDE ausbauen.
Ich will im Studio aber gar nicht so viel drin haben. Man kann ein Tool auch schnell überfrachten. Mir reichen die Dinge, die ich zum Entwickeln brauche. Den ganzen anderen Gedöns und Klimbim ist nur Overhead und machen IDEs höchstens langsam und instabil. Das sieht man ja auch deutlich an Eclipse.

Versteh mich nicht falsch, ich finde Eclipse als IDE sehr gut. Ich arbeite mit dem Visual Studio, weil ich Stabilität, Performance und guten Support möchte. Das bietet Eclipse nicht.

Aber ich wollte es ja im Raum stehen lassen....

Ich konnte nicht feststellen, dass da großartig Plugins für Eclipse buggy sind. Ich hab den Link nicht hier, aber es gibt diesbzgl. ne sehr gute Seite, wo man echt geile Plugins runterladen kann.
Auch nicht zu verachten sind wohl die Plugins für die Java IDE. Ja, die Java IDE besteht zu 100% aus Plugins. Eclipse ist nämlich lustigerweise gar keine Java IDE.
Deshalb sind solche allgemeine Aussagen nicht wirklich nachvollziehbar, wie ich finde.

Einfacher kann man keine IDE ausbauen.
Ich will im Studio aber gar nicht so viel drin haben. Man kann ein Tool auch schnell überfrachten. Mir reichen die Dinge, die ich zum Entwickeln brauche.

Das ist alles eine Frage der Menüführung. Ich vermisse für C# einige interessante Compiler-Warnungen und Refactoring-Optionen. Wenn man mehr Komfort gewöhnt ist, vermisst man sowas einfach.
Wie einfach VS auszubauen ist, weiß ich nicht. Ich denke aber mal, dass man nicht die selben Möglichkeiten hat wie bei Eclipse, wo wirklich ne ganze Java IDE aus Plugins besteht, mit allen Menüs und Kontextmenüs usw.

Den ganzen anderen Gedöns und Klimbim ist nur Overhead und machen IDEs höchstens langsam und instabil. Das sieht man ja auch deutlich an Eclipse.

Du könntest in VS auch noch 200 weitere Refactoring-Optionen haben und es wäre nicht lahm. Es liegt nicht an der Komplexität.
Eclipse verbessert sich bzgl. Performance zur Zeit übrigens sehr stark. Und Eclipse ist doch wirklich nicht instabil?

Versteh mich nicht falsch, ich finde Eclipse als IDE sehr gut. Ich arbeite mit dem Visual Studio, weil ich Stabilität, Performance und guten Support möchte.

Versteh mich nicht falsch, ich mag Visual Studio gerne.
Die Performance ist godlike, es hat ein geniales Look & Feel und ist einfach zu bedienen. Mein einziger Kritikpunkt ist und bleibt, dass es zu wenig fortgeschrittene Features gibt und ich habe ja einige konkrete genannt.
Man braucht IMHO halt nicht so stolz ein paar Refactoring-Optionen vorstellen, wenn andere IDEs 30mal mehr können und das schon seit Jahren.
Ich arbeite gerne mit VS, wenn ich in C# code weil ich es für eine der besten C# IDEs halte. Ich halte es auch gut für möglich, dass das so bleibt, wenn sie sich konsequent weiterentwickelt. Die Konkurrenz ist ja noch nicht so groß.

Helium

Die Generics sind auch weniger flexibel, sie sind auf das beschränkt, was auch C# kann.

Also so primitive Dinge, wie Generics zur Laufzeit instanzieren? Das kann ich nichtmals in C++

Technisch sind sie IMHO auch top. Aber sprachlich nicht. Kennst du noch die 4 Varianztypen, über die wir letztens gesprochen haben? C# kann das nicht.

Ich finde das aber eigentlich sehr nützlich und habe das tatsächlich schon ein paar mal gebraucht.

Dagegen war ein anderes Feature von C# in der Praxis bisher für mich nicht einsetzbar: Die Nutzung von value types, was mich eigentlich sehr gereizt hätte. Mich reizt aber ein int/long nur noch halb so viel, wenn ich kein '+' benutzen kann und im Moment kann man keine statischen Methoden als constraint verwenden. Irgendwie ist dort auch wie vieles in C# nur halb zu Ende gedacht worden.
Ich hätte ein generisches Point-struct gebraucht, einmal mit int und einmal mit long. Jetzt hab ichs nicht-generisch für beide Fälle mit long gemacht. Sicher kein Beinbruch, aber ich hätte mir schöneres vorstellen können.

Das einzige, was für mich echt reizvoll ist, da hast du Recht, ist

class Test<T>
{
    public T[] createArray(int count)
    {
        return new T[count];
    }
}

Java suckt dagegen in dieser Hinsicht:

class Test<T>
{
	public static void main(String[] args)
	{
		Test<Integer> test = new Test<Integer>();

		// *PENG*
		Integer[] array = test.createArray(10);
		array[5] = 3;
	}

	public T[] createArray(int count)
	{
		return (T[])(new Object[count]);
	}
}

Wenigstens kann man aber sein zurückgeliefertes T[] benutzen und Ts reinstecken und auslesen.

Für Sachen wie Standardkonstruktor von T (C#) hab ich dagegen im Moment noch keine Verwendung gefunden.
Wenn ich mir jetzt aber vorstellen würde, Java würde mit den Generics technisch von vorne anfangen, die coolen Features, die es aber jetzt schon hat, behalten... *sabber*

So bleibt mir nur die Erkenntnis, dass die C#-Leute sich eigentlich eine Chance verbaut haben, während die Java-Leute das bestmögliche aus ihrer Situation gemacht haben.

AndreasW

So bleibt mir nur die Erkenntnis, dass die C#-Leute sich eigentlich eine Chance verbaut haben, während die Java-Leute das bestmögliche aus ihrer Situation gemacht haben.

was ist das denn für ein Quatsch. Die Implementierung von Generics kann genau wie in Java auch nachträglich geändert werden. Es hat sich, genau wie in Java, niemand was verbaut.

Die Implementierung bei C# müsste IMHO nicht geändert werden, sondern die Sprache.
Du kannst eine Sprache nicht beliebig ändern, nicht im Nachhinein. Was meinst du, warum C++ so ein geniales Übersetzungsmodell hat und Java kein "vernünftiges" override mehr kriegt?
Nur bei C# hatte man die Chance, die Generics wirklich gut zu machen und jetzt fehlen viele Features. Vielleicht bin ich aber auch vorschnell. Ergänzungen an Sprachen hat es öfter schon gegeben, vielleicht besteht die schwache Hoffnung, dass das noch was wird. Ich würde es mir jedenfalls wünschen.

Bei Java müsste man auf jeden Fall mit vorhandenem Bytecode brechen, oder eine VM für viele Plattformen, vielen Prozessorarchitekturen und zwei verschiedenen Bytecode-Formaten bauen...

*phoenix* 0

Hi!

Helium schrieb:

Die Generics sind auch weniger flexibel, sie sind auf das beschränkt, was auch C# kann.

Also so primitive Dinge, wie Generics zur Laufzeit instanzieren? Das kann ich nichtmals in C++

Ist das dein Ernst? Ich weiss jetzt nicht so recht wie ich das verstehen soll, aber generics zur Laufzeit instanzieren geht doch ?

Was die constraints mit statischen Methoden betrifft, gibt es irgendwo auf der Microsoft Homepage einen Antrag, wo man sich eintragen lassen kann. Das ist dort, wo auch die anderen Vorschläge sind, aber man muss sich registrieren. Gerade weil man nur instanzmember vorgeben kann, bin ich ein wenig von den Generics weggekommen. Mit normalen templates kommt man im neuen C++ einfach weiter. Vor einiger Zeit habe ich mir einige Klassen geschrieben, die die operatoren für T zur Laufzeit implementieren (kleine automatisch generierte Funktionen die op_Addition aufrufen, oder ldarg.0 ldarg.1 add ret halt), was mir dann aber syntaktisch zu dumm wurde. Es wäre auch langsammer gewesen, da richtige Funktionsaufrufe anstelle von Operatoren gewesen wären. Und genau hier liegt glaub ich das Problem. Ein operator+ wird zur Compile-Zeit aufgelöst. Dabei entsteht folgendes:

Bei System.Int32:

ldarg.0
ldarg.1
add
ret

Bei System.Decimal

ldarg.0
ldarg.1
call die blub op_Addition bei System.Decimal
ret

Einmal ist es ein Funktionsaufruf, mal nicht! Das als constraint zu implementiern ist ihnen wohl zu schwer.

Ich glaube das grundlegendere Problem liegt woanders. Du kannst ja für deine eigenen Typen auch nen op+ schreiben, der dann letztlich ein Funktionsaufruf ist. Für int ist es halt ne besonderheit, intern im .Net Framework.
Das Problem liegt ganz einfach darin, dass Interfaces keine statischen Methoden vorgeben können, wie der op+ eine ist.

@AndreasW: Vielleicht kann ich dir hiermit deutlicher machen, was ich vermisse:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Arrays.html#sort(T[], java.util.Comparator)
Diese Methode sortiert ein Array mit Elementtyp T, der Comparator muss aber nicht ein Comparator<T> sein, sondern kann auch ein Comparator<Basisklasse von T> sein. Das kann schon sinnvoll sein, denn vielleicht ist T von einer Klasse abgeleitet, für die schon ein Comparator geschrieben ist, der für T auch noch passend ist.
Auf so etwas kann man öfter mal stoßen (nicht nur beim Vergleichen), wenn man es kennt, lernt man es zu schätzen, zumindest ich.