This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm building my first JavaEE web application using Glassfish and Netbeans. However, I'm finding it frustrating because I'm probably spending 90% of my time troubleshooting why it's not doing what I expect it to. Now I understand there is a learning curve but still it's frustrating.
Currently I try to initiate everything from unit tests, e.g. test-driven development. If/when I run into a problem I use netbeans "debug test file" feature to follow the flow of the problem. I'm wondering if there is a better way to troubleshoot issues?
Simply watching the output doesn't seem like enough. For example if an EJBcontainerException is thrown, well that could be anything you and you have to dig for the cause. Sometime the cause is shown in the stacktrace but other times I've had to use the debugger to dig in and find the problem. Nonetheless, all this is time consuming.
One huge time saver for me would be a way to keep the EJBContainer up and running. It currently takes about 30s to start, understandable considering it's an API of the glassfish server. But if there was a way to keep it up that would be nice.
There are some here who would chide you for depending on an IDE to learn complex Java technology. IDEs do so much for you that it's easy to create stuff that you have no idea of how it works and in the process, you can miss key concepts. And produce really horrible, flimsy apps, when you apply this to production work. I speak from personal experience, alas. While I don't really recommend using only Windows Notepad as an editor to learn with, you should avoid using "wizards" at least.
The quickest way to "debug" many application problems is to use a platform which automatically catches and reports errors before you start building on them. Java is outstanding in that regard, since a lot of things simply won't compile until you handle them properly. Conversely, the scripting languages that are so "productive" really aren't, because while they may get the UI up and running faster, they don't have any way to detect things like data type violations until you actually run the code. You haven't really become more productive, just shifted which point in the development cycle all the work has to be done in.
Unit test are definitely a booster. Often, however, they do require a little redesign in order to get full leverage. Unit tests usually run best and fastest when you separate the framework-dependent code from the framework-dependent code so that the unit tester is presented with a POJO. In cases when service calls must be made, a mock service can be much faster than actually invoking the real service.
Customer surveys are for companies who didn't pay proper attention to begin with.