Warum ist die Java-Toolchain eigentlich so haushoch überlegen?
-
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
-
Wenn ich in FreeBSD in einem Port, z.B. GIMP, "make install" eingebe, zieht er alle Sourcen von GIMP runter und dann noch alle fehlenden Libs, die GIMP braucht... und dann legt der GCC los und baut GIMP und alle Anhängigkeiten. Die jeweiligen Libs zieht er dann auch brav von den jeweiligen Servern, also Cairo Lib vom Cairo Server, Python vom Python Server usw. Das Ports-System ist Basistechnik von FreeBSD.
Ja, insofern gibt es das Maven-Konzept für andere "Umgebungen" schon länger.
-
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:
Sowas ist Alltag in geeignet großen Projekten. Dependancy Management ist längst nicht mehr trivial. Es lässt sich auch schwer vermeiden, wenn die Anwendung nur geeignet groß ist. Ein Projekt mit 5.000+ Klassen musst Du unweigerlich irgendwie in Module gliedern. Und wenn diese Anwendung dann produktiv eingesetzt wird, Du aber trotzdem die Software noch weiter entwickelst, wirst Du auch unweigerlich die Module versionierern wollen. Vielleicht arbeitest Du dann noch in einer größeren Firma, wo manche Module projektübergreifend eingesetzt werden. Auch dann kommst Du um die Versionierung der Module nicht drum herum.
Entsprechend schwierig gestalten sich dann auch die Builds einer solchen Multi-Modul Anwendung. Du musst zyklische Abhängigkeiten beachten bzw. vermeiden. Du musst gucken, dass Du die Module in der richtigen Reihenfolge kompilierst usw.
Maven ist da ein echt gutes Tool. Aber wer Spaß dran hat, kanns natürlich auch mit Ant und Co. per Hand machen.
