Ich bin mal gespannt ob & wann sun endlich jave unter eine open source lizens stellt. Laut SUN, soll dies ja geschehen! Evl. gibt dies dann ein weiteren positiven Schub nach vorn für java...
-
Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.
java noch angesagt?
- Ersteller brufis
- Erstellt am
Hi zusammen,
also irgendwie habe ich das Gefühl so manch einer hat hier relativ wenig Ahnung davon, was Java überhaupt ist - ich weiss, provokante Aussage aber wenn man sich die bisherigen Antworten mal so ansieht...
Java ist schonmal gar kein Ersatz für SQL. Das eine hat mit dem anderen recht wenig zu tun. SQL ist eine Datenbankabfragesprache, Java eine echte Programmiersprache.
Und dann zum immer wieder gerne angesprochenen Thema Java sei langsam: Diese pauschale Aussage ist schlicht und ergreifend falsch. Die ersten Java-Versionen waren nicht gerade der Knüller was Geschwindigkeit angeht, das ist ohne Frage richtig. Inzwischen jedoch besteht so gut wie kein Unterschied mehr zwischen nativ kompilierten Programme und Java-Anwendungen. Es gibt sogar Fälle wo Java durch den Hotspot JIT-Compiler schnelleren und performanteren Code erzeugt als das in C jemals möglich wäre. Wie das geht? Zur Laufzeit werden die Hauptperformance-Engpässe bestimmt und genau dafür wird dann der passende native Code compiliert und ausgeführt.
Sicherlich: Wenn's auf Geschwindkeit put ankommt, und ich number-crunching bist zum erbrechen durchführe dann ist logischweise C oder FORTRAN die Programmiersprache die man wählen sollte - aber in eigentlich allen anderen Anwendungsbereichen hat man mit Java da keinerlei Probleme mehr. Selbst für's Gamen gibt's inzwischen brauchbare Tools.
Ciao
Chris
P.S. Es heisst Java und nicht JAVA genauso wie es Delphi und nicht DELPHI heisst
also irgendwie habe ich das Gefühl so manch einer hat hier relativ wenig Ahnung davon, was Java überhaupt ist - ich weiss, provokante Aussage aber wenn man sich die bisherigen Antworten mal so ansieht...
Java ist schonmal gar kein Ersatz für SQL. Das eine hat mit dem anderen recht wenig zu tun. SQL ist eine Datenbankabfragesprache, Java eine echte Programmiersprache.
Und dann zum immer wieder gerne angesprochenen Thema Java sei langsam: Diese pauschale Aussage ist schlicht und ergreifend falsch. Die ersten Java-Versionen waren nicht gerade der Knüller was Geschwindigkeit angeht, das ist ohne Frage richtig. Inzwischen jedoch besteht so gut wie kein Unterschied mehr zwischen nativ kompilierten Programme und Java-Anwendungen. Es gibt sogar Fälle wo Java durch den Hotspot JIT-Compiler schnelleren und performanteren Code erzeugt als das in C jemals möglich wäre. Wie das geht? Zur Laufzeit werden die Hauptperformance-Engpässe bestimmt und genau dafür wird dann der passende native Code compiliert und ausgeführt.
Sicherlich: Wenn's auf Geschwindkeit put ankommt, und ich number-crunching bist zum erbrechen durchführe dann ist logischweise C oder FORTRAN die Programmiersprache die man wählen sollte - aber in eigentlich allen anderen Anwendungsbereichen hat man mit Java da keinerlei Probleme mehr. Selbst für's Gamen gibt's inzwischen brauchbare Tools.
Das hat doch mit Objektzuständen nichts zu tun. Beim Testing kannst du niemals 100% Zweigabdeckung erreichen, was aber überhaupt nicht am Unterschied objektorientiert/imperativ liegt sondern viel mehr an der Art und Weise _wie_ man diese Paradigmen umsetzt und wie man sein Programm gestaltet. Schonmal mit JUnit gearbeitet? Dann wirst du schnell merken, dass Testen auch (oder gerade) in Java schnell, einfach und ohne Probleme machbar ist.Peedee schrieb:
Ciao
Chris
P.S. Es heisst Java und nicht JAVA genauso wie es Delphi und nicht DELPHI heisst
Du hast alles begründet, warum nicht diese These?perdian schrieb:P.S. Es heisst Java und nicht JAVA genauso wie es Delphi und nicht DELPHI heisst
Und was JUnit angeht: Wenn man sowieso durch Tests nicht gewährleisten kann das etwas sauber läuft macht es IMHO auch keinen Sinn mit JUnit Entwicklungszeit zu verplempern.
Mit solchen Testverfahren macht man sich eigentlich nur selber etwas vor. Denn wer gewährleistet mir die Richtigkeit der Tests???? Die sind genauso fehleranfällig wie das was getestet werden soll.
*g* Kein Problem. BASIC beispielsweise ist ein Akronym und steht für "Beginner's All Purpose Symbolic Instruction Code". Java hingegen ist kein Akronym sondern einfach der Name einer Insel, die nach dieser Sprache benannt wurde (ehmmm... oder war das doch andersrum? *g*) und deshalb wird der Name der Sprache auch genauso "normal" geschrieben wie die besagte Insel.Killerfritte schrieb:Du hast alles begründet, warum nicht diese These?perdian schrieb:P.S. Es heisst Java und nicht JAVA genauso wie es Delphi und nicht DELPHI heisst
Oh nein, das kann man so auch nicht sagen. Du kannst mit Testing nie wirklich 100%ig sicher sein, dass dein Programm _überall_ und _immer_ korrekt läuft, aber du kannst zumindestens durch gutes Testing die Anzahl der Fälle in denen es sauber läuft _deutlich_ erhöhen! Nur zu sagen "Ich werde eh nie wirklich Sicherheit erlangen, also lassen wir es ganz" läuft genauso am Problem vorbei.Killerfritte schrieb:
Nein das stimmt auch nicht. Ein guter Test zeichnet zeichnet sich dadurch aus, dass du damit eine große Bandbreite an möglichen Anwendungsfällen "erschlägst". Und deshalb muss auch _vorher_ klar sein, was durch den Test erreicht werden soll, bzw. was verhindert werden soll.Killerfritte schrieb:
Wenn ich einen Testfall habe, der beispielsweise eine Bestellaufnahme kontrolliert, so kann ich genau wie einem chemischen Experiment hingehen und erstmal auflisten, was ich eigentlich habe: Bestelldaten (2x Artikel 1, 1x Artikel 2, usw.) und meine Kundendaten. Genauso weiss ich was rauskommen soll, nämlich eine Rechnung über X EUR, ausgestellt auf Kunde XYZ. Das sind 100% verifizierbare Ergebnisse. Jetzt lasse ich mein Programm laufen, und vergleiche hinterher den Output.
Sicherlich kann es vorkommen, dass auch hier ein Fehler im Test selber steckt - man steckt halt nicht in allem drin
Aber wenn ein Programm vor einem guten Testing in 40 von 100 Fällen richtig läuft, und nach dem Testing in 99 von 100 Fällen, dann hat sich Testing aber deutlich gelohnt.Ciao
Chris
dijee!!
bin zwar kein profi in programmieren...
aber was pedian gesagt hat, da muss ich ihm voll recht geben! testen sollte von vornherein miteingeplant werden und auch durchgeführt werden!!!
was ich so die erfahrung gemacht habe stehn noch viele firmen auf C/C++,
in der firma, wo ich derzeit praxis mache ist vor allem Delphi vorn dabei! so ziemlich das einzige!
(bis auf VBA, wo ich arbeiten durfte)
und ein programm gibts dann noch in C...
aber ka wo Delphi noch eingesetzt wird, bei hardwarenahen sachen sollts halt super sein...und wenn man sich länger damit beschäftigt ist Delphi schon sehr gut...sehr schnell...und bietet auch arrays von buttons, imgs usw...
nja, musste halt auch meinen senf dazugeben!
bin zwar kein profi in programmieren...
aber was pedian gesagt hat, da muss ich ihm voll recht geben! testen sollte von vornherein miteingeplant werden und auch durchgeführt werden!!!
was ich so die erfahrung gemacht habe stehn noch viele firmen auf C/C++,
in der firma, wo ich derzeit praxis mache ist vor allem Delphi vorn dabei! so ziemlich das einzige!
(bis auf VBA, wo ich arbeiten durfte)
und ein programm gibts dann noch in C...
aber ka wo Delphi noch eingesetzt wird, bei hardwarenahen sachen sollts halt super sein...und wenn man sich länger damit beschäftigt ist Delphi schon sehr gut...sehr schnell...und bietet auch arrays von buttons, imgs usw...
nja, musste halt auch meinen senf dazugeben!
Also wenn man sich (die zugegebenermaßen nicht ganz realistischen) Stellenanzeigen anschaut, dann ist JAVA schon mit aufgeführt.
Beruflich scheint es sich in die anderen Programmiersprachen "einzugliedern".
Eigentlich schade, weil JAVA "ungefähr" was ich mir vor Jahren als
"entschärftes" C++ vorgestellt hatte.
JAVA kann man übrigens schneller machen, wenn übers Java Native Interface (JNI) hardware-abhängige Module einbindet.
Mit den entsprechenden Nachteilen (nicht ganz portabel) natürlich.
Beruflich scheint es sich in die anderen Programmiersprachen "einzugliedern".
Eigentlich schade, weil JAVA "ungefähr" was ich mir vor Jahren als
"entschärftes" C++ vorgestellt hatte.
JAVA kann man übrigens schneller machen, wenn übers Java Native Interface (JNI) hardware-abhängige Module einbindet.
Mit den entsprechenden Nachteilen (nicht ganz portabel) natürlich.
Ist so pauschal nicht richtig.mampfi schrieb:
Es gibt Situationen, in denen es Sinn machen kann JNI zu verwenden, um einen Performance-Gewinn zu erreichen. Das ist allerdings die Ausnahme. Zu Java 1.0/1.1 Zeiten konntest du über JNI noch massiv Performance gewinnen aber inzwischen hat sich die JVM Technologie deutlich weiterentwickelt. Hotspot leistet da meistens deutlich mehr als eine JNI optimierte Lösung, und in manchen Bereichen ist dadurch Java während der Ausführung von JIT compiliertem Code sogar schneller als ein vergleichbares C-Programm[1][2].
Das Drucken ist in der Tat etwas... gewöhnungsbedürftig. Aber was ist am Filehandling schlecht?mampfi schrieb:
Christian
[1] http://www.osnews.com/story.php?news_id=7372
[2] http://www.sys-con.com/story/?storyid=45250
Zugeben die IOStreams sind konsequent objektorientiert (sorry liebe Smalltalker).
Mir persönlichs wärs lieber wenns einen umfassenderen Daten Typ "File" gäbe.
Da kann man beispielsweise ne Zeile lesen und danach ein Zeichen.
Aber das ist Geschmackssache.
Visual Basic find ich gar nicht so schlecht.
War echt Wahnsinn, wie komplex das Schreiben von Windows-Programmen anfangs war, dann kam die "Stütze" VB und siehe da, die Shareware-Programme sprudelten aus dem Boden.
Aus der Diskussion über die großen Brocken J2ee usw. halt ich mich mangels Erfahrung lieber raus.
Mir persönlichs wärs lieber wenns einen umfassenderen Daten Typ "File" gäbe.
Da kann man beispielsweise ne Zeile lesen und danach ein Zeichen.
Aber das ist Geschmackssache.
Visual Basic find ich gar nicht so schlecht.
War echt Wahnsinn, wie komplex das Schreiben von Windows-Programmen anfangs war, dann kam die "Stütze" VB und siehe da, die Shareware-Programme sprudelten aus dem Boden.
Aus der Diskussion über die großen Brocken J2ee usw. halt ich mich mangels Erfahrung lieber raus.
deac schrieb:
Es ist immer schade wenn sich Menschen Meinungen über etwas bilden, das sie garnicht wirklich kennen.
Fakten:
1)Delphi ist in einigen Teilen der Welt sehr verbreitet. Dazu zählen die USA, aber auch die Ostblockstaaten.
2) Viele Firmeninterne Programme sind mit Delphi geschrieben. Diese gelangen natürlich nie nach außen, daher fallen sie nicht auf
3) Der "Macher" von Delphi, Anders_Hejlsberg, ist auch einer der wichtigsten Köpfe bei MS bezüglich Software Entwicklungstools.
http://de.wikipedia.org/wiki/Anders_Hejlsberg
4) Delphi ist kein Klicki-Bunti Tool, Borland hat es aber verstanden dem extrem schnellen und effizienten Object Pascal Compiler aus eigenem Haus eine sehr gute und beispielhafte (vergleich mal die VCL und QT, seltsame paralellen wie ,) ) Objectbiliothek mit samt einem ausgezeichneten grafischen RAD/Two-Way Editor bezulegen.
5) Man beurteilt nichts das man nur 5 Minuten gesehen hat. Lerne lieber von den Borland Entwicklern wie man sauberen Quellcode schreibt, lerne die VCL/CLX auswendig
Es gibt sogar zwei *g*mampfi schrieb:
java.io.File und java.io.RandomAccessFile
Kannst du doch: Im RandomAccessFile kannst du readLine() und readChar() aufrufen - ist doch genau das, was du haben willst oder?mampfi schrieb:
Klar, die Frage ist bis zu welcher Komplexität du sowas treiben willst. Jede Sprache hat sicherlich Ihre Daseinsberechtigung (okay, C nicht aber das ist was anderes *g*) und für eine kleine Windows-Spielerei meinetwegen auch VB. Aber ein Warenwirtschaftssystem mit diversen Clients in VB programmieren? Ne ne.mampfi schrieb:
Genau dasgleiche mit Delphi: Wenn es um User-Interfaces im Desktop-Bereich geht ist die Sprache sicherlich vollkommen geeigent für den Job.
Chris
vb und delphi sind für mich sprachen, bei denen man bei einem etwas größeren projekt zwar recht schnelld die ersten, sagen wir mal 85% schafft, bei den restlichen 15% jedoch kläglich scheitert!
da hast du ja genau die richtigen länder angesprochen! mit der hohen schulbildung! man mag es zwar nicht glauben, aber die ammis sind noch dümmer (auch/vorallem die programmierer). ich kann davon aus erster hand berichten! ich bin zur zeit auf "entwicklungshilfe" in den usa!
VIELE is vielleicht ein wenig übertrieben, kann aber schon sein.... fakt is jedoch, das es jeden egal ist, wenn so ein teil mal stehen bleibt, oder irgendetwas halt nicht GANZ so geht, wie es geplant war!
sollte das jetzt für oder gegen delphi sprechen?
kann sein... ich habs mir nur bis zur version 6 (glaub i) angetan
es war dann doch eher ein jahr, oder so...
ich muss jedoch sagen, dass es mir damals schon spaß gemacht hat... da habe ich auch nicht viel anderes gekannt (außer assembler, pascal und c)
dann habe ich jedoch mit vc++ begonnen und später eben java...
ich kann nur sagen, ich will NIE wieder zurück *g*
da hast du ja genau die richtigen länder angesprochen! mit der hohen schulbildung! man mag es zwar nicht glauben, aber die ammis sind noch dümmer (auch/vorallem die programmierer). ich kann davon aus erster hand berichten! ich bin zur zeit auf "entwicklungshilfe" in den usa!
VIELE is vielleicht ein wenig übertrieben, kann aber schon sein.... fakt is jedoch, das es jeden egal ist, wenn so ein teil mal stehen bleibt, oder irgendetwas halt nicht GANZ so geht, wie es geplant war!
sollte das jetzt für oder gegen delphi sprechen?
kann sein... ich habs mir nur bis zur version 6 (glaub i) angetan
es war dann doch eher ein jahr, oder so...
ich muss jedoch sagen, dass es mir damals schon spaß gemacht hat... da habe ich auch nicht viel anderes gekannt (außer assembler, pascal und c)
dann habe ich jedoch mit vc++ begonnen und später eben java...
ich kann nur sagen, ich will NIE wieder zurück *g*
deac schrieb:
Hier würde ich Jein sagen
Grundsätzlich kann man mit allen Sprachen scheitern. Ich habe aber gerade größere Projekte in Delphi scheitern sehen, aber auch in anderen Sprachen.
Meiner Meinung nach hilft Delphi auch unerfahrenen Programmieren dort, wo sie mit anderen Sprachen scheitern würden, ein gewisser Filter für schlechte Programmierer fällt also weg.
Aber für erfahrene Programmierer gilt das nicht, für diese sind die Funktionen vor allem Erleichterungen.
Nur sollte man sich für Delphi VIEL Zeit nehmen, da die vielen Komponenten die mitgeliefert werden (je nach Version) wirklich kaum fix zu verstehen sind.