Top posts
Latest articles
Netbeans 6.5 Final Release
(No Ratings Yet)
Loading ...A short while back I wrote a quick review on the beta of Netbeans 6.5 and that it had some issues. Since the final version was released some time ago I thought it was time for a new review. This time of the final version.
The reason for me not to write one straight away was simple, I first wanna play around a little to find all the pleasant features and those less pleasant ones.
Bigger, better, best
The first thing you expect is this new version to be bigger, better and the best one yet. Well it is bigger in size, with 190MiB for just Java development. So this means a lot more time downloading, but hey that’s a one time thing.
So lets move onto something more relevant. Is it better then Netbeans 6.1. Lets summorize some of the issues I had with the previous version and see if the problem is solved:
- It crashed when working on larger projects. This issue has been fixed, netbeans won’t crash or hang. Though on occasion the parser may crash. Disabling autocomplete and syntax checking.
- For some reason previous versions had difficulty displaying the names of parameters when using Java libraries. For as far as I’ve been able to determine this has been solved.
- The autocomplete completely fails in some more complicated web projects. Well I’m sorry to say this is still true. For some projects not only does autocomplete fail, but so does the syntax checker, both for the JSP files as well as the Java Source files.
So are there any other changes that would make you consider moving from Netbeans 5.5 to 6.5?
New stuff you will like in Netbeans 6.5
Well have there been any changes that would make you wanna switch to the new version.
- The new version actually has some basic debugging integrated of JavaScript. Though I haven’t got it working yet.
- PHP development is now support. Which is a big plus, but it still kinda feels like a cheap addon that doesn’t work perfectly yet. (Maybe in the next release)
- Thread debugging has been improved and made easier
Unfortunattely not all is good in the world of Netbeans. There are also some new bugs, some of which are really annoying.
- For some unexplainable reason adding of libraries by right clicking the ‘Libraries’ in the project view doesn’t work all the time.
- Like I stated earlier the code completion fails in some of the older Java project I’m working on. Not only does code completion fail, but the syntax checker tells me every single line is wrong. Even though the project compiles beautifully
As a final note: is it worth upgrading to this version. Then I’d have to say hell yeah, it’s a lot better then previous versions. If you are a PHP developer however I suggest not using it, for the moment. Especially when you are already using Zend-Studio, which is still a lot better.
Netbeans 6.5 Beta
Since I have to use Netbeans at my work, I always try and find the best version for me. In my case this means a version that runs quickly and is sorta stable. Since the new Netbeans 6.5 beta was released I decided to give it a shot.
First things I was seriously hoping was that they fixed the bug with Netbeans not recognizing the names of function parameters of libraries. This is a problem which got me so pissed that I switched back from Netbeans 6 to 5.5, which did not have the problem. Both Netbeans 6.0 and Netbeans 6.1 had the same problem with function parameters.
Let’s just say that on this they did not disapoint. The new Beta version has got no issues recognizing the names of function parameters. So that’s a serious improvement of the previous releases. I also like the new style for debugging and code editing.
The only real issues so far are the fact that with large web applications Netbeans 6.5 constantly hangs and stops responding. Another issue is that the debugger does not highlight the line that it’s on. The latter is probably a simple fix, but it does make debugging slightly difficult.
So lets wait and see if some of these issues get resolved in the final release.
How To Get An Accurate Session Count With Tomcat
Recently we started to notice that even after disabling a server in our loadbalancer we still get traffic on it after two months. At least for as far as we count it. We currenlty count traffic by using the SessionListener to get notification of people leaving and coming, but somehow our counter gets stuck at about 500 sessions 2 months after switching the server of in the load balancer.
Some time back I already wrote about the setup we use in counting sessions. Read more on that in the ‘Cleaning Up Java Sessions’ post. We put live this change some time back. But I’m still having some issues with the sessions.
What we do is something like this. When a user comes in through a servlet we look if a specific object is set in the session. If not we invalidate the session and add the object. In a seperate class we catch all session starts and destructions.
Upon the session start function in HttpSessionListener we increase the counter. Upon the destruction of the session and if the our session object is set we decrease the counter. But for some reason we have some sessions that do not get cleaned up by Tomcat. Or there are some users that simply stay online for over 2 months.
To get a semi accurate count of the active session I looked into getting the amount of active sessions from the Tomcat StandardManager class. In theory you would be able to obtain this through the tomcat implementation of the HttpSession object. But for some reason these objects are package protected.
There has to be an easier way of getting an accurate count of the amount of active sessions through the tomcat API.
Cleaning Up Java Sessions
As part of a migration from Resin 1.3 to Tomcat 5 we had to migrate servers that are session based. Because we wanted to measure the time someone was on the website a listener had to be used. In resin this was done by implementing a HttpSessionBindingListener. But when we migrated to tomcat our measurements no longer worked.
Once a session became invalidated the HttpSessionBindingListener valueUnbound method was called. During this call we used the getLastAccessedTime() on the session to figure out how long the session was idle before the session was cleaned up.
During the investigation as to why the idle time was no longer logged we found out that for some reason the valueUnbound was no longer working the same in Tomcat as it used to in Resin. After some debuging it appeared as if the HttpSession.getLastAccessedTime() could no longer be used at this stage of the clean up. Every time you tried to access it I got a IllegalStateException.
Some searching on the web later toled me that this was because the session is already invalidated at this point. And an invalidated sessions information cannot be trusted. So what I had to do is build another listener. This time one that is more generic and catches all session deletions. The class to implement in order to do this is called the HttpSessionListener. The methods on this class are called when a session is made or destroyed.
By storing the last access time during the destruction the idle time is available.
Why It’s good to have the directory structure match namespace structure
Before I dive to deep into a point bullet list as to why this is important let’s first explain how I got to this point. For the past year or so I’ve been working in Java. One of the few languages that I know of that automatically creates a new directory for each package created (similar to C++ namespace). If you don’t pay any attention to it you’d never even know it does this.
But when you want to look at files in the file explorer you might have some trouble finding the right file, and you may find expanding all the directories annoying (I know I did ). Especially when you are browsing the SVN or CVS when each folder takes forever to load 
.
As I noted in the first paragraph were over a year further and I must say that I like structuring the folder structure the same as the namespaces in the code. Let me explain why.
Easier to find a class
Though you may not notice it at first, but it is easier to find a class when the directory structure is similar to that in the source code. After all you already know the namespace it’s in. So locating the files becomes a lot easier.
You instantly know what classes belong to which namespace
I don’t know about all off you but I don’t always have my projects open when I’m documenting on trac. So to figure out which classes are part of a namespace I simply open the directory and find out. That way I don’t have to load the entire project every single time.
Moving of classes to other namespaces becomes easier
When you come to the point that you need to refactoring having all classes from a namespace in one directory makes it a lot easier to refactor. No longer do you have to open each file to find out in which namespace it’s located, just look at the directory structure.
This also introduces the downside that you need to move the classes in the SVN or CVS since the namespace has changed, but hey everything has it’s downsides .
Let me know if you now any good reasons, or have some strong reasons against.
