Logic (falls vorhanden) hinter Google App Engine ohne Standard-JDK 1.6 APIs

Question

Es ist wie GAE sieht eine Teilmenge von JDK 1.6 Klassen gewählt hat, gemäß:

Google App Engine JDK white list

was sehr schade ist, als eine Klasse bekommt Verbindungsfehler überall mit den meisten üblichen Java-Bibliotheken, die sich mit Datenbindung, Reflektion, Klassenladen und Anmerkungen befassen. Obwohl einige Auslassungen für veraltete oder veraltete Dinge gelten können, gibt es andere, die es nicht gibt. Mein besonderes Anliegen ist das Streaming von Pull-Parsern (javax.xml.stream. *), Das erst nach einer langen Verzögerung zu JDK 1.6 hinzugefügt wurde (die API wurde etwa zur gleichen Zeit wie JDK 1.4 fertiggestellt). Wenn Sie dies auslassen, wird es schwieriger, eine skalierbare Hochleistungs-XML-Verarbeitung durchzuführen.

Problem wie ich verstehe ist, dass nicht nur Klassen fehlen, aber sie können nicht einmal aus Sicherheitsgründen hinzugefügt werden.

Also: das ist eine offene philosophische Frage, die wahrscheinlich nur GAE-Entwickler sicher beantworten konnten, aber ... warum werden einige APIs scheinbar willkürlich aus dem Standard-JDK 1.6 entfernt?

UPDATE:

Schnell Anmerkung: Dank für Antworten. Für das, was es wert ist, sehe ich wirklich nicht, wie Sicherheit mit javax.xml.stream nicht zu tun haben würde. Sicherheitsaspekte sind für viele andere Dinge relevant (und ich brauche zum Beispiel keine Threads und kann sehen, warum sie nicht da sind), daher ist es verständlich, dass es eine Antwort gibt; einfach nicht anwendbar für diesen.

Stax API ist nur eine Reihe von Schnittstellen und abstrakt für das Schreien laut. Aber was noch wichtiger ist, es hat genau die gleichen Auswirkungen wie die Schnittstellen SAX, DOM und JAXP - die bereits enthalten sind!

Aber es sieht aus wie dieses Problem, um die Aufmerksamkeit von Google Devs gebracht wurde:

discussion on whitelisting Stax API

so hier hofft, dass diese und ähnliche Probleme schnell gelöst werden können.

Answer 1

Es ist äußerst zweifelhaft, dass diese Dinge willkürlich fallen gelassen wurden. GAE läuft in einer äußerst sicherheitsrelevanten Umgebung, und die Chancen stehen gut, dass eine interne Prüfung der Klassenbibliotheken einige Risiken festgestellt hat, die Google nicht eingehen wollte.

Answer 2

GAE wird in einer gehosteten Umgebung mit nicht vertrauenswürdigen (und potentiell böswilligen) Clients ausgeführt, denen häufig kostenloser Zugriff gewährt wird.

In dieser Art von Umgebung ist die Sicherheit ein sehr hohes Problem, und APIs, die Dateisystemzugriff haben, werden sehr stark untersucht. Ich denke, das ist der Grund, warum sie sich dafür entschieden haben, ziemlich konservativ damit zu beginnen, was sie erlauben.

Es würde mich überhaupt nicht überraschen, wenn mehr Klassen ihren Weg in die Whitelist finden, da Sicherheitsprobleme angesprochen werden (und auf Nachfrage basieren).

Aber ich würde nicht einmal erwarten, Threading-Tools, z.

Answer 3

Wie bei Ihren leistungsstarken Streaming-XML-Parsern könnten Sie versuchen, eine geeignete Bibliothek (JAR-Datei) zu finden. Sofern es nicht auf Threads oder Dateizugriff (oder Blacklist-API) beruht, sollte es genauso gut funktionieren wie das im JDK.

Es gibt viele (ziemlich komplexe) libraries that work on GAE.