JDBCPersistence Technology Preview Release

[alexr]

Hi all,

I have just released a technology preview of JDBCPersistence project.
JDBCPersistence is an ORM framework designed and implemented to deliver
performance of hand written JDBC code.

Performance is achieved by employing bytecode generation that creates
classes that specifically target operation that user requests the
framework to do. Such, an insert method generated by the framework,
will operate on an instance of a concrete class, reading properties
from the bean using straight method calls (not reflection). The values
are then being supplied to PreparedStatement using its respective
methods eg. setInt(int value, int position), setString(String value,
int position) etc, again via straight method calls.

Code generation occurs at runtime, so the setup is very easy, there is
no build step. SQL is leveraged as the query language.

All are welcome to download JDBCPersistence Technology Review Release
from http://www.jdbcpersistence.org and don't hesitate to provide
feedback and questions via jdbcpersistence -(at gmail com

More information on the internalsof the framework is available at
http://www.codegeneration.net/tiki-read_article.php?articleId=67

Thank you.

 

[Chris Uppal]

Code generation occurs at runtime, so the setup is very easy, there is
no build step. SQL is leveraged as the query language.

Seems a sensible approach. I'm surprised that it's not more widely used.

After all, Sun's class library uses bytecode generation in several places (to
implement reflective method invocation, for instance) -- it's not as if it's
evil, or even particularly tricky...

-- chris

 

[alexr]

Seems a sensible approach. I'm surprised that it's not more widely used.

After all, Sun's class library uses bytecode generation in several places (to
implement reflective method invocation, for instance) -- it's not as if it's
evil, or even particularly tricky...

-- chris

Agree with you Chris,

Java is perfect for this and it's not a hard thing to do, but the
benefits might be tremendous. Java RMI has become a lot simpler with
java 5 as the stubs and sceletons are now generated at runtime, not
development time. What is the point of generating java classes and then
noting that developers can't change them? If I can't change a class
then don't show it to me. Or, what is the costs of having millions of
java developers having to do an extra step in development to generate
these things, and then maintain them (some will actually check them
into version control systems)? The costs are huge. Java technology
stack is surpassing human capacity to understand it, and it is overdue
for simplification, IMHO.