Warum ist die Java-Toolchain eigentlich so haushoch überlegen?
-
SideWinder schrieb:
Eigentlich helfen Resharper und Visual Assist X nur um mal halbwegs an den Punkt zu kommen, was die Eclipse-Editor-Komponente von Haus aus bietet. Von Library-Einbindng keine Rede.
Also ich arbeite täglich seit 8 jahren mit Eclipse, und ich weiß jetzt nicht, welche großartigen Unterschiede/Deffizite du jetzt im Gegensatz zu VAX meinst.
SideWinder schrieb:
Warum kann ich nicht auf mein Projekt rechtsklicken und Libraries -> Use boost library anwählen und er compiliert autom. alles im Hintergrund was benötigt wird?
Was hat das Build mit Einbindung zu tun? Sehr wenig. Wenn ich Java-Sourcen runter lade, muß ich die auch erstmal bauen lassen. Meistens mit nem Ant-Script. Oder Maven? Oder Netbeans- oder Eclipse-Projekt? Uih uih uih!
Und dafür muß ich auch erstmal Ant einrichten, Pfade setzen usw.Eine fertige Lib kann ich übrigens mit Drag&Drop in das VS-Projekt hinzufügen.
Es gibt auch Installer für Libs, ich sage nur Boost Installer von Boost Consulting. Wenn ich zu fauel bin "bjam" in die Konsole einzugeben und zwei Pfade in VS einzutragen. Eine Lib muß ich nicht mal hinzufügen, weil Boost selber per #pragma die richtige Lib-Datei importiert.
Oder wxPack das wxWidgets mit nem Mausklick für VS installiert.
Wenn ich das mal so grob überschlage, habe ich nicht mehr Arbeit als mit Java.
SideWinder schrieb:
Warum muss ich bei NHibernate mich immer noch mit XML rumplagen? usw. es ist eigentlich im Vergleich ziemlich jämmerlich
Mit NHibernate kenne ich mich nicht aus. Aber als ich vor vier Jahren Javas Hibernate benutzt habe, mußte ich auch mit XML rum hantieren, um die Klassen/Mapping zu definieren. Heute läuft es in Java wahrscheinlich mit Annotations ab, richtig? Ja, dann hat man halt das gefrickel in den *.java-Dateien drin. Ob C# auch Annotations erhält weiß ich nicht.
Aber deine Kritik kommt mit doch sehr spitzfindig vor. So als ob in Java alle Features und Tools seit 15 Jahren drin wären... und C# 15 Jahre hinter her hinkt.
-
SideWinder schrieb:
Siehe Topic.
Bspw. MyEclipse, ein Projekt mit Anbindung an Datenbank inkl. Reverse-Engineering für Hibernate, Logging, Build-Tools, Unit-Tests, CVS/SVN-Einbindung uvm. alles unter einem wunderbaren Hut.
weil es java ca. 100 jahre länger gibt als C#.
davon abgesehen ist java für mich das schlimmste fleckwerk von überhaupt.
3 vorteile die ich sehe:
* weiter verbreitet
* standard library grösser
* mehr anerkannte und HALBWEGS brauchbare librariesund diese drei punkte führe ich auch zum grössten teil darauf zurück, dass es java schon viel länger gibt.
-
SideWinder schrieb:
Warum muss ich bei NHibernate mich immer noch mit XML rumplagen? usw. es ist eigentlich im Vergleich ziemlich jämmerlich
Musst du nicht
-
hustbaer schrieb:
* mehr anerkannte und HALBWEGS brauchbare libraries
- Spring Framework
- Spring Security (ehem. ACEGI)
- Hibernate
- Maven 2 / Ant
- JUnit/ TestNG
- Eclipse Equinox / Plattform
- AspectJ
- GWT
usw.... würde ich nicht grade als halbwegs brauchbar sondern eher als erstklassig beschreiben.
-
byto schrieb:
... würde ich nicht grade als halbwegs brauchbar sondern eher als erstklassig beschreiben.
du vielleicht. ich nicht.
trotzdem sehe ich den vorteil gegenüber den für C# verfügbaren (freien) libraries, was ich ja auch geschrieben habe. einige bis viele halbwegs brauchbare libs plus wenige wirklich gute, ist halt immer noch viel besser, als wenige halbwegs brauchbare plus haufenweise schrott.
der grössere vorteil ist aber vermutlich: "man" hat sich halbwegs gut geeinigt, was "man" verwendet. auch wenn dieses "was" nur "gerade eben ausreichend" ist, und deutlich davon entfernt "erstklassig" zu sein.
-
Was hast Du an den oben genannten Libs auszusetzen? Wie würdeste Du es besser machen? Und warum denkst Du, hat das noch niemand getan?
-
Artchi schrieb:
Ich würde mal sagen, das man auch mit VS und somit C# sehr gut an Java Tools rankommt. Nur das man bei VS ein paar Euros investieren muß. Es gibt ja den Reshaper, Visual Assist X usw. Damit kann man VS schon sehr gut erweitern. Ich habe zu Hause die große VS2005 und da kann man auch Unittests erzeugen. Ich benutze diese dinge allerdings nicht, aber die Menüpunkte sind auf jeden Fall da.
Es geht wie schon erwähnt weniger um allgemeine Editor-Features (wobei das eigentlich schon ein Witz ist, dass man sich solche Features extra noch teuer dazu kaufen muss), sondern um ganz andere Dinge wie z.B. Build-Management, Integration von anderen Applikationen durch Plug-Ins (z.B. Tomcat Web Server) etc
Beispiel: Wir haben bei uns eine Build-Umgebung mit Maven, Archiva, und Eclipse eingerichtet. Wenn ich zusätzliche Libs brauche dann füg ich die nicht per Hand ein (wie z.B. von dir bei VSStudio genannt), sondern trag das einfach als zusätzliche Maven-Dependency ein. Schon holt er mir automtisch die aktuellste releaste Version der Bibliothek. Wenn ich doch ne spezielle Release-Version brauch trag ich das einfach ein. Ist echt sehr einfach und unheimlich praktisch. Klar, diese Umgebung muss auch erst mal aufgesetzt werden, aber das ist ne einmalige Aktion.
Oder bei der J2EE-Entwicklung kann ich automatisch mit paar Klicks mir meinen Tomcat-Server zurechtsetzen, Anwendungen deployen, testen etc. Ist einfach ne super nahtlose Integration.
Ist vielleicht alles analog mittlerweile auch irgendwie mit VSStudio machbar (kenn mich da nimmer so aus), aber ich glaube nicht dass das so einfach und mit der Feature-Breite funktioniert.
-
nep schrieb:
Beispiel: Wir haben bei uns eine Build-Umgebung mit Maven, Archiva, und Eclipse eingerichtet. Wenn ich zusätzliche Libs brauche dann füg ich die nicht per Hand ein (wie z.B. von dir bei VSStudio genannt), sondern trag das einfach als zusätzliche Maven-Dependency ein. Schon holt er mir automtisch die aktuellste releaste Version der Bibliothek. Wenn ich doch ne spezielle Release-Version brauch trag ich das einfach ein. Ist echt sehr einfach und unheimlich praktisch.
Hem, also das Eintragen in Maven ist keine Handarbeit, weil man es nicht in MSVS einträg?
Das ist ja mal ne geile Aussage.Sorry, aber du verlagerst nur die Handarbeit von einem Tool in ein anderes Tool. Die Arbeit ist aber immer noch da. Und man staune, man muß sogar noch nachdenken, welche Lib man für sein Projekt nutzen will... und sogar welche Version die Lib haben muß.
-
Maven lädt aber nicht nur die eine Lib runter und verdrahtet sie korrekt im Classpath, sondern kümmert sich auch um alle Abhängigkeiten dieser Lib. Ich kenne eine Vielzahl Frameworks, die wiederum von einer Vielzahl Libs abhängig sind, die wiederum von Libs abhängig sind usw. Das alles per Hand aufzulösen, ist äusserst ecklig, vor allem wenn man dann noch etwaige Versionskonflikte dazukommen. Da nimmt einem Maven schon ne Menge ab.
Aber klar, um in 0815 Projekte ne einzelne Lib hinzuzufügen, braucht mans nicht. Da reicht dann auch Konsole + Texteditor. :xmas1:
-
Artchi schrieb:
nep schrieb:
Beispiel: Wir haben bei uns eine Build-Umgebung mit Maven, Archiva, und Eclipse eingerichtet. Wenn ich zusätzliche Libs brauche dann füg ich die nicht per Hand ein (wie z.B. von dir bei VSStudio genannt), sondern trag das einfach als zusätzliche Maven-Dependency ein. Schon holt er mir automtisch die aktuellste releaste Version der Bibliothek. Wenn ich doch ne spezielle Release-Version brauch trag ich das einfach ein. Ist echt sehr einfach und unheimlich praktisch.
Hem, also das Eintragen in Maven ist keine Handarbeit, weil man es nicht in MSVS einträg?
Das ist ja mal ne geile Aussage.Sorry, aber du verlagerst nur die Handarbeit von einem Tool in ein anderes Tool. Die Arbeit ist aber immer noch da. Und man staune, man muß sogar noch nachdenken, welche Lib man für sein Projekt nutzen will... und sogar welche Version die Lib haben muß.
Da hast du mich falsch verstanden.
Es geht nicht um das Hinzufügen selbst (klar das muss man so oder so machen), sondern um die Art und Weise wie das geschieht.
Hier werden eben wie auch von byto erwähnt alle möglichen weiteren Abhängigkeiten automatisch aufgelöst etc.
Klar, für kleinere Projekte ist das zu Fuß (diesmal vermeide ich von Hand ;)...)) sicherlich schneller wenn man alles direkt reinzieht. Aber sobald du einige Abhängigkeiten auf Bibliotheken (in verschiedenen Release-Ständen) und diese wiedrrum verschiedene Abhängigkeiten haben, geht das so sicherlich besser.
Und vor allem ist das so viel reproduzierbarer, wie wenn man einfach selbst ständig seine Libs in VSStudio reinzieht...
-
Irgendwie habe ich das gefühl, dass hier viele relativ uninformiert sind. Aussagen, wie man könne Unittests erst sei 2008 schreiben? WTF‽‽‽
Fluent NHibernate ist anders, als das was Hibernate bietet, aber bedeutet nicht, dass man sich mit XML rumplagen muss. Anders beduetet nicht nicht-existent.
Dann es gäbe keine alternativ-Sprachen für .Net. Erstens ist C# einfach nicht so beschissen, wie Java, so dass der Druck eine Alternative zu schaffen nicht so groß ist, zweitens gibt es trotzdem entsprechende Projekte wie Sand am Meer. Die Standardsprachenportierungen beginnen mit Iron (IronPython, IronRuby, ...). Microsoft selbst bringt eine eher aus der funktionalen Ecke stammende Sprache raus F# und es gibt weitere, wie Nemerle, ... . Dann gibts Boo, Cobra, ... . Dann sind da noch die Sprachen, die sowohl JVM als auch die CLR als Ziel haben, wie Fantom, inzwischen auch Clojure (ClojureCLR ist noch Beta), ...
Auf Maven wäre ich nicht unbedingt eifersüchtig. Da würde ich lieber Buildr einsetzen.
Allgemein würde ich sagen, dass die Java-Plattorm die Nase in einigen Punkten vorn hat, aber so wie es teilweise dargestellt wird ist es mit Sicherheit nicht. Hier wird sogar behauptet, das .Net Entwickler höchstens mal was von VCS gehört haben. Da kann man dann echt nurnoch glauben, dass das rumgetrolle sein soll.
-
Ich glaube du verstehst hier falsch. Es war mehr eine Frage als eine Anschuldigung.
Fluent NHibernate ist anders, als das was Hibernate bietet, aber bedeutet nicht, dass man sich mit XML rumplagen muss. Anders beduetet nicht nicht-existent.
Genau solche Produkte werden gesucht.
Dann es gäbe keine alternativ-Sprachen für .Net.
Davon war doch noch gar nicht die Rede?
Hier wird sogar behauptet, das .Net Entwickler höchstens mal was von VCS gehört haben. Da kann man dann echt nurnoch glauben, dass das rumgetrolle sein soll.
Das ist natürlich Quatsch, aber dass AnkhSVN sich nicht mit den Java-seitigen Plugins für VCS vergleichen kann ist dir hoffentlich aufgefallen.
MfG SideWinder
-
SideWinder schrieb:
Dann es gäbe keine alternativ-Sprachen für .Net.
Davon war doch noch gar nicht die Rede?
Durch die Offenheit von Java sind auch ganz viele Community-Projekte entstanden. Wie Groovy, Scala, Jython, usw. Wo sind solche Projekte für C#?
Das ist natürlich Quatsch, aber dass AnkhSVN sich nicht mit den Java-seitigen Plugins für VCS vergleichen kann ist dir hoffentlich aufgefallen.
Wer wirklich noch SVN einsetzt könnte sich VisualSVN ansehen.
-
Wegen Maven habe ich folgendes gefunden: http://npanday.codeplex.com/
Zu SVN: was fehlt denn in Ankh SVN? Ich benutze es regelmäßig, und kenne auch Subclipse. Das einzige was ich in Ankh SVN nicht machen kann, ist einen Branch und Tag erstellen (weil die Funktionen tatsächlich in Ankh fehlen). Da greife ich dann halt zu TortoiseSVN. Aber ansonst ist Ankh SVN bei der täglichen Arbeit in der aktuellen Version schon sehr umfangreich, kann nicht klagen.
-
Maven lädt aber nicht nur die eine Lib runter und verdrahtet sie korrekt im Classpath, sondern kümmert sich auch um alle Abhängigkeiten dieser Lib. Ich kenne eine Vielzahl Frameworks, die wiederum von einer Vielzahl Libs abhängig sind, die wiederum von Libs abhängig sind usw. Das alles per Hand aufzulösen, ist äusserst ecklig, vor allem wenn man dann noch etwaige Versionskonflikte dazukommen. Da nimmt einem Maven schon ne Menge ab.
Irgendwie macht mir das mehr Angst, als das ich mich über solche Tools freuen würde. Wenn es so viele Abhängigkeiten gibt, dass man schon ein Tool braucht, um von allem die richtige Version zu bekommen, läuft irgendwo was schief. :xmas2:
-
darf ich dich vielleicht dran erinnern dass es solche tools zum glück schon seit mehr als 20 Jahren gibt? Aber wenn du willst kannst du ja gerne einem Inder 5 euro die std bezahlen damit er das für dich erledigt.
-
ree schrieb:
darf ich dich vielleicht dran erinnern dass es solche tools zum glück schon seit mehr als 20 Jahren gibt?
Name?
ree schrieb:
Aber wenn du willst kannst du ja gerne einem Inder 5 euro die std bezahlen damit er das für dich erledigt.
Was auch nicht das eigentliche Problem löst.
-
hürsch schrieb:
Maven lädt aber nicht nur die eine Lib runter und verdrahtet sie korrekt im Classpath, sondern kümmert sich auch um alle Abhängigkeiten dieser Lib. Ich kenne eine Vielzahl Frameworks, die wiederum von einer Vielzahl Libs abhängig sind, die wiederum von Libs abhängig sind usw. Das alles per Hand aufzulösen, ist äusserst ecklig, vor allem wenn man dann noch etwaige Versionskonflikte dazukommen. Da nimmt einem Maven schon ne Menge ab.
Irgendwie macht mir das mehr Angst, als das ich mich über solche Tools freuen würde. Wenn es so viele Abhängigkeiten gibt, dass man schon ein Tool braucht, um von allem die richtige Version zu bekommen, läuft irgendwo was schief. :xmas2:
Nun wenn man eine hohe Modularität bzw. Wiederverwendung anstrebt, und man über mehrere Abteilungen hinweg entwickelt dann ist das so. Bei kleineren Projekten hast du die Probleme nicht, das ist richtig.
-
nep schrieb:
Artchi schrieb:
nep schrieb:
Beispiel: Wir haben bei uns eine Build-Umgebung mit Maven, Archiva, und Eclipse eingerichtet. Wenn ich zusätzliche Libs brauche dann füg ich die nicht per Hand ein (wie z.B. von dir bei VSStudio genannt), sondern trag das einfach als zusätzliche Maven-Dependency ein. Schon holt er mir automtisch die aktuellste releaste Version der Bibliothek. Wenn ich doch ne spezielle Release-Version brauch trag ich das einfach ein. Ist echt sehr einfach und unheimlich praktisch.
Hem, also das Eintragen in Maven ist keine Handarbeit, weil man es nicht in MSVS einträg?
Das ist ja mal ne geile Aussage.Sorry, aber du verlagerst nur die Handarbeit von einem Tool in ein anderes Tool. Die Arbeit ist aber immer noch da. Und man staune, man muß sogar noch nachdenken, welche Lib man für sein Projekt nutzen will... und sogar welche Version die Lib haben muß.
Da hast du mich falsch verstanden.
Es geht nicht um das Hinzufügen selbst (klar das muss man so oder so machen), sondern um die Art und Weise wie das geschieht.
Hier werden eben wie auch von byto erwähnt alle möglichen weiteren Abhängigkeiten automatisch aufgelöst etc.
Klar, für kleinere Projekte ist das zu Fuß (diesmal vermeide ich von Hand ;)...)) sicherlich schneller wenn man alles direkt reinzieht. Aber sobald du einige Abhängigkeiten auf Bibliotheken (in verschiedenen Release-Ständen) und diese wiedrrum verschiedene Abhängigkeiten haben, geht das so sicherlich besser.
Und vor allem ist das so viel reproduzierbarer, wie wenn man einfach selbst ständig seine Libs in VSStudio reinzieht...Man stelle sich einfach eine Art Linux Paketmanager vor, aber für die Bibliotheken. Man auch ein zentrales Repository, http://repository.sonatype.org/index.html und man kann sich natürlich auch private Repositories anlegen.
Aber vor allem ist man von der IDE unabhängig. Ein Maven Projekt kann ich in Netbeans, Eclise, InteliJ oder auch mit einem Texteditor bearbeiten. Das kann zwar Ant auch, aber Maven ist wesentlich fortschrittlicher und einfacher.
-
hürsch schrieb:
ree schrieb:
darf ich dich vielleicht dran erinnern dass es solche tools zum glück schon seit mehr als 20 Jahren gibt?
Name?
dpkg z.B.
ree schrieb:
Aber wenn du willst kannst du ja gerne einem Inder 5 euro die std bezahlen damit er das für dich erledigt.
Was auch nicht das eigentliche Problem löst.
software ist in der regel nunmal von anderer software abhängig, und die ebenfalls, das lässt sich nicht ändern, du kannst ja wenn du lustig bist auch alles selbst programmieren, dass das nicht effektiver ist als mal die abhängigkeiten einzutragen ist wohl offensichtlich
