Typesafe database interaction with Java 8

http://benjiweber.co.uk/blog/2013/12/28/typesafe-database-interaction-with-java-8/

by benjiweber • 13 years ago

45 37 13 years ago

benjiweber.co.uk

zastrowm• 13 years ago

As a .NET programmer, it's great to see the changes that are coming to Java. Method references and lambdas should make for some really nice + typesafe fluent apis.

Although waiting for Android to support the new features will still be a pain (it just got support for 7 with the release of KitKat).

clhodapp• 13 years ago

The Android tools now have essentially-fake support for Java 7. Basically, they updated dx (the classfile-to-dex converter) to not throw exceptions immediately upon encountering a v51-format (Java 7) classfile, but, rather, to throw exceptions whenever such a file actually contains Java 7-specific bytecode features (MethodHandles, InvokeDynamic, and related features). This means that Android has support for the syntax-only features of Java 7 (the ones implemented entirely upstream in javac), but falls short of implementing any of the actually-interesting platform features that would have required changes to the phone-side VM.

Edit: The reason I bring this up (apart from being a little bit sore about it, personally), is that this means that Android is actually really far from Java 8 support, as these features were added in Java 7 at least partially to facilitate lambda support in Java 8 (see http://cr.openjdk.java.net/~briangoetz/lambda/lambda-transla...).

falloutfar2• 13 years ago

It's not as far as you think it is :) see https://bitbucket.org/jpilliet/android-292

eranation• 13 years ago

Try Kotlin or Scala in the meantime. Both had good Android support

mpweiher• 13 years ago

Looks a lot like what was done in ROE or Gemstone, which both execute blocks/lambdas against recording proxies and then translate the messages to DB queries. (I did something similar with Higher Order Messages).

bsaul• 13 years ago

I'm not a java expert, so i'm wondering : is the fact that this example still has to rely on cglib a downside ?

lmm• 13 years ago

Yes. If you're willing to use cglib or some other code generation (or reflection) you can already achieve the same thing, and there are projects like QueryDSL that do it.

drdaeman• 13 years ago

Is it a language- or platform-side feature? I mean, is this something that needs additional support from JVM side or could be done on existing JVMs (i.e. a compiler for Java 8 could be written that would produce code that'd run on older JDK without need for upgrade)?

ZitchDog2• 13 years ago

It requires JDK 8 - but there is a project to backport the lambda syntax back to Java 7: https://github.com/orfjackal/retrolambda

ZitchDog2• 13 years ago

This ends up looking a lot like JOOQ - but JOOQ doesn't require Java8

http://www.jooq.org

benjiweber• 13 years ago

Indeed. JOOQ is nice. However, it does rely on code generation to do some of the nicer things http://www.jooq.org/doc/3.2/manual/code-generation/

Now that there are new language features it may not be required.

lukaseder8• 13 years ago

Many jOOQ users appreciate code generation for the simple reason to keep Java code in sync with the database schema... This is crucial if you have 500+ tables with dozens of columns, each

mbell2• 13 years ago

This looks really nice.

I wish Java would do something about getters and setters. It's very awkward that they are not incorporated into the language but so many libraries assume they exist that it's a defacto requirement to generate the same boilerplate constantly. I wish the language itself would provide default 'simple' getters/setters the way Groovy does and incorporate them throughout so I could use e.g.

    .set(Person::firstName)  //Reference a default setter method for the firstName member if one isn't explicitly defined

instead of

    .set(Person::setFirstName)

ed_blackburn• 13 years ago

As a C# developer I urge caution. When getters and setters become as trivial as

public int Age { get; set; }

Code becomes less OO and more procedural filled with anaemic models / bags of state. Practices like Tell don't Ask, Information Hiding and Rich Models, slip away.

yawz• 13 years ago

Very very valid points, in my experience.

thangalin• 13 years ago

Accessor messages in Smalltalk, a pure Object-Oriented Programming environment, have been that trivial for a long time. See: http://www.jmcsweeney.co.uk/computing/m206/accessors.php

The issue, as I see it, isn't the ease of creating accessors; the issue is that students do not seem to learn about the practices you've mentioned.

I demonstrate "Tell, Don't Ask", "Information Hiding", and "Encapsulation" in the following presentation:

http://whitemagicsoftware.com/encapsulation.pdf

mbell2• 13 years ago

Code becomes less OO

Frankly...good. If there is one thing Java desperately needs, it's less OO code.

adrianmalacoda• 13 years ago

You might find Project Lombok [1] interesting. It's a library of annotations that can be used to generate boilerplate code.

[1] http://projectlombok.org/

batbomb2• 13 years ago

I wrote something in Java 7 I call zerorm that has some similar functionality. The type safety is mostly optional, but it can be enforced in a few ways, either through the compiler or at "bind time". It's similar to jOOq, korma, etc... but one nice benefit is it doesn't try to do everything, it has no dependencies, and the core part of the code is around 3k LoC IIRC.

http://github.com/zerorm/zerorm

lukaseder8• 13 years ago

From the GitHub docs:

    $( colName ) is also unsafe in the sense that whatever
    colName is will be thrown out directly to SQL. However,
    $$( colName ) is a bit safer because it removes double
    quotes and wraps the identifier

Gotta love that :-) It's obviously safer, given the amount of $. What does $$$( colName ) do?

batbomb2• 13 years ago

haha yeah. I'm not sold on that yet, it was a design decision I made so that I personally could do some crazy things with column names. The lack of safety would only come if you had a string that was somehow modifiable by a user and that was to be used as a column name. So the $$ just means make the name use ANSI quotes, instead of an unquoted identified (column name). The single $ lets users implement whatever they want for a column name, which is useful if you want to keep a tiny library and not worry about database specific features like functions, etc...

ww520• 13 years ago

I wrote something similar (Jsoda) for AWS's databases a while back, https://github.com/williamw520/jsoda. It just uses plain Java.

falloutfar2• 13 years ago

Hi Benji, there is a way to avoid CGlib proxy for what you want to do. It's clearly a hack but I think it's a better hack than using CGlib because it doesn't require code generation.

By default, a method reference or a lambda doesn't carry a reflective description of itself to be lightweight. This description is generated by the compiler, pass to the metafactory but once the method reference object is created the recipe of the method reference is lost. That is true but in one case, if the lambda or the method reference is Serializable, in that case, the recipe need to be kept in order that the runtime can deserialize the method reference. There are several ways to force a method reference to be serializable, the easiest way is to declare the functional interface that will receive the method reference as inheriting from Serializable. This means you can not use java.util.function.Function, you have to create your own interface that inherits from Serializable. Once you have done that, you just have to serialize the method reference to an array and deserialize it by hand to extract the recipe. So the only thing you need is a code that simulate de-serialization withtout using the classical ObjectInputStream of Java because it will not let you sneak at the recipe. The code here [1], do what you want.

cheers,

[1] https://github.com/forax/jayspec/blob/master/jayspec/src/com...

revetkn2• 13 years ago

How does it handle operations more complex than "select * from user"? For example, joins and subqueries. And wouldn't it be nicer to have the database layer figure out properties for you instead of writing mapping code by hand?

For example (this uses SQL, I am not big on ORMs):

  User user = database.queryForObject("SELECT * FROM user WHERE user_id=?", User.class, userId);

lukaseder8• 13 years ago

This boils down to whether you prefer SQL to be an external or internal DSL in your host environment.

External DSL = Actual target language, no simulation thereof, but String-based, no typesafety, detached bind variables, SQL injection, etc.

Internal DSL = Typesafe, compiled, but only a simulation of the real language, limited by the host language

revetkn2• 13 years ago

BTW, I just checked out jOOQ. I think you did a great job with it. This is the first ORM I've seen that really embraces SQL. Nice work

lukaseder8• 13 years ago

Congrats to your tool. Using method references is quite clever, reminds me of a couple of tools that did something with instrumentation and advanced reflection (cglib, I guess). These come to my mind:

OhmDB (http://www.ohmdb.com)

LambdaJ (https://code.google.com/p/lambdaj/)

JaQu (http://www.h2database.com/html/jaqu.html)

JIRM, I think, also played around with similar ideas (https://github.com/agentgt/jirm)

Comparing this approach with jOOQ (http://www.jooq.org), I think that method references might be somewhat limited in a SQL sense of thinking. How would you handle aliases? E.g. how would you perform a self-join, such as:

    FROM person p1
    JOIN person p2 ON p1.parent_id = p2.id

unclebucknasty4• 13 years ago

Sorry, but this is ugly. Reminds me a bit of entity beans and all of the extra code hoops required in order to "automate" some functionality.

Here, we are really just using code declaratively, then doing extra work to map, etc. Then, folding in CGLib too? And, given that the queries are written in code, modifications to columns manipulated and so forth require re-compilation anyway.

Accessing the DB is not rocket science. I am not sure why we find new ways to complicate it so much. It is primarily just grunt work when done by hand. So, I do understand the desire to avoid that part of it.

This being the case, I will stick with my homegrown code generation tools for DB interfacing. Over the years, new tools have come and gone, which simply seem to move the problems around (Hibernate, anyone?) And, during that time, I haven't found anything simpler or more straightforward than a tool I wrote over ten years ago to generate the (typesafe) base DAO layer from simple queries.

edandersen2• 13 years ago

The problem with homegrown DB interfacing stuff is that no other developers want to learn to use it, instead of standard using ORMs. Fine if you are a lone wolf but using a 10 year old homemade DAO layer wouldn't fly in a team.

unclebucknasty4• 13 years ago

Perhaps, but I think that's actually part of the fallacy here. That is, this mindset "let's all adopt and learn to use something obtuse and wildly overly-complicated, so that it at least becomes a standard that we can use (and further propagate) elsewhere." I noticed, for instance, that you didn't refute the ugliness of the OP. Your reply instead seems to be saying, "at least we can get the team to use it".

Now, this is really reminding me of EJB. Seriously, it's how we end up with these insane "standards", the embrace of which is probably at least partly responsible for Java's reputation as an inefficient language in which to develop.

And, there are certainly ways to approach code generation in a team environment, especially if the team was willing to put a fraction of the effort into such an approach, as they would put into learning and maintaining something like the OP. At the end of the day, you just need to get data in and out of the DB. Whether it is ten years old or homegrown shouldn't matter so much if it is clean, easily maintained, and efficient. Teams adopt project-specific patterns all the time for other parts of development. Why not for the DB access?

But, I just offered up my solution as a way to say that, in all of these years, I have yet to see a truly attractive alternative to something homegrown and "old". Many seem to agree as here we are with yet another proposal. But, things seem to be getting worse, as the OP is an example that borders on parody of previous offerings. Dynamic proxies and CGLib? Really?

When I read the title, I thought maybe someone had nailed it. But, we start with ugly, somewhat declarative code that surfaces SQL syntax, pass around some function names, throw in some mapping, get some dynamic proxies in the mix and, oh yeah, you're also gonna need CGLib, etc. I literally thought it was a joke. Then, I come here and the first comment is "This looks really nice".

So, aside from what I have decided to do to solve the problem, I would just ask why the OP approach should be considered a viable alternative and why we favor coalescing around such complicated anti-patterns instead of guiding our "teams" toward saner choices that work.

Typesafe database interaction with Java 8

Related Stories