We Keep Coding

Is there a missing JavaDoc warning in Netbeans?

I am taking AP Computer Science and my teacher requires JavaDocs. I was wondering if there is a way to make sure that none are missing. I am using Netbeans for the class but I'm sure that others would like to know if it exists for other IDEs too. Also, is there a way to automatically add empty JavaDocs? Thanks for all the help.

You can generate them automatically in Eclipse using a plugin called JAutoDoc. Netbeans 4.0 and up has a feature called Auto Comment which formats your comments to be Javadoc-compliant and also flags up any that are missing, so this appears to be what you're after.
Check out https://netbeans.org/competition/win-with-netbeans/auto-comment.html for details, but the gist is that you select "Auto Comment" from the tools menu.

You are looking for checkstyle plugin that will show you warning in situation when there is no javadoc for method.

In NetBeans, select your project in the Projects window, then select the "Analyze Javadoc" item from the "Tools" menu. This will produce a report detailing missing or faulty (e.g. missing parameters) Javadoc within the project. I've tested this feature personally in Netbeans 10.0, but I believe it's been there since at least version 8.1.
As an alternative to selecting your entire project in the Projects window, you can also select subgroups of packages or classes to check. This is particularly useful if you're not interested in adding Javadoc to your unit tests: you can just select "Source Packages" and run "Analyze Javadoc" on them without producing warnings about classes in the "Test Packages" group.

What's the fastest way to get all build errors in a Java project?

Currently I'm looking at integrating some build processes into my source control (Git hooks specifically). I'm trying to write a pre-commit hook that checks for build errors in my Java project (a medium-large test development project) and fails to allow commits that contain errors in the build. This is turning out to be rather challenging.
The approach here uses a command-line Eclipse tool to build and output warnings and errors. This does technically work, but it's slow and may cause problems with the Eclipse IDE (I've already had heap allocation errors). I've also looked at solutions using ant but these approaches don't seem to be a simple one-line solution, and may still be slow.
My main question: what's the fastest (run-time compilation speed) way to build and validate a Java project, by command line? I'd like a solution that returns 0 with no errors and something else if errors are present, but I'm willing to look at other things.

Let's start with some basics:
pre-commit hooks run on the server and not the client. There is no working directory by default. You have to make sure that javac is available, and is the correct version.
Your pre-commit hook will freeze up the user's terminal until completion.
Now, how long will it take to checkout a fresh copy of your Java project, run Ant, wait for it to compile, and then process the output of the compile? a minute or two? 20 seconds? 10 seconds? Even 10 seconds will feel like forever as you wait for the Git push to complete. And, if other users want to commit code, they have to also wait.
A better, and easier approach is to use a Continuous Build Server like Jenkins. Jenkins is easy to setup. (It comes with its own application server built in) and has hundreds of plugins that you can use to help report the health of your project. If a compile cannot happen, Jenkins will email the culprit and whomever else you mention.
We have our Jenkins setup to do Ant builds, Maven builds, and use either Git or Subversion as our repository (depending upon the project). Jenkins builds the project, keeps the console log, and will fail the build if build.xml fails. At our place, this means I start pestering the developer to fix the problem or to undo their changes. At my last workplace, developers were given 10 minutes to fix the build, or I would undo their changes.
Not only can Jenkins let you know when a build fails, but has plugins that can report on the Java compiler warnings, Javadoc warnings, run Findbugs, PMD, find duplicate lines of code (via CPD that comes with PMD), and then report everything in a series of graphs. You can also mark builds as unstable (build completes, but is problematic) or simply fail the build based upon the number of issues found with these tools.
Jenkins can also run Unit tests, and again graph the results, then run coverage analysis with JaCoCo or Cobertura or Emma.
So, take a look at Jenkins. It's easy to setup and will do exactly what you want and more.

Ant. There isn't going to be a "one-line-solution". Write an ANT script that compiles the code, and fails if there are any errors. It's not easy, but it's the best option.

Out of the choices you mention, Ant is the best. But let's face it, writing XML sucks. My guess is that any build tool will fail and return an error code when compilation fails. My favorite is sbt, but there's a bit of a learning curve if you aren't into Scala (and even those in Scala like to complain about sbt). Another great option IMO is Gradle. You write your scripts in Groovy which is a dynamically-typed superset of Java.

Jenkins may be a something you could look at

Code Coverage Source Annotation with EclEmma

I installed EclEmma for its source annotation abilities relating to code coverage, how it highlights code with various colors based on whether or not that code is hit during execution. I intend to use this information for debugging purposes. The default install adds a "launch with coverage" button, which is what I want. This works perfectly for the entry point into the program; that entire source file gets beautiful coverage information smeared all over it. Unfortunately none of the other project files get the same treatment.
When I go over to the new coverage tab I see my source folder structure and all of my source files are listed along with coverage percentages. This is nice, but I would really like it to add the coverage annotations to my other source files so that I can review code coverage line by line in the rest of my project. Presently even clicking on them in the coverage tab with the percentage sitting directly to the right opens the plain unannotated source file (well, unannotated besides Eclipse's normal annotations for Java code). How can I get EclEmma to add source code coverage information to all of my source files, not just the one containing the point of entry to the program?
I suspect that there is a simple fix that I am missing, but the best I can get from the relevant documentation is how to change the color of the annotations.
For reference I am using Eclipse 4.2.1 for Java development. My EclEmma installation is the one from the Eclipse Marketplace.
Thank you for your time,
-- Techrocket9

For unknown reasons the issue seems to have resolved itself. I can only conclude that the EclEmma does not require alteration to display source annotations for other files, and that a bug in my particular Eclipse install triggered the issue and that the bug was fixed in an Eclipse or EclEmma update.

Standard Java Project Description Format

I'm coming from the .NET world where Visual Studio is pretty ubiquitous. VS has a .sln file which pretty exhaustively describes a project, including where to find source files, dependencies, etc.
Now I'm doing some java coding in a team. My problem is this: I'm using intellij and others are using eclipse (while others could be using some other IDE). Is there a standard project description file that can be shared among IDE's? I obviously don't want to put my intellij specific files to source control. So what I'm looking for is a standard that pretty much any self-respecting IDE would recognize which you could point it to and it would be able to interpret the project structure, how to find dependencies, the class paths, etc.

Maven should be able to do it (a project build manager and source control overlay), but alas, there is no standard project file. There are Maven plug-ins available for all the major IDEs. http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html

Note quite. But you have a "way out". You can use Maven2. It has a unified pom file which contains all:
source folders (note: maven imposes a default convention on those, but they are still configurable)
compiler level
dependencies
build steps
etc..
(Of course that would require to install the maven plugins for both IDEs)
Another option would be to force either of the IDEs and commit their proprietary descriptors.

As others have posted, Ant and Maven are pretty much the de facto project spec utilities in the Java world. Those are both generally easy to learn -- a fair learning curve, but nothing dramatic -- and are pretty powerful. You could speak to your team members or leader and see how they've dealt with it -- I'm sure it isn't a new problem.
Aside from that, a lot of development teams (in my experience, at least) try to avoid putting project files in source control. The developers are required to basically create their own projects in whatever IDE they're using. It makes getting started on a project a little more difficult for a developer coming fresh into an existing project, but it also helps the developer get a little better acquainted with the project.
At my shop (very, very small team), we use Eclipse, but we still have to manage the workspaces (similar to VS solutions, but not quite the same) ourselves. I've created some Ant scripts for use on our continuous integration server, and that won't necessarily keep problems from arising, but it helps make them more obvious when they do.

There is no such standard project description file as far as I know. But intellij is able to take an eclipse and convert to an intellij project. Also you could look at maven.

There is not one. You could switch to an build system using ANT (similar to Make) but that has pitfalls of it's own. You will get the most mileage if you and your team standardize on an IDE though ...

I think what you want here is for a developer using Eclipse to edit the project settings and have those changes reflected in IDEA for some other developer. If that's the case, then Maven is what you want. IDEA 9.x has great support for Maven, and so does Eclipse. If a developer that uses Eclipse edits the dependencies in the Maven project files (pom.xml files), then IDEA can import the files and change it's project settings.
RE: ANT vs Maven - In this respect (syncing project settings) ANT build files won't work because they are imperative (script-like) rather than declarative.

Maven should be the preferred way but most IDE's now days support some kind of ant based project which is what most of the IDES use internally. Usually called free-form projects.

I'm not a Maven fan myself. I'd recommend Ant long before Maven.
If you're using IntelliJ, I'd argue that it does have a pretty standard idiom. And since it can import any Eclipse project file, you'll be on safe turf laying things out as IntelliJ does it.
I don't check in my IntelliJ project files, but the /src, /lib, /test, /resources etc. are all fair game.
The true answer should be that your team should huddle up and come up with a standard layout that you agree on regardless of IDE. You've got to check code into SVN sometime.
Your question is interesting to me, because I'm trying to go in the other direction (Java->C#, IntelliJ->Visual Studio), and I'm having trouble doing the mapping in the other direction.
I think it's just part of learning a language and its native IDE. I find that it's best to find an experienced guide.
One problem you'll have is that the .NET universe is isotropic (all things Microsoft), where even your small corner of the Java universe is heterogeneous (IntelliJ and Eclipse and NetBeans). You're less likely to find one true answer for all of Java.

Clover on Java EE Container

I would like to run Atlassian Clover in a production environment (I don't have an issue with overhead ). Does anyone have experience with this, or can you direct me how to do it?
My goal is to get clover reports based on real users actions. I'm using JBoss + JDK 1.5

You can deploy clover build (along with the coverage.db files generated during the instrumentation) to your servers, add a bunch of clover-specific java options to set it up and then collect the results, merge them using the clover merge tools and generate the reports. See Clover Wiki for detailed instructions.
Please note that by default, clover dumps the coverage data upon process termination - you might want to do some research on how to make it happen periodically. Look into -flushpolicy and -flushinterval options.

found the answer finally , thanks all .
after I created the Clover DB ( cmd / or eclipse integration ) , while starting my App server I add the following params
-Djboss.shutdown.forceHalt=false -Dclover.initstring.basedir=/coverage.db
it will do the job

The general strategy would be to use Clover (or Cobertura or a similar tool) when you compile your web application. If you use maven for doing your builds, you can use the cobertura plugin:
http://mojo.codehaus.org/cobertura-maven-plugin/instrument-mojo.html
To add this easily with the cobertura:instrument goal. You then drop the generated war into JBoss just as before.
You'd probably also be interested in Glassbox:
http://www.glassbox.com/glassbox/Home.html
It doesn't generate code coverage, instead it gives you a high-level report at what's going on and can tell you where you may have bottlenecks.

I haven't used clover in a long time... but I do use cobertura (http://cobertura.sourceforge.net/faq.html) for code coverage. Looking at the FAQ for cobertura it does work with JBoss.