Author Archives: Jeanne Boyarsky

copy & paste

Posted on by
1

Virtually all of us are guilty of copy and paste “reuse.”  There are different types of reuse though and each come with their own set of problems and gotchas.

Copy/paste a method or large code snippet

This is the kind of reuse that almost everyone will agree is bad.  When all is said and done there are two copies of the code.  If a defect is found, it is likely to be fixed in one and not the other.  Which is bad because an avoidable defect now stays in the code.  This practice is hinting we should extract a new method and call it from the original code and our new code.

Copy/paste a code snippet and then change some values

While less blatant than the copy/paste a method code, it is still a code smell.  This practice is hinting we should be refactoring into a new method that takes some parameters.

Copy/paste a code snippet and then change the body

This approach tends to be used for boilerplate code.  One common example is copying the Java code for a regular expression replace loop and then changing the middle where the replace logic.  In languages with closures, the need for refactoring is more glaring.  In Java, it becomes a call on whether the reuse is worth it.  For tiny examples, it tends to not be.  For more complex examples, an inner class or inheritance is often the answer.

Copy/paste an idea

The hardest type of copy/paste reuse to detect is when it is on a conceptual level.  A copy paste detection tool is unlikely to find it as the code wasn’t copy/pasted.  This kind of copy/paste reuse occurs when someone is trying to figure out how to accomplish a task – say develop a DAO.  Suppose the developer is new and doesn’t know what to do.  The developer sees some code that loops through a result set and decide to use that idea.  Then the developer sees some code that says getString() and copies that for all the types.  This is all well and good until the data types aren’t varchars.  Now the developer has getString() being used to get numbers and Dates too.  Worse yet, this will not crash and appear to work.  However, it will create other problems such as figuring out how to parse the date.  If you were to ask the developer why they are using getString() instead of getDate(), the developer won’t know.  This is fairly low level example.  The same can happen on a higher level such as why the developer is using JDBC instead of JPA/entity beans/etc.

JavaRanch’s statement on Not being a code mill gets into this.  Experts from the page “We are not, however, a code mill and make a point not to give out working code to someone who wants to … dump it into their project without knowing what it does. … that will help you to learn how to solve your problem using best practices.”  I think this is an important point in all levels of reuse.  While copy/paste reuse may appear to work at first, it doesn’t help in the long run.

When the copy/paste code causes defects in the future or needs to be modified, it needs to be understood.  “I did it that way because some other code does” doesn’t make for a helpful reason to the team down the road.

EJB3 – annotations vs xml

Posted on by
2

Scott’s recent post on EJB3 got me thinking about annotations as a “replacement” for XML.

By now, we all know why shoving everything in XML isn’t the best of ideas.  I think shoving everything in Java code is bad too.  In particular deployment time concerns (like security) shouldn’t require a recompile.

JEE 5 offers the ability to choose whether to use all annotations, all XML or a mix of annotations and a partial deployment descriptor.  Yet most of the articles and books I’ve seen encourage using annotations for everything and the deployment descriptor as some kind of legacy practice or anti-pattern.  This reminds me of the situation where most people agree code in a JSP is bad practice and yet it keeps coming up due the vast quantity of beginner books with code in the JSP.  From reading the books, it sounds like EJB deployment descriptor XML = bad regardless of whether that is the case in practice.

I do think the annotation approach is fine for the mapping – unless you are developing a common component that will be deployed to different schema definitions.  Most of the time, the schema is stable as Scott noted.

Let’s look at some of the things in an EJB deployment descriptor (for a session bean):

  • Bean Type – This is a coding concern and as such fits well in the Java code.  If my bean changes from stateful to stateless, I should be looking at my code.
  • Security Settings -This is a deployment time concern.  There’s no reason a role change should mandate a redeployment.  Or that the developers know this information.  The application assembler or deployer could add this in.  As such, the security settings are well suited to being in an XML file.  This also has the advantage of a reusable component provider being able to provide generic information and the integrating applications specify XML info specific to their application.
  • Transaction Settings – This one could be argued either way.  If certain settings such as “required new” are needed, it makes sense to specify in the code to hint at this.  At the same time, the correct transaction setting could depend on the integrating application.  I think transaction settings could be a use case for specifying as a Java annotation and allowing/suggesting the integrating application override in XML.
  • Resource References -Resources are both a coding concern and a deployment time concern.  The code certainly cares that the correct resources exist.  And the deployer cares that they are linked correctly.  Luckily, this scenario has existed for years and there already exists an approach.  The reference name and link to the JNDI can be specified as Java annotations since they are coding concerns and likely stable.  The deployer has always been responsible for setting up the correct resource in the JNDI.

None of these are hard and fast rules.  They are just meant to get people thinking about when to use Java annotations vs XML for the deployment descriptors.  We don’t want to just use Java annotations blindly because they are there.

As more people migrate to EJB 3, I think we are going to see some of a “I’m not going to have a deployment descriptor at all now that I can do everything in Java” mentality.  We’ll have to see if it is going to take a swing to far in the other direction (no XML) before people realize some things belong in Java while others belong in XML.