Re: Beyond Java Tiger - Defekte und Lücken in Java

Hallo Sven.

Sven Köhler schrieb:

> Was meinst du mit "nicht objekt-orientiert" ? Und was meinst du mit
> "nicht preemptiv"?

Das hab ich in der Antwort zu Theo gerade beschrieben. Bei "nicht
preemptiv" hast du zB das Problem dass hoch-priorisierte Threads in
java die sich zB in einer endlos loop befinden sich auch von niedriger
priorisierten Threads nicht mehr abschiessen lassen --> system hängt
sich auf.

> Viel witziger ist, dass die Thread-Klasse nicht Thread-safe ist ;-)
> Mit anderen worten: eine Methode (ich glaube es war setPriotity oder so)
> der Thread-Klasse beschwerte sich bei mir, dass ich sie für ein "totes"
> Thread aufrufe. Schade auch, denn Kontrukte wie
>
> if (thread.isAlive())
> {
> //hier könnte das Thread sterben
> thread.setPriority(...)
> }
>
> machen keinen Sinn.

Auch ThreadGroup ist nicht thread-safe. Genau an dieser Stelle tun sich
Abgründe auf.

> > 2.die Synchronisierungs-Mechanismen sind extrem ausbaufähig. Hier gibt
> > es rudimentäre Lücken und ärgerliche Defizite auf dessen Behebung
> > ich schon lange warte.
>
> Welche Lücken/Defiziete meinst du?
> Meine Kritik ist nur: was hat synchronized in der Sprache zu suchen?
> Ich hätte die Sprache um allgemeinere Konstrukte ähnlich dem
> synchronized-Block erweitert und dann eine Bibliothek für Threads zur
> Verfügung gestellt, die unter verwendung des allgemeineren Konstrukts
> die Funktionalität von synchronized relalisiert.
>
> IMHO fehlt auch soetwas wie ein Timeout bei synchronized.
> Beispiel:
>
> synchronized (object, 1000)
> {
> //we've got the monitor
> }
> else
> {
> //oops, we didn't
> }

ganz genau das fehlt. und: man kann nicht sicher mehrere locks requiren
(wie sagt man das auf deutsch?) und diese multiple locks sollen dann
auch immer in der gleichen Reihenfolge aquired werden.

> > 3.wait()/notify() is funktional noch nicht am Optimum.
>
> IMHO fehlt mir etwas, um folgendes Beispiel zu realisieren:
> - ich habe ein Objekt a
> - ich habe ein Objekt b
> - ich möchte auf eine Zustandsänderung von a _oder_ b warten.
>
> Konkreteres Beispiel:
> - ich möchte darauf warten, dass die Liste a (die grade leer ist)
> gefüllt wird _oder_ die Größe der Liste b unter einen gewissen
> Schwellwert fällt. Beide Listen sind nicht von mir programmiert sondern
> Teil des JDK und die benutzten Monitore sind intern.
>
> Selbst wenn man Zugriff auf beide Monitor-Objekte hätte, gibt es nicht
> sowas wie
>
> synchronized (a.monitor)
> {
> synchronized (b.monitor)
> {
> waitOnMultipleObjects(a, b);
> }
> }
>
> Quasi a.wait() und b.wait() gleichzeitig aufrufen, das wär doch schön.

das lässt sich doch hinkriegen.

> > 4.Lücken und Inkonsistenzen bei static/non-static access bzw. der
> > Synchronisierung in diesem Zusammenhang
>
> Die da wären?

siehe bitte post oben.

> > 6.die fehlende Destruction von zB Singletons
>
> Hmm, IMHO ist "Singleton" kein Konzept von Java - eher etwas was man mit
> Java machen kann, wenn man denn will.
> Frage: wann soll ein Singleton "gelöscht" werden?
> Möglichkeiten gibt es: SoftReferences statt starke Referenzen.

siehe bitte post oben.

>
> > 7.das abrupte shut-down von Daemon threads ist sub-optimal.
>
> Hmmm, System.exit() bedeutet den abrupten shutdown von allen Threads.
> Niemand zwingt einen dazu, DaemonThreads zu benutzen. Das Konzept ist
> auf meinen ersten Blick hin überflüssig.

siehe bitte post oben.

> > 8.Suspend() und resume() gehört wird unterstützt
>
> Thread.suspend() und Thread.resume()? Die gehören verboten - und sind es
> bereits.

Warum? Ich finde sie nützlich. Ich verstehe nicht warum man hier wie
ein Schuljunge behandelt wird. Nur weil die Nutzung potentiell
gefährlich ist muss sie ja nicht per se untersagt werden. Das darf ich
doch bitte selbst entscheiden. Denkbar wäre suspend() wirft eine
RuntimeException wenn der Target-Thread irgendwelche Locks hält oder
gar wartet bis alle Locks freigegeben sind.

> Einige Dinge hier gehen mir zu sehr auf die API ein. Ich würde folgenden
> Schlachtplan bevorzugen:
>
> 1. wie ist die Sprache Java (Syntax, Semantik) zu verbessern?
> 2. wie wäre die API mit der in Schritt 1 vorgeschlagenen Sprache zu
> verbessern?

das liesse sich aber auch trennen.

>
> Noch etwas Kritik an der Sprache:
>
> Ich stolpere hin&weider über folgendes Problem:
> eine Exception soll abgefangen werden damit ich noch ein CleanUp machen
> kann bevor dann die ursprüngliche Exception weitergegeben wird.
>
> [...]

hmmmm....gute Punkt-das schau ich mir später mal genauer an.

> Darüberhinaus ging ich einmal blauäugig davon aus, dass eine Zuweisung
> einer Referenz an eine Variable nicht schief gehen kann - oder auch ein
> return. Dies wird einem durch die Spec aber nicht zugesichert - oder
> zumindest wurde das hier in der NG verneint.
>
> Extrem Paranoide werden nun feststellen, dass die Zeilen
>
> Connection conn = factory.createConnection();
> try
> {
> //code
> }
> finally
> {
> conn.close();
> }
>
> die Datenbankverbindung nicht in jedem Fall schließen - nämlich genau
> dann, wenn createConnection() und eine Connection zurückgibt aber die
> Zuweisung an die Variable conn den Ablauf des Code durch eine Exception
> unterbricht.

stimmt. Das ist nicht atomar.

> Formal _kann_ man also hier garnicht korrekt programmieren - nie.
> Schade auch.

Die Frage ist wie Du "korrekt programmieren" definierst. ;-)

Michael

.

Relevant Pages

  • Re: Beyond Java Tiger - Defekte und =?ISO-8859-1?Q?L=FCcken_in?= =?ISO-8859-1?Q?
    ... preemptiv" hast du zB das Problem dass hoch-priorisierte Threads in java die sich zB in einer endlos loop befinden sich auch von niedriger priorisierten Threads nicht mehr abschiessen lassen --> system hängt sich auf. ... Java machen kann, wenn man denn will. ... Denkbar wäre suspendwirft eine RuntimeException wenn der Target-Thread irgendwelche Locks hält oder gar wartet bis alle Locks freigegeben sind. ... wenn createConnectionund eine Connection zurückgibt aber die Zuweisung an die Variable conn den Ablauf des Code durch eine Exception unterbricht. ...
    (de.comp.lang.java)
  • Re: CMutex /CEvent (multiple threads)
    ... deals with exception detection. ...  If your function does not handle an exception in Java, ... designer did not understand what a Mutex was and that the notion that Lock could return ... ...roll back transaction ...
    (microsoft.public.vc.mfc)
  • =?iso-8859-1?q?Re:_Beyond_Java_Tiger_-_Defekte_und_L=FCcken_in_Java?=
    ... java group befinden. ... Cooperative Threads werden auch nicht von jedem OS unterstützt. ... Immutable kenne ich als Eigenschaft von zum Beispiel ... >> 9. warum implementiert die ThreadGroup nicht alle Methoden des Threads ...
    (de.comp.lang.java)
  • Re: datetime exception 0xC0000008 JRE 1.4 windows
    ... > sais 2am. ... because both keys had 3am. ... > This exception goes up through the JAVA and kills the program - but only ...
    (comp.lang.java.programmer)
  • Re: contracted exceptions
    ... The Java experience shows that compiler checked exception ... violated exception contract caused Program_Error to be raised, the original, ...
    (comp.lang.ada)