Suche
Interview mit Christoph Engelbert

„Wir werden noch ein wenig Spaß mit Unsafe haben, vermutlich bis Java 11“

Hartmut Schlosser

Christoph Engelbert

In einer Mitteilung auf der OpenJDK-Mailing-Liste hat Mark Reinhold eine Kompromisslösung für die Behandlung des sun.misc.Unsafe APIs in Java 9 vorgeschlagen. Wie genau der Kompromiss aussehen soll, und ob damit wirklich alle Bedenken ausgeräumt werden können, haben wir mit Christoph Engelbert (Hazelcast) besprochen.

JAXenter: Mark Reinhold hat auf der Mailing-Liste nun die Marschroute für die Behandlung interner APIs in Java 9 rausgegeben. Wie sieht diese aus?

Christoph Engelbert: Private APIs, für welche bereits eine Alternative in Java 8 besteht, werden in Java 9 entfernt. Dies betrifft, soweit ich weiß, nicht wirklich viele private APIs. Die meisten, welche in diese Kategorie fallen, werden vermutlich nur selten genutzt.

Private APIs, welche keine Alternative in Java 9 haben, werden weiterhin verfügbar sein wie bisher. Hier wird der neue, durch Jigsaw geschaffene, Scope “module“ nicht eingesetzt, um die Packages zu verstecken.

Private APIs, welche eine Alternative in Java 9 besitzen, werden als deprecated markiert und final in Java 10 entfernt oder versteckt (Mark Reinhold nennt es liebevoll “encapsulated”).

sun.misc.Unsafe könnte gegen Ende von Java 9 vielleicht eine funktionsfähige Alternative besitzen und könnte somit in Java 10 als deprecated markiert werden. Wir werden noch ein wenig Spaß mit Unsafe haben, vermutlich bis Java 11. Aber – ich möchte jeden Entwickler dazu anregen, seine Frameworks oder Libraries so schnell wie möglich an die öffentlichen Alternativen anzupassen, wenn diese verfügbar sind, um eine erneute Eskalation der Situation in der Zukunft zu verhindern!

JAXenter: Was bedeutet das für das viel diskutierte Unsafe API?

Christoph Engelbert: Wie bereits erwähnt, dürfte sun.misc.Unsafe in die zweite Kategorie fallen. Das bedeutet, in Java 9 wird sich erst einmal nichts ändern, außer dass Unsafe als deprecated markiert wird. Das Package sollte weiterhin exportiert werden und alle bisherigen Anwendungen müssten laufen wie bisher. Zu mindestens ist das mein Verständnis. Ich denke auch nicht, dass die VarHandles als echte Alternative gesehen werden, auf jeden Fall nicht im aktuellen Entwicklungsstadium. Zu viele Use Cases sind noch nicht sauber abgedeckt, und diese mit Gewalt rein zu hämmern, wäre fatal.

JAXenter: Wie ist deine persönliche Meinung – wurde damit ein guter Kompromiss erreicht?

Christoph Engelbert: Ich denke nicht nur, dass es ein guter Kompromiss ist, es ist genau wonach wir gefragt haben. Ein klarer Migration Path mit der Möglichkeit, über eine Version hinweg Systeme und Anwendungen anzupassen.

JAXenter: Wie wird es nun weiter gehen?

Christoph Engelbert: Wir, also Hazelcast und ich, sowie viele andere auch werden helfen, die Use Cases aufzustellen und entsprechende Implementierungen auf Nutzen und Speed zu testen. Ich persönlich beschäftige mich gerade intensiv mit den VarHandles und sammele Informationen und teste eigene VarHandle-Implementierungen.

Ich denke, die richtigen Weichen sind gesetzt, Jigsaw wird möglicherweise noch genug andere Probleme bringen (z.B. das veränderte URL Schema durch Module und ähnliches) – aber ein Problem ist schon mal gelöst.

JAXenter: Vielen Dank für dieses Interview!

Christoph Engelbert is the Technical Evangelist and Senior Solutions Architect at Hazelcast. He’s also an Apache Committer and Open Source enthusiast, and is mostly interested in Performance Optimizations and understanding the internals of the JVM and the Garbage Collector.

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.