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.<p>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.<p>cheers,<p>[1] <a href="https://github.com/forax/jayspec/blob/master/jayspec/src/com/github/forax/jayspec/SerializationDecoder.java" rel="nofollow">https://github.com/forax/jayspec/blob/master/jayspec/src/com...</a>
This looks really nice.<p>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.<p><pre><code> .set(Person::firstName) //Reference a default setter method for the firstName member if one isn't explicitly defined
</code></pre>
instead of<p><pre><code> .set(Person::setFirstName)</code></pre>
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.<p>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.<p>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.<p>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.
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.<p>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).
This ends up looking a lot like JOOQ - but JOOQ doesn't require Java8<p><a href="http://www.jooq.org" rel="nofollow">http://www.jooq.org</a>
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?<p>For example (this uses SQL, I am not big on ORMs):<p><pre><code> User user = database.queryForObject("SELECT * FROM user WHERE user_id=?", User.class, userId);</code></pre>
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:<p>OhmDB (<a href="http://www.ohmdb.com" rel="nofollow">http://www.ohmdb.com</a>)<p>LambdaJ (<a href="https://code.google.com/p/lambdaj/" rel="nofollow">https://code.google.com/p/lambdaj/</a>)<p>JaQu (<a href="http://www.h2database.com/html/jaqu.html" rel="nofollow">http://www.h2database.com/html/jaqu.html</a>)<p>JIRM, I think, also played around with similar ideas (<a href="https://github.com/agentgt/jirm" rel="nofollow">https://github.com/agentgt/jirm</a>)<p>Comparing this approach with jOOQ (<a href="http://www.jooq.org" rel="nofollow">http://www.jooq.org</a>), 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:<p><pre><code> FROM person p1
JOIN person p2 ON p1.parent_id = p2.id</code></pre>
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.<p><a href="http://github.com/zerorm/zerorm" rel="nofollow">http://github.com/zerorm/zerorm</a>
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)?
I wrote something similar (Jsoda) for AWS's databases a while back, <a href="https://github.com/williamw520/jsoda" rel="nofollow">https://github.com/williamw520/jsoda</a>. It just uses plain Java.
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).