Tuesday December 04, 2007 Next, Janos Koppany from Intland (Stuttgart) introduces us to his Jolt-award winning change management tool, CodeBeamer. He compares CodeBeamer to other project hosters like Sourceforge - its purpose is to help a team to manage their application lifecycle. Check out javaforge to get the picture. You'll see that Codebeamer has a web interface that offers tons of services (cvs, wiki, build management, forums, bug reporter, etc) for your team. There is an integrated CodeBeamer plugin for NetBeans for developers, and a webapp version for managers. (A plugin for 6.0 will soon be released).
Next one is Jaroslav Bachorik. He demos a NetBeans feature that, to his surprise, only a small number of developers in the room know and use: The NetBeans profiler.
But now there is no excuse anymore, since the profiler is now fully integrated and pre-installed in NB6. :-P The catch about profiling is: If you profile a whole app, the whole results gathering process will most likely run pretty sluggish. If you however restrict profiling to critical parts, you will gather results much faster. The NetBeans profiler understands your project and lets you select individual methods to profile.
So, a question form the audience was, whether it was possible to profile a set of methods described by a regular expression, such as "foo*bar"? No, currently, the star operator does only globbing (org.package.*). To get results for a subset, you will have to profile a superset of methods and then filter the results by the specified regular expression.
Jaroslav also shows some real-life use cases, among them an actual memory leak that a NetBeans user found in the HttpUnit app. The user noticed that the number of generations (= objects of the same age) increased and a certain kind of objects was never garbage collected (object age = how many garbage collections it survived). He found out that the problem was an array of exception objects, silently caught and collected, until the array overflowed.
Another interesting feature are profiling points (similar concept to debugger breakpoints): How often do you add code here and there just to count how often a method was called, or when, or how long it ran? Don't clutter your code with these unrelated things, use profiling points instead. :) Learn more (e.g. a heap walker) about the profiler on the new product pages.
Posted by seapegasus ( Dec 04 2007, 06:08:42 PM CET ) Permalink