• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to recognize code (Java) that can be reuse in different projects

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Recently I was asked to look at existing Java Applications that have been developed in-house.This is not a code review job. But I have to look for more generic pieces of code that can be reuse.
For example Java code that is being rebuilt every time in each application for connection to a DB or ESB. I think of solutions as a Maven archetype for a consistent structure for java application for all teams.

Since I have no experience with this task and have little time to look in every Java class of these projects, I wonder who has experience with this and can hereby give me some tips?
 
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A mvn archetype won't be a good solution. That's for when you want a way of generating similarly structured projects. It can be argued that archetypes actually promote code duplication which is what you're tasked at removing.
What you probably need to do is create common artifacts (jar files) containing the common code and put those artifacts as dependencies to the current projects so that way the reusable logic is in one place.

How to identify the duplicated logic can get complicated depending on the level you're willing to look at this from. e.g all persistence logic could be abstracted into classes that deal with persistence for any tables (e.g using JPA if it wasn't being used) but that might require a big rework of existing logic.
A practical way would be to use a code metric tool across all the projects' code base (e.g jdeodorant). Perhaps even better would be to start writing unit tests for the existing projects. If you have to write unit tests you will be forced to write reusable code. That should point out what bits of code are reusable and can be moved to a common jar file.
Also remember however that, almost all abstractions are leaky.
 
Smarra blaka
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your comment, I appreciate it.
I understand that Mavenarchetype is useful for java structure but can cause code duplications in various projects. Make common Jars makes sense.

You suggested that in a short time I can find duplication code with jdeodorant.
Do you perhaps have an example or a configuration script or XML rules for me to get this quickly running?

Junit test will cost me some more time but it is indeed a good tip. What I not do understandand is your last sentence in which you write that abstraction can lead to leaky code.
Abstraction (Jars) which is kept in one place should promoted better maintainance of the code then every body doing something?
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The last statement is just a warning based on the Law of Leaky abstractions. Typically re-factoring code for re-usability involves identifying abstractions so anyone embarking on this mission should be aware that most abstractions (non trivial) are problematic in some scenarios.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic