Category Archives: Java/Java EE

trying architexa – an eclipse diagramming plugin

Posted on by
1

Architexa recently announced free licensing for individuals or teams of up to three.  I figured I’d run it against CodeRanch JForum to see what happens.

Requirements/Install

The software is an Eclipse plugin.  You get the link after registering.  A different update site is provided for Eclipse 3.X vs Juno (4.2).  I know some CodeRanch JForum developers use IntelliJ IDEA.  I don’t, so I can try it out.  The install was smooth.  I did get asked to confirm I trust the certificate within Eclipse.

One minor discrepancy.  The website says the software is free for individuals and teams of up to three developers.  The email confirming your email and welcoming you says the software is free for individuals and teams of up to four developers.  Moot point at the moment since I’m using it as an individual.  But Architexa should sync these up.

The email asks me to validate my email using a localhost link.  Same for editing my profile.  I can’t click on it to validate.  Hm.. I then went to the website and clicked the “forgot password” link.  This got an emailed password which I could use to validate in Eclipse itself.  Again the change password link is a localhost link.  After entering that password, Eclipse said my account was validated.  So while the links are broken, I’m in the tool.

Learning curve

Architexa asks which projects it should index.  I said just JForum.  Architexa provides good Eclipse “cheat sheets” to start out quickly.

Layered Diagram

This is like a dependency graph for packages.  Very nice.  If you mouse over, you see incoming (afferent) and outgoing (efferent) dependencies.  You can also drill down to see lower level packages.

Class Diagram

Right clicking a package opens the option to create a class diagram.  Two classes generated on top of each other, but I can drag them around (or highlight them or call other attention.)  It is easy to view the source code from the class diagram.  I don’t see how to view the method names/fields in the class diagram.  This info is available in the outline view in Eclipse already though so it isn’t critical.

Sequence Diagram

This appears to be an enhanced editor.  You drag classes into it and it shows calls.  This seems like more work to create.  I tried dragging a few items over and “add all” to get the calls.  Unfortunately calls aren’t so much within one or two classes so this didn’t help much.  I didn’t create anything worth taking a screenshot of.

Overall opinion

The package diagram caught my attention the most.  I really like the dependency arrows.  The class diagram provides a nice visualization as well.  The sequence diagram seems like it would be a good documentation aid if one was creating sequence diagrams for the project.  Which I’m not because we inherited the design of the code and I’m already familiar with the flow.  I think more value would come from sharing documents and using the tool as a team.

For a “real” (paid) project, I”m not sure I’d be so thrilled to keep my documentation in a proprietary tool. Even a free one.  But for getting a feel for the software on a product that is “documentation-lite” or “no documentation”, the layered (package) diagrams and class diagrams provide a nice way to jump in.  Assuming you are using Eclipse already of course.

Eclipse Memory Analyzer

Posted on by
Reply

Last time CodeRanch has a memory leak, a teammate ran Eclipse Memory Analyzer and I ran JVisual VM.  This time, I did both.  I took the heap dump as described here.  JVisual VM told me hibernate was using a ton of memory.

To run

To run Eclipse Memory Analyzer, I needed to launch Eclipse with more memory.  The default wasn’t enough to open the heap dump.  On Windows, I would edit the eclipse.ini file.  On Mac, I instead used a command line.  (I have read that it is supposed to be possible to edit the eclipse.ini too.  Didn’t work the once I tried it.)

./eclipse -vmargs -Xmx4g -XX:-UseGCOverheadLimit

(It was a production dump; just under 1 GB.)

What I learned

The Leak Suspects report was right on. It noted that the heap dump had three large Hibernate Session objects.  I was only expecting one.  We are using Entity Factory (which use Hibernate Session behind the scenes if using Hibernate JPA).  It turned out there was some code which intended to to cache the entity factory, but in fact didn’t for some nightly jobs we have.

try-with-resources and jdbc without sql injection

Posted on by
2

As I was on Oracle’s JDBC tutorial page, I noticed it was using a Statement rather than a PreparedStatement. I grumbled to myself about how this is teaching people to develop using SQL Injection and decided to Google for an example so I could tweet about it.

I was looking for an example of using try-with-resources automatic resource management using PreparedStatements. I searched on google for “try with resources jdbc”. This didn’t go well. I found a lot more of the same example including one from Martjin and Ben whom I respect. It is even that anyone’s example is bad. It is just oversimplified and implies that using createStatement is more common than using prepareStatement.

I then searched for “try with resources preparedstatement” to be more specific about it and found:

  • Informit does use a PreparedStatement but one without any binding variables.  Which means as an example, it isn’t much better.
  • JavaCodeGeeks does the same.
  • Someone on StackOverflow asked how best to do it and got an answer involving a nested try.  Which does work, but the nested try seem less readable than it needs to be.

I propose:


public List<String> query(Connection conn) throws SQLException {

List<String> list = new ArrayList<String>();

try (PreparedStatement stmt = createPreparedStatement(conn);  ResultSet rs = stmt.executeQuery()) {

while (rs.next()) {

list.add(rs.getString("name"));

}

}

return list;

}

private PreparedStatement createPreparedStatement(Connection conn) throws SQLException {

PreparedStatement ps = conn.prepareStatement(SQL);

ps.setString(1,  "test");

return ps;

}

The StackOverflow post proposes:

public List<String> query(Connection conn) throws SQLException {

List<String> list = new ArrayList<String>();

try (PreparedStatement stmt = conn.prepareStatement(SQL)) {

stmt.setString(1, "test");

try (ResultSet rs = stmt.executeQuery()) {

while (rs.next()) {

list.add(rs.getString("name"));

}

}

}

return list;

}

The StackOverflow answer is shorter.  I think the reason I like mine better is that is is easier to template out so the JDBC plumbing is only in a superclass.  Leaving us with

public List<String> query(Connection conn) throws SQLException {

List<String> list = new ArrayList<String>();

try (PreparedStatement stmt = createPreparedStatement(conn); ResultSet rs = stmt.executeQuery()) {

return processResultSet(rs);

}

return list;

}

The subclass then has two methods to implement:

  1. PreparedStatement createPreparedStatement(Connection conn)
  2. T processResultSet(ResultSet rs)  [templated to return type of subclass’ choosing]

Which approach do you like better?