We Keep Coding

How do you fix bugs and add features to a source file and also guarantee that you don’t break some applications? [closed]

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.

Findbugs vs Google CodePro AnalytiX (Eclipse plugins) [closed]

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.

Java-based i18n/L10n [closed]

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've seen internationalization implemented in a classic ASP shopping cart as a most-massive monolithic dictionary of (int,String) key-value pairs, where the calling code passed the dictionary an integer representing which string was to be returned (binary-ORed with the desired language id) and the value for each unique int was the "internationalized" string.
This seems like a very, very, very horrible way to implement i18n.
I'm in the "pre-design" (if there is such a thing) phase for a Java-based Swing application that I would want to be internationalized. Not that I speak anything other than English (ha!) but it would be nice to expand into other languages in the future without having to refactor 20,000 strings.
So, this begs the question: what are the best practices surrounding Java-based i18n (and L10n for that matter)? What sort of classes & structures are used? Obviously, if this winds up as one big com.myproject.i18n package with an "Internationalizer" class as the common gateway for the rest of my code, I would want this to be a singleton class, yes?
Just a request for some food-for-thought here, any nudges in the right direction are greatly appreciated :-)

The idea is to work around properties files. They are easy to work with and you can extend this system easily.
You can find a nice answer here.
Netbeans have also a great sample tutorial.
After you get your languages right, you will need software to switch locales, localize dates and amounts etc. Kai Toedter' tools are very reliable. You can add these beans to your IDE and drag and drop them to your JPanels.

You can create your property file and insert them into iL10Nz.
In order to evoid context issues, it is good to have a scrrenshot for each strings that you are progressively creating. This will pay off with the languages you will translate into
Check http://www.myl10n.net

You can take a look at Gettext Commons. It's i18n in gettext-way for Java. It has Maven plugin for generating, updating and compiling PO files. Personally after some time of use found it's easier to go with standard ResourceBundles.

i using netbeans for developing GUI application based on Swing Application Framework [SAF]
and you can get powerful tools for internationalizing Project on Netbeans IDE.
look at this article : Internationalizing a GUI Form

What are the benefits of Java? [closed]

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 always hear that programmers try to pick the right tool for the job. I've never programmed in Java, so I was wondering What are its benefits? Why is it so popular? What should I use it for?
I just program recreationally. Is there anything about it that makes it particularly fun??

I think after 12 years or so, the "write once, run anywhere" mantra is almost true. Writing Java code pretty much isolates you from the platform dependent aspects of the systems on which you deploy it.

Portability
Incredible breadth of libraries
Bottom-up security
Performance
Robustness

Massive communities, the amount of help, libraries, IDE's, is huge (and thats a good thing).

For a casual programmer Java can teach a lot about object-oriented programming, and encourage good programming habits in general, without the need to worry about as many of the "messy" details (pointers, memory management) as, say, C++.
It's also a bit easier to debug "catastrophic" errors.

Java is really good at integration - there are specifications and implementations for integrating with many kinds of systems that you're likely to run into in an "enterprise" environment.
It's not really a "fun" language relative to popular high-level languages.

This seems to be getting healthy answers, but you might also want to look at "Why do people use Java?"

Java is a good language, but that is secondary to the importance of the standard library that comes with it. The jdk may not be the most elegant kit ever built, but it is extensive, powerful and reliable. Programming in Java the language is simple. Programming with appropriate reuse of the jdk is what it is all about.

Cross platform is in my opinion the most relevant benefit.
The main goal of Java was to create a programming language that could run anywhere. The target was GUI apps. This however never happen because the environment was too slow at the beginning ( now it has been improved ) but it prove true in the server side where the cost of development reduced a lot because the product development can be done in PCs and the deployment in very expensive hardware.
It brought easy of development also, because it was designed to have C++ like syntax but running on a virtual platform to avoid platform specific code. At first the penalty was the execution speed, because it was interpreted, but release after release the interpreters became more and more faster that even MS model its next generation of development after java and call it .net
Additionally You can have a read of the Java design goals here

I want to add one point: Java keeps a good compatibility to earlier versions. That means, your Java-projects are compile and run in most cases without any problem on newer versions. That seems to be a little point, but this stability in API's and language helps to build a big community around Java, including good tool-support.
Others already mentioned other important points:
good portability
lot's of libraries for nearly anything
easy debugging and easy to catch problems

There are only two reasons to use Java:
The Java Virtual Machine (Hotspot).
The huge amount of available libraries and tools.
There are other languages that run on the JVM and make better use of Java libraries than Java does, however.

After using Java for some time, I've come to the conclusion that it's fun to write in, limited in some very irritating ways, and it's performance is good though it seems that many programs are crippled by poor design.
I'm not sure if the latter is a function of Java, or an effect of Java.
In either case, in addition to all of the above stated benefits it's very useful for doing "net" related things. Treating resources with a simplified interface regardless of "where" the particular resource is, etc...
It is by no means a universal hammer.

oop provides like encypsilation ,inheritance,polymorphism not available in traditional programing .oop is closer to real life presentation of the programming
1. Relation ships can be representation using inheritance
2. Programme developement become easy due to increased modularity

How do commercial Java static analysis tools compare with the free ones? [closed]

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.