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?
Related
It might sound a little bit weird, but I am looking for a possibility to test if some statements in the code are rejected by the typechecker (which means that the code should NOT compile).
Be explain my intend: I am running a controlled experiment on type-systems where my subjects have to write some methods in java for me. The functionality of the methods written by the subjects can be easily tested using unit-tests, but I also want the methods to be well-typed (which means that some methodcalls should not be allowed).
One way I could imagine to achieve that would be writing the statements which should break the build into a seperate file, add it to the classpath and run javac to see if any error occurs during the build. Although this might work, it does not feel very sophisticated, so my question is: Is there any better way to (automatically) test if some statements are refected by the typechecker?
This is a variation of the Halting Problem, which isn't solvable in the general case. To do this, you have to run (or in this case compile) the code. Therefore, the solution you've already proposed is the best solution.
Have you looked at the Checker Framework? It can be used to static code analysis and more. It might be a good fit for what's you are doing. Here is the link on my answer with an example of the annotation type processor.
Also you may find the Java Compiler API quite helpful. It allows to execute javac programmatically in a single java machine. So you could use it as a part of your tests.
Background: I notice that in many projects almost all classes in the internal code are public and not final, even if they don't need to be. However, it seems sensible to me to make this decision not by default, but only make classes public if they are actually meant to be used from other parts of the system. Having package protected classes is an easy mechanism to enforce boundaries between modules, and serves as a documentation on the intended use of a class.
If there was a (preferrably free :-) tool to protect all classes that can be protected without breaking the program, and maybe make everything final that has no subclasses, that would be a good starting point to start a conscious use of protection mechanisms. (Of course you need to tweak things afterwards.) Do you know such tool?
Caveat: I am aware that there are better modularization mechanisms like OSGI and the planned superpackages and so forth. But in many current projects this is not an option, and using the plain old Java mechanisms is something you can easily do. Also, this works only if you have shared code ownership (such that everybody can change things back to public as needed) and if you are developing an endproduct, not a library for use by others. I am also not too sure about the benefits of making things final - this prevents AOP and mocking.
CLARIFICATION: As I said, I am not talking about libraries that are thrown over the fence to someone who can't change it, but about internal code of medium sized projects where everybody is encouraged to change and refactor everything as needed. When I am talking about package protected or final think of it as "protected until someone feels a compelling need to lift those restrictions". If someone feels the need to lift the restrictions set by the tool, he is welcome to do so.
Even if there was such a tool, (there isn't), a good programmer wouldn't use it... access specification is a design issue best understood and settled by the programmer himself. Think about it... you make a program and run the tool and get everything sorted (Assuming the tool is super-intelligent in the first place to actually understand your program).. then you decide to modify it... extend some classes, etc.. and you end up extending final classes and making objects of private classes.. (and these are few of the many problems you'll face)...
Thing is.. when the tool does its job, you would no longer even understand your own program.
Bottomline.. stop looking for tools to solve your design issues.. (its like asking for tools that will automatically debug your program)
You can have a look at ATL from Eclipse. Although ATL is used to create model to model transformations between different kinds of models, there is no restriction that source and target model are not of the same type. You could create a transformation from Java to Java that makes your current classes protected or final. MoDisco is a toolset of Eclipse makes use of that, just if you want to see examples.
I am wondering if there is a tool that can identify cohesive blocks of code within JAVA source code.
For example if I had a long method that I would like to extract another method from - is there any tool that automatically can tell me large chunks of code that would be worth extracting?
There are plug-ins like PMD (for eclipse) & FindBugs etc., to do static code review which flags code based on rules your configured.
Google CodePro Analytics has an Eclipse plug-in that can provide a bunch of statistics like lines of code and cyclomatic complexity that can be good indicators that a method should be refactored.
I don't think you will find a tool that can automatically refactor 'cohesive' blocks of code into methods. There is too much subjectivity in that.
I looked for a similar tool with another question: https://stackoverflow.com/questions/12016289/tool-for-visualizing-dependencies-inside-a-java-class just on a slightly higher level: a single class.
I think the same answer applies: There isn't anything like that. There are tools though that provide information from which you might extract the information you are looking for.
I'd look into DependencyFinder. It provides access to all the bits and pieces of the code, so you could find clusters of code elements that access a common set of variables. Unfortunately I found the API a little confusing and not well documented, so you'll need some try and error or get into contact with the author. It also probably won't give you access to whitespace I think. But I don't think this is a valid approach anyway.
Another Tool you might want to look into is JaMoPP It should even have information about whitespace. Although it is a Java Plugin you can use the underlying library independent of eclipse (I think).
Check out Sonar It has very good support for finding duplicate code blocks.
Sonar uses PMD and FindBugs underlying. It also generates some custom metrics like class complexity, method complexity which points to classes / methods that are too large and which are candidate for breaking down.
Control blocks (i.e. conditionals and loops) are "cohesive" in that you cannot readily extract blocks of code that cross control block boundaries. Find blocks that can be replaced by a method call, that makes the original method easier to understand. You will have the best impact on complexity by extracting out the regions of deepest control flow nesting, so this is a good place to start. You don't need a tool as such - the code itself has the info you need.
I have a problem which is hard to explain so lets get started:
Context: I have a application running on a tomcat server Lets call it "admin". The admin have an import/export function. Our own application is an extension to that and we need to gather some information when the "admin apps" use the import/export function.
Problem: The third party jar that contain the class ImportController is located there: ~/someFolder/admin/WEB-INF/lib/admin.jar. The goal is to gather the Old project ID and the new Project ID so that our extension can link our class to the right project. Since i know the method signature i though i could use AOP to do so.
Idea: The idea i came with is to put something like idHiJacker.jar that would contain a single pointcut and advice into the ~/someFolder/admin/WEB-INF/lib/ and enable load-time weaving. That advice would simply put the information into an xml file so our extension would be able to read it when we want to put the link back after a project import.
Also i must say I'm a pure newbie with AOP and web stuff. But i do not wish to import a monster for just doing this small operation with AOP. At the moment im reading on aspectJ and AspectWerkz
Question:
1) Am I in the right direction? Do you see anything that would make this idea not work at all?
2) If this is possible what would be the good practice to do it in a very clean manner?
3) Should i do it with AspectJ? AspectWerkz? Or Something else?
4) Am i doing this for nothing? Is there an easier way to do that operation?
Edit: Also if you have good tutorial to link with answer, it would be awesome
Thanks for your time and answer
Question:
1) Am I in the right direction? Do you see anything that would make this idea not work at all?
I can't see any reason why this will not work. Aspect Oriented Programming and cross-cutting concerns apart, the notion of advice is to execute some before or after some other pointcut and often to influence the behavior of that advised function. You are doing exactly that here.
2) If this is possible what would be the good practice to do it in a very clean manner?
There is some inherent chaos with aspects/advices -- since the control flow is hijacked more then a simple sequential reading of code is needed to understand whats going on.
3) Should i do it with AspectJ? AspectWerkz? Or Something else?
I have never used AspectWerkz but I have very good experience with AspectJ; especially in terms of the support here on stackoverflow and perhaps even more on its mailing list.
4) Am i doing this for nothing? Is there an easier way to do that operation?
Unless you can change the code of import controller or change the clients to make extra calls to do the linking thing this interception based approach seems best IMHO.
I have suggestion for a simpler solution - use a decorator pattern to wrap around the third party ImportController, put your functionality before the third party library is called. You should be able to do this since you seem to have access to the admin application.
This is essentially doing what AOP is doing, but using code. Your approach using load time weaver should also work, but is in my opinion complicated - if you absolutely plan to go this way, do use AspectJ.
I have a very quick question - Is it possible to modify the source code of Java API e.g. Junit, JABX ?
I know it seems a very stupid question, but it has been bugging me for a while.
If you can get your hands on the source, then sure you can modify it. It might not be the best option. It might be better to just create subclasses (if possible) and overwrite implementations, and use your subclasses. Or use composition to proxy the library classes. Depends on what you need to do/fix.
Keep in mind if you modify the source of an external library, and upgrade, you have to modify the source again. You might have to change your extensions/proxies as well if you go that route, but experience has taught me that's typically less complicated.
for open source API such as JUnit: yes