views:

448

answers:

3

It looks like GAE has chosen a subset of JDK 1.6 classes, as per:

Google App Engine JDK white list

which is very unfortunate as one gets class linkage errors all over the place with most common java libraries that deal with data binding, reflection, class loading and annotations. Although some omissions may be for deprecated or legacy things, there are others that are not. My specific concern is with streaming pull parsers (javax.xml.stream.*) which was just added to JDK 1.6 after a long delay (API was finalized at about same time as JDK 1.4). Omitting this makes it harder to do scalable high-performance xml processing.

Problem as I understand is that not only are classes missing, but they can not even be added because of security constraints.

So: this is an open-ended philosophical question that probably just GAE devs could answer for sure but... why are some APIs dropped from standard JDK 1.6, seemingly arbitrarily?

UPDATE:

Quick note: thanks for answers. For what it's worth I really do not see how security would have anything to do with not including javax.xml.stream. Security aspects are relevant for great many other things (and I don't need threads, for example, and can see why they are out), so it's understandable boilerplate answer; just not applicable for this one.

Stax API is just a set of interfaces and abstract for crying out loud. But more importantly, it has exactly the same ramifications as including SAX, DOM and JAXP interfaces -- which are included already!

But it looks like this issue has been brought to attention of google devs:

discussion on whitelisting Stax API

so here's hoping that this and similar issues can be resolved swiftly.

+2  A: 

It's extremely doubtful that these things were dropped arbitrarily. GAE runs in an extremely security-sensitive environment, and the chances are good that an internal audit of the class libraries found some risks that Google was not willing to take.

Tim Gilbert
I somewhat doubt this was the criteria as well. Security most likely was used to determine how security manager handles requests to resources (files, network etc), but to class inclusions...
StaxMan
@StaxMan - Keep in mind that GAE does allow a lot of "risky" things. A lot of reflection features that would normally have to be disabled in such an environment are available. That makes it also a function of what kind of attacks one could run with private fields, methods, etc.
jsight
Yes, agreed, and I think that is great. But it sort of makes it even more strange that less risky things were not included. I do hope it's really sort of "clerical error" and nothing error.
StaxMan
+6  A: 

GAE is run in a hosted environment with untrusted (and potentially malicious) clients, who often are given access for free.

In that type of environment, security is a very high concern, and APIs which have filesystem access get very heavy scrutiny. I think thats why they've chosen to start pretty conservatively in terms of what they allow.

It wouldn't surprise me at all if more classes find their way into the whitelist as security issues are addressed (and based on demand), though.

But I wouldn't even expect to get threading tools available, eg.

jsight
Exactly right. The whitelist is there for security reasons. It's possible some classes were excluded that should be included; hopefully they'll be reviewed and added once it's determined they're secure and can't be used to break out of the sandbox.
Nick Johnson
A: 

As for your high-performance streaming XML parsers, you could try to find an appropriate library (jar file). Unless it relies on threads or file access (or black-listed API), it should work just as well as the one in the JDK.

There are a lot of (rather complex) libraries that work on GAE.

Thilo
Yes, except that if the API lib implements (like javax.xml.stream) is effectively blacklisted (is under 'javax' and not whitelisted), my understanding is that it can not be loaded -- you can include API jar, but that'll fail to load with security violation.It's worth testing out I suppose though.
StaxMan
True. You would need to use the native API of that particular library (and not javax.xml.stream).
Thilo
I'd be ok with native API, but the impl itself MUST have API javax.xml.stream classes available -- it implements them. So that's the bigger problem. Unlike JAXP which is very thin wrapper on DOM, SAX, Stax is a "real" API.
StaxMan
A similar issue was raised as a bug report for AWT and Swing classes that can be used outside of GUI programming. That bug has been acknowledged. So I suppose you can reason with the Google folks to get it in.
Thilo
Yes, there is now an issue logged for stax api (raised by tapestry users that need it too), so I hope this gets resolved.
StaxMan