As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I already have used the Google CodePro AnalytiX but I never used Findbugs.
My first impression with Findbugs is that it is harder to configure. After that, I believe that both are similar.
What's your opinion?
Just one more question related: None of these plugins sent our code to the servers, right? (for example, if we use CodePro our code isn't sent to Google Servers).
Update in 2016: CodePro Analytix is not available anymore, so go with Findbugs.
Original answer
better in CodePro Analytix:
Issue level (error, warning, info) can be changed for every item. Findbugs can only enable/disable issues.
Many issues can be configured in detail (like the list of blacklisted swear words).
Can show you all the issues in the currently opened editors (and adapts this when opening or closing editors), which is much more convinient then selecting packages, projects or whatever and then to manually trigger a scan on them
Several issues can be fixed automatically (like declaring all parameters final). In Findbugs everything must be done manually.
better in Findbugs:
Is more concentrated on typical Java programming bugs (but does not have the rich selection of issues like CodePro)
does more analysises that need a lot of context information
can be used locally in Eclipse or on an integration server like Hudson/Jenkins
configuration on Hudson/Jenkins and in local IDE can be shared, so you see the exact same results in your IDE and on the server
has a "cloud mode", where distributed teams can share their findings (and the evaluation of the findings), so that they do not all check the same issues again
All of the above was more related to how you can work with the tool. The actual finding of bugs may depend very heavily on the project to be checked. In the past I often suggested to use both, Findbugs first, CodePro afterwards:
Do the first checks with Findbugs, as it finds the more severe issues. But after those have been fixed, you may find yourself in lots of noisy issues (or even false findings). Therefore after working on the most severe issues of Findbugs, I suggest switching to CodePro Analytix as it has less false findings and can be controlled in more detail.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Files will ship with bugs, and companies will always want to provide new features. There must
be a way to distribute new files with the hope that the applications will work just fine. And if the application doesn't work fine, there has to be an easy way to restore the application to its last-known good state.
I know this will be general question but I think that is also a general problem.
Comparisons of the solution in different platforms will be amassing.
Dear friends, Actually I am not talking about How to develop software,
Its about How to deploy software with minimum side effects on end users machine
(should be step 0, or -1) use a capable source code management tool, and use it to its full potential: especially branching)
Test Driven Development - always have tests for what you can test, and design code to be testable (to the point it is feasible, of course.)
never do any of these two the same time:
refactoring
introducing new features
fixing a bug
use continuous integration wherever possible
Reverting to "last stable" release in case of emergency
This must be supported by some infrastructural decisions, like keeping around the last stable release compiled and ready to be redeployed if something goes awry despite the efforts (been there, done that)
You should do unit testing. That's a good solution to avoid and track regressions.
But you can't just fast make a change in a big application and build a test unit ensuring everything is OK. You have to make a bunch of test units.
Which is costly, but there is no cheap way to ensure an application is bug free. The only solution is to dedicate a lot of work to testing, be it using unit testing or human testers or both. There's emphasis on that point in Joel Test because a serious team must spend enough in testing.
Restoring an application to an old state is just having a good version control system and not a mess with configuration and data parts. Some VCS have tools to help you find when a bug occured, for example git-bisect.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I need something that is competitive to Volusion/Magento in terms of features. Cost is not an issue.
Thanks
I've been watching the situation around shopping carts for past 5 years very closely. Imho the only carts that are worth trying :
jadasite
konakart
shopizer
Broadleaf Commerce
ofbiz
I've used all of them now. The first 3 are sort of out-of-the-box. I prefer jadasite and shopizer, because they are opensource projects and you have all the Konakart's paid features for free in Jadasite. And from what I know they are even better. You can install these shopping carts and go.
If you are skilled developer and want to spend a month or two playing with a nice technology, or you need a solution for a middle - big businesses, try ofbiz, because ofbiz gives you a platform for building enterprise class e-commerce solution.
Finally, Broadleaf Commerce is somewhere in the middle. I blogged about it recently. Great technology stack, very experienced project lead. You have to have at least a year of java dev experience, because the way of integration and customization has "integration" nature, based on Spring beans/services/controllers or persistence entities overriding/merging/adding ... But it is very simple principle and I was able to work on a custom shopping cart even the same day when I checked out the code from svn.
http://ofbiz.apache.org/
ofbiz includes;
Open Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, Open Source SCM, Open Source MRP, Open Source CMMS/EAM, and so on.
ATG is an outstanding package. It is highly extensible, completely skinnable and very scalable. It is used by many of the largest online retailers, has a strong network of partners and support is quite good. ATG provide training courses for developers and architectural consultancy services. It includes integrations with advanced search, CRM, trouble ticketing and many allied functions.
All that having been said, it is closed-source, obtuse, complex, expensive and has a steep learning curve. It uses a proprietary ORM that mimics Hibernate and other language constructs that parallel J2EE or Spring such as dependency injection, but in it's own special way. Don't assume that your average J2EE or Spring developer will be able to pick it up quickly.
You do need to be careful of some of ATG's implementation partners, some of them are stacked with developers that have barely completed the standard ATG training program and you would be better off training your own staff. Check their references and make sure you actually speak to past clients.
Standard disclaimers apply, I have no affiliation with ATG, caveat emptor.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am trying to use Spring for the first time in an application. The general issue that comes up repeatedly is how to debug Spring. The framework is configuration heavy so traditional code debugging seems fruitless. I have no real idea how to go about troubleshooting short of turning on the debugging level logs (which are lacking) and scanning through.
Are there any general tips or tools to assist Spring debugging?
If you're using Eclipse, then get hold of the Spring IDE (available from the Eclipse Marketplace within the Help menu of Eclipse). This will provide code-completion, bean visualisation, and hot-linking to your config files.
I don't think Spring debugging should be any different to any other debugging scenario.
What aspects of Spring are you using ? If you're using dependency injection properly, then I wouldn't anticipate any problems.
However if you're dynamically resolving beans via their name (at runtime, using ApplicationContext.getBean()) then I can see that's going to cause you problems anticipating flow of control etc., and would suggest that you revisit your IoC.
EDIT: It's quite useful to have the Spring source code available. It's well put together and quite readable, and therefore possibly of use when debugging.
I generally just use the java debugger in eclipse - it works fine on most classes. Some classes are wrapped at compile/runtime by bytecode changes - for these you generally cannot put breakpoints in methods, however you can set a breakpoint at method entry.
If you have a very specific situation you maybe should elaborate a bit in your question.
I'm generally also ok with the logging levels - what do you think is wrong with them?
As of 09/2011 (Version: 2.6.1.RELEASE, Build Id: 201105041000) a real annoyance is the fact that the debugger doesn't stop inside closures, so you have to remember to put a breakpoint inside the ones you want to examine; that is fine as it is "almost" going to a different class which a lot of time doens't matter, but when it does, you have to remember that.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm familiar with a handful of the free static analysis tools available for Java, such as FindBugs and PMD. What I'd like to know is how the commercial products such as Klocwork and Coverity stack up against these. What are their strengths and weaknesses?
We use a suite of open source and commercial static analysis tools. The different tools find different kinds of bugs and some are tuned for lower false positive rates, at the expense of possibly missing some real problems.
In my experience, Findbugs does a good job of finding real problems, especially if you focus on Correctness errors as their team suggests. Recently the developers of Findbugs have added some basic security vulnerability checks as well. Coverity has a low false positive rate especially if you don't turn on their experimental checkers, and Coverity Prevent includes a good tracking database for trend/cluster analysis. I am not convinced yet that their threading checkers (static or dynamic) work - at least they haven't found anything interesting for us. Klocwork Developer for Java returns higher false positives, but we find they have the strongest security checking of these tools. So it depends on whether your priority is quality checking (Findbugs, Coverity) or security vulnerability analysis (Klocwork, or Fortify). Some of our developers also use PMD to support source code reviews, as it helps with general code cleanup.
A recent project conducted with NIST called "SATE: Static Analysis Tool Exposition" reviewed a wide variety of different tools and their underlying approaches.
https://samate.nist.gov/index.php/SATE.html and other references to this project such as at OWASP.
The general finding is that different tools have different strengths and weaknesses, so use more than one if you want to do a thorough job.
I'll suggest you to try SONAR an open source software quality management tool, dedicated to continuously analyze and measure source code quality.
This soft take the result from code analysis tool, consolidate that results and give you access to an user friendly interface.
The one feature you will most certainly find in a commercial static analysis tool (and that you will not find easily in a freeware analysis tool, at least in 2008, at the time of the OP) is
Reporting: Measures software quality trends over time
As explained in this question about code metrics, any static code analysis in itself in not always meaningful, because you could have:
too many "defects" to fix
too many categories of defect reported
You need the ability to do some triage, and you need to check if a particular defect is occurring less and less over time or not, in order to help you prioritize what to fix.
This is especially true on legacy project with thousands of classes: you do not fix defect on many files just like that, without having a good reason. That reason can be deduced from a good reporting and trend analysis you will not find with freeware tools.
Update: from 2012 (4 years later), Sonar (Now in 2018 named "SonarQube") "Historical Information" (aka "Time Machine") in its 4.x and 5.x series.
Note those project dashboards were dropped in SonarQube 6.1 (Sept. 2016): see this thread.
Those dashboard would need to be re-created manually through a custom page.
SonarQube 6.5 restores a bit of those dashboards with the Activity page, which gets (several predefined and one customisable) charts to display the evolution of a project.
I have not had direct experience with Findbugs or PMD but have met plenty of people who have compared them with Klocwork and Coverity.
My general take on the feedback has been:
Findbugs and PMD are more "tool-ish". The type of thing you'd run on your desktop. It finds a wide range of potential problems but tends to be noisy, meaning false positives and "I don't care" varieties. It does find some good stuff. I've heard mixed feedback on its long term use. Some feel that the ROI on a free tool is infinite however there is a true cost to false positives.
Not surprisingly, Klocwork and Coverity, which cost money, tend to be more solution oriented that can also scales better to work with teams, has a more efficient, easier to use UI and tends to be less noisy. It seems their analysis is doing deeper inspection and therefore coming up with better results if you did a side by side comparison. When adopting a tool across a team, you'll have various levels of enthusiasm for using a tool and the noise factor is a big issue that prevents widespread adoption. Of course there are things like having support to back you up, etc.
In general, because Findbugs and PMD are free, you see that as a first option. Many companies see value and choose Coverity or Klocwork for a longer term solution although I see also running Findbugs and PMD. They tend to find different things and so if your goal is to find and fix as much as possible, it's good to have a combination of both.
Disclosure: I work for Code Integrity Solutions (codeintegritysolutions.com) which is a partner of Coverity.
here's a list of commercial analysis tools : http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Java_2
coverity has several tools :
http://www.coverity.com/html/coverity-readiness-manager-java.html : this should be on par with findbugs and PMD but with better presentation
prevent : http://www.coverity.com/html/prevent-for-java.html : low FALSE POSITIVES.
thread analyzer : http://www.coverity.com/html/coverity-thread-analyzer-java.html : this is what is absent in most open source tools.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Being vaguely familiar with the Java world I was googling for a static analysis tool that would also was intelligent enough to fix the issues it finds. I ran at CodePro tool but, again, I'm new to the Java community and don't know the vendors.
What tool can you recommend based on the criteria above?
Findbugs
PMD
Checkstyle
Lint4J
Classycle
JDepend
SISSy
Google Codepro
FindBugs, PMD and Checkstyle are all excellent choices especially if you integrate them into your build process.
At my last company we also used Fortify to check for potential security problems. We were fortunate to have an enterprise license so I don't know the cost involved.
I recommend FindBugs. http://findbugs.sourceforge.net/ Good in assisting to do code review.
IntelliJ IDEA from JetBrains. They also do ReSharper in the .Net community.
Sonar is a quality control tool. It gauges quality of Java applications through the observance of coding rules conventions, metric measures and advanced indicators.
Sonar is based on the following projects :
JavaNCSS: Quality Metrics
Checkstyle: Style Cheking
PMD: Code scanning for potential errors.
Cobertura: Test Coverage
You could also use Simian for duplication detection.
CRAP4J is not only an awesome name but it's quite useful. The other good ones are all above, best of all (IMHO) is FindBugs, because it really does find honest-to-goodness bugs right away in a big code base.
You can try JavaDepend, it complement other static analysis tools, and provides a CQL language to query code like database,
JavaDepend provides also many interactive views to understand the existing code base and more than 82 metrics.
All the above are great tools. PMD is probably the most common.
Another tool is Enerjy. It recently became free, so you can download it and try for yourself. Enerjy is somewhat more organized and a better fit to larger teams. It makes it easier to customize and share the rules. Personally, I'm not a big fan, but maybe you'll fancy it more than I do.
Couple of commercial vendors that have a Java offering:
Klocwork
Coverity
They won't "fix the issues" they find (nor will, I believe, any of the other ones mentioned above) but these are all tools that have varying strengths.