Apache JDBC utils

[Lew]

*NO* reflection API was used at all, *NO* injection
pattern was used, also no penguins where harmed. The
framework consists of what would one call XDoclet today.

But instead of XDoclet I use JSP to generate via
its output the Java code for the XXXBeans. The
input are some property files and the JDBC access
to the meta data of the already existing DB.

+--------+ +-------------+
| DB | | .properties |
+--------+ +-------------+
| |
------ -----
| |
v v
+--------+
| JSP |
+--------+
|
v
+------------+
| XXXBean |
+------------+

Some part of the framework deals with invoking JSP
without browser attention in kind of batch mode. But
using JSP to generate Java code is straight forward.
Check out genbean.jsp, it starts with:

public class <%=table%>Bean extends util.bean.BeanUtil {
private util.bean.ColumnDescriptor[] columndescriptors;

And as you might expect it can generate Java code and
place what table has a value in front of Bean. Or something
more elaborate:

<%
generator.bean.Column col=new generator.bean.Column();
col.setTable(tab);
col.list();
while (col.next()) {
%> private <%=col.getType()%> <%=col.getName()%>=<%=col.getNullConst()%>;
<%
}
col.close();
%>

The above iterates through the columns of the given table,
and the generates variable declarations.

Scriptlet in JSP is an antipattern.

 

[Arved Sandstrom]

Jan Burse wrote:

[ SNIP ]

Scriptlet in JSP is an antipattern.

You calling this an anti-pattern motivated me to go and see what
Wikipedia had to say about anti-patterns:
http://en.wikipedia.org/wiki/Anti-pattern. And as far as programming
anti-patterns go,
http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns.

What's rich is that at the beginning of the article they hand out some
rules for what differentiates anti-patterns from bad habits, bad
practices or bad ideas. Then they trot out a plethora of supposed
anti-patterns that completely violate their own definition.

I don't know when we passed into the zone of inanity with this entire
patterns business, but it couldn't have been more than a year or two
after GOF came out.

No reflection on the intent of your observation, Lew: scriptlets in JSPs
are generally a bad idea.

AHS

 

[Jan Burse]

Scriptlet in JSP is an antipattern.

No,
Java EE 6 calls it even "deprecated".

But advantage of JSP is that it is readily
available. And its actually very old, already
around 1990. But you will not hear some praise
of it from me.

It has more been a conceptual issue in
matula how to generate XXXBean. But you
can of course plug-in your preffered
template language in the below flow:

+--------+ +-------------+
| DB | | .properties |
+--------+ +-------------+
| |
------ -----
| |
v v
+--------+
|>>Here<<|
+--------+
|
v
+------------+
| XXXBean |
+------------+

Now I am waiting for a post that says
..properties files are an anti pattern.
Which I can also agree upon. So the
point of the .properties files here is
to provide annotation of the DB schema.

Of course one can also use here anything
else than .properties files that allows
for peristence or input of some
annotations. So the flow is basically
as follows:

+--------+ +-------------+
| DB | | >> Here 2 <<|
+--------+ +-------------+
| |
------ -----
| |
v v
+-----------+
|>>Here 1 <<|
+-----------+
|
v
+------------+
| XXXBean |
+------------+

Bye

 

[Jan Burse]

It has more been a conceptual issue in
matula how to generate XXXBean. But you
can of course plug-in your preffered
template language in the below flow:

+--------+ +-------------+
| DB | | .properties |
+--------+ +-------------+
| |
------ -----
| |
v v
+--------+
|>>Here<<|
+--------+
|
v
+------------+
| XXXBean |
+------------+

Advantage of using a template processor
where templates show the output generation
of the XXXBean basically as Java code with
holes in it, is the easy prototyping of
the templates.

Just take some code you have already written,
and that worked. And then generalize it by
making the holes into it and write code
around it that fills the holes.

Other less textual approaches would include
generating an AST, which is then textualized.
Generating an AST can be of one more advantage
than the template approach, since it would allow
non linear generation of the output. And one
could also use updates as part of the AST generation.

Templates with linearly interwined code are best
suited for code generation when the code generation
also follows some linear flow. So when the output
resembles a regular or context free grammar.
Something along these lines.

Bye

 

[Daniel Pitts]

*NO* reflection API was used at all, *NO* injection
pattern was used, also no penguins where harmed. The
framework consists of what would one call XDoclet today.

But instead of XDoclet I use JSP to generate via
its output the Java code for the XXXBeans. The
input are some property files and the JDBC access
to the meta data of the already existing DB.

+--------+ +-------------+
| DB | | .properties |
+--------+ +-------------+
| |
------ -----
| |
v v
+--------+
| JSP |
+--------+
|
v
+------------+
| XXXBean |
+------------+

Some part of the framework deals with invoking JSP
without browser attention in kind of batch mode. But
using JSP to generate Java code is straight forward.
Check out genbean.jsp, it starts with:

public class<%=table%>Bean extends util.bean.BeanUtil {
private util.bean.ColumnDescriptor[] columndescriptors;

And as you might expect it can generate Java code and
place what table has a value in front of Bean. Or something
more elaborate:

<%
generator.bean.Column col=new generator.bean.Column();
col.setTable(tab);
col.list();
while (col.next()) {
%> private<%=col.getType()%> <%=col.getName()%>=<%=col.getNullConst()%>;
<%
}
col.close();
%>

The above iterates through the columns of the given table,
and the generates variable declarations.

Scriptlet in JSP is an antipattern.

He's using a JSP to generate a Java source file, and your complaint is
about scriptlets?

 

[Jan Burse]

But advantage of JSP is that it is readily
available. And its actually very old, already
around 1990. But you will not hear some praise
of it from me.

A more profane reason not to use JSP is the
fact that it polutes the perm spaces of Java.
One JSP is compiled into a class, and you can
even recompile without stopping/starting a
web context. This is a realy nice feature.

But Java perm spaces can be restricted, and so
it can be prohibitive to use JSP when you
have a great number of templates. This is
not so much a problem when you only need
a couple of templates to generate some DB
beans and other associate Java classes.

But it can be a problem in many other circum-
stances. So one can then lookup one of the
many template languages and processors on
the market, or one can roll an own template
language and processor (*).

Bye

(*)
http://www.jekejeke.ch/idatab/doclet/blog/en/docs/int/jan/098_2011/096_template_proc/package.html

 

[John B. Matthews]

I'll have to run NetBeans tonight to remind myself of what it
produces as a "JPA controller". Bear in mind, persistence units
are actually what are described in persistence.xml (one or more).

D'oh, I misinterpreted the results of my little experiment. Both
Customer.java and CustomerJpaController.java are generated by the
wizard; the Create Persistence Unit button generates the persistence.xml
file from entries in a dialog. Opening the latter in the IDE is
something akin to opening a .form file in the GUI designer.

Don't get me wrong, I'm a JPA enthusiast. Before it showed up I used
the native APIs in Toplink, Toplink Essentials and Hibernate, and
even those usually would win out over straight JDBC.

But what you did above just scratches the surface. It's now your
responsibility to read and understand the JPA specification and get
the lay of the land for the APIs. I mean "your" in the general sense
here.

Thanks for putting this in perspective. I'm a complete tyro to JPA, and
I couldn't resist a little immediate gratification.

You've always used JDBC, you say. You're aware then that you have to
know quite a lot to use that well. You need to know a lot more -
*plus* understanding JDBC, IMO - to use JPA well. We've been throwing
around terms like conceptual or architectural weight - with JPA you
pull in a fair bit of that.

I don't believe that *you* would stop here - in fact you'd go ahead
and read the spec - but I've seen a fair few programmers that think
that's mostly all there is to JPA: use the IDE to generate from the
DB, or vice versa. They always run into problems sooner or later.

By way of analogy, I see something similar with people thinking that a
GUI designer will obviate the need to understand Swing.

 

[Arne Vajhøj]

No,
Java EE 6 calls it even "deprecated".

Really?

Where does it specify that?

But advantage of JSP is that it is readily
available. And its actually very old, already
around 1990. But you will not hear some praise
of it from me.

Java is from 1995 and JSP from 1999.

Arne

 

[Jan Burse]

He's using a JSP to generate a Java source file,
and your complaint is about scriptlets?

Yes, the argument that goes against <% %> since
they are not true XML tags doesn't work since
the Java source files are generated as
text/plain.

But a template language could nevertheless
be used that is based on XML. Only problem
here is if one wants to generate an instruction
from the template language itself. Which is
normaly not the case for Java code, since it
has hardly raw XML.

But In general the problem is agravated whenever
one wants to use a template language X to generate
code in the same template language X. For example
in a couple of places I use JSP to generate JSP.
The workaround here is to define a custom tag
that generates the <% and %>.

Here is the code for this Taglet:

/**
* <p>This tag generates the <% %> pair.
*
* <p>Matula 1.3 (a beans and jsp generator)
* <br>GPL 2003-2005, Jan Burse, XLOG Switzerland
*/
public class ScriptJava
extends TagSupport {

public int doStartTag() throws JspException {
try {
pageContext.getOut().print("<%");
}
catch (IOException x) {
throw new JspException(x);
}
return TagSupport.EVAL_BODY_INCLUDE;
}

public int doEndTag() throws JspException {
try {
pageContext.getOut().print("%>");
}
catch (IOException x) {
throw new JspException(x);
}
return TagSupport.EVAL_PAGE;
}

}

Bye

 

[Lew]

No,
Java EE 6 calls it even "deprecated".

But advantage of JSP is that it is readily
available. And its actually very old, already
around 1990. But you will not hear some praise
of it from me.

That "but" has nothing to do with the inadvisability of putting scriptlet in JSP.

Nor do the advantages or disadvantages JSP have anything to do with the advisability of scriptlet therein.

The age of JSP is even less relevant. Java is older than JSP and no one is suggesting we not use Java, either.

It has more been a conceptual issue in
matula how to generate XXXBean. But you
can of course plug-in your preffered
template language in the below flow:

+--------+ +-------------+
| DB | | .properties |
+--------+ +-------------+
| |
------ -----
| |
v v
+--------+
|>>Here<<|
+--------+
|
v
+------------+
| XXXBean |
+------------+

Now I am waiting for a post that says
.properties files are an anti pattern.
Which I can also agree upon. So the
point of the .properties files here is
to provide annotation of the DB schema.

Of course one can also use here anything
else than .properties files that allows
for peristence or input of some
annotations. So the flow is basically
as follows:

+--------+ +-------------+
| DB | | >> Here 2 <<|
+--------+ +-------------+
| |
------ -----
| |
v v
+-----------+
|>>Here 1 <<|
+-----------+
|
v
+------------+
| XXXBean |
+------------+

Why in the world would someone consider properties files an antipattern?

Don't use scriptlet in JSPs.

 

[Lew]

He's using a JSP to generate a Java source file, and your complaint is
about scriptlets?

Absolutely.

First, all JSPs are used to generate Java source files. That's how JSP works.

Also, there already are SQL tags available for JSP.

Finally, I don't see how the scriptlet is necessary. Please feel free to educate me; I've been wrong before.

 

[Daniel Pitts]

Absolutely.

First, all JSPs are used to generate Java source files. That's how JSP works.

Also, there already are SQL tags available for JSP.

Finally, I don't see how the scriptlet is necessary. Please feel free to educate me; I've been wrong before.

JSP's are compiled into Java source files, that is different than using
them to compile into Java source files which are executed to produce
other Java source files. The fact that his JSP's *output* is a Java
source file is what I think is containing badness.

Partially because JSPs aren't exactly "stand-alone" templates, they run
in a servlet request. Alternatives might be Freemarker templates, as an
example.

 

[Jan Burse]

Also, there already are SQL tags available for JSP.

Now you are confusing things. XXXBeans are generated
here not necessarely for later use inside JSP. Although
it is not excluded that XXXBeans are used inside
JSP. And in that sense they would rival SQL
tags. And since I don't know SQL tags so much, I
am not sure which would win over the other.

But since my XXXBeans are also design to do bulk
updated/delete and not only select, their application
domain is a little bit broader than information fusion
for a web page. They can also be used for short term
transaction in actionlets, for item transactions inside
batches, or whatever else requires SQL access to a
database for either querying or data manipulation.

The presentation layer of the application is actually
irrelevant. And of course one thing I did not yet
mention, for better performance the XXXBeans will use
some connection pooling.

But XXXBeans should be viewed as the very lowest layer
of database access, forming part of the storage layer of
an application. On top of it one can build the processing
layer of an application which would combine XXXBeans to
form higher serverices. Maybe they can be best compared
to DAOs or ADOs.

Bye

 

[Jan Burse]

First, all JSPs are used to generate Java source files. That's how JSP works.

Wow, he actually understood it wrong. Outch.

Probably a problem of round robin a lot of threads all the time.

 

[markspace]

The "M" in "ORM" stands for "mapping" or "mapper".

I always thought it was "management" but I don't see anything on the web
to support my recollection, so I guess not.

Using a
single 'EntityManager' to handle many things for a long time is
monolithic, and causes persistence sessions to fill and get slow.
Funneling everything through a single data-access construct suffers
from the "God object" complex.

OK, I guess it never occurred to me that someone would do something like
that. I'll have to keep an eye out for that little anti-pattern.

"Non-monolithic" means, for example, a separate data-access class for
each module that needs access. So your "FooOrder" module will have a
data-access object with its own 'EntityManager', "BazHistoryMarker"
will have another, and so on.

This is the way DAOs always naturally decompose for me. I can't see how
someone would come up with a different idea.

Thanks for taking the time to describe those terms.

 

[Arne Vajhøj]

What are you actually gaining by not using a full blown ORM
(JPA, traditional Hibernate etc.)?

Precisely so that you don't have a full-blown ORM with either a native
API or JPA. I'll give you an example: I do integrations with lightweight
ESBs [1], and sometimes I might have to write some simple JDBC in
components and all I want are some Java Beans to represent the ResultSet
rows. Just for packaging. Something like DBUtils could be handy (in fact
I'm delighted that markspace reminded me of this handy API). I
definitely don't want a full-blown JPA ORM in that environment.

Like I said in another post, if you make an argument that a full-blown
ORM is always preferable to a lightweight one, that's practically
tantamount to saying that it never makes sense to use JDBC either.

If we are talking about "single row centric" then I would go for
either the heavy ORM to get functionality or plain JDBC to avoid
dependency (the last argument is more or less a SE only argument).
I would find it difficult to see a good argument for going with
the light ORM.

For "multi row centric" then I would go for plain JDBC as
ORM is not intended for that.

I doubt that you will save any code in your app.

Likely not. That's not why you'd pick a rudimentary mapper.

I doubt that the less memory usage will be noticeable.

Likely not. It's not why I'd make a decision.

It is not really a problem that the full blown ORM is hundreds
of thousands of lines of code, because maintenance is not
your responsibility.

It's not, no. But that full-blown ORM with 500,000 lines of code (pretty
close to what EclipseLink 2.2 has in its 'org' package [2]) is going to
have quite a few more defects than an ORM with 5,000 lines of code
(DBUtils has about 8,000 [2]).

That is obvious true, but I don't know if it is relevant.

If we follow the traditional rule of 1 bug per 1000 lines
of code, then we will see:

500 KLOC => 500 bugs
5 KLOC => 5 bugs

But there are two things to remember:
1) The same usage will only use a smaller portion of the large library.
2) This is when delivered first time. Bugs get fixed as they get found.
The more the code is used the faster the bugs get found.

If we compare the 500 KLOC library with the 5 KLOC library then
doing what the small library can do may only use 25 or 50 KLOC of
the large library.

If that is the case and the larger library is used so much more than
the smaller library (and the functionality of the larger library
that can be done by the smaller library is most likely the
functionality most used) that there are 5 or 10 times less bugs
left per size, then there may actually be fewer bugs left.

Is this just number magic? I don't think so!

If you want a stable OS and a stable database would you go for
an exotic product with a small code base or a well known
product with a much larger code base?

No particular aspersions on EclipseLink, but when one of those defects
is hurting *your* project, even with access to source it's not
straightforward to fix it, and it's not an overnighter to get the EL
team to do so either. With as few lines of code are in DBUtils source,

*I* can fix it, and readily.

I would not want to fix it. I would want something where you can report
the bug to someone and let them fix it.

The operative word being "could". Leaving aside the other management
capabilities of the persistence context Level 1 cache, like uniqueness
of identity within a PC, if you are constructing objects with a simple
mapper like DBUtils you *have* a cache. Your objects are in memory;
you're not hitting the DB every time you need them.

That is not really level 1 cache.

As for JPA Level 2, well, that's a decision best approached carefully
and not made available by default. I surely don't think you need to go
with JPA just in case you might need Level 2 cache at some point.

If it was just that: no. But there are other features that also could
become useful.

Arne

 

[Arne Vajhøj]

Going off on a slight tangent here, but I've noticed a tendency in
projects that uses a full ORM to do the data modelling away from the
database and let the Java object model "drive" the database schemas.

True.

And for a bad reason. ORM's work best that way.

Arne

 

[Arne Vajhøj]

Simpler project dependencies, direct control over the SQL, less
"architectural weigth", "nærhet til materialet".

True.

But how much does this really impact things in the real world?

*shrugs* None of those would normally make me forego the convenience
and utility of a full ORM, but they are still gains.


Well, there's Android development.

OK.

In that context memory footprint may be important.

Well, maintenance _of_ the ORM might still affect your project
and need to be managed, though.

True.

But I can not see anything being better than JPA in relation
to having a stable API where changes to the ORM does not require
changes in the ones own code base.

Arne

 

[Arne Vajhøj]

A more profane reason not to use JSP is the
fact that it polutes the perm spaces of Java.
One JSP is compiled into a class, and you can
even recompile without stopping/starting a
web context. This is a realy nice feature.

But Java perm spaces can be restricted, and so
it can be prohibitive to use JSP when you
have a great number of templates. This is
not so much a problem when you only need
a couple of templates to generate some DB
beans and other associate Java classes.

But it can be a problem in many other circum-
stances. So one can then lookup one of the
many template languages and processors on
the market, or one can roll an own template
language and processor (*).

Java classes generated from JSP's are no
different than any other classes.

If you generate a class per something, then you
use perm gen space.

And the the classes are unloaded (via GC of
classloader) then the space is released again.

Arne

 

[Arne Vajhøj]

Yes, the argument that goes against <% %> since
they are not true XML tags doesn't work since
the Java source files are generated as
text/plain.

<% %> and <jsp:scriptlet></jsp:scriptlet> are equally
frowned upon.

Arne