SELFHTML als chm-Datei (compiled HTML-Windows-Hilfe)

[Stefan Muenz]

Liebe Forumer,

auch wenn noch so viel gegen Windows gewettert wird: noch arbeitet die Mehrzahl der User mit diesem System. Und es gibt auch durchaus ein paar ganz praktische Dinge bei Windows. Dazu gehoeren unter anderem die chm-Dateien, das Format der Windows-Hilfe seit Windows 98 bzw. seit Internet-Explorer 4.x oder hoeher.

SELFHTML ist ein dankbarer Kandidat fuer den HTML-Help-Compiler, der aus solchen Dokumenten chm-Dateien machen kann. Und so war es ja eigentlich nur eine Frage der Zeit, bis auch SELFHTML 8.0 in diesem Format vorliegen wuerde. Wolfgang Reszel (http://www.rumborak.de/) hat ganze Arbeit geleistet und eine chm-Version erstellt, die SELFHTML 8.0 inklusive Errata und mit allen chm-typischen Navigations-Features enthaelt.

Wer es selber mal ausprobieren will, geht auf http://aktuell.de.selfhtml.org/extras/selfchm.htm. Dort kann man die chm-Version downloaden.

viele Gruesse
  Stefan Muenz

[Bio]

Sup!

Was sind denn die grossartigen Features von CHM, die mir bisher völlig entgangen sind, die rechtfertigen, Selfhtml in einem proprietaeren Windows-Format anzubieten?
(Man mag darueber streiten, ob man sich dafuer rechtfertigen muss - ich finde aber: ja)

Gruesse,

Bio

[Harry]

Sup!

pentopf !

Was sind denn die grossartigen Features von CHM, die mir bisher völlig entgangen sind, die rechtfertigen, Selfhtml in einem proprietaeren Windows-Format anzubieten?
(Man mag darueber streiten, ob man sich dafuer rechtfertigen muss - ich finde aber: ja)

-Volltextsuche
-Schönes Inhaltsverzeichnis
-Alles in einer Datei ohne nervende aus- und einpack-Sachen

Vielleicht solltest Du Dir ja wirklich mal http://aktuell.de.selfhtml.org/extras/selfchm.htm zu Gemüte führen.

Ist es Deiner Meinung nach dann gerechtfertigt, ein sinnvolles zugegebnermaßen proprietäres Format nicht zu verwenden, nur weil "bloß" 90% der Benutzer es auch verwenden können (jaja, die viel gebeutelte und geschimpfte Randgruppe der Windows-Nutzer), wohingegen die anderen 10% immer noch auf das sonst ebenso hervorragende Dokument im HTML-Format zurückgreifen können ?

Ciao,

Harry
 (Verteidiger sinnvoller Erfindungen wider der Sturheit ehemaliger Netsi-Ritter)

[Christoph Schnauß]

hallo  Bio,

Was sind denn die grossartigen Features von CHM, die mir bisher völlig entgangen sind, die rechtfertigen, Selfhtml in einem proprietaeren Windows-Format anzubieten?

ist zwar schon etwas älter, aber unter http://forum.de.selfhtml.org/archiv/1999_1/t01633.htm#a7002 kannst du bissel was nachlesen dazu. Leider sind die angegebenen links zum download des Help-Compilers nicht mehr ganz aktuell

(Man mag darueber streiten, ob man sich dafuer rechtfertigen muss - ich finde aber: ja)

ich finde: nein. Eine "Rechtfertigung" ist in diesem Fall nicht nötig, eine kurze Erklärung, die meines Erachtens gegeben worden ist, ist allerdings hilfreich.

Ich habe schon eine ganze Weile gern mit diesem Compiler gearbeitet, das Konzept hat sich gerade für Unterrichtszwecke bestens bewährt. Allerdings hätte ich mich an so ein Riesending wie SelfHTML nicht herangewagt, das ist eine immense Tipparbeit.

Im übrigen kann man die chm-Dateien auch wieder auspacken und hat dann alle ursprünglichen HTML-Dokumente hübsch einzeln wieder.

Grüße aus Berlin

Christoph S.

Gruesse,

Bio

[Wilhelm]

Hi

Was sind denn die grossartigen Features von CHM, die mir bisher völlig entgangen sind,

uebersichtlich und leicht bedienbar. Man verlaeuft sich nicht so oft wie bei der HTML-Version, da der Navibaum immer da ist.

(Man mag darueber streiten, ob man sich dafuer rechtfertigen muss - ich finde aber: ja)

Da liegst Du voellig falsch.

<bewusst ohne ;-)>

Dein Kampf gegen MS in allen Ehren, aber sorry, es hat Dich einen Dreck zu interessieren, wenn ein User dieses Forums fuer Windows-User eine .chm erstellt und dieses Teil zum Download angeboten wird. In welcher Welt lebst Du denn.

Niemand zwingt Dich, das Teil zu nutzen.

Schoen langsam uebertreibst Du in Deine Aeusserungen masslos, Deine Einstellung ist schon fast paranoid.

</bewusst ohne ;-)>

Ich fuer meinen Teil werde unter Windoof mit der .chm arbeiten, fuer die RS/6000 habe ich ja noch immer die HTML-Version.

Wilhelm

BTW: Das properitaere Solaris ist auch nicht immer das Mass aller Dinge. Kann man fast mit AIX vergleichen. Koecheln brav die eigene Suppe :-)

[Bio]

Sup!

Dein Kampf gegen MS in allen Ehren, aber sorry, es hat Dich einen Dreck zu interessieren, wenn ein User dieses Forums fuer Windows-User eine .chm erstellt und dieses Teil zum Download angeboten wird. In welcher Welt lebst Du denn.

Ehmm... in "Der besten aller denkbaren Welten", denke ich ;-)

Niemand zwingt Dich, das Teil zu nutzen.

Wirklich? "Sie" haben ja sogar schon Bielefeld erfunden - wer weiss, was "sie" als naechstes tun...

Schoen langsam uebertreibst Du in Deine Aeusserungen masslos, Deine Einstellung ist schon fast paranoid.

Och. Ich habe einfach keine Lust, "objektiv" mit irgendwelchen Windoze-Freaks zu diskutieren. Wenn man das Problem von der Anwender-Ebene sieht, dann hat Windoze natuerlich jede Menge Vorteile, aber wenn man den groesseren Zusammenhang der Monopolstellung von M$ sieht, dann spielen diese Dinge keine Rolle.
Ich will halt gern eine Welt ohne Software von M$, und agitiere gerne gegen diese sehr innovative Firma, die tolle Produkte herstellt.

Ich fuer meinen Teil werde unter Windoof mit der .chm arbeiten, fuer die RS/6000 habe ich ja noch immer die HTML-Version.

Es waere aber doch moeglich gewesen, einen OS-unabhaengigen Viewer in Java mit Volltextsuche zu schreiben, der die Dokumentstruktur anhand der LINK-Elemente erkennt (falls Selfhtml8 die hat - weiss gerade nicht so genau).
Wie auch immer, bei der recht klaren Struktur von Selfhtml finde ich so Scuhhilfen gar nicht so ultra-praktisch, und wenn ich Selfhtml durchsuchen wollte, dann wuerde ich eben lokal htdig drauf ansetzen.

Ich finde es halt nicht gut, dass jetzt moeglicherweise irgendein Idiot herkommen koennte und sagen: "Unter Windows kann ich Selfhtml viel besser lesen, da gibt's das als .chm, da ist alles viel einfacher, unter Linux waere das vieeel zu kompliziert, bla bla bla."
Man koennte sagen: Ich goenne den Windoze-Nutzern das .chm einfach nicht! Ich gebe es zu!

BTW: Das properitaere Solaris ist auch nicht immer das Mass aller Dinge. Kann man fast mit AIX vergleichen. Koecheln brav die eigene Suppe :-)

Erzaehl das mal XWolf, der Solaris fuer die ultima ratio haelt ;-)

Gruesse,

Bio

[Wilhelm]

Hi Bio

Wirklich? "Sie" haben ja sogar schon Bielefeld erfunden - wer weiss, was "sie" als naechstes tun...

Mir fehlt da zwar der Zusammenhang, aber ich finde Bielefeld fast noch abartiger als Altoetting. :-)

Och. Ich habe einfach keine Lust, "objektiv" mit irgendwelchen Windoze-Freaks zu diskutieren.

In Anbetracht der kuerzeren Lebensdauer von Maennern gegenueber Frauen habe ich mir das schon lange angewoehnt. Ich bin in einem Alter, da darf man sich nicht mehr so aufregen. ;-)

Ich will halt gern eine Welt ohne Software von M$, und agitiere gerne gegen diese sehr innovative Firma, die tolle Produkte herstellt.

Dagegen ist nichts einzuwenden, aber man sollte die Relationen im Auge behalten. So ein kleines Prograemmchen staerkt mit Sicherheit nicht die Monopolmacht von MS.

Ich fuer meinen Teil werde unter Windoof mit der .chm arbeiten, fuer die RS/6000 habe ich ja noch immer die HTML-Version.

Es waere aber doch moeglich gewesen, einen OS-unabhaengigen Viewer in Java mit Volltextsuche zu schreiben, der die Dokumentstruktur anhand der LINK-Elemente erkennt (falls Selfhtml8 die hat - weiss gerade nicht so genau).

Bleibe mir mit JAVA vom Hals. (oder hoere ich hier ein Faible fuer SUN heraus).

Ich finde es halt nicht gut, dass jetzt moeglicherweise irgendein Idiot herkommen koennte und sagen: "Unter Windows kann ich Selfhtml viel besser lesen, da gibt's das als .chm, da ist alles viel einfacher, unter Linux waere das vieeel zu kompliziert, bla bla bla."

Wenn jemand mit solch einer Argumentation kommt, kriegt er von mir den "Dummlaber des Monats" und eine Kiste mit alten Tomaten aus dem Grossmarkt. Den "Moin Swen :-)" des Tages kriegt er auch noch dazu.:-)

@stonie: ja:ich brachte es ueber die Lippen.

Man koennte sagen: Ich goenne den Windoze-Nutzern das .chm einfach nicht! Ich gebe es zu!

So kleinkariert? alà "Da Nachbar hat ein neues Spielzeug raaabaaaeeehhh!"

Erzaehl das mal XWolf, der Solaris fuer die ultima ratio haelt ;-)

Fein fuer ihn. Selbiges koennte ich von AIX sagen (obwohl: boese IBM)

Gruesse
Wilhelm

der CDE immer noch besser findet als KDE und Gnome zusammen.

[Martin Jung]

Hi,

Bleibe mir mit JAVA vom Hals. (oder hoere ich hier ein Faible fuer SUN heraus).

Wieso?

Viele Grüße,
Martin

[Wilhelm]

Hi,

Bleibe mir mit JAVA vom Hals. (oder hoere ich hier ein Faible fuer SUN heraus).
Wieso?

Einfach so. :-)

Wurde ja mal als eierlegende Wollmilchsau bejubelt. Aber die Praxis sieht leider etwas anders aus.

Beispiel:
IBM hatte frueher einen Systemkonfigurator fuer S/390 und AS/400. Das Teil hatte laeppische 12MB und war nett und handlich.
Jetzt ist man nur noch hip und bietet das Teil nur noch als Java-Programm fuer Browser an. Die Groesse hat sich auf (je nach Umfang) auf mindestens 180MB erweitert.
Und jetzt versuch mal, mit dem Ding vernuenftig auf einem PII zu arbeiten.
Pustekuchen, ein PIII mit mind. 800MHz und 256MB Speicher sollten schon sein. Von einer Netzwerk-Installation ist abzuraten, da bei mehreren Benutzern der Laden dicht ist. (Nicht jeder hat Glasfaser)

Noch Fragen?

Gruesse
Wilhelm

[code2i]

Hi,

Bleibe mir mit JAVA vom Hals. (oder hoere ich hier ein Faible fuer SUN heraus).
Wieso?

Einfach so. :-)

Wurde ja mal als eierlegende Wollmilchsau bejubelt. Aber die Praxis sieht leider etwas anders aus.

Beispiel:
IBM hatte frueher einen Systemkonfigurator fuer S/390 und AS/400. Das Teil hatte laeppische 12MB und war nett und handlich.
Jetzt ist man nur noch hip und bietet das Teil nur noch als Java-Programm fuer Browser an. Die Groesse hat sich auf (je nach Umfang) auf mindestens 180MB erweitert.

Hmmm glaube kaum das der Sprung von 12 auf 180MB nur wenn überhaubt an Java liegt !

Und jetzt versuch mal, mit dem Ding vernuenftig auf einem PII zu arbeiten.
Pustekuchen, ein PIII mit mind. 800MHz und 256MB Speicher sollten schon sein. Von einer Netzwerk-Installation ist abzuraten, da bei mehreren Benutzern der Laden dicht ist. (Nicht jeder hat Glasfaser)

Ich glaube das ist ein denkbar schlechtes Beispiel für den Wiederspruch zu Java weil es irgendwie nix mit Java zutun hat. Und ich glaube kaum das IBM sich für einen Rückschritt entschieden hatte.

Naja ...bis dann

cu code2i

[Wilhelm]

Hi

Hmmm glaube kaum das der Sprung von 12 auf 180MB nur wenn überhaubt an Java liegt !

Wenn Du meinst. ;-)
Ich kenne den Funktionsumfang der alten und der neuen Version. Die Erweiterungen wuerden den Sprung niocht rechtfertigen. Also muss es wohl an der Plattform liegen.

Wenn Du noch die Konstruktionszeichnungen dazu nimmst, wird es noch ein "wenig" mehr.

Ich glaube das ist ein denkbar schlechtes Beispiel für den Wiederspruch zu Java weil es irgendwie nix mit Java zutun hat.

Aha, womit dann?

<fillout>
[] ich kenne das Programm
[] ich kenne das Programm nicht

</fillout>

Und ich glaube kaum das IBM sich für einen Rückschritt entschieden hatte.

Technologischer "Fortschritt" != praktischer Fortschritt.

Wenn ein Vertriebsmensch am Telefon mit einem Kunden eine Maschine konfiguriert, kommt auch noch der Faktor Zeit hinzu. Denn durch ueberfluessige Sperenzchen und Ladezeit dauert alles ein bisschen laenger.

Gruesse
Wilhelm

[code2i]

Hallo

Hmmm glaube kaum das der Sprung von 12 auf 180MB nur wenn überhaubt an Java liegt !

Wenn Du meinst. ;-)
Ich kenne den Funktionsumfang der alten und der neuen Version. Die Erweiterungen wuerden den Sprung niocht rechtfertigen. Also muss es wohl an der Plattform liegen.

Hmmm ... ich finde diesen gewaltigen Unterschied 12 zu 180 sehr merkwürdig. Denn normalerweise sind in Java geschriebene Programme meist deutlich kleiner. Kann ja auch sein das IBM da in der Konstruktion des Programms mächtig Mist gemacht hat.

Ich glaube das ist ein denkbar schlechtes Beispiel für den Wiederspruch zu Java weil es irgendwie nix mit Java zutun hat.

Aha, womit dann?

Ich meinte das dieses Programm eher eine Außnahme darstellt um C und Java Programme im Umfang zu beschreiben.... wie gesagt... eigentlich ist es anders herum. Erklären lässt sich das ganze wenn hier "Objektorientiertes Programmieren" völlig vernachlässigt wurde. Dann allerdings nicht mit diesem Faktor. Wohlmöglich hat man auch noch den SourceCode mit reingepackt..... ?

<fillout>
[] ich kenne das Programm
[x] ich kenne das Programm nicht

</fillout>

Und ich glaube kaum das IBM sich für einen Rückschritt entschieden hatte.

Ohhh sorry ... hab nicht genau nachgedacht... klar kann das bei Big Blue vorkommen.

Technologischer "Fortschritt" != praktischer Fortschritt.

Wenn ein Vertriebsmensch am Telefon mit einem Kunden eine Maschine konfiguriert, kommt auch noch der Faktor Zeit hinzu. Denn durch ueberfluessige Sperenzchen und Ladezeit dauert alles ein bisschen laenger.

Jo ...sehe ich auch so !!! Deswegen hatte man eigentlich Java entwickelt!!!

Ich sag nur noch (wunder wunder ....)

cu ;-)

[Martin Jung]

Ho,

Beispiel:
IBM hatte frueher einen Systemkonfigurator fuer S/390 und AS/400. Das Teil hatte laeppische 12MB und war nett und handlich.
Jetzt ist man nur noch hip und bietet das Teil nur noch als Java-Programm fuer Browser an. Die Groesse hat sich auf (je nach Umfang) auf mindestens 180MB erweitert.

ach so ;-))
Mit solchen "Tools" durfte ich auch schon arbeiten. Sieht nach mittelmäßiger Implementierung aus...

Noch Fragen?

Nö.

Aber vielleicht eine Gegenthese: mit JAVA lassen sich durchaus performante _und_ komplexe Anwendungen realisieren(http://www.eclipse.org).

Viele Grüße,
Martin

PS: Was mir gerade auffällt. Ein Systemkonfigurator für S/390 und AS/400 hat doch sinnvollerweise nur _zwei_ Zielplattformen, nämlich S/390 und AS/400, oder? Eigentlich also wäre die durch JAVA mögliche "Plattformunabhängigkeit" doch in diesen Ausmaßen gar nicht notwendig?

[Christian Kruse]

Hoi,

Bleibe mir mit JAVA vom Hals. (oder hoere ich hier ein Faible fuer SUN heraus).
Wieso?

Inkonsistent, langsam und nicht Standardtisiert.

Gruesse,
 CK

[Slyh]

Hi,

Bleibe mir mit JAVA vom Hals. (oder hoere ich hier ein Faible fuer SUN heraus).
Wieso?

Inkonsistent,

Ja, an ein paar Stellen. Na und?

langsam

Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt nicht _langsam_!

nicht Standardtisiert.

Äh, und?

Aber ich denke, das Thema hatten wir schon...

Gruß
Slyh

[Christian Kruse]

Hallo,

Inkonsistent,

Ja, an ein paar Stellen. Na und?

Wenn du das magst....

langsam

Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt
nicht _langsam_!

Doch.

nicht Standardtisiert.

Äh, und?

Ich finds schon krank, dass eine Firma mal eben so mir nichts, dir nichts die
APIs aendern kann.

Aber ich denke, das Thema hatten wir schon...

Ja. Und es wurde kein vernuenftiges Argument fuer Java gebracht.

Gruesse,
 CK

[Slyh]

Hallo,

Inkonsistent,

Ja, an ein paar Stellen. Na und?

Wenn du das magst....

Ich mag das auch nicht. Jedoch sehe ich das ganz so realistisch, daß
meiner Meinung nach durch ein paar kleinere Ungereimtheiten nicht
gleich die ganze Sprache schlecht wird. Auch bei Sun werden Fehler
gemacht. Leider lassen sich die Fehler nicht so leicht ausbügeln,
sollen auch noch alte Java-Programme auf den neueren Versionen der
API laufen.

Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt
nicht _langsam_!

Doch.

Ach? Beispiele? (Sag jetzt nicht Swing. Das ist bekannt. Hat sich aber
schon sehr verbessert... und ist soooo langsam nun auch nicht.)

Ich finds schon krank, dass eine Firma mal eben so mir nichts, dir nichts die
APIs aendern kann.

Da sehe ich dein Problem nicht. Die Firma hat die API geschrieben,
die Firma darf die API verändern. Was ist schlecht daran die API
zu ändern?
Du könntest wirklich ein bißchen genauer werden. (Auch wenn du
vermutlich die Diskussion leid bist.)

Aber ich denke, das Thema hatten wir schon...

Ja. Und es wurde kein vernuenftiges Argument fuer Java gebracht.

Java ist plattformunabhängig.
Java ist mächtig.
Java ist einfach.
Die Java-API ist seeeehr umfangreich.
Java läuft sogar im Browser (hehe)
Java ist sicher.
Java wird immer umfangreicher und besser und schneller.

Deine Gegenargumente kenne ich noch. Im großen und ganzen hattest du
recht. Aber - wie ich schon sagte - kleinere Fehler machen die
Sprache nicht unbedingt schlechter. Es sind ja keine Sachen, die man
nicht leicht umgehen könnte...

Gruß
Slyh

[Christian Kruse]

Hallo,

Inkonsistent,

Ja, an ein paar Stellen. Na und?

Wenn du das magst....

Ich mag das auch nicht. Jedoch sehe ich das ganz so realistisch, daß
meiner Meinung nach durch ein paar kleinere Ungereimtheiten nicht
gleich die ganze Sprache schlecht wird. Auch bei Sun werden Fehler
gemacht. Leider lassen sich die Fehler nicht so leicht ausbügeln,
sollen auch noch alte Java-Programme auf den neueren Versionen der
API laufen.

StringBuffer war nicht das einzige Beispiel. Derartige Schnitzer sind schlicht
und ergreifend ein Indiz fuer ein fehlerhaftes Konzept. Bei Java muss man
viel auswendig lernen.

Weisst du ueberigens, wofuer Java urspruenglich geschrieben wurde? Fuer
Kaffee-Maschinen (daher der Name), Waschmaschinen, etc.

Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt
nicht _langsam_!

Doch.

Ach? Beispiele? (Sag jetzt nicht Swing. Das ist bekannt. Hat sich aber
schon sehr verbessert... und ist soooo langsam nun auch nicht.)

Ein beliebiger Java-Editor. Nimm JBuilder, nimm JEdit, egal.

Ich finds schon krank, dass eine Firma mal eben so mir nichts, dir
nichts die APIs aendern kann.

Da sehe ich dein Problem nicht. Die Firma hat die API geschrieben,
die Firma darf die API verändern. Was ist schlecht daran die API
zu ändern?

Eine API legt man einmal fest und schreibt dann hoechstens Erweiterungen.
Ich hab nicht unbedingt die groesste Lust, alles neu schreiben zu muessen.

Du könntest wirklich ein bißchen genauer werden. (Auch wenn du
vermutlich die Diskussion leid bist.)

Noe, werd ich nicht. Weil dann wieder eine sinnlose Diskussion ausbricht. Und
da habe ich in der Tat keine Lust mehr drauf.

Aber ich denke, das Thema hatten wir schon...

Ja. Und es wurde kein vernuenftiges Argument fuer Java gebracht.

Java ist plattformunabhängig.

Perl auch.

Java ist mächtig.

Das wage ich zu bezweifeln, aber Perl auch.

Java ist einfach.

Perl auch.

Die Java-API ist seeeehr umfangreich.

Man mag das sehen wie man will -- fuer mich ist das nicht unbedingt immer
ein Vorteil. Aber die von Perl ist es auch.

Java läuft sogar im Browser (hehe)

Perl auch.

Java ist sicher.

Wie soll eine Sprache sicher sein?

Java wird immer umfangreicher und besser und schneller.

Umfangreicher: ja. Schneller: naja, langsam. Besser: Geschmack- und
Definitions-Sache.

Deine Gegenargumente kenne ich noch. Im großen und ganzen hattest du
recht. Aber - wie ich schon sagte - kleinere Fehler machen die
Sprache nicht unbedingt schlechter.

Wenn es denn kleinere Fehler waeren.

Es sind ja keine Sachen, die man nicht leicht umgehen könnte...

Wenn du das sagst.

Ich sags mal ganz klar und deutlich: ich mag Java nicht. Ich halte Java fuer
umstaendlich, wenig kompfortabel, langsam und inkonsistent. Daran wirst du so
einfach nicht ruetteln koennen, denn ich habe es oft genug selber miterlebt
und erlebe es noch mit (ich muss fuer Lotus Domino 6 entwickeln).
Und Lust auf eine weitere Diskussion habe ich auch nicht. Martin hat mich nach
Gruenden gefragt, warum wir (bzw. Wilhelm) Java ablehnen. Ich habe sie
genannt. Wenn du es anders siehst -- bitte schoen, von mir aus.

Gruesse,
 CK

[Slyh]

Hallo,

StringBuffer war nicht das einzige Beispiel. Derartige Schnitzer sind schlicht
und ergreifend ein Indiz fuer ein fehlerhaftes Konzept. Bei Java muss man
viel auswendig lernen.

Nein. Das Konzept von Java ist klar und gut durchdacht. Leider haben
sich die Programmierer an manchen Stellen nicht ans Konzept gehalten.

Weisst du ueberigens, wofuer Java urspruenglich geschrieben wurde? Fuer
Kaffee-Maschinen (daher der Name), Waschmaschinen, etc.

Nein, das war nur ein mögliches Anwendungsgebiet. Da Java plattform-
neutral ist, kann es auch in Kaffee-Maschinen eingesetzt werden.
Es war nie die Rede davon, daß es nicht auf z.B. PCs laufen soll. Das
ist also kein Argument.

Ach? Beispiele? (Sag jetzt nicht Swing. Das ist bekannt. Hat sich aber
schon sehr verbessert... und ist soooo langsam nun auch nicht.)

Ein beliebiger Java-Editor. Nimm JBuilder, nimm JEdit, egal.

Jetzt sagst du ja doch Swing. Forte hättest du noch nennen können.
Hier gebe ich dir recht. Wenn du dir aber mal Eclipse anguckst, wirst
du feststellen, daß Java überhaupt nicht langsam ist. Und GUI-lose
Programme sind tatsächlich gleich schnell oder annähernd so schnell
wie vergleichbare C-Programme.

Da sehe ich dein Problem nicht. Die Firma hat die API geschrieben,
die Firma darf die API verändern. Was ist schlecht daran die API
zu ändern?

Eine API legt man einmal fest und schreibt dann hoechstens Erweiterungen.
Ich hab nicht unbedingt die groesste Lust, alles neu schreiben zu muessen.

Mußt du ja nicht. Sun verändert ja die API nicht grundlegend, sondern
erweitert diese nur. Gib mir ein Beispiel dafür, was du jetzt nicht
mehr tun kannst, das du mit der JDK 1.0 noch tun konntest.

Noe, werd ich nicht. Weil dann wieder eine sinnlose Diskussion ausbricht. Und
da habe ich in der Tat keine Lust mehr drauf.

OK, das akzeptiere ich.

Java ist plattformunabhängig.

Perl auch.

Ja, aber langsamer als Java. Jede interpretierte Sprache ist
plattformunabhängig.

Java ist einfach.

Perl auch.

Nicht wirklich, nein. Perl ist eine der kompliziertesten Sprachen, die
ich kenne. Das macht sie aber tatsächlich auch mächtig, wenn man sich
erstmal reingearbeitet hat.

Die Java-API ist seeeehr umfangreich.

Man mag das sehen wie man will -- fuer mich ist das nicht unbedingt immer
ein Vorteil.

Ich sehe keinen Nachteil. (außer daß die SDK groß ist)

Aber die von Perl ist es auch.

Kein Vergleich zu Java.

Wenn es denn kleinere Fehler waeren.

Naja, ich kenne keine größeren. Ich arbeite aber vielleicht auch noch
nicht lange genug mit Java.

Ich sags mal ganz klar und deutlich: ich mag Java nicht.

Ich weiß :-)

Und Lust auf eine weitere Diskussion habe ich auch nicht. Martin hat mich nach
Gruenden gefragt, warum wir (bzw. Wilhelm) Java ablehnen. Ich habe sie
genannt. Wenn du es anders siehst -- bitte schoen, von mir aus.

Ja, ich sehe es anders. Und deshalb habe ich auf dein Posting
geantwortet. Ich akzeptiere deine Meinung und kann deine
Argumentation verstehen. Trotzdem wollte ich einfach eine andere
Meinung als die pauschalisierte Java-ist-scheiße-Meinung beisteuern.
So scheiße ist Java nämlich nicht...

Gruß
Slyh

[Christoph Schnauß]

hallo slyh,

Das Konzept von Java ist klar und gut durchdacht

Weil es nicht von Sun stammt, sondern in den allermeisten Bereichen ganz einfach "abgeschrieben" wurde bei Stroustrup

Weisst du ueberigens, wofuer Java urspruenglich geschrieben wurde? Fuer
Kaffee-Maschinen (daher der Name), Waschmaschinen, etc.
Nein, das war nur ein mögliches Anwendungsgebiet. Da Java plattform-
neutral ist, kann es auch in Kaffee-Maschinen eingesetzt werden.
Es war nie die Rede davon, daß es nicht auf z.B. PCs laufen soll.

Doch. Genau wie CK sagt, bestand das ursprüngliche Ziel der "green"-Arbeitsgruppe darin, Programme für Kaffeemaschinen und so nen Zeugs zu entwickeln. Grob ausgedrückt, war die Aufgabenstellung des "green"-Projekts so: entwickle eine Lösung, damit deine Kaffeemaschine deiner elektronischen Türsicherung sagen kann, daß sie dein Handy anrufen soll um dir mitzuteilen, daß das Aquarium grade ausgelaufen ist ... Ursprünglich wollten sie dafür C++ nehmen, hatten damit Probleme, und Gosling hat sich dann hingesetzt und schnell mal ne eigene Sprache entwickelt  -  an manchen Stellen nahe an C/C++. Daß sich Java auch auf PC's einsetzen und übers "Netz" verbreiten läßt, war gar nicht beabsichtigt, sondern ein zufälliger Nebenbei-Effekt.

... Jede interpretierte Sprache ist
plattformunabhängig.

Da hab ich Zweifel mit der apodiktischen Formulierung "jede"

Java ist einfach.
Perl auch.
Nicht wirklich, nein. Perl ist eine der kompliziertesten Sprachen

"Kompliziert" mögen die regulären Ausdrücke sein. Sonst kaum etwas. Und RegExpressions gibts auch in anderen Sprachen, sogar in Javascript

So scheiße ist Java nämlich nicht...

Ich mag Java für gelegentliche kleine Spielereien ganz gerne.

Grüße aus Berlin

Christoph S.

[Christoph Schnauß]

hallo CK,

Weisst du ueberigens, wofuer Java urspruenglich geschrieben wurde? Fuer
Kaffee-Maschinen (daher der Name), Waschmaschinen, etc.

"ursprünglich" hieß Java gar nicht "Java", sondern "Oak", weil der Erfinder der Sprache (Gosling) ständig eine Eiche in seinem Blickfeld hatte, wenn er aus dem Fenster sah ... das gab dann TradeMark-Komplikationen, woraufhin der Name geändert wurde.

So hab ich das mal irgendwo gelesen.

Christoph S.

[Martin Jung]

Hi Christian,

ich klinke mich jetzt einfach mal hier ein (im Parallelzweig wäre es genauso angebracht gewesen).
Weiterhin erlaube ich mir, die Struktur des Postings ein klein wenig zu verändern.

<moved>

Ich sags mal ganz klar und deutlich: ich mag Java nicht.

Das ist Dein subjektives Problem und kein objektives Argument.

<moved>

Ich halte Java fuer
umstaendlich, wenig kompfortabel, langsam und inkonsistent. Daran wirst du so
einfach nicht ruetteln koennen, denn ich habe es oft genug selber miterlebt
und erlebe es noch mit (ich muss fuer Lotus Domino 6 entwickeln).
Und Lust auf eine weitere Diskussion habe ich auch nicht. Martin hat mich nach
Gruenden gefragt, warum wir (bzw. Wilhelm) Java ablehnen. Ich habe sie
genannt.

Nein. Ich las keinen Grund/Beispiel für Umständlichkeit, geringe Komfortabilität und generelle Langsamkeit.

StringBuffer war nicht das einzige Beispiel. Derartige Schnitzer sind schlicht
und ergreifend ein Indiz fuer ein fehlerhaftes Konzept.

Eine suboptimale Umsetzung ist kein Beleg für Mängel des Konzepts.

Was hast du eigentlich für ein Problem mit einer Veränderung der API?
Um was für "Schnitzer" handelt es sich denn bei StringBuffer und Konsorten.
Dü würdest eine neu entwickelte API nie mehr verändern, auch wenn die praktische Erfahrung vieler Entwickler dies eigentlich nahelegt?
Programme, die mit einem alten API laufen, laufen generell auch weiterhin mit dieser API.
In den Bereichen, in welchen Java massivst eingesetzt wird (verteilte Businessapplikationen) sind die (äußerst selten vorkommenden!) Api-Anpassungen das _geringste_ Problem und die _einfachste_ Herausforderung.

Bei Java muss man viel auswendig lernen.

Generell setzt Erkenntnis Wissen voraus. Was aber, bitte schön, muss man auswendig lernen? Meinst Du die Java-Datentypen?

Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt
nicht _langsam_!
Doch.

Sehr überzeugend.
Java mag für "JPhotoshop" nicht geeignet sein, weil _dafür_ zu langsam.
Immer wider dieses dämliche "Java ist viel langsamer als C/C++ und was weiß ich nicht alles". Es sind nur wenige Programme ausgesprochen rechenintensiv. Die meiste Zeit "warten sie" auf Benutzereingaben, langsame Datenbank- oder Festplattenzugriffe. In den überwiegenden Fällen haben langsame Java-Applikationen ihre Ursache einfach in schlechtem Design und/oder schlechter Implementation* (manchmal ist auch durchaus die Entscheidung zu Java für die Problemlösung bereits der Fehler).
Wer eine potentiell performanzkritische Anwendung "mal so schnell" in Java schreiben will und wahl- und wissenslos die abstrakten Designmöglichkeiten von Java verwendet (Stichworte: Strings, Reader/Writer, Collection-Framework), ist selbst schuld.
Man könnte sogar augenzwinkernd sagen: JAVA zwingt den Entwickler wieder, über seine Arbeit nachzudenken ;-)

* Dies kann übrigens auch Folge der Kombination aus "jungem Alter" und gleichzeitigem Erfolg von Java sein (woran letzteres wohl liegt?).

Ein beliebiger Java-Editor. Nimm JBuilder, nimm JEdit, egal.

Eine repräsentative und umfangreiche Auswahl.

Ich finds schon krank, dass eine Firma mal eben so mir nichts, dir
nichts die APIs aendern kann.

Was ist daran krank - das nennt man Fortschritt, Weiterentwicklung. Übrigens passiert das bei SUN nicht "mir nichts, dir nichts". Vielleicht passiert es ohne Deine Zustimmung, aber solche Fragen können und werden vorher in Java Community diskutiert.

Eine API legt man einmal fest und schreibt dann hoechstens Erweiterungen.

Aha. Wo steht das?

Ich hab nicht unbedingt die groesste Lust, alles neu schreiben zu muessen.

Du plädierst für nichts anderes als Stillstand.

Java ist plattformunabhängig.
Perl auch.

Ist kein Gegenargument.

Java ist mächtig.
Das wage ich zu bezweifeln

Warum? Beispiele? Gründe (wo sind diese, ich warte immer noch)

aber Perl auch.

Java ist einfach.
Perl auch.

Die Java-Syntax ist für Programmiereinsteiger mit Sicherheit leichter zu erlernen. Ich halte Java sogar für elegant.
Wer ernsthaft damit arbeiten will, muss sich aber selbstverständlich ernsthaft und ausdauernd damit beschäftigen (OO!).

Java ist sicher.

Wie soll eine Sprache sicher sein?

Weil die (jdk)-VM bereits ein gewisses Maß an Sicherheit garantiert (z.B. Stack-Overflow Attacken, zumindest ist mir bisher noch keine bekannt). Das "Sandbox"-Modell ermöglicht die eine frei konfigurierbare Zugriffskontrolle auf Systemresouren, sei es aus lokalem oder "remote" Code. Weil auf Pointer und Pointerarithmetik verzichtet wird.
Letzteres ermöglicht prinzipiell auch die effizientere Entwicklung von robustem Code.

Fürderhin bietet Java:

• Unterstützung für Multithreading
• Unterstützung für verteilte Anwendungen
• Reflektions-Mechanismus
• strukturiertes Exception-Handling
• Unterstützung für Internationalisierung durch Unicode (alle Strings/Chars werden intern als Unicode-Zeichen behandelt)
• Java ist Binärcode-kompatibel

Viele Grüße,
Martin

[Christian Kruse]

Hallo,

Weiterhin erlaube ich mir, die Struktur des Postings ein klein wenig zu
verändern.

Du hast mich sinnbefreiend zitiert.

<moved>

Ich sags mal ganz klar und deutlich: ich mag Java nicht.
Das ist Dein subjektives Problem und kein objektives Argument.

Ich habe hier nie den Anspruch erhoben, objektiv zu sein. Wenn du mein Posting
vernuenftig gelesen hattest, dann haettest du gesehen, dass ich geschrieben
habe, dass ich absichtlich nicht naeher auf die Punkte eingegangen bin, um
keine Diskussion vom Zaum zu brechen. Darauf habe ich naemlich nicht die
geringste Lust. Wenn dich meine Ansichten und deren logische Begruendungen
interessieren, such im Archiv. Die Diskussion, die hier auszubrechen beginnt,
bringt null. Und das war mein letzter Beitrag zu diesem Thread.

Gruesse,
 CK

[Daniela Koller]

Hi Martin

<moved>

Ich sags mal ganz klar und deutlich: ich mag Java nicht.
Das ist Dein subjektives Problem und kein objektives Argument.

Hat er das jemals behauptet?

Nein. Ich las keinen Grund/Beispiel für Umständlichkeit, geringe Komfortabilität und generelle Langsamkeit.

Genereller Grund: Dank einem einzelnen! Javaw Prozess war meine Maschine
derart langsam das ich nicht mehr tippen konnte, auf dem Prozess lief
eine Servlets/JSP Anwendung mit einem einzelnen User, die Anwendung
bestand aus 1 Servlet + ungefähr 10 JSP und einzelne Action Klassen.

StringBuffer war nicht das einzige Beispiel. Derartige Schnitzer sind schlicht
und ergreifend ein Indiz fuer ein fehlerhaftes Konzept.
Eine suboptimale Umsetzung ist kein Beleg für Mängel des Konzepts.

Noch eins: URLEncoder, der gefährdet gerade die Auslieferung unserer
Applikation weil der nur mit dem ServerEncodingarbeitet, wohlgemerkt
nicht das des Servlets, sondern Server.

Was hast du eigentlich für ein Problem mit einer Veränderung der API?
Um was für "Schnitzer" handelt es sich denn bei StringBuffer und Konsorten.
Dü würdest eine neu entwickelte API nie mehr verändern, auch wenn die praktische Erfahrung vieler Entwickler dies eigentlich nahelegt?

Wegen praktischer Erfahrung eine API zweimal ändern? So geschehen bei den
Events bei swing oder AWT

In den Bereichen, in welchen Java massivst eingesetzt wird (verteilte Businessapplikationen) sind die (äußerst selten vorkommenden!) Api-Anpassungen das _geringste_ Problem und die _einfachste_ Herausforderung.

Schön wäre es, unzulängliche Apis die ein Umstellen auf eine nicht Quickhack
Lösung sind häufig nötig.

Bei Java muss man viel auswendig lernen.
Generell setzt Erkenntnis Wissen voraus. Was aber, bitte schön, muss man auswendig lernen? Meinst Du die Java-Datentypen?

Die ganzen Unzulänglichkeiten? ZB: bei welchen zu Java gehörenden Klassen
kann man clone benutzen, wann ist es Müll, oder das selbe mit equals das
auf die Referenz und nicht auf den Inhalt vergleicht? Zu diesem Thema
gibt es zahlreiche Webpages.

Wer eine potentiell performanzkritische Anwendung "mal so schnell" in Java schreiben will und wahl- und wissenslos die abstrakten Designmöglichkeiten von Java verwendet (Stichworte: Strings, Reader/Writer, Collection-Framework), ist selbst schuld.
Man könnte sogar augenzwinkernd sagen: JAVA zwingt den Entwickler wieder, über seine Arbeit nachzudenken ;-)

Nein, es nimmt ihm das Nachdenken ab indem es vorgaukelt dass es das nicht wäre,
das sind dann die schlecht designten Applikationen von denen du sprichst. Schliesslich
schreit Java dem Anwender ja entgegen, bei mir gibt es nichts gefährliches...

* Dies kann übrigens auch Folge der Kombination aus "jungem Alter" und gleichzeitigem Erfolg von Java sein (woran letzteres wohl liegt?).

Wieso ist Windows immernoch erfolgreich? Das Schlüsselwort ist Marketing

Ich finds schon krank, dass eine Firma mal eben so mir nichts, dir
nichts die APIs aendern kann.
Was ist daran krank - das nennt man Fortschritt, Weiterentwicklung. Übrigens passiert das bei SUN nicht "mir nichts, dir nichts". Vielleicht passiert es ohne Deine Zustimmung, aber solche Fragen können und werden vorher in Java Community diskutiert.

Und Sun kann darüber entscheiden ganz alleine, ja, nette Community, aber keine
Druckmöglichkeit. BTW: es passiert wohl mir nichts dir nichts, wenn zb Bugmeldungen
als solved geschlossen werden, allerdings mit einer API-Änderung in der nächsten
Version (Beispiel erneut URLEncoder)

Eine API legt man einmal fest und schreibt dann hoechstens Erweiterungen.
Aha. Wo steht das?
Ich hab nicht unbedingt die groesste Lust, alles neu schreiben zu muessen.
Du plädierst für nichts anderes als Stillstand.

Er plädiert dafür, ältere Applikation nicht nur deswegen ändern zu müssen,
weil irgend ein Hersteller lust hat, alte APIs nicht mehr zu unterstützen.
Und ganz genau das heist deprecated, Vorsicht, ändere es, irgendwann
unterstützen wirs einfach nicht mehr.

Java ist plattformunabhängig.
Perl auch.
Ist kein Gegenargument.

War das jemals als Gegenargument gedacht und nicht viel eher als
was ist daran _so_ speziell.

Java ist mächtig.
Das wage ich zu bezweifeln
Warum? Beispiele? Gründe (wo sind diese, ich warte immer noch)

Die Sprache Java ist sehr schwach, die Klassenbibliothek Java
ist stärker, gehört jedoch nicht zu einer Sprache, und Java lässt
sowohl in der Klassenbibliothek, als auch in der Sprache sehr
elementare Dinge vermissen, so zum Beispiel für eine Sprache
sie sich wunderbar Objektorientiert nennt Design by Contract.

Java ist einfach.
Perl auch.
Die Java-Syntax ist für Programmiereinsteiger mit Sicherheit leichter zu erlernen. Ich halte Java sogar für elegant.

Die ganzen Spezialfälle wie bereits oben erwähnt sind es nicht, ich habe
C++ in 2 od 3 Monate bei 6h wöchentlich gelernt, Java lerne ich jetzt seit
5 Monate täglich 8h, ich komme mit den Spezialfällen immernoch nicht klar.

Wer ernsthaft damit arbeiten will, muss sich aber selbstverständlich ernsthaft und ausdauernd damit beschäftigen (OO!).

Java ist kein sauberes OO, und es ist auch bei ernsthaftem und dauerhaftem Beschäftigen
nicht angenehmer mit Java zu arbeiten.

Java ist sicher.

Wie soll eine Sprache sicher sein?
Weil die (jdk)-VM bereits ein gewisses Maß an Sicherheit garantiert (z.B. Stack-Overflow Attacken, zumindest ist mir bisher noch keine bekannt). Das "Sandbox"-Modell ermöglicht die eine frei konfigurierbare Zugriffskontrolle auf Systemresouren, sei es aus lokalem oder "remote" Code. Weil auf Pointer und Pointerarithmetik verzichtet wird.

Speicherlöcher krieg ich dir in Java auch ohne Pointer hin.

Letzteres ermöglicht prinzipiell auch die effizientere Entwicklung von robustem Code.

• Unterstützung für Internationalisierung durch Unicode (alle Strings/Chars werden intern als Unicode-Zeichen behandelt)

Und Designfehler in anderen Klassen machen diesen Vorteil zumindest für Servlets bis und mit
Java 1.3.1 zunichte -> URLEncoder (mein persönlicher Liebling)

• Java ist Binärcode-kompatibel

Was soll das sein?

Gruss Daniela

[uwe]

Hallo Daniela

... ich habe C++ in 2 od 3 Monate bei 6h wöchentlich gelernt ...

Du willst C++ in 48 bzw. 72 Stunden gelernt haben? Nimms mir nicht uebel, aber das wage ich echt zu bezweifeln ... .

Viele Gruesse
Uwe

[Calocybe]

Moin!

... ich habe C++ in 2 od 3 Monate bei 6h wöchentlich gelernt ...

Du willst C++ in 48 bzw. 72 Stunden gelernt haben? Nimms mir nicht uebel, aber das wage ich echt zu bezweifeln ... .

Aeh... also mir kamen die Zahlen beim Lesen schon sehr hoch vor. Und Du meinst, das ist immer noch zu wenig? Oder hab ich Dich jetzt missverstanden?

So long

[uwe]

Gruess dich,

kann sein, dass ich da irgendwas falsch verstanden habe. Bei mir kam das so rueber, als ob da jemand behauptet, er haette C++ innerhalb von 48h von der Pike auf gelernt und beherrscht die Sprache. Das ist unmoeglich. Allein die Syntax und den Umgang mit der IDE (inkl. Compiler Switches etc.) richtig zu verstehen, braucht seine Zeit. Mal ganz zu schweigen von den (Un)tiefen der Sprache, der Win API und aehnlichen Monstren.

Bis denn
Uwe

[Daniela Koller]

Hi Uwe

kann sein, dass ich da irgendwas falsch verstanden habe. Bei mir kam das so rueber, als ob da jemand behauptet, er haette C++ innerhalb von 48h von der Pike auf gelernt und beherrscht die Sprache. Das ist unmoeglich.

Nein Uwe, ich behaupte, ich beherrsche die Sprache (ist ja auch nicht
schwierig, ein paar (zweistellig) Keywords, dazu Regeln wegen Reihenfolge.
Zudem mit Hilfe einer Referenz auch den Umgang mit den Basisdingern der
STL (vorallem Container). Ich behaupte nicht ich hätte in der Zeit
Objektorientierung begriffen, das konnte ich lange vorher schon.

Allein die Syntax und den Umgang mit der IDE (inkl. Compiler Switches etc.) richtig zu verstehen, braucht seine Zeit. Mal ganz zu schweigen von den (Un)tiefen der Sprache, der Win API und aehnlichen Monstren.

IDE hat nichts mit C++ zu tun, ich benutze auch keine IDE, wozu auch wenn ich
n guten Editor habe und Compilerswitches haben auch nichts mit der Sprache C++ zu tun.

Und was hat die WIN API mit der Sprache C++ zu tun? Wozu sollte ich die WIN API als
Unixbenutzer überhaupt lernen wenn ich nicht für Windows was programmieren will.

Ich bleibe dabei, die Sprache selber kann ich, was du hier erwähnst, ist nicht die
Sprache C++. Gleichenfalls behaupte ich, auch meine Klassenkameraden die vorher
nie programmiert haben können die Sprache C++.

Gruss Daniela

[uwe]

Hallo Daniela,

ich verstehe, worauf du hinaus willst, aber meiner Meinung nach sind
Programmiersprache, API des jeweiligen Betriebssystems (egal ob Win oder *nix) und Entwicklungsumgebung (ob IDE, Editor oder von mir aus auch handschriftlich ...<g> ) nun mal untrennbare Teile eines Ganzen. Insofern bedeutet das "Beherrschen" einer Sprache eben nicht nur das simple Erlernen der Sprachelemente und -regeln.

Ciao
Uwe

[Daniela Koller]

Hi Uwe

ich verstehe, worauf du hinaus willst, aber meiner Meinung nach sind
Programmiersprache, API des jeweiligen Betriebssystems (egal ob Win oder *nix) und Entwicklungsumgebung (ob IDE, Editor oder von mir aus auch handschriftlich ...<g> ) nun mal untrennbare Teile eines Ganzen. Insofern bedeutet das "Beherrschen" einer Sprache eben nicht nur das simple Erlernen der Sprachelemente und -regeln.

Viele APIs sind in mehreren Sprache sehr sehr ähnlich, auch Editoren sind
mit mehreren Programmiersprachen zu benutzen, von dem her muss man
die einfach nicht jedes mal neu lernen. Genauso wie APIs vorallem bei
Windows sehr häufig ändern, du verlernst ja nicht nicht die Sprache oder
kannst sie nicht mehr nur weil du ne API neu lernen musst.

Für mich besteht nach jetzt 4 Sprachen die ich auch alle nach dem lernen
noch benutzte/benutzt habe, das lernen einer Sprache wirklich nur noch
aus dem Lernen der Syntax und den Besonderheiten einer Sprache, sowie
falls nötig, die Basisbibliotheken einer Sprache (bei Java vorallem
die Packages java.lang.* und java.util.* plus weitere Basispackete
und bei C++ halt eben die STL, bei PL/1 sinds die Standard Builtinfunctions
bei HPS die mitgelieferten Basisdinger).

Gruss Daniela

[uwe]

Hi Daniela,

klarer Fall von Missverstaendnis, sorry. Wenn du bereits vier Sprachen und das entsprechende Drumherum beherrscht, dann ist das Erlernen einer neuen Sprache natuerlich relativ einfach, keine Frage. Ich war davon ausgegangen, dass wir hier ueber Anfaenger reden.

Einen netten Abend noch

Uwe

[Frank Schönmann]

hi!

... ich habe C++ in 2 od 3 Monate bei 6h wöchentlich gelernt ...
Du willst C++ in 48 bzw. 72 Stunden gelernt haben? Nimms mir nicht
uebel, aber das wage ich echt zu bezweifeln ... .

Dadurch, dass man entscheidende Stellen im Quoting weglässt, werden
Antworten darauf nicht automatisch richtig. Es ging nicht darum, mit
C++ vernünftig zu programmieren, sondern die Syntax und ihre evtl.
Spezialfälle zu lernen.

bye, Frank!

[uwe]

Hi Frank,

Die Java-Syntax ist für Programmiereinsteiger mit Sicherheit leichter zu erlernen. Ich halte Java sogar für elegant.

»»Die ganzen Spezialfälle wie bereits oben erwähnt sind es nicht, ich habe
C++ in 2 od 3 Monate bei 6h wöchentlich gelernt, Java lerne ich jetzt seit
5 Monate täglich 8h, ich komme mit den Spezialfällen immernoch nicht klar.

Ich verstehe die obige Aussage so, dass sie C++ in 48h gelernt hat, aber mit den Java Spezialfaellen auch nach 5 Monaten noch nicht klar kommt. Falls Daniela sich auch bei C++ auf die Spezialfaelle bezogen hat, dann entschuldige ich mich natuerlich. Falls sie jedoch sagt, sie hat C++ von der Pike auf in 48h gelernt, dann glaube ich das nach wie vor nicht.

Ciao
Uwe

[Martin Jung]

Hi Daniela,

Hat er das jemals behauptet?

Nicht explizit. Ich ging aber, offensichtlich irrtümlicherweise, davon aus.
Weißt Du, Argumentationen im Stile von "ich finde etwas blöd, weil BEHAUPTUNG1, BEHAUPTUNG2, BEHAUPTUNG 3. Ich möchte aber darüber nicht näher sprechen, weil ich keine (!!) Diskussion vom Zaun brechen will" halte ich, gelinde gesagt, für eigenartig.

Genereller Grund: Dank einem einzelnen! Javaw Prozess war meine Maschine
derart langsam das ich nicht mehr tippen konnte, auf dem Prozess lief
eine Servlets/JSP Anwendung mit einem einzelnen User, die Anwendung
bestand aus 1 Servlet + ungefähr 10 JSP und einzelne Action Klassen.

Hälst Du das für ein _generelles_ Argument für die Langsamkeit? Vielleicht lag es nur an der ungünstigen Parametrisierung der VM. Auf meiner Maschine (PII/350, 192 MB) habe ich keine Probleme, wenn z.B. TOMCAT, mySQL und KAWA gleichzeitig läuft (natürlich nicht mit 1000-en Usern ;-)) ).

Die ganzen Unzulänglichkeiten? ZB: bei welchen zu Java gehörenden Klassen
kann man clone benutzen

bei allen, die das Interface "Cloneable" implementieren.

, wann ist es Müll

Was? Die Methode clone()? Wenn sie falsch verwendet wird (Stichworte: flaches/shallow oder tiefes/deep Kopieren). Wie man die clone()-Methode implementiert ist Sache des Entwicklers und nicht der Sprache.

, oder das selbe mit equals das
auf die Referenz und nicht auf den Inhalt vergleicht?

Ich finde diese Thematik eigentlich einleuchtend.
Default-Verhalten:
1. Der "=="-Operator prüft bei allen _primitiven_ Datentypen _immer nur_ auf Wertgleichheit und bei _nicht-primitiven_ _immer nur_ auf Objektgleichheit der Referenz (andere sagen "auf Identität").

2. Zusätzlich gibt es eine Default-Implementation der Methoden equals() und hashCode() in "Object" (die somit in jedem abgeleiteten Objekt verfügbar sind). equals(Object obj) ist dabei simple implementiert: return (this == obj), sodass diese Methode auch auf Objektgleichheit prüft. D.h. standardmäßig führt die Verwendung von "==" und equals() bei Referenzen somit zum selben Ergebnis.

3. Da JAVA schlecht wissen kann, wann Objekte _inhaltlich_ bzw. in der Anwendungslogik gleich sind, ist es die Sache des Entwicklers, diese Bedingung durch Überschreiben von equals() entsprechend zu implementieren (er sollte natürlich auch tunlichst dafür sorgen, dass hashCode() dann ebenso entsprechend angepasst wird). Z.B. könnten zwei Bücher in der Anwendungslogik "gleich" sein, wenn sie denselben Titel und Autor haben, oder bereits, wenn sie nur denselben Titel haben. Bei zwei "inhaltlich gleichen" Buchobjekten würde eine entsprechende equals()-Methode dann "true" zurückgeben, "==" aber weiterhin zu "false" ausgewertet werden.
Beispiel: Bei String-Objekten (s.u.) ist die equals()-Methode derart überschrieben, dass auf inhaltliche Gleichheit geprüft wird -> "Hallo".equals("Hallo") == true.

Soweit finde ich das Konzept eigentlich leicht verständlich (obschon das zugrundeliegende Prinzip natürlich schwieriger zu verstehen ist als der Gebrauch einer for-Schleife). Bis auf _eine_ Ausnahme (s.u.) finde ich es auch sehr praktikabel, da immer vorhersehbar ist, was ein "=="-Vergleich prüft. Soweit ich weiß, gibt es in den C-Derivaten (oder nur C++) auch das Konzept der Operator-Überlagerung. Dies mag einerseits größere Flexibilität mit gut lesbarer Syntax verknüpfen, dürfte aber in der Praxis auch zu Problemen führen bzw. prinzipiell den Keim zur Verwirrung in sich tragen (Stichpunkt: Erben von Klassen, zu denen der Quellcode und/oder eine entsprechende Doku fehlt).

Strings: Hierbei gibt es in der Praxis in der Tat einige Missverständnisse (die aber eigentlich keine sind, da obige Regeln einfach nur angewandt werden).
Alle Strings sind ja bekanntlich in Java ebenfalls Objekte. JAVA unterscheidet aber zwischen Strings, die zur Compile-Zeit durch Variablenzuweisung angelegt werden, und solchen, die zur Laufzeit mittels "new String()" generiert werden. Der Hintergedanke war/ist die Vermeidung/Minimierung von Datenredundanz, also Resourcenschonung (ich erahne schon die spöttischen Kommentare ..). Zu diesem Zweck vewaltet die VM einen internen Pool von String-Objekten, der aus Compile-Zeit Strings beim Laden der Klassen gebildet wird (aber auch zur Laufzeit erweitert werden kann -> intern()-Methode von String).

Beispiel:
Du definierst 100 verschiedene String-Variablen, die aber alle denselben Inhalt zugwiesen bekommen ("Hallo").
Beim Laden der Klasse wird aus der Character-Folge der ersten String-Variablen ein entsprechendes String-Objekt erzeugt, diesem Pool hinzugefügt (mittels Aufruf der intern()-Methode von String durch die VM) und die Referenz auf dieses Objekt dann der Variablen zugewiesen.
Bei jeder weiteren Variablen wird zunächst geprüft (mittels Aufruf der equals()-Methode von String durch die VM), ob ein String-Objekt gleichen Inhalts im Pool bereits vorhanden ist. Ist dies nicht der Fall, wird wieder ein neues String-Objekt erzeugt, dem Pool hinzugefügt und die zurückgegebene Referenz der Variablen zugewiesen. Wenn aber bereits ein String-Objekt gleichen Inhalts existiert, wird eben diese Referenz zuückgegeben, sodass die zweite Variable dann dasselbe String-Objekt wie die erste referenziert. Alle 98 weiteren des Beispiels würden das ebenso tun. In diesem Falle würde der "=="-Vergleich für jede der 100 Variablen untereinander völlig korrekt "true" ergeben. Dies aber nur wegen Objektgleichheit, die in diesem Falle "zufälligerweise" auf der inhaltlichen Gleichheit zur Compile-Zeit beruht..
String-Objekte, die zur Laufzeit mittels "new String()" und demselben Inhalt generiert werden, stellen aber unterschiedliche Objekte dar. Daher ergäbe hierbei "==" eben "false".
Da dieses Verhalten in der Tat meistens für Verwirrung sorgt, ist man immer auf der richtigen Seite, wenn man inhaltliche Vergleiche ausschließlich durch Verwendung von equals() vornimmt.

Wir würdest Du denn das prinzipielle Problem des Unterschiedes zwischen Objekt- und Inhaltsgleichheit und deren Prüfung lösen (bzw. wie ist es denn in anderen OO-Sprachen gelöst? Eleganter? Einfacher?)

Nein, es nimmt ihm das Nachdenken ab indem es vorgaukelt dass es das nicht wäre,
das sind dann die schlecht designten Applikationen von denen du sprichst. Schliesslich
schreit Java dem Anwender ja entgegen, bei mir gibt es nichts gefährliches...

Meinst Du mit "gefährliches" Stolperfallen? Hat nicht jede Sprache ein Reservoir an solchen?
Mir hat Java nichts entgegengeschrien und auch nichts vorgegaukelt. Ich versuche zu verstehen, was einer Sprache mir bietet, welche Dinge problematisch sind, und verwende sie entsprechend.

Und Sun kann darüber entscheiden ganz alleine, ja, nette Community, aber keine
Druckmöglichkeit. BTW: es passiert wohl mir nichts dir nichts, wenn zb Bugmeldungen
als solved geschlossen werden, allerdings mit einer API-Änderung in der nächsten
Version (Beispiel erneut URLEncoder)

OK, in diesen Prozessen stecke ich zu wenig drin. Soweit mir bekannt ist, hat das W3C auch keinerlei Druckmöglichkeit auf die Umsetzung der Standards in Applikationen. Welche Organisationsform oder Intstitution böte denn Deiner Meinung nach solche Möglichkeiten? Wie ist das bei anderen Sprachen? Es ist doch letztlich immer vom Good-Will der beteiligten Entscheidungsträger abhängig, oder?
Ich lasse mich aber gerne eines Besseren belehren.

Er plädiert dafür, ältere Applikation nicht nur deswegen ändern zu müssen,
weil irgend ein Hersteller lust hat, alte APIs nicht mehr zu unterstützen.

Wieso muss er das? Die "alte" Laufzeit-Umgebung existiert doch weiterhin? Und da jede Applikation per default sowieso in ihrer eigenen VM läuft (und auch sollte), sehe ich da auch überhaupt kein Problem.

Und ganz genau das heist deprecated, Vorsicht, ändere es, irgendwann
unterstützen wirs einfach nicht mehr.

Für mich ist ein API ein Standard, und ein solcher wird weiterentwickelt wie viele andere auch. Dies bedeutet aber auch, dass man Fehlerhaftes korrigiert und Ungeeignetes/Gefährliches entfernt.
Wie stehst Du denn zu deprecated-Deklarationen verschiedener HTML-Tags durch das W3C?

War das jemals als Gegenargument gedacht und nicht viel eher als
was ist daran _so_ speziell.

OK, habe ich dann falsch interpretiert.

Die Sprache Java ist sehr schwach,

Das ist mir zu banal. Was meinst Du mit "schwach"?

die Klassenbibliothek Java
ist stärker, gehört jedoch nicht zu einer Sprache, und Java lässt
sowohl in der Klassenbibliothek, als auch in der Sprache sehr
elementare Dinge vermissen, so zum Beispiel für eine Sprache
sie sich wunderbar Objektorientiert nennt Design by Contract.

Kannst Du das Prinzip kurz erläutern? Von welchen OO-Sprachen wird das untertützt?
Was sind weitere Beispiele, die die Verwendung des Plurals "elementare Dinge" rechtfertigen?

Java ist kein sauberes OO,

Nun ja, ich sehe das weniger puristisch oder akademisch. Ich halte es für gut praktizierbares OO.

und es ist auch bei ernsthaftem und dauerhaftem Beschäftigen
nicht angenehmer mit Java zu arbeiten.

Das kann ich für Dich leider nicht widerlegen.

Speicherlöcher krieg ich dir in Java auch ohne Pointer hin.

Was meinst Du mit "Speicherloch"?

Und Designfehler in anderen Klassen machen diesen Vorteil zumindest für Servlets bis und mit
Java 1.3.1 zunichte -> URLEncoder (mein persönlicher Liebling)

Mit diesem Encoder sollte ich mich mal beschäftigen. Was ist eigentlich Euer konkretes Problem damit?

• Java ist Binärcode-kompatibel
  Was soll das sein?

Verklausuliert für plattformunabhängig ;-))

Viele Grüße,
Martin

[Daniela Koller]

Hi Martin

[..] Disskusion zu Clones und Clonable

, wann ist es Müll Was? Die Methode clone()? Wenn sie falsch verwendet wird (Stichworte: flaches/shallow oder tiefes/deep Kopieren). Wie man die clone()-Methode implementiert ist Sache des Entwicklers und nicht der Sprache.

Du hast aus dem Zusammenhang zitiert, ich sprach ausdrücklich nur von Klassen die zu Java gehören.

, oder das selbe mit equals das auf die Referenz und nicht auf den Inhalt vergleicht? Ich finde diese Thematik eigentlich einleuchtend. Default-Verhalten:

[..]

Das Verhalten ist mir durchaus bekannt, ich ärgere mich lediglich über die inkonsistente Implementierung innerhalb der zu Java gehörenden Klassen. Bei allen anderen Klassen geb ich dir Recht, Aufgabe des Entwicklers. Beispiel für zu Java gehörende Klassen: String und StringBuffer...

Beispiel: Bei String-Objekten (s.u.) ist die equals()-Methode derart überschrieben, dass auf inhaltliche Gleichheit geprüft wird -> "Hallo".equals("Hallo") == true.

Bei String ja, bei StringBuffer bereits wieder nicht.

Soweit finde ich das Konzept eigentlich leicht verständlich (obschon das zugrundeliegende Prinzip natürlich schwieriger zu verstehen ist als der Gebrauch einer for-Schleife). Bis auf eine Ausnahme (s.u.) finde ich es auch sehr praktikabel, da immer vorhersehbar ist, was ein "=="-Vergleich prüft. Soweit ich weiß, gibt es in den C-Derivaten (oder nur C++) auch das Konzept der Operator-Überlagerung. Dies mag einerseits größere Flexibilität mit gut lesbarer Syntax verknüpfen, dürfte aber in der Praxis auch zu Problemen führen bzw. prinzipiell den Keim zur Verwirrung in sich tragen (Stichpunkt: Erben von Klassen, zu denen der Quellcode und/oder eine entsprechende Doku fehlt).

Der == Vergleich ist keinerlei Problem, grundsätzlich ist bei c++ == vergleichbar mit .equals in Java, es tut dass, was der Entwickler der Klasse für richtig hält, wenn man auf Adressgleichheit prüfen will in C/C++, geht das nunmal anders. Mit == auf Referenzgleichheit prüfen zu wollen, ist wie mit .equals auf Referenz prüfen zu wollen, manchmal gehts, manchmal nicht.

Mit der Vererbung hast du in Java genau das selbe Problem, wenn du die Doku nicht hast, hast du keine Ahnung was .equals tut.

[..] Erklärungen wieso bei String .equals zu benutzen ist.

Kein Einspruch das .equals zu benutzen ist, nur würde ich das eben auch gerne bei StringBuffer tun und würde ein konsistentes Verhalten erwarten, irgendwie muss ich schliesslich Zeichenketten auf den Inhalt überprüfen können, egal wie die technische Implementierung aussieht.

Wir würdest Du denn das prinzipielle Problem des Unterschiedes zwischen Objekt- und Inhaltsgleichheit und deren Prüfung lösen (bzw. wie ist es denn in anderen OO-Sprachen gelöst? Eleganter? Einfacher?)

Konsistent innerhalb der Klassen die zum JDK gehören, ich habe nichts dagegen dass == auf Referenz prüft, auch nichts dagegen dass .equals auf Inhalt prüft, nur möchte ich das gerne identisch haben, wenn Inhaltsgleichheit möglich ist, dann ist irgendeine Methode implementiert die implementiert wie Inhaltsgleichheit innerhalb der Realität definiert ist, ansonsten soll die Vergleichsmöglichkeit bei Inhalt einfach fehlen, aber nicht etwas da sein, was mir suggeriert, es ginge doch.

Nein, es nimmt ihm das Nachdenken ab indem es vorgaukelt dass es das nicht wäre, das sind dann die schlecht designten Applikationen von denen du sprichst. Schliesslich schreit Java dem Anwender ja entgegen, bei mir gibt es nichts gefährliches... Meinst Du mit "gefährliches" Stolperfallen? Hat nicht jede Sprache ein Reservoir an solchen? Mir hat Java nichts entgegengeschrien und auch nichts vorgegaukelt. Ich versuche zu verstehen, was einer Sprache mir bietet, welche Dinge problematisch sind, und verwende sie entsprechend.

Mir schreit Java die ganze Zeit vor, Pointer sind gefährlich, damit kann ich Speicherlücken bauen, deswegen gibt es sie nicht, es wird gesagt Speicherlöcher seien dadurch unmöglich, jede Speicherverwaltung würde die VM tun, nur stimmt das nicht, mangels vernünftiger Destruktoren bleiben Files geöffnet wenn man sie nicht explizit schliesst. (Ich weis das Files offenlassen schlechter Stil ist).

Und Sun kann darüber entscheiden ganz alleine, ja, nette Community, aber keine Druckmöglichkeit. BTW: es passiert wohl mir nichts dir nichts, wenn zb Bugmeldungen als solved geschlossen werden, allerdings mit einer API-Änderung in der nächsten Version (Beispiel erneut URLEncoder) OK, in diesen Prozessen stecke ich zu wenig drin. Soweit mir bekannt ist, hat das W3C auch keinerlei Druckmöglichkeit auf die Umsetzung der Standards in Applikationen. Welche Organisationsform oder Intstitution böte denn Deiner Meinung nach solche Möglichkeiten? Wie ist das bei anderen Sprachen? Es ist doch letztlich immer vom Good-Will der beteiligten Entscheidungsträger abhängig, oder? Ich lasse mich aber gerne eines Besseren belehren.

Ich möchte gerne sowas wie ANSI-C++, eine Sprachbasis die festgelegt ist, auf die ich mich verlassen kann und die eine klare Versionsnummer trägt. Das ist unrealistisch, ich weis, auch bei C++ können gewisse Compiler nicht was sie sollten.

Er plädiert dafür, ältere Applikation nicht nur deswegen ändern zu müssen, weil irgend ein Hersteller lust hat, alte APIs nicht mehr zu unterstützen. Wieso muss er das? Die "alte" Laufzeit-Umgebung existiert doch weiterhin? Und da jede Applikation per default sowieso in ihrer eigenen VM läuft (und auch sollte), sehe ich da auch überhaupt kein Problem.

Und was tut ein Benutzer der Applikationen hat die eine neue VM benutzen? Das es möglich ist, verschiedene VMs zur selben Zeit laufenzulassen wäre mir nicht bewusst, ich lasse mich da aber gerne aufklären.

Und ganz genau das heist deprecated, Vorsicht, ändere es, irgendwann unterstützen wirs einfach nicht mehr. Für mich ist ein API ein Standard, und ein solcher wird weiterentwickelt wie viele andere auch. Dies bedeutet aber auch, dass man Fehlerhaftes korrigiert und Ungeeignetes/Gefährliches entfernt. Wie stehst Du denn zu deprecated-Deklarationen verschiedener HTML-Tags durch das W3C?

Ganz grundsätzlich halte ich das für ein Problem wenn deswegen diese Tags bei ensprechender DOCTYPE Deklaration nichtmehr unterstützt würden, nur sind für mich HTML-Seiten kurzlebiger als Applikationen (Ich hab schon 20 jährige Applikationen anpassen müssen). Zudem steckt in den meisten Fällen nicht ganz so viel Arbeit drin. (10 Personenjahre und mehr sind wohl eher unwahrscheinlich für eine einzige Version). Dazu kommt, das wohl die Anpassungen einfacher sind und weniger Auswirkungen rundherum haben. Auch sind die Auswirkungen wohl weniger gravierend, hauptsächlich sind Formatierungstags weggefallen, dann sieht schlimmstenfalls etwas nicht mehr gut (oder auch grässlich) aus aber die Seite verweigert nicht vollständig ihren Dienst.

Die Sprache Java ist sehr schwach, Das ist mir zu banal. Was meinst Du mit "schwach"?

Die Sprache Java besteht aus einem Haufen Schlüsselwörter, die können grundsätzlich mal nicht sehr viel, wozu auch, dafür gibt es die Klassenbibliothek. Ich finde das auch auf keine Fall negativ sondern eher positiv, nur ist es eben nicht die Sprache die viele Dinge von Haus aus kann.

die Klassenbibliothek Java ist stärker, gehört jedoch nicht zu einer Sprache, und Java lässt sowohl in der Klassenbibliothek, als auch in der Sprache sehr elementare Dinge vermissen, so zum Beispiel für eine Sprache sie sich wunderbar Objektorientiert nennt Design by Contract. Kannst Du das Prinzip kurz erläutern? Von welchen OO-Sprachen wird das untertützt?

Nehmen wir an, ein Parameter darf nur Werte zwischen 2 und 5 annehmen, das einzige was du tun kannst, ist in nem anderen Fall eine Exception zu werfen, oder sonst irgend etwas nettes wie Fehlermeldung in die Konsole zu schreiben.

Bei Design by Contract sagst du hingegen bei diesem Parameter, er darf nur diese Werte annehmen, und das musst du dann auch nicht mehr händisch überprüfen. Die einzige Sprache die mir bekannt ist die das macht ist Eiffel (leider sehr teuer und kaum verbreitet).

Was sind weitere Beispiele, die die Verwendung des Plurals "elementare Dinge" rechtfertigen?

Templates, ein Haufen anderer schöner Dinge die UML kann, Java aber nicht (C++ zu nem grossen Teil auch nicht). Dann die Existenz von primitiven Datentypen, vorallem im Zusammenhang mit den Collections ist das mühsam und fehlerträchtig.

Java ist kein sauberes OO, Nun ja, ich sehe das weniger puristisch oder akademisch. Ich halte es für gut praktizierbares OO.

Ich halte es auch für praktizierbares OO wenn es keine Basisdatentypen gibt. Genauergesagt würde ich das für sehr viel bequemer halten. Performanceentscheide halte ich in dem Zusammenhang für falsch da diese eher in den Optimierer des Compilers gehören und nicht dem Benutzer aufgebrummt werden sollten.

und es ist auch bei ernsthaftem und dauerhaftem Beschäftigen nicht angenehmer mit Java zu arbeiten. Das kann ich für Dich leider nicht widerlegen.

Stimmt, weil, das ist wie mit allen Programmiersprache reine Geschmackssache.

Speicherlöcher krieg ich dir in Java auch ohne Pointer hin. Was meinst Du mit "Speicherloch"?

Unnötig verwendeter Speicher der zur Laufzeit nicht mehr benutzt werden kann und auch nichts sinnvolles mehr enthält, also sozusagen verschwendeter Speicher. Das passiert wenn man Files nicht explizit schliesst und alle Referenzen auf das Objekt verliert.

Und Designfehler in anderen Klassen machen diesen Vorteil zumindest für Servlets bis und mit Java 1.3.1 zunichte -> URLEncoder (mein persönlicher Liebling) Mit diesem Encoder sollte ich mich mal beschäftigen. Was ist eigentlich Euer konkretes Problem damit?

Das Problem ist eher ein Designfehler unsererseits in dem Fall, kann aber auch sehr gut auftreten wenn der Designfehler nicht vorliegt. URLs werden ja bei der Übertragung URLEncoded (gibt n RFC dafür, hab ich nicht zur Hand), jetzt haben aber einige der Zeichen die verschlüsselt werden müssen andere Positionen im Zeichensatz je nach verwendetem Zeichensatz. Da unsere Benutzer auf der ganzen Welt sind, sind die Zeichensätze entsprechend vielschichtig genauso wie die Laute die verschlüsselt werden müssen (da ist unser Designfehler die nicht HTMLmässig zu verschlüsseln, passiert jedoch auch mit normaleren Sonderzeichen). Jetzt gibt es aber keinerlei Möglichkeit (in Java 1.4 gibt es sie) den Zeichensatz zu spezifizieren der verwendet werden soll, es wird auch nicht der benutzt, der im Webserver eingestellt ist, sondern der, des Servers (also Hardware/Betriebssystem).

Und Umsteigen auf die neue Javaversion ist in unserem Fall im Moment nicht möglich.

• Java ist Binärcode-kompatibel Was soll das sein? Verklausuliert für plattformunabhängig ;-))

ANSI C ist auch Plattformunabhängig, muss nur immer wieder compiliert werden. Zudem hat Java da meiner Meinung nach mit Swing viel verloren, und zwar weil es eben nicht ein Button so macht wie ich ihn mir gewohnt bin, sondern wie der Progammierer es will. Auf die das ich meine Oberfläche und meine Einstellung wie alles aussehen soll aber sehr bewusst ausgewählt habe, kommt kein Programmierer. Jetzt läuft die Applikation zwar noch auf allen Plattformen (für die es VM's gibt), aber es sieht nicht mehr aus wie eine normale Applikation für diese Plattform. Mit AWT tut es das allerdings nach wie vor.

Gruss Daniela

[Christian Kruse]

Hoi,

Hat er das jemals behauptet?
Nicht explizit. Ich ging aber, offensichtlich irrtümlicherweise, davon aus.
Weißt Du, Argumentationen im Stile von "ich finde etwas blöd, weil
BEHAUPTUNG1, BEHAUPTUNG2, BEHAUPTUNG 3. Ich möchte aber darüber nicht
näher sprechen, weil ich keine (!!) Diskussion vom Zaun brechen will" halte
ich, gelinde gesagt, für eigenartig.

Ich habe nicht argumentiert, immer noch nicht. Du hast etwas gefragt, ich
habe geantwortet. Wenn dir das nicht passt, such im Archiv nach meinen
Gruenden.

Gruesse,
 CK

[Thomas Mell]

Hi

langsam

Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt nicht _langsam_!

Dann saug dir mal den J-Builder von Borland - die Krücke ist in Java geschrieben. Tolle Idee, mit einen langsamen in Java geschriebenen Editor ebenso langsamen Javacode zu schreiben... Java ist mit Abstand die langsamste aller höheren Sprachen. Aber wer sich unbedingt Plattformunabhängikeit auf die Fahne schreibt (was für die wenigsten Anwendungen benötigt wird) muß halt Opfer bringen...

Grüße
Thomas

[Slyh]

Hallo,

Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt nicht _langsam_!

Dann saug dir mal den J-Builder von Borland - die Krücke ist in Java geschrieben. [blabla]

Dann saug dir mal Eclipse (http://www.eclipse.org). Ist in Java
geschrieben und sauschnell. Man kann auch in C++ extrem langsame
Programme schreiben.
Wenn du dich mal darüber informierst, was ein JIT macht, wüßtest du, daß
die Programme genauso schnell laufen können wie eben z.B. in C++.
(Swing ist allerdings tatsächlich recht langsam. Das ist wohl auch
primär das Problem vom JBuilder.)

Gruß
Slyh

[Martin Jung]

Hi Slh,

Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt nicht _langsam_!

Dann saug dir mal den J-Builder von Borland - die Krücke ist in Java geschrieben. [blabla]

Dann saug dir mal Eclipse (http://www.eclipse.org). Ist in Java
geschrieben und sauschnell.

Danke, dass Du den Link noch einmal hier gesetzt hast,

Viele Grüße,
Martin

[Robert Bamler]

Hallo,

Ich fuer meinen Teil werde unter Windoof mit der .chm arbeiten, fuer die RS/6000 habe ich ja noch immer die HTML-Version.

Es waere aber doch moeglich gewesen, einen OS-unabhaengigen Viewer in Java mit Volltextsuche zu schreiben, der die Dokumentstruktur anhand der LINK-Elemente erkennt (falls Selfhtml8 die hat - weiss gerade nicht so genau).

Gute Idee! Freue mich schon darauf, dass du das verwirklicht hast. Wenn du das nicht machst, macht's eben (wenn man Glück hat) ein anderer. Aber das ist ja nicht schlimm - dann kann man sich wenigstens darüber aufregen, dass er alles falsch gemacht hat.

Ich finde es halt nicht gut, dass jetzt moeglicherweise irgendein Idiot herkommen koennte und sagen: "Unter Windows kann ich Selfhtml viel besser lesen, da gibt's das als .chm, da ist alles viel einfacher, unter Linux waere das vieeel zu kompliziert, bla bla bla."
Man koennte sagen: Ich goenne den Windoze-Nutzern das .chm einfach nicht! Ich gebe es zu!

Das das kindisch ist, ist offensichtlich. Der einzige Nachteil, den ich darin sehe, ist das vielleicht mal jemand sagt: "In der Windows-Hilfe ist sogar eine umfangreiche HTML-Referenz dabei."
Selbst das ist natürlich unwahrscheinlich, da sich derjenige ja in aller Regel die chm-Datei selbst heruntergeladen hat und deshalb besser bescheid wissen sollte.

Robert

http://www.designauswahl.here.de
mit kostenlosem Webseiten-Generator ROBE.dit
[more than a HTMLE.dit]

[Oliver García]

Hallo,

Wer es selber mal ausprobieren will, geht auf http://aktuell.de.selfhtml.org/extras/selfchm.htm. Dort kann man die chm-Version downloaden.

Das ist wirklich beeindruckend. Und zwar in mehrfacher Hinsicht:

Natürlich habe ich (als deren Autor) zuerst ausprobiert, ob die
eingebaute Selfhtml-Suchmaschine auch hier funktioniert. Sie tut es. Die
Microsoft-Entwickler haben offenbar ganze Arbeit geleistet, was die
Synchronisierung der Komprimierungs- und Kompilierungstechnik mit dem
"Browsermotor" angeht. Auch komplexe Javascript-Anwendung werden eins zu
eins mit verpackt. Praktisch bedeutet das für den Nutzer der
Selfhtml-CHM-Version, daß er zwei Volltextsuchen zur Verfügung hat und
sich die für ihn nützlichere aussuchen kann.

Die andere große Überraschung war, daß der große Datenumfang von
Selfhtml der CHM-Konvertierung nicht entgegen stand. Vielleicht kann ja
Wolfgang Reszel an dieser Stelle etwas dazu schreiben, wie aufwendig die
Umsetzung war. Ich betreue selbst ein Internet-Projekt in einem Umfang
von rund 100 MB Html-Seiten, aus dem einmal eine CD-Version entstehen
soll. Bislang hatte ich eine CHM-Fassung ausgeschlossen, aber nach
dieser Demonstration sieht das anders aus.

Gruß,
Oliver

[code2i]

Hallo,

Wer es selber mal ausprobieren will, geht auf http://aktuell.de.selfhtml.org/extras/selfchm.htm. Dort kann man die chm-Version downloaden.

Das ist wirklich beeindruckend. Und zwar in mehrfacher Hinsicht:

Natürlich habe ich (als deren Autor) zuerst ausprobiert, ob die
eingebaute Selfhtml-Suchmaschine auch hier funktioniert. Sie tut es. Die
Microsoft-Entwickler haben offenbar ganze Arbeit geleistet, was die
Synchronisierung der Komprimierungs- und Kompilierungstechnik mit dem
"Browsermotor" angeht. Auch komplexe Javascript-Anwendung werden eins zu
eins mit verpackt. Praktisch bedeutet das für den Nutzer der
Selfhtml-CHM-Version, daß er zwei Volltextsuchen zur Verfügung hat und
sich die für ihn nützlichere aussuchen kann.

Ich habe mir das auch mal angeschaut, weil mir zuerst die Komprimierung ins Auge viel. Allerdings liegt die CHM Version nach dem öffnen meiner Meinung nach nicht mehr komprimiert vor, da sie ca. 14 MB an Arbeitsspeicher verschlingt. Davon sind Anzeige-Elemente ausgenommen denn die ganze CHM Datei arbeitet mit der Browsertechnologie des IE und große Teile davon sind im Explorer vorhanden, so das nichts zusätzlich geladen werden muss oder Speicher verbraucht.

Zur SelfHTML Suchmaschiene und CHM Suche !!!

Nach meinen Testversuchen kann ich gut und gerne auf die Suche der CHM Datei verzichten. Es werden nur einfache Stringsuchen und verknüpfte String treffer geliefert. Völlig nutzlos !

Ich greife nach wie vor lieber auf die implementierte JavaScript Suche zurück. Diese liefert eindeutig perfekte Ergebnisse. Themenbezogen etc... ( schon klar, brauch ich mich nicht drüber auszulasen.... kennst du besser)

Die andere große Überraschung war, daß der große Datenumfang von
Selfhtml der CHM-Konvertierung nicht entgegen stand. Vielleicht kann ja
Wolfgang Reszel an dieser Stelle etwas dazu schreiben, wie aufwendig die
Umsetzung war. Ich betreue selbst ein Internet-Projekt in einem Umfang
von rund 100 MB Html-Seiten, aus dem einmal eine CD-Version entstehen
soll. Bislang hatte ich eine CHM-Fassung ausgeschlossen, aber nach
dieser Demonstration sieht das anders aus.

Wie er das umgesetzt hat ist mir im Moment auch noch unbekannt. Allerdings passiert bei der Konvertierung nichts "Weltbewegendes". Grob gesagt ist es nur ein anderes Frontend für einen Browser. Der ich glaube... intern mit einer grammatikalischen Komprimierung arbeitet. So ist die Datei kleiner aber da es nur die HTML Syntax betrifft, sehr schnell in der Suchfunktion.
Allerdings will ich das selbst nocheinmal überprüfen !

Hui rund 100 MB Html-Seiten... das ist ne Menge!!!

Ich arbeite in der Freizeit an einem Programm in Java, welches ähnlich CHM sein soll. Ich verwende dazu Java ! Als Frontend soll der User aber seinen vertrauten Browser verwenden. Also eine Client-Server Architektur.

Ich arbeite mit zwei Typen der Komprimierung.
Der "Transport Compression" - welche nur dazu dient, für übertragungen so klein wie möglich zu sein. (Derzeitiger SelfHTML Status liegt bei ca. 3.6MB)
Und einer "Container Compression" - welche nur die HTML Syntax betrifft. So soll die Arbeitsgröße der Datei weit unter 10MB liegen.

Etwas Probleme macht mir da allerdings dein SucheScript mit knapp 3.8MB. Darauf kann ich leider noch keine Regeln anwenden. Könnte passieren das sie genauso groß bleibt wie die ganze SELFHTML Doku.

Böse gesagt... weg damit !! wäre einfach. Aber das liegt nicht im Sinn des ganzen. Mein Ziel ist es die JavaScript Suche erst beim lösen der "Transport Compression" dynamisch zu erstellen um so auf die gewaltigen JS index Daten in dieser Phase verzichten zu können.

Aber erst wird erstmal alles so bleiben, denn Priorität hat der reine HTML Modus und SelfHTML dient mir dazu nur als Beispiel. Diese Form der Komprimierung lässt sich auch wunderbar auf z.B. die Dokumentation des Java SDK anwenden. (erste Tests mit über 60% Kompression - gegenüber zip).

Komischerweise geht das auch mit Java class Daten.

Bis aus dem allem ein richtiges Programm wird, kann noch dauern.(Bin erst bei der Konstruktion der Protokolle und Funktionen...)

Hätte man doch nur mehr Freizeit ;-)

Gruesse code2i

[MADU]

hallo,

ein sehr gutes projekt - das schnelle nachschlagen wird damit noch praktischer.

vielen dank an wolfgang reszel für die mühe

lg MADU