Haben JDK-Klassen weitere Spezifikationen als Javadoc?

8

Haben JDK-Klassen über Javadoc hinaus noch weitere Spezifikationen? Wenn ja, wo?

Betrachten Sie zum Beispiel Collections.unmodifiableMap . Sein Javadoc nicht etwas über Fadensicherheit sagen; Ich kann also nicht einfach davon ausgehen, dass es sicher ist, die resultierende Karte anderen Threads zugänglich zu machen, ohne eigene spezielle Schritte zu unternehmen, um Thread-Sicherheit zu erreichen. Aber IMHO würde jede realistische Implementierung die interne Karte in einem final -Feld speichern, so dass in Java 5 und höher die resultierende Karte threadsicher ist, solange die interne Karte ist (mit einer "Vor-Vor" -Beziehung) alle Zugriffe auf die resultierende Karte und alle vorherigen Änderungen an der internen Karte). Das ist zum Beispiel die OpenJDK-Implementierung.

Also, wie kann ich herausfinden, ob ich ein bestimmtes Verhalten portabel annehmen kann?

    
ruakh 19.08.2016, 18:48
quelle

2 Antworten

10

Der Javadoc ist die Spezifikation. Das heißt, eine gute Spezifikation zu schreiben ist unerträglich schwierig, da beides nicht mit nützlichen Dingen überhört wird, die nicht zu übermäßig sind (und die zukünftige Fähigkeit, die Implementierung zu entwickeln, unterminieren).

Wenn ich raten müsste, würde ich sagen, dass der Grund, warum dies aus der Spezifikation weggelassen wurde (außer möglicherweise Aufsicht), dass jede Thread-Sicherheit konditional ist als die zugrunde liegende Sammlung (a) nicht veröffentlicht wird und (b ) nicht geändert werden, nachdem die nicht änderbare Ansicht erstellt wurde, und dies müsste ebenfalls sorgfältig angegeben werden.

    
Brian Goetz 19.08.2016, 19:03
quelle
1

Am Ende gibt es nur ein Kontinuum von wird sich nie ändern über könnte das Verhalten in der nächsten Point-Release ändern in passiert zufällig auf Ihrer Plattform . Selbst spezifiziertes Verhalten kann veraltet sein und dann irgendwann entfernt werden, es passiert nur sehr selten (z. B. Thread.destroy ). Ob Sie sich also auf ein vernünftiges, aber nicht spezifiziertes Verhalten verlassen können, hängt davon ab, wie stark Sie eine Garantie benötigen, wie viel Aufwand Sie für die defensive Codierung ausgeben / Tests hinzufügen, um zukünftige Änderungen zu erkennen.

Aber ja, die Javadocs sind die stärkste Garantie, die Sie bekommen können, alles andere bedeutet, sich auf dünneres Eis zu bewegen.

Viele Projekte basieren auf APIs, die nicht nur nicht dokumentiert sind, sondern intern und scheinbar implementierungsspezifisch sind. sun.misc.Unsafe ist hier das Paradebeispiel, bis zu dem Punkt, an dem die meisten seiner Funktionen in Version 9 zu korrekten JDK-APIs wurden.

Im Fall von Collections.unmodifiableMap , wenn Sie wirklich sicher sein wollten, dass die Veröffentlichung sicher ist, können Sie nach dem Erstellen eine Ladengrenze einfügen.

    
the8472 20.08.2016 06:38
quelle