I need advice on how to rewrite a java GUI. Ultimate goal is easier to maintain & enhance.
What I have built is a Java Applet Client interface that acts and behave similar to Eclipse. developer can design their data entry forms without using a single line of code (drag and drop), and define its attribute. This part is pretty well iron out. however, i am left with more than 40,000 lines of codes that is very difficult to maintain.
Each time a bug is occur or a new enhancement, i normally cant program in a more direct way. more than half the time, i need to workaround the problem and that adds up the lines of code.
Consideration:
-Java Web Applet (because it runs on any browser with J2RE installed)
-runs on slow machine
-deployment of around 200 nodes and growing
Problems that i currently have:
-Listeners are all over the place. sometimes is inside the element.AddListener(new listener..). Sometimes is outside of the class, could be in another package that contain all the rest of listener.
Question: is it always good idea to put all listener in another package? if that is that case, i cant use "this." to get the reference i need.
-JTable this is a killer to me :( the problem i had on Cannot access the Jtable column data after set invisible still persist. Imagine i have JTable with 3 column. First column is a dropDown, second and third column is a textfield. Whenever a value choose from dropdown, i need to base on the selected value, and update to the second column and third column. the problem is, if the user click and it click on other row very fast, it will update to a column that is in the wrong row.
-Currently the program is coded in the sense of it is single thread. whenever the user does a http connection to the server side, reading a file, writing a file and etc, i need to make it as asynchronous process so it doenst feel like "program hang". what is the best way to do this?
Really appreciate help here! Thanks!
Lots of questions here and I'm not sure where to start but I can sympathize with you one this one. Unless you have a well seasoned team that has already gone through the pains of Swing application development things can quickly become out of control and unmanageable.
Before you adventure into re-writing a project I would start with defining some simple standards for development. Like package structures and listeners. I would also recommend splitting the application up into well unit tested modules or sub projects.
Also, ask yourself if you really need to re-write the application or does it just need some TLC. As a consultant and Director of IT I see developers always wanting to re-write applications just because they've learned something new or don't think it's up to par. When they come to me and tell me that it's junk and needs to be re-written I usually send them back and ask them to come up with alternative solutions to a re-write and the impact of each solution including - doing nothing. In a lot of cases we didn't write the application at all.
[UPDATE]
Lastly, If you are going to re-write I would use a Domain Driven Design and MVC approach. Yes, I said MVC for desktop applications!. We've had great success with these methodologies. It keeps a good separation of concern and makes things easily re-usable. It also provides the structure to easily switch out the presentation layer. Most importantly it's easy to unit test and any developer that understands MVC can understand the basics of your project without knowing the details.
I have some more thoughts but i'll leave it at that for now. ;)
use dsl for gui:
swinghtmltemplate
swixml
yaml
there are some more of them
this will remove the need to describe listeners, allow binding in dsl manner
Why dont you just reuse the eclipse framework to build your own gui instead of writing it from scratch in Swing ?
I've recently been more and more frustrated with a problem I see emerging in my projects code-base.
I'm working on a large scale java project that has >1M lines of code. The interfaces and class structure are designed very well and the engineers writing the code are very proficient. The problem is that in an attempt to make the code cleaner people write Utility classes whenever they need to reuse some functionality, as a result over time and as the project grows more and more utility methods crop up. However, when the next engineer comes across the need for the same functionality he has no way of knowing that someone had already implemented a utility class (or method) somewhere in the code and implements another copy of the functionality in a different class. The result is a lot of code duplication and too many utility classes with overlapping functionality.
Are there any tools or any design principles which we as a team can implement in order to prevent the duplication and low visibility of the utility classes?
Example: engineer A has 3 places he needs to transform XML to String so he writes a utility class called XMLUtil and places a static toString(Document) method in it. Engineer B has several places where he serializes Documents into various formats including String, so he writes a utility class called SerializationUtil and has a static method called serialize(Document) which returns a String.
Note that this is more than just code-duplication as it is quite possible that the 2 implementations of the above example are different (say one uses transformer API and the other uses Xerces2-J) so this can be seen as a "best-practices" problem as well...
Update: I guess I better describe the current environment we develop in.
We use Hudson for CI, Clover for code coverage and Checkstyle for static code analysis.
We use agile development including daily talks and (perhaps insufficient) code reviews.
We define all our utility classes in a .util which due to it's size now has 13 sub-packages and about 60 classes under the root (.util) class. We also use 3rd party libraries such as most of the apache commons jars and some of the jars that make up Guava.
I'm positive that we can reduce the amount of utilities by half if we put someone on the task of refactoring that entire package, I was wondering if there are any tools which can make that operation less costly, and if there are any methodologies which can delay as much as possible the problem from recurring.
A good solution to this problem is to start adding more object-orientation. To use your example:
Example: engineer A has 3 places he needs to transform XML to String so he writes a utility class called XMLUtil and places a static toString(Document) method in it
The solution is to stop using primitive types or types provided by the JVM (String, Integer, java.util.Date, java.w3c.Document) and wrap them in your own project-specific classes. Then your XmlDocument class can provide a convenient toString method and other utility methods. Your own ProjectFooDate can contain the parsing and formatting methods that would otherwise end up in various DateUtils classes, etc.
This way, the IDE will prompt you with your utility methods whenever you try to do something with an object.
Your problem is a very common one. And a real problem too, because there is no good solution.
We are in the same situation here, well I'd say worse, with 13 millions line of code, turnover and more than 800 developers working on the code. We often discuss about the very same problem that you describe.
The first idea - that your developers have already used - is to refactor common code in some utility classes. Our problem with that solution, even with pair programming, mentoring and discussion, is that we are simply too many for this to be effective. In fact we grow in subteams, with people sharing knowledge in their subteam, but the knowledge doesn't transit between subteams. Maybe we are wrong but I think that even pair programming and talks can't help in this case.
We also have an architecture team. This team is responsible to deal with design and architecture concerns and to make common utilities that we might need. This team in fact produces something we could call a corporate framework. Yes, it is a framework, and sometimes it works well. This team is also responsible to push best practices and to raise awareness of what should be done or not, what is available or what is not.
Good core Java API design is one of the reason for Java success. Good third party open sources libraries count a lot too. Even a small well crafted API allows to offer a really useful abstraction and can help reduce code size a lot. But you know, making framework and public API is not the same thing at all as just coding an utility class in 2 hours. It has a really high cost. An utility class costs 2 hours for the initial coding, maybe 2 days with debugging and unit tests. When you start sharing common code on big projects/teams, you really make an API. You must ensure perfect documentation then, really readable and maintainable code. When you release new version of this code, you must stay backward compatible. You have to promote it company wide (or at least team wide). From 2 days for your small utility class you grow to 10 days, 20 days or even 50 days for a full-fledged API.
And your API design may not be so great. Well, it is not that your engineers are not bright - indeed they are. But are you willing to let them work 50 days on a small utility class that just help parsing number in a consistent way for the UI? Are you willing to let them redesign the whole thing when you start using a mobile UI with totally different needs? Also have you noticed how the brightest engineers in the word make APIs that will never be popular or will fade slowly? You see, the first web project we made used only internal frameworks or no framework at all. We then added PHP/JSP/ASP. Then in Java we added Struts. Now JSF is the standard. And we are thinking about using Spring Web Flow, Vaadin or Lift...
All I want to say is that there is no good solution, the overhead grows exponentially with code size and team size. Sharing a big codebase restricts your agility and responsiveness. Any change must be done carefully, you must think of all potential integration problems and everybody must be trained of the new specificities and features.
But the main productivity point in a software company is not to gain 10 or even 50 lines of code when parsing XML. A generic code to do this will grow to a thousand lines of code anyway and recreates a complex API that will be layered by utility classes. When the guy make an utility class for parsing XML, it is good abstraction. He give a name to one dozen or even one hundred lines of specialized code. This code is useful because it is specialized. The common API allows to work on streams, URL, strings, whatever. It has a factory so you can choose you parser implementation. The utility class is good because it work only with this parser and with strings. And because you need one line of code to call it. But of course, this utility code is of limited use. It works well for this mobile application, or for loading XML configuration. And that's why the developer added the utility class for it in the first place.
In conclusion, what I would consider instead of trying to consolidate the code for the whole codebase is to split code responsibility as the teams grow:
transform your big team that work on one big project into small teams that work on several subprojects;
ensure that interfacing is good to minimize integration problems, but let team have their own code;
inside theses teams and corresponding codebases, ensure you have the best practices. No duplicate code, good abstractions. Use existing proven APIs from the community. Use pair programming, strong API documentation, wikis... But you should really let different teams make their choices, build their own code, even if this means duplicate code across teams or different design decisions. You know, if the design decisions are different this may be because the needs are different.
What you are really managing is complexity. In the end if you make one monolithic codebase, a very generic and advanced one, you increase the time for newcomers to ramp up, you increase the risk that developers will not use your common code at all, and you slow down everybody because any change has far greater chances to break existing functionality.
There are several agile/ XP practices you can use to address this, e.g.:
talk with each other (e.g. during daily stand-up meeting)
pair programming/ code review
Then create, document & test one or several utility library projects which can be referenced. I recommend to use Maven to manage dependecies/ versions.
You might consider suggesting that all utility classes be placed in a well organized package structure like com.yourcompany.util.. If people are willing to name sub packages and classes well, then at least if they need to find a utility, they know where to look. I don't think there is any silver bullet answer here though. Communication is important. Maybe if a developer sends a simple email to the rest of the development staff when they write a new utility, that will be enough to get it on people's radar. Or a shared wiki page where people can list/document them.
Team communication (shout out "hey does someone have a Document toString?")
Keep utility classes to an absolute minimum and restrict them to a single namespace
Always think: how can I do this with an object. In your example, I would extend the Document class and add those toString and serialize methods to it.
This problem is helped when combining IDE "code-completion" features with languages which support type extensions (e.g. C# and F#). So that, imagining Java had a such a feature, a programmer could explore all the extension methods on a class easily within the IDE like:
Document doc = ...
doc.to //list pops up with toXmlString, toJsonString, all the "to" series extension methods
Of course, Java doesn't have type extensions. But you could use grep to search your project for "all static public methods which take SomeClass as the first argument" to gain similar insight into what utility methods have already been written for a given class.
Its pretty hard to build a tool that recognizes "same functionality". (In theory this is in fact impossible, and where you can do it in practice you likely need a theorem prover).
But what often happens is people clone clode that is close to what they want, and then customize it. That kind of code you can find, using a clone detector.
Our CloneDR is a tool for detecting exact and near-miss cloned code based on using parameterized syntax trees. It matches parsed versions of the code, so it isn't confused by layout, changed comments, revised variable names, or in many cases, inserted or deleted statements. There are versions for many languages (C++, COBOL, C#, Java, JavaScript, PHP, ...) and you can see examples of clone detection runs at the provided
link. It typically finds 10-20% duplicated code, and if you abstract that code into library methods on a religious base, your code base can actually shrink (that has occurred with one organization using CloneDR).
You are looking for a solution that can you help you manage this inevitable problem, then I can suggest a tool:
TeamCity: an amazing easy to use product that manages all your automated code building from your repository and runs unit tests etc.
It's even a free product for most people.
The even better part: it has built in code duplicate detection across all your code.
More stuff to read up:
Tools to detect duplicated code (Java)
a standard application utility project. build a jar with the restricted extensibility scope and package based on functionality.
use common utilities like apache-commons or google collections and provide an abstraction
maintain knowledge-base and documentation and JIRA tracking for bugs and enhancements
evolutionary refactoring
findbugs and pmd for finding code duplication or bugs
review and test utility tools for performance
util karma! ask team members to contribute to the code base, whenever they find one in the existing jungle code or requiring new ones.
Currently we are studying the Java based tool which is primarily Reporting tool.It was developed in 2000/2001 period and uses many open source libraries like Apache Avalon/Mx4J.Adaptor/edu.Oswego(java concurrent package) etc. Tool uses jdk 1.3.1 and goal is to upgrade to jdk 1.5.We have also been asked to remove these 'outdated' packages and replace by standard Java packages if possible.
Unfortunately we have the code available for study but lacks any documentation and really difficult to track the flow(Total number of classes written might be more than 1000) during debugging.
Whats the best way to understand this kind of tool? Any graphical tool to see the relationship between the classes?
Thanks,
SR
You could try some of the Source Code Analyzer plugins to eclipse. Tools like DIVER or X-Ray might be useful.
That's a common problem (unfortunately), and again unfortunately there is no easy solution.
There are many tools to help you (see below), but these are only helpers, they will not solve the problem for you.
I have found that a systematic approach is best. There is a good article on this:
Swallowing an elephant in 10 easy steps , about understanding a large, undocumented system. It's about Perl, but the ideas are independent of language.
Some tools that might help:
Step through interesting parts in a debugger (e.g. Eclipses debugger)
Use Eclipse's "Call hierarchy" and "find references" to understand which part of the code uses what
Run tests with simple input data, understand what they produce
Write javadocs into the code documenting what you found, possibly correcting existing docs
Use tools to visualize class dependencies. I have unsed JDepend with some success; there are many others.
Eclipse (and newer version of NetBeans and perhaps IntelliJ) have wonderful tools for analyzing large codebases:
Call hierarchy (CTRL + ALT + H) - you see the hierarchies of calls to/from a given method
Type hierarcy (F4) - you see the whole inheritance structure
Data hierarchy
Right click on item > References
many different search options
Any graphical tool to see the relationship between the classes?
If you want to see the relationship between classes you could try Green UML . It creates a nice UML class diagram out of your repository. It works on Eclipse.
I hope that helps.
You can do it easily in NetBeans.
Select the method signature and press ALT+F7 (or alternately right click and then click "Find Usages") this would show you from where a particular method is being called.
Second option is little hectic but may give some results. Configure log4j for your project and try to give the proper logging code in each method.
Is there an IDE/Tool/script/something that can show call hierarchy and/or data flow in Scala+Java programs (preferably from source code).
Or (as a backup plan) is there a tool that can show it using Java bytecode? (And preferably give the option to go to source code, if provided by user).
All that, preferably integrated into an IDE and/or Maven :-)
The requirement to support Scala is crucial in this question. I Already know of and use such tools for Java, in 3 IDEs. They do not work very well (actually: at all) when Scala is involved.
TIA
Poor man's call hierarchy: Comment the method out and see where your red squigglies show up. [/me ducks]
Did you tried Eclipse?
SBT can do that. You'll have to check it out to get more information, because I haven't done it.
EDIT
Sorry, I confused things. SBT can generate component dependencies, not call hierarchy.
Developers who have used eclipse cannot miss out the Cntrl+Shift+G combo - the easiest way to find all references to a particular member/method/class in your workspace.
Consider a scenario where you are a new guy maintaining a web application written in java. Now, you are about to change a method signature, and you do a Cntl+Shift+G to find all references to the said method (yes, hoping that you are not doing depedency injection / reflection etc). However, a new guy, would want not to screw up any functionality in the application. How would ensure that the functional dependencies are not affected?
I guess..the question is a bit unclear.. lemme rephrase... Say you are changing something functional (an if loop in a business rule or whateva) - this will definetly CHANGE something else in the context of the application.. and at this point you wish there was something (a plugin?) in eclipse, that would tell you - "hey noob..don't change this - it would affect this..." - Now, if you were to create something that does this for eclipse (plugin?) - where would you start? (tagging parts of scr code and introducing a depdency tree? etc?)
Perhaps I failed to understand your question, but I think I might have an answer. Take a look at nWire for Java (or PHP). It is a plugin for code exploration. Focusing on a piece of code, the developer can quickly determine where the method is invoked, where the class is used, etc. This makes it easier to understand what you are about to change.
I am the developer of this plugin. If it is not exactly what you are looking for, let me know, I'll be happy to better understand what you are looking for.
Besides: ALT+SHIFT+C is the way to change a method signature. ALT+SHIFT+G "only" finds references, which is helpful of course.
vickirk mentionend the most important aspect here: Without having tests and a good code coverage you aren't able to apply any changes without risking a failing system afterwards.
The book "Working Effectively with Legacy Code" from Robert C Martin explains it nicely: All code, which is not covered by tests, is legacy code. You could draw the conclusion, that before you apply any functional change you need to ensure a sufficient test coverage.
Tagging parts in the source code seems like a bad idea, since these tags need to be additionally maintained, which usually never really happens in projects. :)
What about JDepend?