Programmieren unter Linux oder which Language....

EY!!! Ich kann Kylix downloaden;
Borland hat blos geupdated, deswegen waren die Server nicht erreichbar!!
Hab denen Gemailt!
Jetzt zieh ich mir das mal!
 
Den vorwurf man koenne in Java keine komplexen Dinge realisieren solltest du zurueckziehen, bevor man dich hier steinigt! :) Das ist nur ein boeses vorurteil, es kommt nur auf den willen und das koennen an... ich bekomm das jeden tag zu hoeren, wegen Perl und dennoch habe ich einfach ignoriert was mir die leute gesagt haben und einen 2000 Zeilen grossen, extrem threadenden server fuer codewars in perl geschrieben und er laeuft ohne probleme, und das ist nur das kleinere projekt! :) Also... vorsichtig mit solchen aussagen! ;)

Aber wenn du nun kylix hast ist das doch wunderbar... ich wuensch dir viel spaß und erfolg!!

ciao ExRevel
 
hehejo schrieb:
Das Argument "langsam" lass ich nicht gelten. Gut optimiert läuft das wie ne eins.

Andere Sprachen machen das _ohne_ Optimierung.

hehejo schrieb:
Und du hast wirklich den Vorteil dass es auf jedem OS mit JavaMachine läuft! :)

Da NetBSD (welche meines Erachtens in C bzw. C++ geschrieben ist)
jetzt schon auf mehr Plattformen läuft, als Java es in absehbarer Zeit tun wird, ist das Argument für'n A...
 
@ssc Dein zweites Argument hinkt ein weing! NetBSD laeuft auf verschiedenen Maschienen... i86, Alpha, Toaster und so weiter aber bei Java ging es darum, dass es auf verschiedenen OS (Operating Systems) NetBSD zB. ist eins, laeuft, was andere sprachen so toll nicht machen! Denn die unterschiede zwischen C auf Windows und C auf Linux sind vorhanden... die API von Delphi und Kylix unterscheidet sich auch und die von HBasic und VBasic auch...

Verstehst du was er meinte?

ciao Exi
 
Das man mit Java keine komplexen Projekte machen kann hab ich nie
behauptet, ich hab nur gesagt, dass es nicht einfach wird! Und wie es zur
Zeit aussieht, ist Sun in einer sehr schlechten wirtschaftlichen Position und
wenn Sun sein Java nicht weiter macht, wär das echt schade und wie gesagt,
Java werd ich sowieso lernen müssen, aber das nehm ich mir später mal vor.

Habt ihr nicht vielleicht ne Ahnung, ob es deutsche Tutorials oder Dokus
zu HBasic gibt? HBasic gefällt mir *gg* Hab da drin ein schönes Hello
World geschrieben!!! In ca. 15 min ist Kylix fertig, noch 50mb
 
Java habe ich deshalb in meiner Liste Oben aufgeführt, weil es vom nutzen wäre es zu lernen, mittlerweile wollen ja schließlich fast alle JavaLeute.....

Ich selber Programmiere Java nicht, weil ich es nicht mag. Ich sehe keinen sinn darin...
Erstens ist Java langsamer als C/C++, Portierbarkeit kann ich auch mit C machen indem ich mich einfach an Ansi halte, und ObjectOrientiert kann ich auch in C.
Es ist oft ein falsch denken, wenn man sagt das eine Sprache OO ist, wie z.b. Java oder C++. Eine Sprache kann höchstens hilfestellungen zur ObjectOrientierung geben. Aber OO Programmieren kann ich auch in C, Perl oder sonst was....

mfg manuel
 
Stimmt!
Für Kylix hab ich jetzt nach Büchern und Tutorials gesucht, aber fast aller
beziehen sich auf Kylix 1 oder 2. Nicht auf 3.
Erstmal kennt jemand gute Tutorials für Kylix und am besten für Kylix 3 oder
vielleicht gute Bücher.
 
ExRevel schrieb:
@ssc Dein zweites Argument hinkt ein weing! NetBSD laeuft auf verschiedenen Maschienen... i86, Alpha, Toaster und so weiter aber bei Java ging es darum, dass es auf verschiedenen OS (Operating Systems) NetBSD zB. ist eins, laeuft, was andere sprachen so toll nicht machen!

Ok, NetBSD ist in der Hinsicht ein schlechtes Beispiel.
Nehmen wir dann doch einfach mal Perl (in seiner Eigenschaft als Programm).
 
Nehmen wir dann doch einfach mal Perl (in seiner Eigenschaft als Programm).

Ich will dich nicht angreifen, versteh das net falsch... aber Perl als Programm als sich, also der Interpreter und der Compiler, die wurden in C geschrieben und es laeuft auf jeder verdammten Plattform auf diesem Planeten, aber auch da braucht man fuer jedes OS und jede Machine eine andere version des Sources... schau einmal auf www.cpan.org dort findest du ca. 40 verschiedene Perlversionen fuer verschiedene Betriebssysteme und Architekturen, also in diesem Fall ist es nicht unabhaengig... die Programme die ich in Perl schreiben kann, die sind nahezu unabhaengig, da hast du recht, aber nur weil Perl das kann ist es ja nun noch lange nicht ueberfluessig das java das auch kann... denn Java kann sachen die perl nicht so gut beherrscht (omg tut das weh sowas zu sagen :) ) z.B. 2D und 3D grafik, da ist das neue Java net schlecht drin.

Aber auch diese Diskussion ist mehr oder weniger ueberfluessig, genauso koennte man ja fragen warum gibts pyhton wenns perl gibt und warum tcl... aber das hat keinen sinn! Das ist alles Geschmackssache... was ich eigentlich mit der Verteidigung erreichen wollte ist, dass Java keine schlechte sprache ist, ich mag sie zwar net und oop kann ich wie unics schon sagte mit perl auch ganz toll erreichen!

ciao Exi
 
Naja, wie es aussieht werd ich wohl doch Java lernen müssen;
Für Kylix gibt es keine aktuellen Tutorials und für HBasic gibt es
keine deutschen Tutorials, denn HBasic ist noch nicht fertiggestellt.
 
sequel schrieb:
...Ich selber Programmiere Java nicht, weil ich es nicht mag. Ich sehe keinen sinn darin...
Erstens ist Java langsamer als C/C++, Portierbarkeit kann ich auch mit C machen indem ich mich einfach an Ansi halte, und ObjectOrientiert kann ich auch in C.
Es ist oft ein falsch denken, wenn man sagt das eine Sprache OO ist, wie z.b. Java oder C++. Eine Sprache kann höchstens hilfestellungen zur ObjectOrientierung geben. Aber OO Programmieren kann ich auch in C, Perl oder sonst was....

mfg manuel


Ich als eingefleischter C(++) Programmierer muss dich leider korrigieren. Wenn du ein Projekt hast, welches absolut plattformunabhängig laufen soll und eine GUI benötigt wird, dann ist JAVA 1. Wahl.

Natürlich muss einem klar sein, dass auch ein absolut optimiertes Java niemals an die Geschwindigkeit von C++ rankommt. Auch dürfte es klar sein, dass Java Programme grundsätzlich mehr Speicher benötigen als C++ Anwendungen.

Aber gerade im Bereich Portabilität, Netzwerkunterstützung usw ist Java nicht schlagbar.

Es ist also immer ein "Abwägen", welche Sprache für welches Projekt sinnvoller ist. Meiner Ansiicht nach sind C und JAVA derzeit die wichtigsten Sprachen. Wenn man C++ (also objektorientiert) programmiert, dann spricht eh nichts dagegen Java zu lernen. Der Umstieg ist sehr einfach.

Um mal kurz auf das eigentliche Thema zu kommen: Ich halte C auch geeignet für Einsteiger. Man kann sich mal auf der HP www.highscore.de umsehen, da gibts nen guten C++ als auch nen guten Java Kurs!!!

Fazit:

- C++ ist unschlagbar was Performance betrifft!
- Java ist unschlagbar was Portabilität betrifft!

Für Leute, die meinen, dass man alles was unter Java geht auch unter C geht mal folgendes Beispiel:

Ich schreibe in Java eine Client Server-Applikation.

Später soll es möglich sein, dass ein Client eine Schnittstelle hat, wo man eigenen Code einbinden kann, der aber auf dem Server ausgeführt wird.

Dank dem "Agentmodell" und dem Vorzug, dass der kompilierte Bytecode eben auf jeder Plattform läuft kann ich direkt eine Java-Klasse vom Client aus über die Leitung schicken und auf einem Server ausführen lassen, wo ich nichtmal das OS kennen muss.
 
Zuletzt bearbeitet:
Anakin77 schrieb:
Aber gerade im Bereich Portabilität, Netzwerkunterstützung usw ist Java nicht schlagbar.

lol, das kann ja nichtmal vernünftig auf UNIX Sockets zugreifen.

Anakin77 schrieb:
Wenn man C++ (also objektorientiert) programmiert, dann spricht eh nichts dagegen Java zu lernen.

Doch, denn Zeit ist Geld.
Und somit ist Zweitverschwendung auch Geldverschwendung.
Und Java zu lernen ist ersteres.

BTW: Ja, ich weiss wovon ich spreche.
Ich arbeite seit Beginn an einem 6-monatigen Java Projekt mit an dem auch noch 7 andere Leute werkeln.
Wir sind im 5ten Monat, ein Ende ist also (zumindest laut Plan) in Sicht :)

Anakin77 schrieb:
Fazit:
- C++ ist unschlagbar was Performance betrifft!
- Java ist unschlagbar was Portabilität betrifft!

C++ wird durch Assembler geschlagen.
Java durch Perl, Python, PHP, ANSI C und so weiter.


Anakin77 schrieb:
Dank dem "Agentmodell" und dem Vorzug, dass der kompilierte Bytecode eben auf jeder Plattform läuft kann ich direkt eine Java-Klasse vom Client aus über die Leitung schicken und auf einem Server ausführen lassen, wo ich nichtmal das OS kennen muss.

Bleibt nur noch die Frage wer solchen Weenie-kram braucht.
BTW: Mit Perl, Python, Ruby und so weiter ist der Quatsch auch möglich.
 
Zuletzt bearbeitet von einem Moderator:
ssc schrieb:
lol, das kann ja nichtmal vernünftig auf UNIX Sockets zugreifen....

hmm, es gibt ganze Firmen die mit so nem Müll Ihre Existenz rechtfertigen. Unter www.netphantom.de (bei der Firma arbeite ich als Informatiker) findest du einen Applicationserver der komplett in Java geschrieben ist.

Ein Blick auf unsere Referenzkundenliste verrät, dass er von IBM, der Deutschen Bank, Allianz, R+V Versicherung und anderen Größen eingesetzt wird.

Anwenderzahl > 100.000

Die meisten größeren Firmen benutzen IBM AIX oder SUN Solaris als Plattform. Aber wahrscheinlich hast du recht und Java kann gar nicht vernünftig auf UNIX Sockets zugreifen.

Auch wenn ich dir sagen muss, dass wir Kunden haben, die mit mehr als 10.000 Socketverbindungen pro Rechner gleichzeitig arbeiten.

ssc schrieb:
Bleibt nur noch die Frage wer solchen Weenie-kram braucht.
BTW: Mit Perl, Python, Ruby und so weiter ist der Quatsch auch möglich.

Wie oben erwähnt nutzt unser Produkt diese Möglichkeit. Das ermöglicht unseren Kunden unseren Client in ihr eigenes Java-Framework einzubauen. Gerade bei großen Firmen wird dieses Interface sehr oft verwendet!

Und auch wenn man diesen "Quatsch" auch mit was anderem machen könnte, er wurde mit 100% Java gemacht. Ich war übrigens kein Entwickler, da ich Java nur halbwegs kann. Ich bin wie gesagt ein reiner C++ Entwickler (naja und Perl und zig andere halt noch).
 
Anakin77 schrieb:
Ein Blick auf unsere Referenzkundenliste verrät, dass er von IBM, der Deutschen Bank, Allianz, R+V Versicherung und anderen Größen eingesetzt wird.
Das wird Minesweeper auch. Was willst du mir mit diesem Marketing-Gewäsch sagen?

Anakin77 schrieb:
Die meisten größeren Firmen benutzen IBM AIX oder SUN Solaris als Plattform. Aber wahrscheinlich hast du recht und Java kann gar nicht vernünftig auf UNIX Sockets zugreifen.

Klar, bei den Hardwareanforderungen, die selbst ein "Hello Word" stellt,
braucht man schon 'ne rel. grosse Firma mit dem entsprechendem Kapital...

Mit "nicht vernünftig" ist gemeint,
das man z.B. keine Sniffer in Pure-Java schreiben kann.
 
Zuletzt bearbeitet von einem Moderator:
Klar haben diese Firmen alle Minesweeper gekauft! :D Ich rede mit dem Marketinggewäsch doch nur um dir klar zu machen, dass Java eine Existenzberechtigung hat. Nur weil C++ schneller ist ist es eben nicht immer erste Wahl.

Und was hast du für ein Problem mit den Hardwareanforderungen?

Du wetterst doch nur allgemein gegen Java ohne überhaupt die Praxis beurteilen zu können. Unser Applikationsserver bekommt auf ner Windoof Kiste mit Dual-Xeon Prozis plus 2 GB Ram durchaus 5.000 gleichzeitige Userconnections auf die Reihe.

Auf nem großen AIX Server (Fire 10k oder Fire 15k) kann man schon auf mehr als 10-20 Tausend User kommen.

Sicherlich werden große Firmen (> 10.000 Angestellte sprich potentielle User) dann wohl eher alles in C++ neu programmieren (es handelt sich ja nur um eine Portierung von einigen Millionen Zeilen Code), da ja die Hardwareanforderungen viel zu hoch sind.

Und komischerweise war der Trend aber ein anderer. Denn es gab früher (und gibt heute noch) ein Vorgängerprodukt, welches komplett in C++ geschrieben war.

We auch immer: Java ist zu langsam und man kann es sicher nicht einsetzen, da sich mit einem Windows Server ja beispielsweise "nur" 5000 gleichzeitige User bedienen lassen können.

Bevor so ne Firma lieber mal zwei Server aufstellt, werden die wohl eher ne Neuentwicklung mit mehr als einem Mannjahr Arbeit bestellen denke ich.

Sag mal bist du noch Student weil du von der Realität so wenig weisst? Du kannst sicher in deiner CCC-Hackerwelt glücklich werden, aber du behinderst eben deinen beruflichen Erfolg, wenn du dich bestimmten Techniken verschließt, nur weil sie in Hackerkreisen eventuell nicht ankommen. Es ist mir klar, dass man Exploits, Sniffer und ähnliches immer in C schreiben wird. Nur wie will jemand damit sein Geld verdienen?

Aber ist dir nicht bewusst wie viele Firmen derzeit Java als Programmiersprache einsetzen? Ich bin beispielsweise derzeit gerade in Diskussionen mit einer Abteilung bei Schwäbisch Hall. Dort geht es um die Folgen Ihrer Entscheidung, komplett auf ein Javaframework zu gehen (für Ihre Sachbearbeiter). Derzeit sind Performancetests das große Thema, weil eben Java durch schlechtere Performance "glänzt". Die Frage ist hier jedoch, ob die Vorteile überwiegen oder eher die Nachteile. Auf jeden Fall steht dort die Entscheidung auf Java zu gehen. Es hat uns eine nette 6-stellige Summe gebracht für die entsprechenden Lizenzen. Von den reinen Servicegebühren kann ein halber Mitarbeiter bezahlt werden. Bei uns hängt die ganze Firma plus unsere "Muttergeseschaft" in Schweden von unserem Applicationserver ab, der in 100% pure Java geschrieben ist. Trotz der wirtschaftlichen Lage haben wir uns in den letzten Jahren eher vergrößert und sind sogar zu einem Ausbildungsbetrieb (Fachinformatiker) geworden. Also irgendwer wird das ganze wohl kaufen und finanzieren obwohl Java verwendet wurde.

Aber eventuell haben ja die Entscheider so wenig Ahnung, weil sie keine so fähigen Berater wie Dich hatten. Eventuell wäre das ganze niemals zustande gekommen, wenn eine solche "Weitsicht" bei unseren Kunden vorhanden wäre. Eventuell vergisst man dabei aber, dass es sich bei den meisten Kunden um eine "Win-Win" Situation handelt.

Ein Tipp: Lies doch mal Stellenanzeigen in größeren Zeitschriften oder in online Jobbörsen. Klar werden viele C++ Entwickler gesucht. Aber woher kommen denn die vielen Angebote für JAVA-Profis?

Ich hoffe es macht irgendwann mal "klick".

Und wie gesagt, klar werden Sniffer besser in C(++) programmiert. Ich würde dafür auch kein Java nehmen. Nur deshalb Java komplett zu verurteilen ist sehr kurzsichtig!

Solche ideologischen Diskussionen mögen fürs Ego gut sein, für das berufliche Weiterkommen ist eine solche Haltung jedoch absolut Gift. Aber wer will das schon???

Und man kann eben nicht alles so einfach portabel machen, nur indem man Ansi-C verwendet. Programmiere doch mal ne GUI mit einigen hundert Fenstern und Dialogen in C für Windows, OS/2, Linux, Solaris, AIX usw. Dies ist in Java sehr viel einfacher. Ein Bytecode der überall läuft fertig! In C muss man einiges betriebssystemspezifisch "basteln". Das kostet massig Zeit und Geld!
 
Zuletzt bearbeitet:
Du kennst wohl auch nur C und Java.
Mit Perl, Python usw sind GUIs dank Binding für QT, TK, GTK und/oder WxWindows ohne weiteres möglich.

Und da die JVM mehr oder weniger ein zweites OS ist, könnte man gleich den unportabelsten C Code den man sich vorstellen kann im VMWare laufen lassen.

Kurzum: Ich weiss das man mit Java (mehr schlecht als recht) GUIs zusammenschustern kann, die unter ein paar auserlesenen OSen lauffähig sind.
Das ist einer der Hauptgründe für diesen Hype.

Zum Thema Frameworks.
In den meisten mir bekannten Firmen wird mit nahezu nicht dokumentierten Frameworks gearbeitet.
Die Programmierer der Frameworks sind allerdings meist schonn woanders angestellt.
Da die eigentlichen Programmierer (des Frameworks) schon woanders sind, wird das Framework nicht optimal eingesetzt und fürchterliches Flickwerk ensteht.
Da werden Wrapper ohne Ende geschrieben,
Um wenn diese mal ihren Weg in's Framework gefunden haben, werden sie auch früher oder später mit anderen Wrappern versehen.
Das ganze kann man beliebig oft fortsetzen,
bis auch das letzte bisschen CPU-Zeit durch konsequentes Wrappen verbraucht wird.

Zum Thema Java und CCC.
Wenn du auf dem letzten Congress gewesen wärst,
würdest du wissen, das es durchaus einige Leute im CCC gibt, die dem Java Hype verfallen sind.

Ich verstehe übrigends nicht warum sich jemand einen Application-Server kauft, wenn es den auch kostenlos gibt. (bekanntestes Beispiel dürfte der JBoss sein)

Eine andere Sache, die mich an Java stört,
ist das es mehr als oft völlig unsinnig eingesetzt wird.
Wir beide wissen das Java nicht grad die schnellste Sprache ist, dennoch wird es in Bereichen wo Performance zählt, vie z.B. dem Sun-Compiler/interpreter verwendet.


Ich versteh nicht wozu man Java braucht.
Perl kann was Java kann - nur schneller und auf mehr Plattformen.


Zum Schluss noch drei nette Quotes:
"Perl -- It's like Java, only it lets you deliver
on time and under budget."
"The JVM is just another plattform where Perl has to be ported to."
"Java? I've heard of it, it is what I drink while hacking Perl!"
 
Zuletzt bearbeitet von einem Moderator:
Kurze Frage am Rande:
versucht die JVM immer noch krampfhaft, nen Mikroprozessor zu emulieren oder ist man so schlau gewesen, den Befehlssatz auch um brauchbare, oft verwendete Bytecodes für regexp-matching usw zu erweitern?
 
Zum Applicationserver:

NetPhantom (NP) ist eben weit mehr als nur das. Es ist quasi ein Server, der im einfachsten Fall Host2Web kann. Er hält Verbindungen zu einem Mainframe (3270) und Javaclients können sich dann mit dem NP-Server verbinden. Damit kann man schon mal auf die gute alte 3270-Emulation verzichten.

Dies alleine ist schonmal ein Kostenfaktor, da viele Firmen für die Emulationssoftware durchaus 50 Euro pro Jahr und Arbeitsplatz bezahlen inkl. Support. Bei 5000 Arbeitsplätzen kommt da gut was zusammen.

Aber neben einer normalen Verbindung kann man mit dem Applicationserver eben auch grafische Benutzeroberflächen gestalten, die quasi als Zwischenschicht zwischen der zeichenorientierten Oberfläche und dem Anwender geschaltet werden. Idealerweise mekrt der Anwender nichtmal, dass er mit einem 3270 Mainframe arbeitet, da der Client sich wie eine Windows (X-Windows) Applikation verhält.

Hier kommen dann die erwähnten Exits zum tragen, denn viele Firmen integrieren dadurch alte Hostanwendungen in ein modernes Umfeld.


Ein Beispiel aus der Praxis:

Ein Mitarbeiter einer gro0ßen Versicherung kommt morgens in sein Büro.

Nachdem er sich angemeldet hat, erscheinen auf seinem Bildschirm alle Briefe, die eingegangen (und automatisch elektronisch gescannt) wurden. Hier wurde automatisch die Vertragsnummer extrahiert durch eine intelligente Dokumentenmanagementsoftware.

Die Nummer wird an andere Applikationen weitergegeben (eventuell auch Mainframe) um gleichzeitig alle Vertragsdaten zu diesem Brief in einem anderen Fenster sichtbar zu haben.

Dies alles passiert in einem Java-Framework, wo die Hostapplikation (mit unseren NP-Server), das Dokumentenmanagement und eventuell noch eine gewöhnliche PC-Applikation zusammengefasst wurden.

Bei dieser Versicherung macht es den Eindruck, dass der Mitarbeiter nur mit einer Anwendung arbeitet. In Wirklichkeit hat er einen dreigeteilten Bildschirm und er arbeitet mit drei Anwendungen die nur einem gemeinsamen Rahmen liegen und sich per Datenaustausch synchronisieren. Auch ein mit Word verfasstes Antwortschreiben wird automatisch versand und dem Dokumentenmangement zugeführt, da auch hier eine Integration in das Framework vorhanden ist.

Für solche Projekte werden 7stellige Summen ausgegeben, weil danach erfahrungsgemäß mehr Schadensfälle pro Mitarbeiter bearbeitet werden können.

Ähnliche Projekte haben viele Firmen derzeit laufen, die sich im Versicherungs- und Bankenumfeld bewegen. Java ist dort eben der kleinste gemeinsame Nenner. Damit meine ich vor allem die ganz großen Firmen. Wenn du auf unserer Seite die Referenzkundenliste gesehen haben solltest, dann weisst du wovon ich spreche.

Ich kann dir aber insoweit recht geben, dass ich persönlich lieber in C programmiere, wenn ich was Kleineres oder was sehr schnelles benötige.

Im Übrigen bin ich ein Assemblerfreak und kann (gezwungenermassen) aber auch Cobol und Fortran 77 (das ist wohl bedeutungslos geworden für mich). Auch Perl ist nicht ganz unbekannt, aber viel mehr als einen Einführungskurs habe ich bisher nicht gemacht.
 
Zuletzt bearbeitet:
@foobarflu:

Der Bytecode wird weiterhin so allgemein wie möglich gehalten. Natürlich versucht die JVM durch Precompile beim ersten Laden, die reine Ausführungszeit zu vermindern und gewisse Optimierungen für die gerade verwendete Plattform hinzubekommen.

Dies gelingt eben nur bedingt und damit ist und bleibt Java deutlich langsamer als eine echte Compilersprache.

@alle

Dieser Nachteil ist nicht wegzudiskutieren. Und Anfangs dachte man vielleicht, dass sich Java aus diesem Grund nicht durchsetzen wird. Bei uns gibt es aber Fachabteilungen von Kunden, die beispielsweise gerne auf Java verzichtet hätten aufgrund der Nachteile und eventuell auch Vorlieben der Entwickler. Nur teilweise werden solche strategischen Entscheidungen eben auch getroffen, ohne, dass die Fachabteilung anfangs mit sowas glücklich ist.

Im Bankensektor gibt es beispielsweise noch öfters das gute alte OS/2. In den letzten Jahren haben viele Firmen Migrationsprojekte aufgesetzt um andere Betriebssysteme zu verwendet. Wenn sich dann beispielsweise solche Projekte mit Neuentwicklungen überschneiden (und eventuell noch nichtmal die Entscheidung vorliegt, ob man normale Windows Fat Clients, Windows Terminal Server, Linux oder gar NCs verwenden wird), dann haben vorsichtige Manager schonmal entschieden Java zu verwenden, da für Neuentwicklung unter Java das Zielbetriebssystem relativ egal ist. Natürlich gibt es auch da Fehlentscheidungen und gescheiterte Projekte. Eventuell einfach auch aus dem Grund, dass die Akzeptanz beim User nicht da war, da die Performance trotz neuerer Rechnergeneration geringer wurde. Wer aber diese Probleme kennt und im Vorfeld analysiert, kann solche Fehlentscheidungen sicher ausschließen.

Es handelt sich im Übrigen nicht nur um eine Handvoll Betriebssysteme, wo Java vernünftig läuft. Unsere Software wird auf den unterschiedlichsten Plattformen eingesetzt. In der Regel ist der Serverteil auf einer UNIX-Plattform und die Clients sind Windoof-Kisten. Aber es gibt auch alle möglichen anderen Varianten.

Einzig auf Linux gibt es wegen dem nicht so günstigen Threadmanagement noch Probleme für einen Servereinsatz, die sich durch den Kernel 2.6 wohl inzwischen gelöst haben.
 
Zuletzt bearbeitet:
Zurück
Oben