Java-Compiler und -Runtime systemweit bekannt machen?

[Vedek Bareil]

Hallo Leute,

auch ein kleiner Vedek versuchte sich schließlich in der Java-Programmierung und lud sich zu diesem Zweck das JDK (Version 1.2.2, für Windows) herunter :)

Bis jetzt scheiterte die Programmierung jedoch daran, daß das Kommando javac Quelldatei.java immerzu mit der Fehlermeldung "Befehl oder Dateiname nicht gefunden" quittiert wurde. Offenbar ist der Java-Compiler wie auch die Runtime java.exe dem System außerhalb des Java-Verzeichnisses (G:\jdk1.2.2\bin) nicht bekannt. Was kann man da tun? Vielleicht irgendwas in der Autoexec oder in der Config.sys? oder mit Regedit?

Im Prinzip könnte ich mir zwar z.B. Eclipse runterladen, wo das vermutlich alles automatisch geregelt wird, aber in Anbetracht der exorbitanten Dateigröße von 85 MB wäre das ein Verzweiflungsakt, zu dem man sich als 56K-Modem-Nutzer als allerletzten Ausweg entschließen würde ;)

[mithrandir]

Dere!

1) Das ist bereits eine ziemlich betagte Version des JDK. Das ist dir schon klar, oder?

2) Autoexec? Verwendest du DOS? Wenn nicht, solltest du die PATH-Variable über die Systemeigenschaften setzen... (Systemsteuerung->System->Erweitert->Umgebungsvariablen)

3) Du könntest in eine Ausgabe des Java-Magazins investieren. Dort gibt es auf der CD stets eine aktuelle Version des Eclipse-Studios und das kostet nicht die Welt ; - )

bye, mith

[Exxtreme]

Wenn man eine halbwegs ausgereift IDE haben will -> www.borland.de/jbuilder

Die Foundation Edition gibt's für umsonst. =)

[HellHorse]

Wenn man eine halbwegs ausgereift IDE haben will -> www.borland.de/jbuilder

Die Foundation Edition gibt's für umsonst. =)
Ich weiss nicht, was ich bis und mit JBuilder 9 gesehen habe, sieht extrem alt ggü Eclipse aus.
(rein für's Java Code schreiben, wenn man mal von EJB und solchen Geschichten absieht)

Oh ich sehe gerade, Refactoring Support gibt's in der Fundation Edition nicht. Damit hat sich die Sache wohl erledigt.
Der graphische Debugger fehlt auch (der Eclipse Debugger pwnt übrigens, wie ich letzhin feststellen durfte).
Als einziger Pluspunkt fällt mir ehrlich gesagt nur der vermutlich bessere Support der Java 1.5 "Sprachfeatures" ein, obwohl eclipse mit 3.1 wohl auch stark aufholen wird.

Und wenn's was kosten darf: IDEA.

[Vedek Bareil]

Mit der PATH-Variablen hab ich's jetzt versucht, bringt aber nicht viel. Compilieren geht zwar jetzt, dafür gibt's dann beim Ausführen wieder nur die Fehlermeldung:

Exception in thread "main" java.lang.NoClassDefFoundError: Filename/class

mit denen Java mich schon unter Linux immer überhäuft hatte. Wenn ich die Entwicklungsumgebung VIDE benutze, ändert die sich auch schonmal in

java.lang.NoSuchMethodError: main

Da würde ich ja noch am ehesten auf der Fehlen einer main-Routine in meinem Programm tippen, eine solche ist aber da...

[Exxtreme]

Ich weiss nicht, was ich bis und mit JBuilder 9 gesehen habe, sieht extrem alt ggü Eclipse aus.
(rein für's Java Code schreiben, wenn man mal von EJB und solchen Geschichten absieht)

Oh ich sehe gerade, Refactoring Support gibt's in der Fundation Edition nicht. Damit hat sich die Sache wohl erledigt.
Der graphische Debugger fehlt auch (der Eclipse Debugger pwnt übrigens, wie ich letzhin feststellen durfte).
Als einziger Pluspunkt fällt mir ehrlich gesagt nur der vermutlich bessere Support der Java 1.5 "Sprachfeatures" ein, obwohl eclipse mit 3.1 wohl auch stark aufholen wird.

Und wenn's was kosten darf: IDEA.
Gibt's Eclipse auch für Linux?

[Aqualon]

Gibt's Eclipse auch für Linux?
*hüstel* (http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.0.1-200409161125/index.php)

HellHorse: Laut http://info.borland.de/newsletter/nl04_3/JBuilder2005/JBuilder2005.htm gibt es Refactoring auch in der Foundation Edition.

Aqua

[Senior Sanchez]

Ich weiss nicht, was ich bis und mit JBuilder 9 gesehen habe, sieht extrem alt ggü Eclipse aus.
(rein für's Java Code schreiben, wenn man mal von EJB und solchen Geschichten absieht)

Oh ich sehe gerade, Refactoring Support gibt's in der Fundation Edition nicht. Damit hat sich die Sache wohl erledigt.
Der graphische Debugger fehlt auch (der Eclipse Debugger pwnt übrigens, wie ich letzhin feststellen durfte).
Als einziger Pluspunkt fällt mir ehrlich gesagt nur der vermutlich bessere Support der Java 1.5 "Sprachfeatures" ein, obwohl eclipse mit 3.1 wohl auch stark aufholen wird.

Und wenn's was kosten darf: IDEA.


ich weiß ja nicht, was du da genau gesehen hast, aber sooo schlecht ist der JBuilder gar nicht. Ich benutze auf arbeit eclipse und zu hause eigentlich den jbuilder und kann die demzufolge schon etwas vergleichen.

Die Stärke von eclipse ist seine offenheit, es ist halt ne werkzeugplattform die de leicht erweitern kannst und bestimmte dinge wie die cvs integration sind meiner meinung nach dort besser gelöst.

ABER: das Argument eclipse sehe besser aus (dank SWT) und sei auch noch schneller, da gehe ich keinesfalls mit. Performance- und Stabilitätsmäßig gesehen (GUI-bau ist nen paradebeispiel) kann es eclipse mit dem JBuilder net aufnehmen, der läuft in meinen Augen wesentlich smoother und ehrlich gesagt macht so das Arbeiten auch mehr Spaß mit. Eclipse ist selbst auf starken rechnern (war nen Pentium M mit 1,5 Ghz) ständig damit beschäftigt den Quellcode zu parsen und irgendwelche Code-schnipsel zu analysieren und irgendwelche klassen raussuchen und so weiter....... der JBuilder macht das auch, nur hier kann ich ohne probs schnell weiter tippen, eclipse schafft das nicht.
Ich finde auch den JBuilder für Einsteiger einfacher, da eclipse mit seinen views den neuling geradezu erschlägt.


mfg Senior Sanchez

[HellHorse]

http://info.borland.de/newsletter/nl04_3/JBuilder2005/JBuilder2005.htm gibt es Refactoring auch in der Foundation Edition.

Also laut diesem PDF nicht:
http://www.borland.de/jbuilder/pdf/jb2005_techview.pdf


ABER: das Argument eclipse sehe besser aus (dank SWT) und sei auch noch schneller, da gehe ich keinesfalls mit.
Wo habe ich das behauptet?

Ich finde auch den JBuilder für Einsteiger einfacher, da eclipse mit seinen views den neuling geradezu erschlägt.

Das stimmt, da geht's einen Moment, bis man durchblickt.

[Vedek Bareil]

sodele, ich hab des Problems Lösung gefunden, und zwar in der FAQ (http://www.faqs.org/faqs/de/comp-lang-java/faq/) von de.comp.lang.java:

im Runtime-Aufruf
java BytecodeFile
einfach die Dateiendung .class hinter BytecodeFile weglassen. Und schon klappt alles =)

[Senior Sanchez]

[quote]
Zitat von Senior Sanchez
ABER: das Argument eclipse sehe besser aus (dank SWT) und sei auch noch schneller, da gehe ich keinesfalls mit.

Wo habe ich das behauptet?
[quote]

ich weiß, das hast du nicht gesagt. Das war etwas unsauber formuliert, meinte damit eigentlich so die allgemeine resonanz mancher eclipse-jünger.

mfg Senior Sanchez

[Crushinator]

Eine Frage in die Runde: Gibt's für Eclipse auch einen relativ vernünftigen GUI-Builder, insbesondere für die JAVA-perspective?

[HellHorse]

Eine Frage in die Runde: Gibt's für Eclipse auch einen relativ vernünftigen GUI-Builder, insbesondere für die JAVA-perspective?
Ich mach mir nichts aus GUI-Buildern aber:
http://www.eclipse.org/vep/
http://www-106.ibm.com/developerworks/opensource/library/os-ecvisual/

[Crushinator]

Kann ich verstehen. Ich frage nur deshalb, weil ich die nette Aufgabe bekommen habe, für unsere Abteilung Ausschau danach zu halten, ob wir angesichts dessen, was in den nächsten Jahren - Longhorn läßt grüßen - auf uns zukommen wird, wie man auf möglichst einfacher Weise bei einigen Produkten unseres Hauses etwas MS-unabhängier werden könnte. GUI-Builder spielen in diesem Zusammenhang eine sehr große Rolle.

Danke für die Links. :)

[Senior Sanchez]

Also von dem GUI Builder bei eclipse würde ich abraten. Das Teil mag ja ganz nett sein, aber sobald du etwas größere Oberflächen designest wird das teil katastrophal langsam, instabil und der erzeugte code ist auch nicht der beste. Gerade wenn de verschiedene Layouts nimmst, wird das richtig haarig und bei per Hand modifiziertem Code tut sich der GUI Builder dann auch schwer.

Ob man GUI Builder mag oder nicht (ich mag sie, baue mir damit schnell immer GUIs zusammen und tune sie dann im nachhinein per Hand), bisher habe ich keinen besseren als im JBuilder gesehen.

Und SWT, was der eclipse builder glaube auch kann, braucht man meiner Ansicht nach so gut wie nicht.

mfg Senior Sanchez

[Crushinator]

Auch Deine Argumente sind nachvollziehbar. Da es sich jedoch um eine Entscheidung handelt, die einem oder einer Firma durch Beschaffung/Erneuerung kommerzieller IDE schlimmstenfalls mehrere Tausend Euronen kosten kann, sollte man möglichst alle Möglichkeiten ausschöpfen, wodurch sich Geld sparen läßt. ;)

[Senior Sanchez]

Auch Deine Argumente sind nachvollziehbar. Da es sich jedoch um eine Entscheidung handelt, die einem oder einer Firma durch Beschaffung/Erneuerung kommerzieller IDE schlimmstenfalls mehrere Tausend Euronen kosten kann, sollte man möglichst alle Möglichkeiten ausschöpfen, wodurch sich Geld sparen läßt.


Das ist wohl wahr, bloß das Geld kannste dann an anderer Stelle wieder in Gehaltskosten stecken, da das elendig sein kann, mitm eclipse gui builder da was zu basteln (ich hab neulich nen Dialog gebaut, knapp 60 Komponenten waren da drin, ich wäre fast verzweifelt........ mit meinem jbuilder hätte ich das aber locker flockig schnell zusammengebaut ;) )

Kannst natürlich dann das gesparte Geld auch in einen Eclipse GUi Experten investieren, wenn alle irgendwann austicken wegen dem teil ;))) (ich würde mich für diese rolle als experte opfern und zur verfügung stellen *rofl*)


mfg Senior Sanchez

[PH4Real]

Eine Frage in die Runde: Gibt's für Eclipse auch einen relativ vernünftigen GUI-Builder, insbesondere für die JAVA-perspective?

Ich finde bisher Jigloo am Besten: http://cloudgarden.com/jigloo/

Der steckt momentan meiner Meinung nach sowohl den Eclipse GUI Builder, als auch den GUI Editor von Borland in die Tasche. Besonders das Erstellen von GridBagLayouts fand ich damit sehr komfortabel.

[Crushinator]

...womit für mich schon mal feststeht, daß Eclipse bei uns mindestens ergänzend zum JBuilder Enterprise Verwendung finden wird. Danke Euch allen. :)

[grakaman]

Wenn man eine halbwegs ausgereift IDE haben will -> www.borland.de/jbuilder

Die Foundation Edition gibt's für umsonst. =)

Habe mir mal die 2005er Enterprise Daten durchgelesen und das sieht richtig gut aus. Wer hier mit Eclipse ankommt, verdient nur ein müdes Lächeln. Und wer GUI's manuell schreibt, der hat dann sicher auch noch nie was von Application Lifecycle gehört, ein in den kommenden IDE Generationen immer wichtiger werdende Integration. Schon einmal aus Produktivgründen ist Eclipse undiskutabel für kommerzielle Einsätze. Dass Eclipse vielleicht mehr Funktionalität als die sogenannten kostenlosen Standard Versionen kommerzieller Ableger bietet und sich für den Privatgebrauch eignet, mag vielleicht sein, aber absolut unerheblich.

Und wenn Mr. Wichtig meint, dass seine große "kommerzielle" Klitsche sich keine Lizensen leisten kann, dann frage ich mich echt in welcher Klitsche er denn arbeitet. Denn komischerweise können das viele Mittelsändler ohne Probleme. Außerdem bieten einige Unternehmen äußerst günstige Abbonements für zumindest einen Arbeitsplatz, bei der man jede Software kostenlos zugeschickt bekommt und man einfach nur noch bei Bedarf extra Lizensen dazubestellt. Ach und bei richtig großen Unternehmen wie z.B. der Coba spielen Lizensen gar keine Rolle. Nicht weil die Unternehmen so viel Geld haben, sondern über extreme Sonderkonditionen verfügen und die Softwarehersteller nur über die schiere Masse an Arbeitsplätzen das Geld reinbekommen.

[Senior Sanchez]

Zitat:
Zitat von Exxtreme
Wenn man eine halbwegs ausgereift IDE haben will -> www.borland.de/jbuilder

Die Foundation Edition gibt's für umsonst.


Habe mir mal die 2005er Enterprise Daten durchgelesen und das sieht richtig gut aus. Wer hier mit Eclipse ankommt, verdient nur ein müdes Lächeln. Und wer GUI's manuell schreibt, der hat dann sicher auch noch nie was von Application Lifecycle gehört, ein in den kommenden IDE Generationen immer wichtiger werdende Integration. Schon einmal aus Produktivgründen ist Eclipse undiskutabel für kommerzielle Einsätze. Dass Eclipse vielleicht mehr Funktionalität als die sogenannten kostenlosen Standard Versionen kommerzieller Ableger bietet und sich für den Privatgebrauch eignet, mag vielleicht sein, aber absolut unerheblich.

Und wenn Mr. Wichtig meint, dass seine große "kommerzielle" Klitsche sich keine Lizensen leisten kann, dann frage ich mich echt in welcher Klitsche er denn arbeitet. Denn komischerweise können das viele Mittelsändler ohne Probleme. Außerdem bieten einige Unternehmen äußerst günstige Abbonements für zumindest einen Arbeitsplatz, bei der man jede Software kostenlos zugeschickt bekommt und man einfach nur noch bei Bedarf extra Lizensen dazubestellt. Ach und bei richtig großen Unternehmen wie z.B. der Coba spielen Lizensen gar keine Rolle. Nicht weil die Unternehmen so viel Geld haben, sondern über extreme Sonderkonditionen verfügen und die Softwarehersteller nur über die schiere Masse an Arbeitsplätzen das Geld reinbekommen.


Ehm ja, was hat denn der JBuilder 2005 Enterprise deiner Meinung nach so alles für geniale Features? EJBs? Application Server Integration? WebServices?

Das ist schön das er das alles kann, aus meiner Sicht widmest du diesen Dingen aber zu hohe Priorität. EJBs und dergleichen werden meiner Ansicht nach eh nicht so oft benutzt wie manche denken, weil oft wird da einfach mit Kanonen auf Spatzen geschossen oder es ist einfach zu kostspielig, da ja noch Lizenzen aufgebracht werden müssen für Application Server, Datenbankserver und so weiter.

Warum ist Eclipse deiner Meinung nach völlig indisktubal für kommerzielle Einsätze? Also wir auf Arbeit haben damit kein Problem, wichtige Features wie CVS Integration oder andere Dinge sind sauber in die Plattform integriert und falls nicht, lässt es sich eben bei Eclipse nachrüsten, was der JBuilder wohl nicht kann. Hier schmeißt Borland lieber alle 6 Monate ne neue Version auf den Markt um irgendwelche klitzekleinen features zu integrieren.

Auch wenn du den Kostenfaktor herunterspielst, das ist ein wichtiges Argument für Eclipse, eben das man dort eine professionelle IDE für lau bekommt. Und gerade für kleinere bis mittelständische Unternehmen ist das doch ein Grund, da man erstens Geld spart und sich nicht so sehr an einen Hersteller bindet. Ich glaube, dass Eclipse wohl ansonsten auch nicht diesen Boom erlebt hätte, zumal du Eclipse ja auch noch für andere Programmiersprachen einsetzen kannst, also wieder Geld gespart, weil du dir keine neue IDE für ne andere Programmiersprache kaufen musst.

Außerdem, ich denke das Geld rausschmeißen muss man nicht und nen anderer nicht zu unterschätzender Vorteil ist, das viele Ausbildungsbetriebe und Hochschulen selbst mit Eclipse arbeiten --> die neuen, jungen arbeitnehmer brauchen sich nicht umgewöhnen sondern können direkt in ihrer gewohnten IDE weiterarbeiten.


PS: bedenke bitte ein bissl deinen Umgangston


mfg Senior Sanchez

[Senior Sanchez]

Zitat:
Zitat von Crushinator
Eine Frage in die Runde: Gibt's für Eclipse auch einen relativ vernünftigen GUI-Builder, insbesondere für die JAVA-perspective?


Ich finde bisher Jigloo am Besten: http://cloudgarden.com/jigloo/

Der steckt momentan meiner Meinung nach sowohl den Eclipse GUI Builder, als auch den GUI Editor von Borland in die Tasche. Besonders das Erstellen von GridBagLayouts fand ich damit sehr komfortabel.


Das ganze Teil sieht richtig gut aus...... nachm Borland Abklatsch ;) Für mich sieht das eindeutig nach dem typischen Borland-GUI-Builder style aus (kann man sich auch Delphi anguggen, das ist fast genauso): oben diese Leiste mit den Komponenten, rechts diese baumstruktur mit den bereits integrierten Komponenten und unten dieser "Objektinspektor" ;) also wo da sämtliche Eigenschaften stehen.

Aber danke für den link, werde es mir mal anschauen und vllt vereint das ja eine der stärken des JBuilder mit Eclipse ;)


mfg Senior Sanchez

[grakaman]

Das ist schön das er das alles kann, aus meiner Sicht widmest du diesen Dingen aber zu hohe Priorität. EJBs und dergleichen werden meiner Ansicht nach eh nicht so oft benutzt wie manche denken, weil oft wird da einfach mit Kanonen auf Spatzen geschossen oder es ist einfach zu kostspielig, da ja noch Lizenzen aufgebracht werden müssen für Application Server, Datenbankserver und so weiter.


Das ist der Standardsatz von Leuten, die sich der Realität verweigern: "Mit Kanonen auf Spatzen schießen". EJB ist in der Java Welt eine äußerst leichte Möglichkeit einen generischen Data Layer in einem Mehrschichtensystem zu implementieren. Leute, die natürlich die grundlegensten architektonischen Richtlinien nicht kennen oder um deren Vorteile wissen, schreiben alles per Hand und meinen dann auch noch, dass wäre eleganter oder besser. Clevere Menschen versuchen abtrakte Probleme und Designrichtlinien generisch zu lösen oder zumindest die Arbeit von Assistenten erledigen zu lassen.


Warum ist Eclipse deiner Meinung nach völlig indisktubal für kommerzielle Einsätze? Also wir auf Arbeit haben damit kein Problem, wichtige Features wie CVS Integration oder andere Dinge sind sauber in die Plattform integriert und falls nicht, lässt es sich eben bei Eclipse nachrüsten, was der JBuilder wohl nicht kann. Hier schmeißt Borland lieber alle 6 Monate ne neue Version auf den Markt um irgendwelche klitzekleinen features zu integrieren.


Was zählt sind Produktivfeatures. Ich will mit ganz geringem Aufwand Mehrschichtensysteme implementieren. Ich will meinen Data Layer über Assistenten direkt in der IDE testen, ob der denn genau so funktioniert, wie ich das will und nicht erst Minuten/Stunden mit der Implementierung verschwenden, um dann zu merken, dass ich wieder alles ändern muss. Ich will GUI's in wenigen Sekunden/Minuten zusammenklicken, damit diese mit der Geschäftsschicht kommunizieren kann. Was glaubst du, warum einige Leute die GUI manuell schreiben? Weil viele den Sinn von Mehrschichtensystemen einfach nicht verstehen und alles in einem Layer schreiben. Dann ist klar, dass man beim manuellen Coden diesen besser organisieren kann. Von mir aus müssen solche Leute dann eben ständig mit dem Kopf gegen die Wand rennen, mir auch scheiß egal. Ich will den kompletten Entwicklungszyklus in der IDE haben, um schnell reagieren zu können. Z.b. Refactoring der UML Diagramme, was sich natürlich sofort im Code auswirken soll. Ich will Pattern Vorlagen für UML Diagramme haben und den Scheiß nicht manuell schreiben. Ich will Änderungen vom Kunden schnell integrieren und diese sollen mir so weit wie möglich automatisch die Arbeit abnehmen. Das ganze soll auch im Team funktionieren. Ich will einen ordentlichen Serverexplorer, über den ich neben Datenbankfunktionen auch noch andere Überwachungsfunktionen auf Betriebssystemebene in einfachster Art und Weise in meine Programme implementieren kann. Und es gibt noch tausend mehr produktive Möglichkeiten, die ich wohl selbst bei weitem nicht einmal alle kenne.

Und btw, JBuilder 2005 unterstützt freilich CSV.


Auch wenn du den Kostenfaktor herunterspielst, das ist ein wichtiges Argument für Eclipse, eben das man dort eine professionelle IDE für lau bekommt.


Der Kostenfaktor ist ein entscheidentens Argument gegen Eclipse. Was du da an Arbeitszeit mehr verbrätst, hast du selbst bei einem kleinen Projekt mind. nach der Hälfte der veranschlagter Zeit wieder raus.


Und gerade für kleinere bis mittelständische Unternehmen ist das doch ein Grund, da man erstens Geld spart und sich nicht so sehr an einen Hersteller bindet.
Ich glaube, dass Eclipse wohl ansonsten auch nicht diesen Boom erlebt hätte, zumal du Eclipse ja auch noch für andere Programmiersprachen einsetzen kannst, also wieder Geld gespart, weil du dir keine neue IDE für ne andere Programmiersprache kaufen musst.


Du lebst in einer Traumwelt. Eclipse ist ein besserer Texteditor und durchaus die beste IDE für lau. Aber trotzdem noch meilenweit hinter den Features der kommerziellen IDE's in der Enterprise Versionen hinterher.

[Senior Sanchez]

Das ist der Standardsatz von Leuten, die sich der Realität verweigern: "Mit Kanonen auf Spatzen schießen". EJB ist in der Java Welt eine äußerst leichte Möglichkeit einen generischen Data Layer in einem Mehrschichtensystem zu implementieren. Leute, die natürlich die grundlegensten architektonischen Richtlinien nicht kennen oder um deren Vorteile wissen, schreiben alles per Hand und meinen dann auch noch, dass wäre eleganter oder besser. Clevere Menschen versuchen abtrakte Probleme und Designrichtlinien generisch zu lösen oder zumindest die Arbeit von Assistenten erledigen zu lassen.


Das alles per Hand geschrieben werden soll oder das EJBs, was schlechtes sind, das habe ich nie gesagt. Es ist bloß einfach für viele Dinge oversized und deswegen wendet man diese da sinnvollerweise nicht an. Es gibt durchaus Anwendungszwecke, eben der Enterprisebereich wo entsprechend komplexe Dinge entworfen werden müssen, z.B. wie bei Amazon.com (die setzen afaik J2EE ein), bloß solche Felder müssen doch von einem Großteil der Applikationen nicht bearbeitet werden. Und für solche Zwecke bietet dann halt auch IBM seine auf eclipse basierende Umgebung an, wo de das alles machen kannst.


Was zählt sind Produktivfeatures. Ich will mit ganz geringem Aufwand Mehrschichtensysteme implementieren. Ich will meinen Data Layer über Assistenten direkt in der IDE testen, ob der denn genau so funktioniert, wie ich das will und nicht erst Minuten/Stunden mit der Implementierung verschwenden, um dann zu merken, dass ich wieder alles ändern muss. Ich will GUI's in wenigen Sekunden/Minuten zusammenklicken, damit diese mit der Geschäftsschicht kommunizieren kann. Was glaubst du, warum einige Leute die GUI manuell schreiben? Weil viele den Sinn von Mehrschichtensystemen einfach nicht verstehen und alles in einem Layer schreiben. Dann ist klar, dass man beim manuellen Coden diesen besser organisieren kann. Von mir aus müssen solche Leute dann eben ständig mit dem Kopf gegen die Wand rennen, mir auch scheiß egal. Ich will den kompletten Entwicklungszyklus in der IDE haben, um schnell reagieren zu können. Z.b. Refactoring der UML Diagramme, was sich natürlich sofort im Code auswirken soll. Ich will Pattern Vorlagen für UML Diagramme haben und den Scheiß nicht manuell schreiben. Ich will Änderungen vom Kunden schnell integrieren und diese sollen mir so weit wie möglich automatisch die Arbeit abnehmen. Das ganze soll auch im Team funktionieren. Ich will einen ordentlichen Serverexplorer, über den ich neben Datenbankfunktionen auch noch andere Überwachungsfunktionen auf Betriebssystemebene in einfachster Art und Weise in meine Programme implementieren kann. Und es gibt noch tausend mehr produktive Möglichkeiten, die ich wohl selbst bei weitem nicht einmal alle kenne.


Solche Testdinge müssen nicht zwangsläufig inner IDE ablaufen, das geht auch schnell über externe Tools die de dann auch inner Produktivumgebung eingesetzt werden können. Nicht das du irgendwann erlebst, was viele n00bs immer sagen: "Aber im JBuilder hat meine Applikation doch funktioniert".

Aus deinen Aussagen über GUIs schließe ich mal, dass du nicht oft Oberflächen designest, bzw. gute GUIs baust. Manuell geschriebener GUI Code ist meistens deutlich besser und flexibler und bei so zusammengeklicktem Zeug haste dann nämlich meistens das Prob, dass wenn die Auflösung, das Betriebssystem oder was auch immer sich ändert, dann die GUI total scheiße aussieht. Oder verkaufste gleich passend zu deiner Software den vorkonfigurierten Rechner wo sowas nicht passieren kann? *g* Und manuell geschriebener Code muss das nicht ausschließen, was du da forderst und meistens tut er das auch nicht, weil Leute die GUIs per Hand coden, wissen in der Regel wie man mehrere Schichten implementiert.
Bei UML Diagrammen und deren Refactoring gebe ich dir Recht, das kann eclipse noch (!) nicht! Aber diese ganzen Automatismen, die du da beschreibst, ich wäre mit sowas vorsichtiger, weil wenn irgendetwas gegen den Baum läuft, dann weiß der Manuell-Coder schneller wo der Fehler liegen kann, weil er eben alles von hand implementiert hat und sich nciht auf irgendwelche Assistenten verlässt. Aber solche Assistenten ermöglichen natürlich schnelleres coding, aber nicht zweifelsohne das bessere.


Und btw, JBuilder 2005 unterstützt freilich CSV.


Habe ich irgendwo geschrieben, dass er das nicht kann? Ich habe nur gesagt, das ich die CVS Integration in eclipse besser gelungen finde.


Der Kostenfaktor ist ein entscheidentens Argument gegen Eclipse. Was du da an Arbeitszeit mehr verbrätst, hast du selbst bei einem kleinen Projekt mind. nach der Hälfte der veranschlagter Zeit wieder raus.


Ist Blödsinn aus meiner Sicht, zeige mir Dinge auf wo du jetzt mehr Zeit verbrauchst? (Ich denke mal das läuft wieder auf die Automatismen der IDE hinaus) Und noch was, in eclipse sind features wesentlich schneller implementiert die helfen Zeit zu sparen, als im JBuilder. Ich erinnere mich noch daran wielange Borland gebraucht hat, endlich das JDK 1.4 richtig zu unterstützen!


Du lebst in einer Traumwelt. Eclipse ist ein besserer Texteditor und durchaus die beste IDE für lau. Aber trotzdem noch meilenweit hinter den Features der kommerziellen IDE's in der Enterprise Versionen hinterher.


Ich schließe mal daraus, dass du dich noch nicht wirklich intensiv mit Eclipse beschäftigt hast, denn dann würdest du anders urteilen.


mfg Senior Sanchez

[grakaman]

Aber diese ganzen Automatismen, die du da beschreibst, ich wäre mit sowas vorsichtiger, weil wenn irgendetwas gegen den Baum läuft, dann weiß der Manuell-Coder schneller wo der Fehler liegen kann, weil er eben alles von hand implementiert hat und sich nciht auf irgendwelche Assistenten verlässt.

Nur mal um eins klar zu stellen, dass man ein tiefes Verständnis haben muss, ist unumstritten. Von jemanden, der übrigens Ahnung von Softwarearchitektur hat, ist das eher selbstverständlich als jemanden, der sinnentfreit drauf los programmiert und alles händisch macht. Code schreiben kann jeder. Die Frage ist, ob man es gut und effizient macht. Wenn man keine Ahnung von Softwarearchitektur hat, dann nützen dir auch alle Assistenten der Welt nichts, da du höchstwahrscheinlich unflexiblen Müll damit produzierst. Weist du hingegen, wie du sie richtig einsetzt, erleichtern sie die Arbeit erheblich und sind mit der entscheidente Produktivpunkt.
Ansonsten divergieren unsere Ansichten dermaßen, dass ein Weiterdiskutieren sinnlos ist. Es ist nur noch zu sagen, dass deine Bedenken bzgl. GUI und Auflösung recht bedenkenlos sind, da es für die automatische Ausrichtung in allen maßgebenden Frameworks Komponenten gibt. Ja stell dir vor, über solche trivialen Dinge haben sich schlaue Menschen schon Jahre zuvor Gedanken gemacht. Die kannst du dann ebenfalls per Designer einfach auf die GUI ziehen kannst. Für wohl 90% aller Geschäftsanwendungen reicht ein Zusammenklicken aus, um jedenfalls erst einmal ca. 95% des Grundgerüsts zu erstellen. Ich kann immer über diese Assistenten-Gegner lachen. Selbst wenn ich in Ausnahmefällen 10- oder 40% an der GUI selbst coden muss, lass ich mir den Rest lieber erstellen, als alles selbst zu schreiben.

[Senior Sanchez]

Es ist nur noch zu sagen, dass deine Bedenken bzgl. GUI und Auflösung recht bedenkenlos sind, da es für die automatische Ausrichtung in allen maßgebenden Frameworks Komponenten gibt. Ja stell dir vor, über solche trivialen Dinge haben sich schlaue Menschen schon Jahre zuvor Gedanken gemacht. Die kannst du dann ebenfalls per Designer einfach auf die GUI ziehen kannst. Für wohl 90% aller Geschäftsanwendungen reicht ein Zusammenklicken aus, um jedenfalls erst einmal ca. 95% des Grundgerüsts zu erstellen. Ich kann immer über diese Assistenten-Gegner lachen. Selbst wenn ich in Ausnahmefällen 10- oder 40% an der GUI selbst coden muss, lass ich mir den Rest lieber erstellen, als alles selbst zu schreiben.


Erstens habe ich nicht gesagt, das ich GUIs nur händisch mache, sondern das ich sie per GUI Builder zusammenbaue und dann noch per Hand nachoptimiere.
Und, entschuldigung, wenn ich das sage, aber von GUI Design hast du denke ich keine ahnung. Du glaubst gar nicht wieviele GUIs daneben gehen, obwohl es ja angeblich diese tollen Frameworks gibt! Das einzig brauchbare was solche Dinge leicht umgehen kann ist meiner Meinung nach das FormLayout, denn da wurde nicht der Fehler begangen, was die schlauen Menschen sich vor Jahren ausgedacht haben: es ist einfach damit zu arbeiten! Das GridBagLayout hingegen, was ja eigentlich dieses ganze Resizing und so kann ist dagegen aber nicht gerade einfach zu handlen und da brauchste schon einiges an know-how! Deshalb gehen auch soviele Designs daneben!


mfg Senior Sanchez

[Xmas]

Ich will [...]
Das ist so etwa die Quintessenz deines Postings. Du willst. Einige Entwickler wollen etwas ganz anderes, und das, aufgrund ihrer Zielsetzung, auch aus gutem Grund. Deswegen ist Eclipse auch nicht indiskutabel für kommerziellen Einsatz.

Du lebst in einer Traumwelt. Eclipse ist ein besserer Texteditor und durchaus die beste IDE für lau. Aber trotzdem noch meilenweit hinter den Features der kommerziellen IDE's in der Enterprise Versionen hinterher.
Du redest wohl die ganze Zeit von Eclipse ohne Plugins. Es gibt eine Menge sehr brauchbarer Plugins für Eclipse, die deinen "kommerziellen" Produkten in nichts nachstehen (und es gibt btw. auch einige kommerzielle Plugins, z.b. für UML, mit denen Eclipse immer noch weniger kostet)

[grakaman]

Du redest wohl die ganze Zeit von Eclipse ohne Plugins. Es gibt eine Menge sehr brauchbarer Plugins für Eclipse, die deinen "kommerziellen" Produkten in nichts nachstehen (und es gibt btw. auch einige kommerzielle Plugins, z.b. für UML, mit denen Eclipse immer noch weniger kostet)

Das halte ich für Unsinn, auch wenn es die OpenSource Gemeinde immer gerne so darstellt. Dein kostenloses UML Plugin kann vielleicht Diagramme zeichen, aber du glaubst doch um Gotteswillen nicht, dass das mit kommerziellen Application Lifecycle Tools wie Together/XDE auch nur annähernd konkurrieren kann. Denn da steckt wesentlich mehr dahinter, als nur Diagramme zeichnen und per Knopf Code zu generieren. Und wo wir gerade dabei sind, dass Problem ist bei den Plugins, dass sie untereinander imkompatibel sind und nie die komplette Funktionlität erreichen, als wenn alles aus einer Hand ist. Auch bei kommerziellen IDE's kann man Plugins integrieren, aber diese können dann z.B. auch keinen Nutzen vom Projektexplorer oder Serverexplorer ziehen. Dann müsste jemand das Super Plugin züchten, was schon alle Funktionlität beinhaltet, aber dann brauch ich auch kein Plugin Prinzip. Deswegen kann ein Plugin immer nur als Zusatz angesehen werden, aber man kann nicht mit Plugins die selbe Funktionalität erreichen. Nur mal hier als Bsp. angemerkt, wäre die Interaktion des GUI Designer mit dem Serverexplorer oder UML Diagrammen.

[Senior Sanchez]

Das ist halte ich für Unsinn, auch wenn es die OpenSource Gemeinde immer gerne so darstellt. Dein kostenloses UML Plugin kann vielleicht Diagramme zeichen, aber du glaubst doch um Gotteswillen nicht, dass das mit kommerziellen Application Lifecycle Tools wie Together/XDE auch nur annähernd konkurrieren kann. Denn da steckt ein wesentlich mehr dahinter, außer nur Diagramme zeichnen und per Knopf Code zu generieren. Und wo wir gerade dabei sind, dass Problem ist bei den Plugins, dass sie untereinander imkompatibel sind und nie die komplette Funktionlität erreichen, als wenn alles aus einer Hand ist. Auch bei kommerziellen IDE's kann man Plugins integrieren, aber diese können dann z.B. auch keinen Nutzen vom Projektexplorer oder Serverexplorer ziehen. Dann müsste jemand das Super Plugin züchten, was schon alle Funktionlität beinhaltet, aber dann brauch ich auch kein Plugin Prinzip. Deswegen kann ein Plugin immer nur als Zusatz angesehen werden, aber man kann nicht mit Plugins die selbe Funktionalität erreichen. Nur mal hier als Bsp. angemerkt, wäre die Interaktion des GUI Designer mit dem Serverexplorer oder UML Diagrammen.


Erkenne ich da eine generelle Abneigung gegenüber OpenSource? Hab so den Eindruck als denkst du, dass OpenSource Software schlechter ist, als kommerzielle Software. Aber was ist zum Beispiel mit JBoss? Das hat ne J2EE Zertifizierung bekommen, also kann das schon nicht schlecht sein! Was ist mit Apache Tomcat? Läuft auch super und ist der quasi-standard unter den Servlet-containern. Soll ich noch weitere OpenSource Software aufzählen? Nicht umsonst hat das Java Magazin auch ne Rubrik "Open Source Perlen".
Also warum sollte es nicht irgendwann nen richtig gutes UML plugin für eclipse geben?

Bisher habe ich bei eclipse keine inkompatibilitäten zwischen den plugins bemerkt. Und man kann wohl mit plugins die selbe Funktionalität erreichen!

Meine Aussage dass du dich mit eclipse noch gar nicht richtig beschäftigt hast, bestätigt sich immer mehr.


mfg Senior Sanchez

[grakaman]

Erkenne ich da eine generelle Abneigung gegenüber OpenSource? Hab so den Eindruck als denkst du, dass OpenSource Software schlechter ist, als kommerzielle Software. Aber was ist zum Beispiel mit JBoss? Das hat ne J2EE Zertifizierung bekommen, also kann das schon nicht schlecht sein! Was ist mit Apache Tomcat? Läuft auch super und ist der quasi-standard unter den Servlet-containern. Soll ich noch weitere OpenSource Software aufzählen? Nicht umsonst hat das Java Magazin auch ne Rubrik "Open Source Perlen".
Also warum sollte es nicht irgendwann nen richtig gutes UML plugin für eclipse geben?

Bisher habe ich bei eclipse keine inkompatibilitäten zwischen den plugins bemerkt. Und man kann wohl mit plugins die selbe Funktionalität erreichen!

Meine Aussage dass du dich mit eclipse noch gar nicht richtig beschäftigt hast, bestätigt sich immer mehr.


mfg Senior Sanchez

Da du ja vornehmlich Argumente ignorierst oder verdrehst, hat es nicht weiter Sinn weiterzudiskutieren. Jeder halbwegs denkende Mensch hat sofort erkannt, dass ich mit Inkompatibilitäten nicht das Nichtfunktionieren der Plugins meine, sondern die Interaktion zwischen diesen.

[Senior Sanchez]

Da du ja vornehmlich Argumente ignorierst oder verdrehst, hat es nicht weiter Sinn weiterzudiskutieren. Jeder halbwegs denkende Mensch hat sofort erkannt, dass ich mit Inkompatibilitäten nicht das Nichtfunktionieren der Plugins meine, sondern die Interaktion zwischen diesen.


Ich habe Argumente nicht ignoriert oder verdreht, hast bloß nix mehr entgegenzusetzen so wie ich das sehe.
Zu den plugins, habs mir nochmal durchgelesen und man kann es auch so verstehe wie du es meintest, trotzdem ist es falsch: die plugins können durchaus miteinander interagieren und dann verlangen sie halt auch das alle entsprechenden plugins installiert sind.


mfg Senior Sanchez

[grakaman]

Also laut diesem PDF nicht:
http://www.borland.de/jbuilder/pdf/jb2005_techview.pdf


Komisch, da musst du dir wohl mal eine Brille kaufen.

[grakaman]

die plugins können durchaus miteinander interagieren und dann verlangen sie halt auch das alle entsprechenden plugins installiert sind.


Oh ja, Plugin A kann vielleicht auf Plugin B von der selben Projektgruppe zugreifen. Vielleicht will ich aber nicht Plugin B, sondern Plugin C von irgend jemand anderen, weil es einfach besser ist. Dann kann ich mir gleich eine alles aus einer Hand Lösung kaufen, anstatt unsinnigerweise von verschiedenen, meist auch noch schlechten Plugins abhängig zu sein. Die Realität sieht dann so aus, dass man die totale Inkonsistenz hat und jedes Plugin überschneidende Funktionalität mitschleppt, was andere auch anbieten, aber man nicht drauf zugreifen kann (z.B. Serverexplorer, Projektexplorer etc.).

[Trap]

Selbstverständlich sind Plugins schlecht, ungefähr so wie Betriebssysteme, wenn nicht alles aus einer Hand ist kann es ja nicht ordentlich sein...

[Crushinator]

Oft verwechselt man auch Interessen kommerzieller Plugins mit den der freien Varianten. In der Opensource-Welt konkuriert man weniger mit den anderen Freien. Zumindest an den OS-Projekten, wo ich je mitgearbeitet habe ging's auch darum, sich in das Umfeld möglichst nahtlos zu integrieren. Oft sind es sogar die Entwickler anderer Projekte des selben Umfeldes, die einem Tips geben, wo es noch an Kompatibilität der Interaktionen hapert, und wie man es lösen könnte.

Was ich damit sagen möchte: Plugins verschiedener Anbieter müssen nicht zwangsläufig schlechter integriert sein als ein Komplettpaket, sie können es aber. In der Opensource-Welt interagieren sie jedenfalls meist besser miteinander als in der Kommerziellen.

[HellHorse]

Komisch, da musst du dir wohl mal eine Brille kaufen.
Also unter "Advanced refactorings, including J2SE(tm) 5.0 refactorings and distributed refactoring accross projects" sehe ich bei Foundation keinen roten Punkt.
Bei "UML(r) code visualization and refactoring from UML diagrams" sehe ich nicht mal bei Developer einen.

Du findest EJB gut oder sogar leicht? Ich bin überrascht. EJB sind vieles, aber sicher nicht oo.
Und EntityBeans sind overkill z.B. auch für die Infomatik eines mitteleuropäsichen Landes, wo man sich aus genau diesem Grund explizit gegen EntityBeans und für ORB entschieden hat.
Und da, genauso wie bei hibernate, toplink und all den zwei dutzend anderen Persistenz Mechanismen für Java (warum gibt's wohl so viele, wo's doch die tollen EntityBeans gibt?), kann dann JBuilder von Haus aus eben nicht helfen.

[grakaman]

Also unter "Advanced refactorings, including J2SE(tm) 5.0 refactorings and distributed refactoring accross projects" sehe ich bei Foundation keinen roten Punkt.
Bei "UML(r) code visualization and refactoring from UML diagrams" sehe ich nicht mal bei Developer einen.

Du findest EJB gut oder sogar leicht? Ich bin überrascht. EJB sind vieles, aber sicher nicht oo.
Und EntityBeans sind overkill z.B. auch für die Infomatik eines mitteleuropäsichen Landes, wo man sich aus genau diesem Grund explizit gegen EntityBeans und für ORB entschieden hat.
Und da, genauso wie bei hibernate, toplink und all den zwei dutzend anderen Persistenz Mechanismen für Java (warum gibt's wohl so viele, wo's doch die tollen EntityBeans gibt?), kann dann JBuilder von Haus aus eben nicht helfen.

Ich rede ja auch spez. von CMP und die kann man ja mit einer ordentlichen IDE in einigen Sekunden erstellen. Warum die nicht oo sein sollen, verstehe ich nicht. Klar würde ich sie nicht in allen Bereichen einsetzen, weil dynamisch generiertes SQL nicht immer von Vorteil ist, vor allem in High Security Umgebungen. Aber zu 90% reichen sie wohl in den gängigen Projekten voll aus.

Und Eclipse kann weder distributed Refactoring, noch Refactoring auf UML Ebene. Also kann man die Foundation Version klar damit vergleichen.

[HellHorse]

Ich rede ja auch spez. von CMP und die kann man ja mit einer ordentlichen IDE in einigen Sekunden erstellen.
Ja, genau hier hilft IDE Unterstützung extrem weil es einfach nur noch dummer Code ist.
Warum die nicht oo sein sollen, verstehe ich nicht.
Vererbung und EntityBeans? Öh, ja ....
Wie geht die Regel? Daten in EntityBeans, Logik in SessionBeans, wenn es geht aus Skalierungsgründen stateless.
Nennen wir die Dinge doch beim Namen. Structs und Prozeduren, die auf structs operieren.
Aber zu 90% reichen sie wohl in den gängigen Projekten voll aus.
In 90% der Fälle reicht irgend ein anderer Persistenzmechnaismus genauso.

Also kann man die Foundation Version klar damit vergleichen.
Weisst du, was genau unter "Advanced refactorings" fällt, nebst "J2SE(tm) 5.0 refactorings and distributed refactoring accross projects"?

[Xmas]

Das halte ich für Unsinn, auch wenn es die OpenSource Gemeinde immer gerne so darstellt. Dein kostenloses UML Plugin kann vielleicht Diagramme zeichen, aber du glaubst doch um Gotteswillen nicht, dass das mit kommerziellen Application Lifecycle Tools wie Together/XDE auch nur annähernd konkurrieren kann.
Ich schrieb auch explizit, dass es auch kommerzielle Plugins für Eclipse gibt.

http://www.borland.com/together/eclipse/index.html
http://www-306.ibm.com/software/awdtools/developer/java/
http://www.visual-paradigm.com/sdeec.php

Nur mal ne kleine Auswahl. Lustigerweise wird XDE sogar gleich mit Eclipse geliefert.

[grakaman]

Ich schrieb auch explizit, dass es auch kommerzielle Plugins für Eclipse gibt.

http://www.borland.com/together/eclipse/index.html
http://www-306.ibm.com/software/awdtools/developer/java/
http://www.visual-paradigm.com/sdeec.php

Nur mal ne kleine Auswahl. Lustigerweise wird XDE sogar gleich mit Eclipse geliefert.

Das schimpft sich aber dann IBM Websphere und hat auch noch ein wenig mehr als nur XDE. Togehter ist zwar etwas langsam, aber meiner Meinung nach richtig gut. Im Grunde habe ich nichts gegen Plugins, wenn sie die IDE wesentlich aufwerten, z.B. weil sie schon 1-2 Jahre alt ist. Nur muss man da wirklich stark drauf achten, ob die Jungs auch weiterexistieren, das Produkt weitersupportet wird, wie sich das Plugin in neueren IDE Versionen verhält etc. Oft geht man eben eine starke Bindung ein, die die interne Softwareentwicklung für die nächste Zeit bestimmt. Zumindest, wenn man dain viel investiert, wird man die Funktionalität wahrscheinlich weiterbenutzen und man ignoriert dann neuere Funktionen, die es vielleicht bei einem IDE Upgrade gibt. Vor dem Aspekt einer Neuanschaffung tendiere ich eher dahin, eine all-in one IDE zu kaufen.

[Xmas]

Das schimpft sich aber dann IBM Websphere und hat auch noch ein wenig mehr als nur XDE. Togehter ist zwar etwas langsam, aber meiner Meinung nach richtig gut. Im Grunde habe ich nichts gegen Plugins, wenn sie die IDE wesentlich aufwerten, z.B. weil sie schon 1-2 Jahre alt ist. Nur muss man da wirklich stark drauf achten, ob die Jungs auch weiterexistieren, das Produkt weitersupportet wird, wie sich das Plugin in neueren IDE Versionen verhält etc. Oft geht man eben eine starke Bindung ein, die die interne Softwareentwicklung für die nächste Zeit bestimmt. Zumindest, wenn man dain viel investiert, wird man die Funktionalität wahrscheinlich weiterbenutzen und man ignoriert dann neuere Funktionen, die es vielleicht bei einem IDE Upgrade gibt. Vor dem Aspekt einer Neuanschaffung tendiere ich eher dahin, eine all-in one IDE zu kaufen.
Also laut der Produktbeschreibung ist nur Eclipse mit dabei.
" Our solution allows users to work inside the included Eclipse IDE, or it can be installed into the IBM® WebSphere? Studio Application Developer and Integration Edition IDEs, and Microsoft® Visual Studio? .NET. "
Was das Verhalten in verschiedenen IDE-Versionen angeht, so kann man den Übergang zu Eclipse 3.0 wohl mit dem Übergang auf VS .NET vergleichen.

Ich finde eine Lösung aus einer Hand auch nicht schlecht, nur gibt es manchmal Dinge, die eine spezialisierte Gruppe besser macht als der IDE-Entwickler. Genau das was du weiter oben geschrieben hast, " Vielleicht will ich aber nicht Plugin B, sondern Plugin C von irgend jemand anderen, weil es einfach besser ist.", lässt sich auch auf Features von IDEs ummünzen.

[grakaman]

Also laut der Produktbeschreibung ist nur Eclipse mit dabei.
" Our solution allows users to work inside the included Eclipse IDE, or it can be installed into the IBM® WebSphere? Studio Application Developer and Integration Edition IDEs, and Microsoft® Visual Studio? .NET. "
Was das Verhalten in verschiedenen IDE-Versionen angeht, so kann man den Übergang zu Eclipse 3.0 wohl mit dem Übergang auf VS .NET vergleichen.


Achso meinst du das. Na dass sie Eclipse bundeln ist ja klar, weil es erstens von IBM ist und auch so kostenlos ist. Und Eclipse ist ja auch das Grundgerüst für Websphere. Zumindest war ich immer der Meinung, dass bei der Enterprise Version XDE dabei ist. Kann mich aber auch irren, habe nur mal die Trial kurz in VS.NET angetestet gehabt.