Java programmieren [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : Java programmieren

M@tes

2005-08-19, 11:33:29

Joa, wir fangen bald in der Schule mit Java / UML / Datenbanken an und ich wollte mich soweit übers Wochenende vorbereiten.
Hab mir dazu Eclipse runtergeladen, mit dem wir später auch arbeiten werden.
Nun brauch ich ja noch nen Javainterpreter oder sowas? :|
Was muss ich dafür installieren, um die Scripte auch testen zu können?
J2SE 5.0 oder wie? :confused:

Gibts für Java auch so Seiten wie SelfHTML?

Klar ich könnt bis next Week warten, aber irgendwie wurmt es mich, da mal einwenig reinzuschaun :smile:

ravage

2005-08-19, 11:45:50

Eine ganz nette online Hilfe ist das eBook Java ist auch eine Insel (http://www.java-tutor.com/javabuch/index.htm)

Da steht auch drin, was du installieren musst, und wie du was einrichten musst, um Java Programme kompilieren und starten zu können.

Pinoccio

2005-08-19, 11:53:09

Wenn du schon eine andere Programmiersprache beherrschst wird JAVA möglicherweise einiges Umdenken erfordern, aber ich persönlich halte JAVA für eine der besten Programmiersprachen zur Zeit.
Ein bißchen in den JAVA-bezogenen Threads hier zu blättern kann dir da sicher einen kleinen Vorgeschmack geben.
In meinen Augen ist, Englischkenntnisse vorrausgesetzt, auf jeden Fall die offizielle API-Dokumantation (http://java.sun.com/j2se/1.5.0/docs/api/index.html?overview-summary.html) eine großartige Hilfe.

In Rahmen welcher Schulischen Ausbildung läuft? Normal 9te Klasse Informatik? oder eher Berufschule Fachinformatiker?

mfg Sebastian

M@tes

2005-08-19, 12:09:46

Jo habe bisher Perl programmiert (ähnlich wie C).
Mal schaun, ob es von Vor oder Nachteil ist.

Nene, Gymnasium und Berufsschule hab ich fertig.
In der Schweiz heisst es BMS.
In Deutschland wäre das eine Art Kombination zwischen ABI und Erweiterte Berufsschule.
Deutsch, Mathe, Englisch, Geschichte, Rechtslage werden da stark vertieft.
Als Wahlschwerpunkt hab ich halt Informatik gewählt.
Hätte es neben der Berufsschule machen können, aber dafür bräuchte ich in der Schweiz Französischkenntnisse. Das war bei mir nicht der Fall.

Java ist auch eine Insel hab ich mir gezogen und werds mal überfliegen :)

Hmm, hab da jetzt jdk-1_5_0_04-windows-i586-p.exe runtergeladen.
Ist das richtig? :|

ravage

2005-08-19, 12:15:04

Jo habe bisher Perl programmiert (ähnlich wie C).
[...]
Hmm, hab da jetzt jdk-1_5_0_04-windows-i586-p.exe runtergeladen.
Ist das richtig? :|
Jap, passt.

Gast

2005-08-19, 12:19:04

Hmm, hab da jetzt jdk-1_5_0_04-windows-i586-p.exe runtergeladen.
Ist das richtig? :|

wenn du windows benutzt, ja

sonst kann ich noch die jdk-docs empfehlen, auch recht praktisch

Shink

2005-08-19, 13:46:09

Auch nicht schlecht: Handbuch der Java-Programmierung
http://www.javabuch.de/download.html

Die API-Doku ist wohl erst dann sinnvoll, wenn man sich in der Sprache auskennt.
PS: Java ist KEINE Scriptsprache. Du compilierst den Quellcode (nicht für deine Rechenarchitektur, aber trotzdem). JavaScript ist was anderes; dass ihr damit Datenbankprogrammierung macht ist aber mehr als unwahrscheinlich.

M@tes

2005-08-19, 13:53:36

Es war auch nicht die Rede von Javascript :smile:
Mit JavaScript kenn ich mich einwenig aus. Ist halt eher an Webprogrammierung gebunden.
Aber Java? Null, nada, nix^^

Zu Hause benutze ich Windows - noch. Ja.
In der Schule läuft das ganze glaub über Linux.
Ist es das gleiche Java, wie auf den neueren Handys?
Sry, hab noch son altes Nokia 7710 oder so.

Shink

2005-08-22, 15:21:57

Nun brauch ich ja noch nen Javainterpreter oder sowas? :|
Was muss ich dafür installieren, um die Scripte auch testen zu können?

Darüber hab ich mich aufgeregt...

Genau das gleiche Java wie das auf Handys ist es natürlich nicht; auf Handys machen manche Sachen eben weniger Sinn. D.h. die Sprache ist die gleiche, aber die Bibliotheken sehen teilweise anders aus. Aber wenn du Zeug für Handys schreiben kannst, beherrscht du definitiv Java (und umgekehrt)

Coda

2005-08-22, 15:25:01

Wenn du schon eine andere Programmiersprache beherrschst wird JAVA möglicherweise einiges Umdenken erfordern,...Kann ich nicht nachvollziehen. Java ist von den Features eigentlich nur abgespecktes C++.

Pinoccio

2005-08-22, 15:27:17

Kann ich nicht nachvollziehen. Java ist von den Features eigentlich nur abgespecktes C++.Jein, der Umstieg von C++ oder C# ist sicherlich kein großes Problem.
Aber ich bin von mir selbst ausgegangen, habe mit BASIC auf dem C64 angefangen und in der Schule zwangsweise Turbo Pascal gelernt, da ist JAVA dann schon ein größerer Umstieg.

mfg Sebastian

patermatrix

2005-08-22, 16:41:01

Was weniger an der Sprache, sondern eher an OOP liegen düfte... :confused:

Pinoccio

2005-08-22, 17:14:04

Was weniger an der Sprache, sondern eher an OOP liegen düfte... :confused:Jein.
Wenn ich mir überlege, was BASIC (wenn ich mich recht erinnere) alles nicht hatte bzw anders gemacht hat: Variablentypen, goto/gosub/return oder auch der direkte Hardware-Zugriff.

mfg Sebastian

M@tes

2005-08-24, 23:37:31

So nun,...
Wir werden mit Hamster anfangen^^
Hab mir das Ding jetzt mal aufn PC kopiert.
Aber es braucht ja ewig zu laden. Is das normal?
Die Fenster hab ich recht schnell. Aber bis mal die Icons, buttons etc pp zu sehen sind. dauert ewig lang :frown:

Abnaxos

2005-08-25, 02:46:02

Kann ich nicht nachvollziehen. Java ist von den Features eigentlich nur abgespecktes C++.

Womit wir genau den Grund hätten, warum immer wieder behauptet wird, Java sei langsam: Wenn man Java wie ein "abgespecktes C++" programmiert, passiert nämlich genau das: Das Programm wird langsam. Nein, Java mag in der Syntax extrem ähnlich sein, aber ein "abgespecktes C++" ist es definitiv nicht. Es ist etwas anderes, etwas eigenes, wenn auch die Syntax stark an C++ erinnert.

CannedCaptain

2005-08-25, 11:44:11

Ich empfele dir eclipse 3.1 (java 1.5 support) als ide. Ist zwar nicht das performanteste (da in java geschrieben), aber vom debugger und code completion zu empfehlen, dazu auch noch kostenlos.

Trap

2005-08-25, 12:01:30

Womit wir genau den Grund hätten, warum immer wieder behauptet wird, Java sei langsam: Wenn man Java wie ein "abgespecktes C++" programmiert, passiert nämlich genau das: Das Programm wird langsam. Nein, Java mag in der Syntax extrem ähnlich sein, aber ein "abgespecktes C++" ist es definitiv nicht. Es ist etwas anderes, etwas eigenes, wenn auch die Syntax stark an C++ erinnert.
Haha, wie soll man denn sonst programmieren? Was ist ein Java-Idiom, das in C++ nicht benutzt wird? Zumindest eins sollte man nennen können, wenn man Java als eigenständige Sprache sehen möchte.

Für mich ist das ne billige Ausrede, wer die Syntax von C++ absichtlich kopiert darf sich nicht beschweren, dass man auch ähnliche Performance bei ähnlichem Code erwartet.

BTW: Die JRE ist garnicht so lahm, meist ist der Programmierer ist schuld oder der hohe Speicherverbrauch der Swappen erzeugt

Pinoccio

2005-08-25, 12:23:04

Haha, wie soll man denn sonst programmieren? Was ist ein Java-Idiom, das in C++ nicht benutzt wird? Zumindest eins sollte man nennen können, wenn man Java als eigenständige Sprache sehen möchte.Ich denke, JAVA wird durch viel Aspekte eine eigene Sprache: Bytecode, keine Zeiger, keine Mehrfachvererbung, was sind Strings, kein goto und festgelegte Parameterlisten bei Funktionen.

mfg Sebastian

Gast

2005-08-25, 13:01:36

Trap

2005-08-25, 13:44:48

Imo zeichnet sich Java u.a. dadurch aus, dass es guten Stil erzwingt.

Es gibt keine Abwärtskompatibilität mehr zu prozeduralem Stil, der Namensraum ist immer eindeutig, Vererbung funktioniert so wie sie soll, inzwischen beinahe typsicher...
Wie sieht es denn bei C++ mit Reflections aus?
C++ bietet keine Introspection oder Reflections als Sprachfeatures, wenn man es braucht muss man es selbst implementieren. Mehr gibt es nicht was aus Java mehr als ein eingeschränktes C++ macht?

Vererbung und OOP ist in Java anders kaputt als in C++. Besser würde ich es nicht nennen.

Guten Stil kann man nicht erzwingen:
public class Cprog{
//insert c program here
//achso, man muss noch vor jede Funktion "public static" schreiben
}

Monger

2005-08-25, 18:32:34

Mehr gibt es nicht was aus Java mehr als ein eingeschränktes C++ macht?

Mal andersrum gefragt: Was hat denn C++ was Java nicht hat?

HellHorse

2005-08-25, 18:45:35

Mal andersrum gefragt: Was hat denn C++ was Java nicht hat?
Einen ganzen, verdammt grossen Haufen.
Vier verschiedene casts um mal einen Anfang zu machen.

Trap

2005-08-25, 19:14:59

Mal andersrum gefragt: Was hat denn C++ was Java nicht hat?
Eine turing-vollständige funktionale Subsprache zur Codegeneration zur Kompilierzeit.

clm[k1]

2005-08-25, 19:44:50

Mal andersrum gefragt: Was hat denn C++ was Java nicht hat?

Die Frage sollte wenn dann lauten: Welche Vorteile hat denn C++ gegenüber Java?

..und da möchte ich mehr hören, als das ewige "es ist schneller" (was nämlich so generell nicht stimmt)

clm[k1]

Monger

2005-08-25, 19:49:21

Einen ganzen, verdammt grossen Haufen.
Vier verschiedene casts um mal einen Anfang zu machen.

Ist das nicht eher eine Schwäche denn eine Stärke? Casts verwässern die Typensicherheit.

Eine turing-vollständige funktionale Subsprache zur Codegeneration zur Kompilierzeit.
Was genau meinst du?

Auf Java basierende Sprachen gibt es afaik inzwischen auch wie Sand am Meer. Hab keine davon benutzt, aber die Leute die "Facade" gemacht haben, haben auf dem Weg dorthin eine ganz Hand voll Subsprachen selber entwickeln müssen - einige davon in Java.

Trap

2005-08-25, 20:09:41

Auf Java basierende Sprachen gibt es afaik inzwischen auch wie Sand am Meer. Hab keine davon benutzt, aber die Leute die "Facade" gemacht haben, haben auf dem Weg dorthin eine ganz Hand voll Subsprachen selber entwickeln müssen - einige davon in Java.
Man muss Java und die JRE unterscheiden. Die Sprachen basieren nicht auf Java, sondern auf der JRE. Genauso wie die .NET Sprachen auf .NET basieren und nicht auf C#.

Nicht typsicher zu sein kann Bug oder Feature sein, hängt von der Anwendung ab.

Ich meinte templates mit meiner blumigen Beschreibung. Man kann ein C++ Programm schreiben, dass den Compiler zum Lösen von z.B. der Türme von Hanoi benutzt und dann zur Laufzeit nurnoch die Ausgabe macht.
Allerdings sind C++ templates unglaublich hässlich wenn man sie dazu benutzt.

Pinoccio

2005-08-25, 20:51:55

Ich meinte templates mit meiner blumigen Beschreibung. Man kann ein C++ Programm schreiben, dass den Compiler zum Lösen von z.B. der Türme von Hanoi benutzt und dann zur Laufzeit nurnoch die Ausgabe macht.
Allerdings sind C++ templates unglaublich hässlich wenn man sie dazu benutzt.OT: Gab es beim c't-puzzle (http://www.heise.de/ct/puzzle/) nicht auch eine Lösung, die so funktionierte? (Der Artikel ist leider nur gegen 50 Cent erhältlich im Web, war in der 14/03 drin.)

mfg Sebastian

HellHorse

2005-08-25, 22:15:20

Ist das nicht eher eine Schwäche denn eine Stärke?
Das überlasse ich jedem selbst zu entschieden. ;) Der springende Punkt ist aber, das war nicht die Frage.

Java hat aber in der hat etwas, das C++ fehlt, und einer der am meisten unterschätzten Vorteile ggü C/C++ ist: array-range-check. Das beseitig auf einen Schlag 50% aller Sicherheitslücken und kostet nur 2% Performance. Ich glaube, ich melde mich zum Spass mal bei Heise an und trolle bei jedem Bericht über buffer overflows `das wäre mit Java nicht passiert'.

Nun sagt ihr sicher kann man alles in C++ auch machen und man kann ein String auch als Objekt kapseln. Selbstverständlich kann man, bloss macht es so gut wie niemand, und viel wichtiger: es wird nicht gelehrt.

Shink

2005-08-26, 15:52:14

Hucke

2005-08-26, 16:16:34

C++ vs Java, das wird noch ein schöner Flamewar-Thread...
Was allerdings keiner bestreiten kann:

- Das Java-Framework ist nicht wirklich vergleichbar zur C++ - Standard Library. Somit ist Programmieren in Java anders als Programmieren in C++. Zu OOP wird man bei Java z.B. schon durch die Verwendung des Frameworks gezwungen, bei C++ kann man sich fast immer drum drücken.
- Da man mit dem Framework von Java mit seinen Standarderweiterungen sehr viel ganz einfach erledigen kann, werden Java-Anwendungen oft langsam; sei es weil man bestimmte Dinge eben zu einfach macht (z.B. Programmlogik bei EventHandling im Darstellungsthread) oder weil das Framework eben nicht für alle Zwecke optimal ist (z.B. Java 2D/3D, JDBC).
- C++ hat keinen GC (hmm... hat das hier tatsächlich noch niemand gesagt?) und es werden weniger Fehler erkannt (z.B. eben Array-range-check).

Die JDBC Problematik würd mich mal interessieren, da ich beruflich sehr viel mit dem Kram zu tun hab. Bis jetzt war ich von den Möglichkeiten und der Performance immer positiv überrascht.

Aber mit dem Punkt, daß Java oft durch Bequemlichkeit der Anwender langsam wird, damit hast Du recht. Java kann schnell sein, wenn man sich richtig anstellt (natürlich abhängig von der VM).

Shink

2005-08-26, 16:41:39

Hucke

2005-08-26, 18:28:06

JDBC unterstützt z.B. nur dynamisches, kein statisches SQL. (siehe z.B.: http://www.ssw.uni-linz.ac.at/Research/Projects/ODBC/DiplomaThesis.Mech/node17.html)
Klar; statisches SQL widerspricht natürlich der Java-Philosophie, aber wenn mans braucht, ist man auf eine externe Library (SQLJ ist dafür wohl "Pseudo-Standard") angewiesen.

Zum anderen kann man als Programmierer beim Pooling viel falsch machen, weil einem der Zugriff auf eine Datenbank so schön einfach vorkommt (was natürlich nicht die Schuld von JDBC ist):
So könnte man drauf pfeifen, sodass man z.B. bei einer dynamisch erzeugten Seite bei jedem Seitenaufruf das Servlet eine Connection und ein Statement neu erzeugen lässt. Blöd, wenn das Servlet dann mehrere tausend mal pro Sekunde aufgerufen wird und wirklich jedes mal neue Verbindungen erzeugt werden.
Oder man lässt alle Verbindungen offen oder vergisst, dass es je nach Datenbank vorkommt, dass sie öfters mal "kaputt gehen".

Fürs statische SQL wüsste ich jetzt keinen Einsatzzweck, aber wir haben auch meist dynamische Anfragen mit wechselnden Parametern. Mal meinen Chef fragen ob der ein tolles Beispiel dafür kennt. Der Kerl hat SQL einfach drauf.

Aber die Geschichte mit tausenden Aufrufen und so, kommt vor, macht man aber nur einmal. Vorausgesetzt man hat Ahnung von Datenbanken, SQL und Java.

Und die Sache mit den Verbindungen ist teilweise wirklich doof. Aber auch das lernt man schnell. Immer schön Connections und Statements schließen. Bloß weil ein Statement eigentlich kein Connection Objekt mehr hat wirds noch lange nicht vom Garbage Collector entsorgt.

Coda

2005-08-26, 18:41:51

Das überlasse ich jedem selbst zu entschieden. ;) Der springende Punkt ist aber, das war nicht die Frage.

Java hat aber in der hat etwas, das C++ fehlt, und einer der am meisten unterschätzten Vorteile ggü C/C++ ist: array-range-check. Das beseitig auf einen Schlag 50% aller Sicherheitslücken und kostet nur 2% Performance. Ich glaube, ich melde mich zum Spass mal bei Heise an und trolle bei jedem Bericht über buffer overflows `das wäre mit Java nicht passiert'..MSVC++ ab 7.1 kann Code generieren der das auch erkennt.

Ansonsten: valgrind :D

Trap

2005-08-26, 20:23:44

- C++ hat keinen GC (hmm... hat das hier tatsächlich noch niemand gesagt?) und es werden weniger Fehler erkannt (z.B. eben Array-range-check).
Wenn man den Boehm GC dazulinkt schon.

HellHorse

2005-08-26, 21:29:52

JDBC
JDBC unterstütz stored procedures, prepared statements (vorkompiliert) und solche Geschichten. Ich gehe mal davon aus, dass das mit statischem SQL gemeint ist.

Edit: was hat JDBC mit Sprache Java als Sprache zu tun?
JDBC 1 bis 3 sollten sich eigentlich 1:1 in C++ implementieren lassen und für JDBC 4, naja ich habe noch keinen Treiber gesehen, der das kann.

Edit2: die C++ library definitiert doch gar kein Interface für SQL Datenbanken, oder irre ich mich da?

Köppchen

2005-08-26, 22:25:42

Wieso gibt ein kein statisches SQL? Was ist mit SQLJ?
Zumindestens zusammen mit DB2 habe ich das schon benutzt und damit ist statisches SQL möglich.
Statisches SQL hat gegenüber dynamischem SQL den Vorteil das Zugriffswege auf die Datenbank frühzeitig (beim Bind) bestimmt werden können.
Ausserdem kann man die Berechtigungen für's sql dann auf das gebundene Paket vergeben und muss nicht die Berechtigungen für den Anwender vergeben der die Datenbankverbindung herstellt.
Für die Produktionssteuerung in größeren Konzernen bietet statisches SQL so einige Vorteile.
Nachteil bei statischem SQL ist die Entwicklungseffizienz. Man braucht immer zusätzlich Precompiler und Bind und erhöht die komplexität für Entwickler. Das verschlechtert z.B. die Turnarundzeiten beim Debuggen.

Bzgl. der Datenbankverbindungen: Applicationserver bieten in der Regel Datasources die man sich über JNDI lookup's abholt. Das sorgt automatisch für Connection Pooling und man hat auch keine environmentspezifischen Parameter im Programmcode (oder in propertyfiles).
Ich kenne das aus der Praxis zwar nur aus Websphere, aber soweit ich weiss gibts auch in Tomcat Datasources.

Gruß Markus

HajottV

2005-08-27, 09:50:14

Hallo,

Java ist viel schöner zu programmieren als C++. Wenn man die Zeiten vergleicht, die man braucht, um in Java bzw. C++ eine (nicht-triviale) Anwendung zu erstellen, dann geht das in Java deutlich schneller.

Allerdings ist Java ineffizienter, daran ändern auch die JIT-Compiler nichts, denn diese erzeugen KEINEN vernünftigen Assemblercode. Ich habe es mal "geschafft", daß die JVM im JIT-Code abgeschmiert ist (konnte ich leider nie wieder reproduzieren, passierte durch einen Stacküberlauf)... so daß ich mir den erzeugten Assemblercode angucken konnten. Da kann man (sorry) echt nur lachen: Der erzeugte Assemblercode erinnerte mich stark an das, was bei meinem Compiler rauskam, den ich im Alter von 15 geschrieben habe. Eine hochoptimierte Kompilation ist locker um den Faktor 2-3 schneller.

Mir sind auch die ganzen Tests aus der c't etc. bekannt, die behaupten, daß Java und C++ sich in Bezug auf Geschwindigkeit nicht viel nehmen. Allerdings sind diese Tests ziemlich unrealistisch, da sie kaum eine Realsituation wiederspiegeln. (Vertrau nie einer Statistik, die Du nicht selbst gefälscht hast.)

Man muß halt immer gucken, was das Einsatzgebiet für eine Sprache ist. Wer in Java number-crunching betreibt und sich wundert, warum es langsam ist... selbst schuld. Wer Textverarbeitung in C++ oder Java macht... auch selbst schuld, dafür gibt's Perl + Co. Wer eine plattformunabhängige Plugin Software schreiben möchte und dafür C++ benutzt, na viel Spaß... da wäre Java die bessere Wahl.

Es gibt nicht die beste Programmiersprache, die für jedes Anwendungsszenario optimal ist.

Gruß

Jörg

Senior Sanchez

2005-08-27, 10:34:23

Hallo,

Java ist viel schöner zu programmieren als C++. Wenn man die Zeiten vergleicht, die man braucht, um in Java bzw. C++ eine (nicht-triviale) Anwendung zu erstellen, dann geht das in Java deutlich schneller.

Das mag ich aber mal bezweifeln. Du beurteilst dass vllt aus deinem Kenntnisstand, aber aus meiner (noch geringen) TopCoder.com Erfahrung kann ich dir sagen, dass die C++ Leute sehr schnell sind. Die haben für jeden Krempel schon irgendwelche Funktionen in der STL und auch das arbeiten mit Regular Expressions scheint denen da ziemlich von der Hand zu gehen ;) Sprich, die Anwendungen sind zwar nicht sehr groß (aber auch nicht trivial), aber die kommen manchmal mit nem Bruchteil meines Java-Codes aus und brauchen somit natürlich weniger Zeit zum tippen.

Allerdings ist Java ineffizienter, daran ändern auch die JIT-Compiler nichts, denn diese erzeugen KEINEN vernünftigen Assemblercode. Ich habe es mal "geschafft", daß die JVM im JIT-Code abgeschmiert ist (konnte ich leider nie wieder reproduzieren, passierte durch einen Stacküberlauf)... so daß ich mir den erzeugten Assemblercode angucken konnten. Da kann man (sorry) echt nur lachen: Der erzeugte Assemblercode erinnerte mich stark an das, was bei meinem Compiler rauskam, den ich im Alter von 15 geschrieben habe. Eine hochoptimierte Kompilation ist locker um den Faktor 2-3 schneller.

Niemand fordert ja, dass Java Assemblercode erzeugen soll, sondern Bytecode! Das ist ein großer Unterschied! Der Bytecode ist das Kompilat für eine Art virtuelle CPU/Plattform, der u.a. von der VM entsprechend ausgeführt werden kann. (Gibt ja auch CPUs die Java nativ beherrschen) Und weil Java eben für alle möglichen CPUs als Laufzeitumgebung ausgelegt ist, muss der Bytecode den kleinsten gemeinsamen Nenner haben, sodass alle VMs auf diversen CPUs was damit anfangen können.
Ach die JVM abschmieren zu lassen, dass passiert manchmal. Nen Stacküberlauf denke ich eher weniger, sowas wird meistens vorher durch Exceptions abgefangen. Meist isses dann immer ne schöne Meldung wie "An error inside the VM occured". Und wenn de dir mal den Bytecode anschauen willst und was dazu gehört, dann schaue dir mal JAD (Java Decompiler an). Dieser dekompiliert *class Dateien und zeigt dir neben dem bekannten Source noch die Bytecode-Befehle an.

Mir sind auch die ganzen Tests aus der c't etc. bekannt, die behaupten, daß Java und C++ sich in Bezug auf Geschwindigkeit nicht viel nehmen. Allerdings sind diese Tests ziemlich unrealistisch, da sie kaum eine Realsituation wiederspiegeln. (Vertrau nie einer Statistik, die Du nicht selbst gefälscht hast.)

Man muß halt immer gucken, was das Einsatzgebiet für eine Sprache ist. Wer in Java number-crunching betreibt und sich wundert, warum es langsam ist... selbst schuld. Wer Textverarbeitung in C++ oder Java macht... auch selbst schuld, dafür gibt's Perl + Co. Wer eine plattformunabhängige Plugin Software schreiben möchte und dafür C++ benutzt, na viel Spaß... da wäre Java die bessere Wahl.

Es gibt nicht die beste Programmiersprache, die für jedes Anwendungsszenario optimal ist.

Naja, Java ist langsamer als C++, kann man nicht dran rütteln, obwohl Java in vielen Dingen doch schon aufgeholt hat. Aber mal ne Frage: Ist Performance in allen Belangen wirklich noch so wichtig?!? Und die endgültige Geschwindigkeit hängt auch sehr stark von den Fähigkeiten des Programmiers ab. Schön viel threaden, bei häufigem und vielen Dateioperationen die nio-Klassen nutzen etc. pp.
Java hat aber halt auch andere Vorteile, wie das Sandboxprinzip oder die doch recht hohe Stabilität und Sicherheit. Auch die Plattformunabhängigkeit ist ein Vorteil und ich finde für Einsteiger ist es ne schöne Sprache um OOP begreiflich zu machen.

EDIT:
Ich empfele dir eclipse 3.1 (java 1.5 support) als ide. Ist zwar nicht das performanteste (da in java geschrieben), aber vom debugger und code completion zu empfehlen, dazu auch noch kostenlos.

Das könnte jetzt implizieren, dass Java-IDEs langsam sind ;) Stimmt aber net so ganz, der JBuilder (zumindest pre-2005) ist, obwohl in Java geschrieben, sehr schnell wie ich finde.

HajottV

2005-08-27, 11:06:24

Das mag ich aber mal bezweifeln. Du beurteilst dass vllt aus deinem Kenntnisstand, aber aus meiner (noch geringen) TopCoder.com Erfahrung kann ich dir sagen, dass die C++ Leute sehr schnell sind. Die haben für jeden Krempel schon irgendwelche Funktionen in der STL und auch das arbeiten mit Regular Expressions scheint denen da ziemlich von der Hand zu gehen ;) Sprich, die Anwendungen sind zwar nicht sehr groß (aber auch nicht trivial), aber die kommen manchmal mit nem Bruchteil meines Java-Codes aus und brauchen somit natürlich weniger Zeit zum tippen.

Dass ein unerfahrenen Java-Programmierer langsamer ist als ein erfahrener C++ Programmierer, glaube ich Dir sofort. Gerade, wenn man die RegEx-Sachen nicht beherrscht, ist man hoffnungslos im Nachteil bei vielen Aufgaben. Damit lassen sich viele Dinge als Einzeler erledigen, für die man sonst seitenweise Code bräuchte. Meine Behauptung ist, daß bei gleichem Kenntnisstand ein Java-Programmierer in der Regel schneller zum Ziel kommt.

Niemand fordert ja, dass Java Assemblercode erzeugen soll, sondern Bytecode! Das ist ein großer Unterschied! Der Bytecode ist das Kompilat für eine Art virtuelle CPU/Plattform, der u.a. von der VM entsprechend ausgeführt werden kann. (Gibt ja auch CPUs die Java nativ beherrschen) Und weil Java eben für alle möglichen CPUs als Laufzeitumgebung ausgelegt ist, muss der Bytecode den kleinsten gemeinsamen Nenner haben, sodass alle VMs auf diversen CPUs was damit anfangen können.
Ach die JVM abschmieren zu lassen, dass passiert manchmal. Nen Stacküberlauf denke ich eher weniger, sowas wird meistens vorher durch Exceptions abgefangen. Meist isses dann immer ne schöne Meldung wie "An error inside the VM occured". Und wenn de dir mal den Bytecode anschauen willst und was dazu gehört, dann schaue dir mal JAD (Java Decompiler an). Dieser dekompiliert *class Dateien und zeigt dir neben dem bekannten Source noch die Bytecode-Befehle an.

Gnarg, bitte lesen und dann posten. Ich habe 3x (!) Assemblercode geschrieben.

Die JVM ist durch einen Stacküberlauf komplett abgeschmiert. Nicht mit "An error inside the VM occured", sondern ein richtiger Absturz im JIT-Assemblercode, wodurch ich dann auch in der Lage war, den zu debuggen. Normalerweise hat man keine Chance, daran zu kommen.

Meine Aussage ist: Der vom JIT Compiler erzeugte Assemblercode ist Schrott. Das hat mit dem Bytecode nix zu tun.

Naja, Java ist langsamer als C++, kann man nicht dran rütteln, obwohl Java in vielen Dingen doch schon aufgeholt hat. Aber mal ne Frage: Ist Performance in allen Belangen wirklich noch so wichtig?!? Und die endgültige Geschwindigkeit hängt auch sehr stark von den Fähigkeiten des Programmiers ab. Schön viel threaden, bei häufigem und vielen Dateioperationen die nio-Klassen nutzen etc. pp.
Java hat aber halt auch andere Vorteile, wie das Sandboxprinzip oder die doch recht hohe Stabilität und Sicherheit. Auch die Plattformunabhängigkeit ist ein Vorteil und ich finde für Einsteiger ist es ne schöne Sprache um OOP begreiflich zu machen.

Ack... ein schlechter Algorithmus ist in C++ immer noch schlecht, und bei vielen Dingen ist ein Faktor 2 auch verschmerzbar. Die unmittelbare Plattformunabhängigkeit ist ein Riesenvorteil.

Das könnte jetzt implizieren, dass Java-IDEs langsam sind ;) Stimmt aber net so ganz, der JBuilder (zumindest pre-2005) ist, obwohl in Java geschrieben, sehr schnell wie ich finde.

Mein Beispiel für eine schnelle Java-IDE ist Eclipse. Das liegt aber auch daran, daß die um Swing einen weiten Bogen gemacht haben.

Gruß

Jörg

Coda

2005-08-27, 11:23:09

Java ist viel schöner zu programmieren als C++. Wenn man die Zeiten vergleicht, die man braucht, um in Java bzw. C++ eine (nicht-triviale) Anwendung zu erstellen, dann geht das in Java deutlich schneller.Kommt das nicht auch größtenteils von den Libraries? Ich denke C++ mit Qt ist ähnlich mächtig im RAD Bereich.

Senior Sanchez

2005-08-27, 11:32:52

Dass ein unerfahrenen Java-Programmierer langsamer ist als ein erfahrener C++ Programmierer, glaube ich Dir sofort. Gerade, wenn man die RegEx-Sachen nicht beherrscht, ist man hoffnungslos im Nachteil bei vielen Aufgaben. Damit lassen sich viele Dinge als Einzeler erledigen, für die man sonst seitenweise Code bräuchte. Meine Behauptung ist, daß bei gleichem Kenntnisstand ein Java-Programmierer in der Regel schneller zum Ziel kommt.

Meine Behauptung ist, dass ein erfahrener C++ Programmierer schneller zum Ziel kommt als ein gleich erfahrener Java Programmierer. Das ist jetzt natürlich auch immer davon abhängig um was für ein Problem es sich handelt. Aber ich denke, die C++ Jungs sind da schneller.

Gnarg, bitte lesen und dann posten. Ich habe 3x (!) Assemblercode geschrieben.

Die JVM ist durch einen Stacküberlauf komplett abgeschmiert. Nicht mit "An error inside the VM occured", sondern ein richtiger Absturz im JIT-Assemblercode, wodurch ich dann auch in der Lage war, den zu debuggen. Normalerweise hat man keine Chance, daran zu kommen.

Meine Aussage ist: Der vom JIT Compiler erzeugte Assemblercode ist Schrott. Das hat mit dem Bytecode nix zu tun.

Achso, sorry, die Aussage hatte ich falsch verstanden. Aber mal nen Erklärungsansatz. Der JIT-Compiler muss ja wie gesagt Just-in-Time arbeiten und deshalb sind zwei Anforderungen zu erfüllen: 1. das Kompilat muss schnell ausführbar sein und 2. der Kompilationsprozess sollte auch entsprechend schnell von statten zu gehen. Gerade das 2. begründet denke ich, warum es dann doch nicht soo hochoptimiert ist.

Mein Beispiel für eine schnelle Java-IDE ist Eclipse. Das liegt aber auch daran, daß die um Swing einen weiten Bogen gemacht haben.

Jetzt geht das Gehetze auf Swing wieder los ;) Ich weiß, Swing hat seine Fehler, aber sooo schlecht und langsam finde ich es nicht. Wenn man effektiv mit Swing programmiert, kann es durchaus schnell sein und in Sachen Geschwindigkeit SWT das Wasser reichen.

Was kritisierst du an Swing?

HellHorse

2005-08-27, 13:21:00

2. der Kompilationsprozess sollte auch entsprechend schnell von statten zu gehen. Gerade das 2. begründet denke ich, warum es dann doch nicht soo hochoptimiert ist.
Nicht nur, das Problem ist zusätzlich dass Java bytecode eigentlich zu low level (=zu viel Information ist verloren gegangen) ist um wirklich hochoptimierte Kompilation zu machen. Um an die benötigen Informationen zu kommen, muss man quasi dekompilieren, was extrem teuer ist. Es gibt da diverse Papers von Thomas Kistler, Michael Franz und Konsorten von der Uni Californien, die SafeTSA vorschlagen, was nicht nur billiger bessere Optimierungen erlauben soll, sondern auch zu kleinerem Code führt und die ganze Verfikation vereinfacht.

Und der Kompilationsprozess muss ja den Ausführungsprozess nicht unterbrechen. Man kann ja zuerst eine quick 'n dirty Kompilation machen und später bei den hotspots immer noch nachoptimieren.

Was natürlich auch nicht hilft ist, dass der ganze vom JIT erzeugte Code bei einem Neustart weg ist. Sun hat aber gemeint sie wollen mal schauen, ob sich da was machen lässt.

Jetzt geht das Gehetze auf Swing wieder los ;) Ich weiß, Swing hat seine Fehler, aber sooo schlecht und langsam finde ich es nicht. Wenn man effektiv mit Swing programmiert, kann es durchaus schnell sein und in Sachen Geschwindigkeit SWT das Wasser reichen.
ACK. Siehe IDEA. JBuilder soll auch schnell sein, habe ich aber seit Ewigkeiten nicht mehr gebraucht.

Senior Sanchez

2005-08-27, 13:39:18

Nicht nur, das Problem ist zusätzlich dass Java bytecode eigentlich zu low level (=zu viel Information ist verloren gegangen) ist um wirklich hochoptimierte Kompilation zu machen. Um an die benötigen Informationen zu kommen, muss man quasi dekompilieren, was extrem teuer ist. Es gibt da diverse Papers von Thomas Kistler, Michael Franz und Konsorten von der Uni Californien, die SafeTSA vorschlagen, was nicht nur billiger bessere Optimierungen erlauben soll, sondern auch zu kleinerem Code führt und die ganze Verfikation vereinfacht.

Und der Kompilationsprozess muss ja den Ausführungsprozess nicht unterbrechen. Man kann ja zuerst eine quick 'n dirty Kompilation machen und später bei den hotspots immer noch nachoptimieren.

Stimmt, das ist natürlich nen Grund der noch schwerer wiegt.

Was natürlich auch nicht hilft ist, dass der ganze vom JIT erzeugte Code bei einem Neustart weg ist. Sun hat aber gemeint sie wollen mal schauen, ob sich da was machen lässt.

Hmm, das wäre ne Idee. Gerade bei Anwendungen die in den Desktop stark integriert sind (sei es durch WebStart oder weil es eben ne dauerhaft genutzte Applikation wie ne IDE ist), könnte dass schon einiges bringen.
Dass ClassData-Sharing geht ja schon ein wenig in diese Richtung, ist aber noch zuweit entfernt. Zumindest bringt dies Vorteile wenn mehrere Java-Apps gleichzeitig laufen.

ACK. Siehe IDEA. JBuilder soll auch schnell sein, habe ich aber seit Ewigkeiten nicht mehr gebraucht.

Den JBuilder empfinde ich auf meinem Rechner (XP 1800+, 512 MB RAM, Win XP SP1, JDK 5.0) wesentlich schneller als Eclipse. Zumindest die Versionen vor dem 2005er JBuilder sehe ich als sehr schnell an, da kann auf meiner Kiste kein Eclipse mithalten. Würde ich bei meinen TopCoder Challenges Eclipse nutzen müssen, ich glaube ich würde öfters in die Tischkante beißen, so lahmarschig wie das manchmal ist.

HajottV

2005-08-27, 18:25:34

Kommt das nicht auch größtenteils von den Libraries? Ich denke C++ mit Qt ist ähnlich mächtig im RAD Bereich.

Absolut. Die Java-Standard-Bibliothek sind der STL meilenweit voraus. Aus diesem Grund gibt es ja auch so viele C++ Bibliothek, die da Abhilfe schaffen. Ich habe leider zu kurz in Qt reingeguckt, um da ein fundiertes Urteil abgeben zu können. Das, was ich mitbekommen habe, sah allerdings super aus (allein schon plattformunabhängiges Threading für C++ ist ein Segen).

Gruß

Jörg

PS: Ich bin eigentlich C++ Programmierer und mag C++ auch lieber als Java... aber Java hat schon einige Vorteile.

Coda

2005-08-27, 20:18:44

allein schon plattformunabhängiges Threading für C++ ist ein SegenDa hat aber boost auch was dafür :)

http://boost.org/doc/html/threads.html

M@tes

2005-08-27, 23:24:53

Ich versteh nur Bahnhof - schlimm? :confused:

Hucke

2005-08-28, 00:00:26

Ich versteh nur Bahnhof - schlimm? :confused:

Nö. Nimm Dir ein bischen Popcorn und setz Dich zu mir. Ich programmiere zwar seit Jahren, aber ich hab bis jetzt immer Vorgaben meines Arbeitgebers gehabt, was ich mit welcher Sprache zu entwickeln hab. Von daher haben mich die Vor- und Nachteile der Sprachen wenig interessiert.

Ich weiß nur, hardcore OOP Fans schreiben unglaublich schlecht zu lesenden Code. :D

M@tes

2005-08-28, 00:16:12

Nö. Nimm Dir ein bischen Popcorn und setz Dich zu mir.
Joa, hab den Therad die ganze Zeit verfolgt, aber gross Mitreden kann ich nicht drüber. Programmiere zwar schon lang perl, aber da liegen Welten zwischen,...
Wäre ev auch mal interessant, wenn jemand das ganze mal für Leien verständlich erklären würde. Damit auch wir von diesen echt faszinierenden Diskussionen lernen können :biggrin:

Shink

2005-08-28, 08:59:01

Den JBuilder empfinde ich auf meinem Rechner (XP 1800+, 512 MB RAM, Win XP SP1, JDK 5.0) wesentlich schneller als Eclipse. Zumindest die Versionen vor dem 2005er JBuilder sehe ich als sehr schnell an, da kann auf meiner Kiste kein Eclipse mithalten. Würde ich bei meinen TopCoder Challenges Eclipse nutzen müssen, ich glaube ich würde öfters in die Tischkante beißen, so lahmarschig wie das manchmal ist.
Hmm, auf meinem Notebook (Duron Mobile 850, 384 MB Ram, XP Pro SP2, JDK 1.5) läuft Eclipse um einiges flüssiger als JBuilder X oder 2005.

Meine Behauptung ist, dass ein erfahrener C++ Programmierer schneller zum Ziel kommt als ein gleich erfahrener Java Programmierer. Das ist jetzt natürlich auch immer davon abhängig um was für ein Problem es sich handelt. Aber ich denke, die C++ Jungs sind da schneller.

Vielleicht gibts sie ja auch einfach schon länger. Kann aber auch sein, dass man mit "höheren geistigen Fähigkeiten" vom größeren Sprachumfang von C++ o.ä. profitiert.

Mir sind auch die ganzen Tests aus der c't etc. bekannt, die behaupten, daß Java und C++ sich in Bezug auf Geschwindigkeit nicht viel nehmen. Allerdings sind diese Tests ziemlich unrealistisch, da sie kaum eine Realsituation wiederspiegeln. (Vertrau nie einer Statistik, die Du nicht selbst gefälscht hast.)

Schon mal von Jake 2 gehört? (http://www.bytonic.de/html/benchmarks.html)
Ich glaub auch nicht, dass die Oracle-Typen Java als Implementierungssprache gewählt hätten, wenn sie dadurch ein lahmeres Produkt als die Konkurrenz bekommen hätten. Mag sein dass der Assemblercode der JIT nach Müll aussieht, aber ich glaube nicht, dass das wirklich so viel ausmacht bei der Performance eines Programmes.

JDBC unterstütz stored procedures, prepared statements (vorkompiliert) und solche Geschichten. Ich gehe mal davon aus, dass das mit statischem SQL gemeint ist.

Nö. Definitiv nicht. In statischem SQL könnte man auch Stored Procedures verwenden. (Ausser, du meinst mit "solche Geschichten" etwas, dass ich nicht kenne)

Edit: was hat JDBC mit Sprache Java als Sprache zu tun?
JDBC 1 bis 3 sollten sich eigentlich 1:1 in C++ implementieren lassen und für JDBC 4, naja ich habe noch keinen Treiber gesehen, der das kann.

Edit2: die C++ library definitiert doch gar kein Interface für SQL Datenbanken, oder irre ich mich da?

Das wollte ich gar nicht sagen. Mein genauer Satzlaut war (ja, ich weiß, es ist schwer, einen Gast-Post genau zu lesen):

- Da man mit dem Framework von Java mit seinen Standarderweiterungen sehr viel ganz einfach erledigen kann, werden Java-Anwendungen oft langsam; sei es weil man bestimmte Dinge eben zu einfach macht (z.B. Programmlogik bei EventHandling im Darstellungsthread) oder weil das Framework eben nicht für alle Zwecke optimal ist (z.B. Java 2D/3D, JDBC).

Also mit anderen Worten: Dass viele Java-Programme langsam sind, heißt nicht, das Java langsam ist.

Senior Sanchez

2005-08-28, 10:09:45

Hmm, auf meinem Notebook (Duron Mobile 850, 384 MB Ram, XP Pro SP2, JDK 1.5) läuft Eclipse um einiges flüssiger als JBuilder X oder 2005.

Wenn ich sehe wielange eclipse braucht um mir alle verfügbaren Funktionen die ich auf diesem Objekt aufrufen kann, anzuzeigen, da ist mein JBuilder schon zweimal fertig damit.

Shink

2005-08-28, 19:42:51

Wenn ich sehe wielange eclipse braucht um mir alle verfügbaren Funktionen die ich auf diesem Objekt aufrufen kann, anzuzeigen, da ist mein JBuilder schon zweimal fertig damit.
Ja, das schon - das klingt aber nicht gerade nach einer Swing vs SWT -Angelegenheit. Das Arbeiten selbst (Menü öffnen, Tab wechseln etc.) geht bei mir in Eclipse schneller. Etwas Anderes ist es natürlich, wenn man aufwändige Eclipse-Plugins wie z.B. den Visual Editor startet...

Coda

2005-08-28, 19:45:54

Ich hab bis heute kein Java-Program in den Händen gehabt, dessen UI nicht zumindest am Anfang träge ist. Das nervt. Ein JITC-Cache würde da aber wohl Wunder wirken.

Abnaxos

2005-08-29, 03:13:01

Senior Sanchez

2005-08-29, 08:33:43

Du wirst staunen:
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#vm_classdatashare

Nicht, dass das (IMHO) nötig gewesen wäre, aber das, wonach es dir verlangt, ist schon lange da ... ;)

Das ist ja das was ich schon sagte, was in die Richtung geht, aber so ganz ist es das nicht was gemeint ist.
Classdatasharing bringt nur etwas wenn mehrere Java Applikationen zur gleichen Zeit laufen müssen.
Worauf hier aber hinausgegangen wurde, ist, dass einmal durch den JITC kompilierte Klassen irgendwo auf der Festplatte oder was weiß ich entsprechend gespeichert wurden. Das bringt dann Performancevorteile für den nächsten Start, da ja quasi dann schon ein richtiges Maschinenkompilat für die aktuelle Architektur vorliegt und nicht nochmal der JITC jedes mal drüber laufen und das kompilieren muss.