openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schmidt <>
Subject Re: JPA and Scala
Date Sat, 22 May 2010 07:51:41 GMT
Hi Kevin, thanks for your reply

In general the Scala community tends to invent things new (one example
are the available persistence layers). This is OK, mostly, because a
language like Scala has many new possibility to express things in
terms of implementation and design of frameworks (DSL).

But I think that if Scala wants to have success (I am a Scala
enthusiast ;-) we have to provide frameworks that allow the
integration of Scala code into existing and proven environments in
terms of knowledge (developer skills) and software.

I do not know all the new emerging Scala persistence frameworks out
there, but I am creating SW-systems for 15 years now and I know that
production readiness is something different (btw, it is never a good
thing to throw away what Java and the JCP invented the last years.)

Thats why I am asking: What does it mean to take a common JCP (JPA
2.0) and its implementation (example OpenJPA), provide a wrapper as
long it is possible and smoothly change things (what at least means
drop parts of the specification). This must not be a generic solution
(I am sure that this will not be possible)

In the case of JPA this means using Scala collections for entities.
The issue here is that these collections do not implement any of Javas
interfaces and there are a lot more possibilities to choose from
mutable and immutable versions.

If you are interested I can post some examples of how a Scala entity
should look like?


On Fri, May 21, 2010 at 9:26 PM, Kevin Sutter <> wrote:
> Hi Christopher,
> I took a quick look at your links.  Interesting ideas.  Of course, the
> easiest way to allow for Scala Buffers is if Buffer extended Collection.  I
> don't know anything about your Buffer architecture or implementation, so I
> don't know if this is even a doable question or not.  As long as your data
> structure could satisfy the signature requirements, then any JPA
> implementation should be good to go.
> As I look at your blog post, it looks like you are hoping to work with all
> three main players (OpenJPA, Hibernate, and EclipseLink).  So, are you
> looking for a general solution that would work with all three?  Or, are you
> looking for a more specific solution?  Supporting the Collection interface
> would be the most general.
> If you have to introduce new method signatures, then you're probably going
> to have to develop a unique plug point for each JPA provider.  For example,
> in OpenJPA we have provided various "strategies" when working with a unique
> situation.  The OpenJPA extension for XML Mapping (vs Relational Mapping) is
> a separate XMLValueHandler strategy.  You might need to think about creating
> something like the ScalaBuffer strategy which would know how to interact
> with your Buffers (vs Collections).
> Just some quick thoughts after reading your post.
> Kevin
> On Fri, May 21, 2010 at 9:28 AM, Christopher Schmidt <
>> wrote:
>> Hi all,
>> I am working on a JPA wrapper for Scala and I think that I have found
>> an elegant way to use some ideas of JPA.
>> I managed to wrap EntityManager, EntitiyManagerFactory and Query.
>> Unfortunately, there is no simple and elegant way to use Scala's
>> collections. Using Scala classes as entities works fine, as long they
>> are using java.lang.List (and the other collections that are
>> specified).
>> My question is: What would it mean (in terms of effort and knowledge)
>> to allow a Scala collection (f.e. a Buffer) as a OneToMany entity
>> attribute?
>> Regards Christopher
>> PS:
>> Buffer is Scala's mutable "List" implementation (see
>> )
>> If you are interested look at
>> (description) and (code)

View raw message