Java lernen - bringts was? [Archiv]

Weyoun

2006-07-05, 13:13:01

Hi,

ich überlege mir gerade, ob ich mich mal mit Java etwas genauer auseinandersetzen sollte. Hilfreich könnten hier meine Fähigkeiten in C/C++, Assembler (x86) und auch in "Websprachen" wie HTML und PHP sein.

Klar - schaden kanns natürlich nicht, aber was mich interessiert ist vor allem der Kosten / Nutzen Faktor. Bringts was? Wieso sehe ich so wenig Programme die unter Java (JVM) laufen?

Wie lange braucht man, um das ordentlich zu verstehen? Mich würden eure Erfahrung dazu interessieren!

MfG,
Weyoun

Trap

2006-07-05, 13:45:25

Es gibt nur relativ wenig was Java hat und C++ nicht, wenn man C++ gut kann dauert Java lernen nur eine Woche oder so (vorausgesetzt man nutzt die Woche und hat einen guten Lehrer/gute Bücher).

Ich würd eher C# empfehlen. Hauptsächlich deshalb, weil ich Java nicht mag.

Monger

2006-07-05, 14:10:53

Die Sprachen die erst in Metasprache übersetzt werden, sind allgemein noch nicht so verbreitet. C# gewinnt zwar ständig an Bedeutung, hat aber noch lange nicht die Bedeutung von C++.

Java ist eine exzellente Lehrsprache - schon alleine weil man kostenlos an ein paar erstklassige IDEs herankommt. Das galt für die Microsoft Konsorten bis vor kurzem ja nicht...

Angeblich wird Java auch sehr viel im Serverbereich eingesetzt - und natürlich bei Kleingeräten wie Handys.

Wenn man noch gar keine Erfahrung mit Programmiersprachen hat, würde ich Java empfehlen. Wenn man schon langjährige Erfahrung mit C++ hatte (und vorallem wenn man Windowsapplikationen schreiben will), würde ich C# empfehlen.

Java's große Schwäche ist, dass es mit der Windowswelt nicht so wirklich zurande kommt. Ansprechende Fensteranwendungen zu machen, ist damit (egal mit welcher IDE) immer noch nicht so wahnsinnig prickelnd, und die ganzen Techniken die Windows selbst anbietet (COM Modell usw.) lassen sich nur mit biegen und brechen da ranflanschen.

Coda

2006-07-05, 14:55:08

Monger[/POST]']Die Sprachen die erst in Metasprache übersetzt werden, sind allgemein noch nicht so verbreitet.
Da täuscht du dich aber mal gewaltig. Es gibt deutlich mehr Stellenanzeigen für Java-Programmierer als für C++-Programmierer in der Industrie.

Ganon

2006-07-05, 15:20:43

Wobei das im Endeffekt sowieso egal ist. Java ist in dem Sinne nur einen andere Syntax für das Programmieren. ;)

PHuV

2006-07-05, 15:23:45

Lerne es, ich bin gerade am Umsteigen (von C auf Java) und tue mich mit diesem ganze Eclipse und Java Mist doch recht schwer. :frown:

Je eher, desto besser. Und ja, Java ist heute enorm wichtig!

Shink

2006-07-05, 15:27:21

Weyoun[/POST]']
Klar - schaden kanns natürlich nicht, aber was mich interessiert ist vor allem der Kosten / Nutzen Faktor. Bringts was? Wieso sehe ich so wenig Programme die unter Java (JVM) laufen?

Wie lange braucht man, um das ordentlich zu verstehen? Mich würden eure Erfahrung dazu interessieren!

MfG,
Weyoun
Die Frage ist: Was willst du damit machen?
Wenn du tatsächlich Windows-GUI-Programme erstellen oder Spiele für "den Hausgebrauch" schreiben willst, bringts sicher wenig.

Auf Serverseite oder als "Arbeitsqualifikation" bringst sicher was: z.B.:
- Datenbankzugriff auf nicht-x86-Mainframes (IBM/Sun), das ganze testweise aber auf der lokalen MySQL-DB verwenden. Da ist Java mit JDBC sicher eine gute Wahl...
- Größere Projekte mit dynamischen HTML-Seiten. Klar geht das auch ohne Java, ist Geschmackssache.
- Web-verteilte Anwendungen (Webservices, CORBA)

Besonders geeignet ist es natürlich für Anwendungen, die das alles brauchen, und da gibts im Business-Bereich natürlich einiges.

Für alles andere (GUI-Programmierung, Spiele, etc.) ist Java auch zu gebrauchen, aber sicher nicht die erste Wahl (wenns auch teilweise eine schöne Sprache ist...)

Davon abgesehen: Anscheinend ist Java ideal dafür geeignet, um damit IDEs zu schreiben. Klingt unlogisch, aber anders ist es für mich nicht zu erklären, dass es so viele gute Java-IDEs gibt.

Die Grundzüge von Java sind für einen C++-Programmierer vermutlich tatsächlich in SEHR kurzer Zeit zu lernen.

Die Frage C# oder Java stellt mE nicht wirklich: Dafür sind sich Sprache und Standard-Libraries zu ähnlich; ein Java-Programmierer kann ohne allzuviel Umstellung auch C#-Projekte erledigen und umgekehrt.

Monger

2006-07-05, 15:45:55

Coda[/POST]']Da täuscht du dich aber mal gewaltig. Es gibt deutlich mehr Stellenanzeigen für Java-Programmierer als für C++-Programmierer in der Industrie.

Dass C++ immer weniger wird, bestreite ich ja gar nicht! Aber bestimmt 90% aller Windows-Applikationen werden nunmal immer noch in C++ geschrieben. Mit natürlich deutlich abnehmendem Anteil...

Coda

2006-07-05, 16:01:16

Monger[/POST]']Aber bestimmt 90% aller Windows-Applikationen werden nunmal immer noch in C++ geschrieben.
Neue? Nö.

Ganon

2006-07-05, 16:08:04

Ist das nicht eher ein Mix aus Borland-Produkten, was die meiste Software aus macht? ;)

Coda

2006-07-05, 16:09:15

Nö. Visual C++ 6 ist immer noch absolut dominant. Bei den neueren Sachen aber auch VC++ 7 und 8.

Senior Sanchez

2006-07-05, 16:11:18

Ganon[/POST]']Wobei das im Endeffekt sowieso egal ist. Java ist in dem Sinne nur einen andere Syntax für das Programmieren. ;)

Das ist aber doch etwas stark vereinfacht ;-)

Java ist schon sehr wichtig und eine exzellente Sprache, die IMO recht schnell erlernbar ist, wenn man schon Programmiererfahrung besitzt. Zweifelsohne wird man aber erst mit der Zeit wirklich gut, weil allein das Standard SDK ist sooo umfangreich, dass man es nur durch viele verschiedene Anwendungen kennenlernt.

Und zum Einsatzort: Gerade Server-Anwendungen werden viel in Java geschrieben und das hat auch viele Gründe.

- Java ist sehr stabil und sicher, es treten ansich weniger Fehler auf
- Java bietet mit der Enterprise Edition ein SDK an, was enorm viele Geschäftsprozesse abdeckt und erleichtert
- Java besitzt eine exzellente Anbindung an Datenquellen, sei es per JDBC, JDO oder z.B. externen Frameworks wie Hibernate

Afaik läuft ebay zum Teil mit Java-Servern und andere große Dienste bestimmt auch, nur merkt man davon als Nutzer in der Regel nichts.

Expandable

2006-07-05, 17:57:25

Ich würde C# empfehlen. Allein schon deshalb, weil Visual Studio 2005 Eclipse um WELTEN voraus ist. Außerdem gefällt mir das Event-Handling in Java (Swing) nicht (wie dämlich ist es bitte, für jeden beschissenen EventHandler Interfaces implementieren zu müssen bzw. umständlich mit Adapter-Klassen rumzumurksen?)...

SavageX

2006-07-05, 18:34:28

Expandable[/POST]']wie dämlich ist es bitte, für jeden beschissenen EventHandler Interfaces implementieren zu müssen ...

Finde ich sehr angenehm und kommt der Struktur sehr zugute (besser, als irgendwelche Methodenaufrufe an Buttons zu flanschen ist es allemal).

public class Actions implements ActionListener {

public void actionPerformed(ActionEvent e) {
// your OMG-button-pressed code here
}
}

Sehr hübsch, um die GUI von der eigentlichen Logik fernzuhalten.

Weiterhin ist Swing nicht die einzige Möglichkeit, um GUIs zu erstellen.

Senior Sanchez

2006-07-05, 18:40:30

Dito Savage.

Zumal es eben ne gute Implementierung des Observer-Patterns ist und mir gefällt das EventHandling eigentlich schon.
Wie soll es deiner Meinung nach denn besser gehen, Expendable?

Darkstar

2006-07-05, 18:41:44

Ganon[/POST]']Wobei das im Endeffekt sowieso egal ist. Java ist in dem Sinne nur einen andere Syntax für das Programmieren. ;)Aus Arbeitnehmersicht ja, aus Arbeitgebersicht nein. Wenn Du nicht schon jahrelang Java gemacht hast, wirst Du Schwierigkeiten haben, Dich auf eine offene Javaentwickler-Stelle erfolgreich zu bewerben.

EgonOlsen

2006-07-05, 18:52:50

Expandable[/POST]']Ich würde C# empfehlen. Allein schon deshalb, weil Visual Studio 2005 Eclipse um WELTEN voraus ist. Außerdem gefällt mir das Event-Handling in Java (Swing) nicht (wie dämlich ist es bitte, für jeden beschissenen EventHandler Interfaces implementieren zu müssen bzw. umständlich mit Adapter-Klassen rumzumurksen?)...Erstens gibt es nicht nur Eclipse und zweitens...ist das wirklich soooo wichtig, was die IDE nun kann oder nicht? Und vor allem: Kann man daran die "Qualität" eine Sprache messen? Man sollte auch mit einem Texteditor zurande kommen (würde ich für den Anfang sogar immer empfehlen), ansonsten ist man beim Programmieren sowieso falsch aufgehoben. Und was die Interface vs. Delegates-Geschichte angeht: Das ist eine philosophische Frage. Damit kann man ganze Threads füllen und ist hinterher so schlau wie zuvor.
Macht Java lernen "Sinn"? Wenn man das als zusätzliche Berufsqualifikation sieht, dann auf jeden Fall. Wenn es nur ein Hobby bleiben soll, dann macht alles Sinn, was Spaß macht. Und die Frage, ob Java Spaß macht...die muss jeder für sich selber beantworten.

ollix

2006-07-05, 18:55:15

Weyoun[/POST]']Bringts was?jo

Coda

2006-07-05, 18:59:47

SavageX[/POST]']besser, als irgendwelche Methodenaufrufe an Buttons zu flanschen ist es allemal
Wieso?

SavageX[/POST]']Sehr hübsch, um die GUI von der eigentlichen Logik fernzuhalten.
Das geht auch mit "Methoden an Buttons anflanschen".

SavageX

2006-07-05, 19:12:42

Wer Methoden an Buttons anflanscht wird gelegentlich durch den GUI-Code (damit meine ich die Teile, wo Buttons etc. auf das Fenster geklebt werden) durchjagen, um die Aufrufe zu ändern, sollte sich doch was bewegen. Das ActionListener Konzept erspart das einem. Gerade bei generiertem GUI-Code (manchmal doch eher eklig) möchte man da lieber nichts ohne Gummihandschuhe anfassen.

Man *kann* auch per Geflansche hübsch getrennten Code hinbekommen. Aber setze das mal konsequent in einer Gruppe um...

(Und ja, man kann mit jedem Mittel beliebig hässlichen Code fabrizieren - aber manche Mittel erscheinen mir etwas anfälliger als andere)

Coda

2006-07-05, 19:43:25

Hast du schonmal Qt benützt? Eher nicht, sonst würdest du anders reden...

SavageX

2006-07-05, 20:03:39

Coda[/POST]']Hast du schonmal Qt benützt? Eher nicht, sonst würdest du anders reden...

Mal vor Urzeiten ein Buch drüber gelesen - hat mich nicht besonders berührt, was ich da gesehen habe (nicht schlecht, lässt sich mit arbeiten). Da muss ich wohl was überlesen oder vergessen haben, da ich offensichtlich nicht so rede, wie Du Dir das vorstellst ;)

Ansonsten darfst Du natürlich kurz den Mechanismus vorstellen, den QT verwendest und über den ich "anders reden" würde, wenn ich ihn derart in Detail kennen würde, wie Du :)

Ich *persönlich* finde den ActionListener Ansatz ganz vernünftig und glaube zu erkennen, was sich die Entwickler dabei gedacht haben, als sie sich für dieses Konzept entschieden haben - "dämlich" (wie von Expandable behauptet) ist keinesfalls ein Prädikat, was ich da draufpappen würde.

Das ist natürlich nicht der einzig selig machende Ansatz - viele Wege führen zu beliebig vielen Roms ;)

Nur finde *ich* es absolut erstrebenswert, Widgets nicht direkt mit Reaktionen zu verdrahten (flapsig von mir als "flanschen" bezeichnet) (<pseudocode>button.setOnPress("myReaction()"))</pseudocode>), da *ich* finde, dass sich so ein Code tendenziell eher mit der eigentlichen Logik vermengt und Wartungsarbeiter sich im worst-case durch das GUI-Gewusel hindurschlagen müssen.

Wer nicht erzwingt, dass Logik und GUI getrennt werden, wird in vielen Fällen keinen getrennten Code erhalten ;)

Coda

2006-07-05, 20:31:10

SavageX[/POST]']Wer nicht erzwingt, dass Logik und GUI getrennt werden, wird in vielen Fällen keinen getrennten Code erhalten ;)
Nochmal: Das hat überhaupt nichts damit zu tun. Du kannst mit Signals genauso ein MVC-Pattern implementieren.

Und auch in der Praxis wie KDE zeigt. Das benützt nämlich durchwegs Qt und hat sicher keinen "furchtbaren" Code.

SavageX

2006-07-05, 20:51:02

Coda[/POST]']Nochmal: Das hat überhaupt nichts damit zu tun. Du kannst mit Signals genauso ein MVC-Pattern implementieren.

Ich wollte doch gar nichts anderes behaupten.

Nur erachte ich es als sinnvoll, wenn ein GUI API dies nach Kräften fördert. Meiner Meinung nach ist sowas besser als Ansätze, die es Entwicklern (oft wider besseres Wissen, weil es halt so schnell geht... und weil man das ja sowieso noch anders macht und und und...) *ermöglichen*, bei ihrer Disziplin einzuknicken.

Gerade für Anfänger erscheint es mir wichtig und sinnvoll, MVC von Anfang an zu *erzwingen*, damit sie gar nicht erst auf "dumme" Ideen kommen. Bei ActionListeners V und C zu vermengen dürfte schon schwieriger sein...

Coda[/POST]']
Und auch in der Praxis wie KDE zeigt. Das benützt nämlich durchwegs Qt und hat sicher keinen "furchtbaren" Code.

Die KDE Entwickler wissen, was sie tun.

darph

2006-07-05, 20:56:11

ollix[/POST]']joEin wenig mehr Inhalt zum Thema (Argumente und ähnlich exotisches Zeugs sind immer wieder gerne gesehen, um die Diskussion aufzuheitern und die unbeteiligten Zuschauer zu amüsieren) darph es dann schon sein.

Xmas

2006-07-06, 00:36:29

SavageX[/POST]']Wer Methoden an Buttons anflanscht wird gelegentlich durch den GUI-Code (damit meine ich die Teile, wo Buttons etc. auf das Fenster geklebt werden) durchjagen, um die Aufrufe zu ändern, sollte sich doch was bewegen. Das ActionListener Konzept erspart das einem. Gerade bei generiertem GUI-Code (manchmal doch eher eklig) möchte man da lieber nichts ohne Gummihandschuhe anfassen.
Mir erschließt sich leider nicht wo jetzt der große Unterschied zwischen "Methode an Button anflanschen" und "ActionListener an Button anflanschen" ist.

Zum Thema: wenn ich es nicht schon getan hätte, würde ich es tun. Es bringt auch etwas, verschiedene Sprachen zu kennen wenn man sie später gar nicht einsetzt. Man kommt mit Konzepten in Berührung die man woanders vielleicht noch nicht gesehen hat und erschließt sich so ganz andere Perspektiven.

Thorn of Roses

2006-07-06, 01:38:43

wdragon[/POST]']Lerne es, ich bin gerade am Umsteigen (von C auf Java) und tue mich mit diesem ganze Eclipse und Java Mist doch recht schwer. :frown:

Je eher, desto besser. Und ja, Java ist heute enorm wichtig!

Umsteigen? Heisst das du machst etwas das du vorher mit C gemacht hast jetzt mit Java? :biggrin: :eek:

mit grinsenden Grüssen,

-Thorn-

PHuV

2006-07-06, 12:29:14

Thorn of Roses[/POST]']Umsteigen? Heisst das du machst etwas das du vorher mit C gemacht hast jetzt mit Java? :biggrin: :eek:

mit grinsenden Grüssen,

-Thorn-

Klar, nur :biggrin:

Nene, Java ist schon ganz anders, und diesen ganzen Methodenscheiß habe ich noch nicht so im Griff, ich finde das alles noch sehr verwirrend, dazu kommt noch SWT und Eclipse, und schon wirds sehr unübersichtlich!

Und das Java besser und stabiler als C sein, kann ich mit meinen Erfahrungen in meiner Firma bisher nicht bestätigen, das ist aus meiner Sicht eine defintive Falschaussage. Releasebau in Java ist teilweise eine richtige Katastrophe, wenn ich mir so die Kommentare der Portierungskollegen höre, ebenso läuft Java, wie sooft behauptet, nicht auf allen Plattformen gleich.

Java frißt teilweise viel Hauptspeicher, macht beim synchroisiern Probleme etc. etc. . Aber das merkt man erst, wenn man richtig große Projekte macht und nicht nur kleine Poppelprogramme.

Man kommt heute um Java nicht herum, deshalb: LERNEN!

grandmasterw

2006-07-06, 12:49:47

Also wenn ich was in Java schreib (mein letztes Uni-Praktikum z.B.) wird das zwar nicht besonders schnell, allerdings brauch ich recht wenig Code, weil schon so viel in der API dabei ist, und die Programme werden vom SE-Standpunkt viel ordentlicher, übersichtlicher, und einfacher zu warten.

Für Endanwender Programme führt Java nochn Schattendasein. Da kann der Hersteller schon ein bissl mehr in C++ Entwicklung investieren, wenn ers ne Million mal verkauft.
Aber für Speziallösungen, wos ne einstellige Anzahl an Kunden gibt, machts durchaus einen Unterschied, dass das Programm mit Java oft schneller fertig ist. Wenn einer wirklich sauber Objektorientiert programmiert, schafft ers mit C++ vermutlich eh in der selben Zeit, aber viele Leute flanschen noch zuviel C Code rein.

SavageX

2006-07-06, 13:31:00

Xmas[/POST]']Mir erschließt sich leider nicht wo jetzt der große Unterschied zwischen "Methode an Button anflanschen" und "ActionListener an Button anflanschen" ist.

Der ActionListener ist eine eigene Klasse und darauf spezialisiert, sich nur um Ereignisse zu kümmern. Hält das C von MVC mit schöner Sichereit zumindest vom V fern.

Eine Methode kann sonstwo stehen.

Im Endeffekt eher ein "kleiner" Unterschied. Vielleicht einfach nur Geschmackssache. Der Diskussion vielleicht gar nicht Wert, also sorry für die off-topicness.

Monger

2006-07-06, 13:36:25

wdragon[/POST]']
Und das Java besser und stabiler als C sein, kann ich mit meinen Erfahrungen in meiner Firma bisher nicht bestätigen, das ist aus meiner Sicht eine defintive Falschaussage.

Hast du jemals eine Java Anwendung gecrasht? Ich nicht. Exceptions geworfen natürlich schon, aber mir die JVM oder gar das Betriebssystem unterm Hintern weggeschossen, das hab ich noch nicht geschafft. In C geht das ganz bequem in drei Zeilen! ;)

noid

2006-07-06, 14:01:54

Monger[/POST]']Hast du jemals eine Java Anwendung gecrasht? Ich nicht. Exceptions geworfen natürlich schon, aber mir die JVM oder gar das Betriebssystem unterm Hintern weggeschossen, das hab ich noch nicht geschafft. In C geht das ganz bequem in drei Zeilen! ;)

Und selbst wenn. C und Java haben nicht den gleichen Einsatzort. Keiner würde jetzt kommen und zB mit C Dateien parsen. Da ist Perl/Python, whatever doch 3mal schneller geschrieben.

Äpfel und Birnen...

Xmas

2006-07-06, 14:02:26

SavageX[/POST]']Der ActionListener ist eine eigene Klasse und darauf spezialisiert, sich nur um Ereignisse zu kümmern. Hält das C von MVC mit schöner Sichereit zumindest vom V fern.

Eine Methode kann sonstwo stehen.
Der ActionListener kann als anonyme Klasse allerdings auch sonstwo stehen (und steht häufig in handgeschriebenem GUI-Code auch genau dort wo die GUI-Elemente instanziert werden).

Senior Sanchez

2006-07-06, 16:44:36

wdragon[/POST]']Klar, nur :biggrin:

Nene, Java ist schon ganz anders, und diesen ganzen Methodenscheiß habe ich noch nicht so im Griff, ich finde das alles noch sehr verwirrend, dazu kommt noch SWT und Eclipse, und schon wirds sehr unübersichtlich!

Und das Java besser und stabiler als C sein, kann ich mit meinen Erfahrungen in meiner Firma bisher nicht bestätigen, das ist aus meiner Sicht eine defintive Falschaussage. Releasebau in Java ist teilweise eine richtige Katastrophe, wenn ich mir so die Kommentare der Portierungskollegen höre, ebenso läuft Java, wie sooft behauptet, nicht auf allen Plattformen gleich.

Java frißt teilweise viel Hauptspeicher, macht beim synchroisiern Probleme etc. etc. . Aber das merkt man erst, wenn man richtig große Projekte macht und nicht nur kleine Poppelprogramme.

Man kommt heute um Java nicht herum, deshalb: LERNEN!

Ich mag die Methoden. Mit der Zeit ist das alles total logisch und ziemlich natürlich in der Denkweise verankert.
Java nicht stabiler als C? Sorry, aber lernt mal richtig damit zu programmieren und die Konzepte *fg* Wie Monger schon schrieb, das BS habe ich mit Java noch nie abgeschossen und semantische Fehler passieren halt (syntaktische gar nicht, das fängt die Online-Fehlerkorrektur ja schon ab falls man mal was falsch machen sollte), aber da gibts dann Exceptions. Trotzdem beendet sich Java dann aber sauber.

Releasebau ne Katastrophe? Hmm, wir nutzen immer CVS-Branches und zu nem bestimmten Zeitpunkt wird kurz das committen gestoppt und der Stand in nem Branch eingefroren. Danach jagt einer nen Ant-Buildscript drüber und fertig die Laube.

Java läuft ansich schon (überall) gleich. Das einzig größere Ärgernis ist da meist die GUI inform von AWT/Swing, aber sofern man fähige GUI-Designer hat, können die die Unterschiede doch recht klein halten. Man muss natürlich verstehen was man macht und wenn ich das Wort "Portierungskollege" höre, schwant mir böses ;-)

Das Java mehr Hauptspeicher frisst ist ja auch klar, wird ja eben auch von ner VM interpretiert und der HotSpot-Compiler braucht eben auch nen bissl Platz für Notizen.

Was meinst du für Probleme beim synchronisieren?

PS: Sorry für den vielleicht manchmal etwas gemeinen Ton, ist nicht so gemeint.

Gast

2006-07-06, 17:16:11

Senior Sanchez[/POST]']
Java läuft ansich schon (überall) gleich. Das einzig größere Ärgernis ist da meist die GUI inform von AWT/Swing, aber sofern man fähige GUI-Designer hat, können die die Unterschiede doch recht klein halten. Man muss natürlich verstehen was man macht und wenn ich das Wort "Portierungskollege" höre, schwant mir böses ;-)
Naja, manche Dinge laufen tatsächlich nicht genau gleich - und können es wohl auch nicht. Teile der JRE bauen eben auf den Betriebssystemfunktionen auf - was sollen sie auch anderes tun. Und irgendwann bekommt man eben Sockets, die nicht abkratzen wollen; irgendetwas dauert auf einmal verdammt lange oder wird auf einmal ein Problem "nur weil man schnell das OS gewechselt hat". Wie sollte es auch anders sein...

Senior Sanchez[/POST]']
Das Java mehr Hauptspeicher frisst ist ja auch klar, wird ja eben auch von ner VM interpretiert und der HotSpot-Compiler braucht eben auch nen bissl Platz für Notizen.

Was meinst du für Probleme beim synchronisieren?
Abgesehen davon hat man ja einen gewissen Speicherbrocken als Heap reserviert. Den kann man aber beim Aufruf des Programms verkleinern, wenn es einem wirklich darauf an kommt. Nur ist das eigentlich nicht wirklich ein Problem, ausser die Leute fangen irgendwann damit an, massenweise Hintergrund-Desktop-Applikationen ala Virenscanner, Lautstärkenregelung und VGA-Control Panel in Java zu schreiben.
Obwohl: Sun macht ja Bemühungen, die JRE von mehreren Java-Applikationen teilen zu lassen, dann wär sogar das egal.

Senior Sanchez

2006-07-06, 17:23:17

Gast[/POST]']Naja, manche Dinge laufen tatsächlich nicht genau gleich - und können es wohl auch nicht. Teile der JRE bauen eben auf den Betriebssystemfunktionen auf - was sollen sie auch anderes tun. Und irgendwann bekommt man eben Sockets, die nicht abkratzen wollen; irgendetwas dauert auf einmal verdammt lange oder wird auf einmal ein Problem "nur weil man schnell das OS gewechselt hat". Wie sollte es auch anders sein...

Mir seltsamerweise noch nie passiert. Vieles was systemabhängig ist, ist ja auch native geschrieben, sodass dort auf eventuelle Sonderfälle eingegangen wird. Dass z.B. Threading auf einem BS mal etwas anders laufen kann als auf nem anderen ist ja normal, aber ich habe davon beim Gebrauch noch nicht viel mitbekommen.

Gast[/POST]']
Abgesehen davon hat man ja einen gewissen Speicherbrocken als Heap reserviert. Den kann man aber beim Aufruf des Programms verkleinern, wenn es einem wirklich darauf an kommt. Nur ist das eigentlich nicht wirklich ein Problem, ausser die Leute fangen irgendwann damit an, massenweise Hintergrund-Desktop-Applikationen ala Virenscanner, Lautstärkenregelung und VGA-Control Panel in Java zu schreiben.
Obwohl: Sun macht ja Bemühungen, die JRE von mehreren Java-Applikationen teilen zu lassen, dann wär sogar das egal.

Ja, eben, aber Hauptspeicher ist doch heutzutage meist nicht mehr sodass Problem, oder?
Mit der JRE, das stimmt. Ein erster Schritt dazu sich Shared Classes und wurde mit Java 5 eingeführt, wird aber noch gar nicht so richtig genutzt. Im Grunde wird dabei nur einmal die Java Klassenbibliothek geladen die sich dann mehrere JREs teilen können.
Im Grunde läufts aber am Ende darauf hinaus sofern möglich vieles in derselben VM laufen zu lassen um einfach die doch manchmal etwas längere Startzeit zu verbessern.

Monger

2006-07-06, 17:42:52

PHuV

2006-07-06, 17:49:20

@Senior Sanchez

Ich weiß nur, daß wir mit Ant und Maven momentan ein Riesenprobleme haben, sauber ein Release mit C und Java-Quellen und unterschiedlichen Head- und Branchzweigen zu bauen. Aber darum kümmert sich die Portierung, nicht ich ;) .

Und ich hörte auch von Problemen mit diversen Protokollen und verteilen Systemen unter Java.

Das Java nicht auf allen Plattformen gleich läuft, sieht man beispielsweise bei AIX, weil die wieder ein eigenes Java onboard haben!

Senior Sanchez

2006-07-06, 17:53:36

Monger[/POST]']Also, Plattformunabhängigkeit ist ja sowieso ein schlechter Witz. Nicht nur für Java, sondern überall - spätestens bei der GUI. Ich WILL meine Handyspiele nicht auf einem 19'' Monitor spielen!
Und auch zwischen Linux, Mac und Windows bestehen nunmal fundamentale Unterschiede im Dateisystem, in der Darstellung, in Speicher- und Prozessverwaltung usw.

Das kann man also Java schlecht vorwerfen. Allenfalls, dass sie es mal ziemlich intensiv promotet haben.

Naja, man kanns mit der Plattformunabhängigkeit auch übertreiben.
Das Hauptkredo ist, dass es auf sämtlichen _gleichwertigen_ Architekturen läuft. Das nen handyspiel nun nicht für nen High-End-Server gedacht ist, dürfte klar sein und somit nix mit Plattformunabhängigkeit zu tun haben ;-)

@wdragon

Naja, sollen sie sich halt drum kümmern ;-)

Probleme mit Protokollen? Welche Protokolle denn?
Die Software die ich für verteilte Systeme bisher schrieb (auf JINI- und RMI-Basis) hat ohne Probleme funktioniert, ka was da bei euch schief läuft.

Das mit AIX ist natürlich wieder son spezielles Ding.