Go for it: NetBeans 6.0 is final
It's been a little less than two years since NetBeans 5.0 came out (in February 2006), and in that time, the IDE has made significant gains in adoption and mindshare. It's been undergoing constant development in that time, with 5.5 released in August of last year, and lots of people happily using the 6.0 preview releases as they've come along.
We've also heard a lot about 6.0's features during its development, such as its deep support of Ruby and other non-Java programming languages. Tor Norbye of the Java Posse podcast is one of the guys responsible for this functionality, and has discussed it a number of times. The integrated profiler is also a highly-desirable feature, one whose usefulness prompted a poll question a few weeks back about profiler use.
- a completely rewritten editor infrastructure
- Ruby/JRuby/Ruby on Rails support
- a new Visual Game Designer
- updated Data Binding support
- integrated Profiling
- new productivity features
- a simplified installation process
This week's Spotlight, to mark the release of NetBeans 6.0 we've launched a new NetBeans 6.0 forum to discuss experiences, issues and ideas with the popular IDE. The new forum is part of a re-freshening of our forums, which includes the archiving of older discussions, and the launch of new forums, including two new forums for OpenJFX, covering JavaFX Script and JavaFX Mobile.
Speaking of the many discussions on the site, today's Forumssection starts out with
cowwoc talking about JNI use and re-use in applets, in Re: Using JNI in applets: impossible due to classloader limitations? "I don't think applet-launcher will help because there is a fundamental problem with the Applet architecture. I only know of two ways to make this work: 1) You can load the DLL into some shared parent classloader that crosses applet boundaries, or 2) You can force the JVM to unload the DLL when the applet terminates. I don't think either approach is technically possible with the existing Applet architecture. Even Tomcat's approach of loading the DLL into some parent classloader is somewhat of a hack. Ideally we want to be able to isolate each application (applet or webapp) into its own JVM but this isn't the case today. I suspect this is what JSR 121 was supposed to solve, but it never made it into JDK5 as was originally envisioned."
Pankaj Jairath points out what GlassFish's load balancing gives you for free, in Re: any plan to add active passive instances to glassfish load balancer plugin? "The auto apply admin feature of LB configuration, would take care of this. Any admin changes to the cluster setup (ex: addition/removal of instance..), being load balanced; would be reflected onto the load balancer configuration maintained at DAS. The auto apply functionality at DAS (would cause in background, regeneration of loadbalancer.xml) would take care of propagating these changes over HTTP to the fronting WebServer. When you create an instance of http Load Balancer at DAS, it identifies the WebServer on which LB runs via the WebServer instance host, port details. HTTP LB upon receiving such update message from DAS, would reconfigure itself."
drkeselj wrestles with a classic cause of AWT confusion in revalidate() or repaint() ??? "What is difference between repaint() and revalidate()? I`ve used one example for repaint() method, but when I replaced it with repaint(), it still works??? When should I use repaint() , but when revalidate()? Thanks."
In today's Weblogs, Fabrizio