odata and scala - using odata java libraries in scala

Someone asked me about using odata java libraries with scala and other communication infrastructure such as dispatch, spray, akka-http or finangle.

You can use the Olingo (formerly SAP odata's library) or the SDL odata library with scala and use your own communication layer. Both libraries provide a communication layer if you want to use it.

However, both libraries have interconnecting sets of components to build up odata request content and parse response information. The communication layers in these two libraries use standard javax.net and java.net type mechanisms for communications.

Both libraries provide client side services:

• A way to create queries. Queries in odata use query parameters such as $top or $select. The query objects in the libraries translate API into these query parameters on an HTTP request object.
• A way to map java beans into odata entities. Typically this is done via annotations. You can think of this layer in the libraries similar to the way that an ORM needs to map jvm objects into a specific RDBMS repository put/get format.
• A way to translate responses into java objects. For example, you can iterate over an entity set returned from an odata entity set request. The libraries provide API for the iteration that fits, somewhat, into standard java semantics.

Both libraries also allow you to create odata data sources, also known as the "server" side. Both libraries allow you to receive odata requests, for example for metadata, and create a metadata object that is automatically serialized as a response.

The real issue with the communication layer in these libraries is that they force a style of programming that is imperative and blocking. That's not an issue for many programs that you might write if they are simple and small enough (small in the sense of execution performance).

To a large degree, the libraries represent what is called "late bound" programming. Late bound programming means that you use annotations or other types of reflection programming to handle the java POJO translation process. Scala programmers would prefer something more typesafe and not use annotations since annotations in these libraries are not checked at compile time. You could take the CSDL description of the entities and generate "early bound" objects, but since the library only uses annotations and reflection, this does not buy much other than saving you some typing.

The libraries also have immature support for OAuth2. SDL odata seems to have some plumbing created but it does not support refresh tokens and timeout scenarios, so you'll have to roll your own. 

SDL odata does provide some scala support, but its mostly a map into the java side of the library. SDL includes an akka based server. It's not clear what state it is in, but it looks promising. The scala support in SDL appears to be for the server versus a focus on the client side.

Olingo is very heavy with a standard "factory-based" java API. Everything is a factory. The late binding approach means that entity "properties" are coded fairly laboriously e.g. you specify that an entity has a property that has a type that has a...and so on. Specific requests are typed so that they have a matching response object type. If you use these, then you can access the "members" of the response and it performs the underlying parsing of the REST odatav4 response body for you. That's all very nice. But it is very painful java syntax.