Login | Register
My pages Projects Community openCollabNet

If you were registered and logged in, you could join this project.

Summary JavaMeasurementTool: For measuring of java source code.
Category process
License GNU Lesser Public License
Owner(s) martin_kersten

JMT: A tool for measuring and judging Java code

Welcome to the homepage of JMT, the Java-Measurement-Tool. JMT allows you to measure and judge Java code. The methods used for measuring and the rules used to judge the results are fully customizable. Custom measurement-method can also be 'plugged in'.

A screenshot of the JMT application



Why Java code should be measured

Most of today's projects are developed by more then one single person. And mostly the people who started the developing are not the people maintaining and extending the project. So today it is even more critical to think about the structure and the design of code. Is it simple enough? Is there anything we can do to ease maintaining? Is it easy to understand and to learn? Of cause judging code is highly subjectiv and depends on the background and the intentions of the 'judges'. But there are some areas where a measurement-program like JMT becomes a great help.

These areas include:

  • The method and attribute structure of the packages.
  • The coupling between the classes and interfaces.
  • The visible elements of a package, class or interface.
  • The amount of lines of code used for implementation.
  • The access modifier structur of a package.
  • The number of attributes and their accessor methods.
Of cause this list is not complete. Even today we find new interresting aspects about code measuring.

Does measuring change the way I program?

Well to be honest I do not know. My programming style changed because of JMT. Well there are still some design questions left but now I am using more advanced structures and pattern. I also know some of the basic weak points of code that unnessesarly consume manpower and money spent on project development.
Today I am using more interfaces, hide all public classes, which are not designed to be public abstract and use static factories to create objects rather then constructors. And well - I hate public constants. I also started to use the construction pattern (sometimes referred as composing pattern) in a better way while adapting some thoughts from psychology.

While developing JMT I done a redesign of the code to reflect my increased knowledge and my changed emotional expectations. I introduced new types (interfaces describing objects), hide all implementational aspects and added public factories to create instances of the types. So I eased the public structure dramatically and also reduced the overall lines of code. After I switched to factory creation instead of constructor creation, the constructors became much simplier and the factories now mostly implement the flyweight pattern which is mainly the root of siginificantly reduced memory usage and also reduced execution time.

And that was caused by a bunch of numbers and some bad marks. Weird, isn't it?