Spring together with Google are going to propose a JSR which will standardize/unify the injection principles in both frameworks:

"...We propose to specify annotations to enable the reuse of injectable classes across multiple dependency injection frameworks..."

The spec leads are Rod Johnson (SpringSource) and Bob Lee (Google). Bob is spec lead in JSR-299 as well, so it might help in the standardization process. It would be the best, if this JSR would even make into JDK. The DI approach is Guice-like and annotation based.

These are really good news. Hopefully the JSR gets accepted and makes as soon as possible into a standard.

Recently I encountered the following error running a Java EE project from different Netbeans installation:

Z:\work\workspaces\winery\winery\nbproject\build-impl.xml:137: The following error occurred while executing this line:
Z:\work\workspaces\winery\winery\winery-war\nbproject\build-impl.xml:347: The libs.CopyLibs.classpath property is not set up.
This property must point to
org-netbeans-modules-java-j2seproject-copylibstask.jar file which is part
of NetBeans IDE installation and is usually located at
<netbeans_installation>/java<version>/ant/extra folder.
Either open the project in the IDE and make sure CopyLibs library
exists or setup the property manually. For example like this:
 ant -Dlibs.CopyLibs.classpath=a/path/to/org-netbeans-modules-java-j2seproject-copylibstask.jar

I found only few pointers to the problem in the web. You will find a hint in the last line of the error report - you have to add the property libs.CopyLibs.classpath to the ant build.

It can be accomplished in menu: Tools --> Options --> Miscallenous -->  Ant. Put the property  libs.CopyLibs.classpath=[Netbeans Install]\NetBeans6.5\java2\ant\extra\org-netbeans-modules-java-j2seproject-copylibstask.jar (without -D). It should work after that.

I encounter the phenomenon few times. It seems like the error happens after upgrading the libraries (in my case icefaces 1.7.2 to 1.8.0), or running the ant build outside Netbeans in command shell, or continuus integration like hudson.

Sometimes it is necessary to perform more dramatic steps to convince C++ developers about Java performance. We developed a JTable with custom model, renderers and editors to port an existing C++ application. We begun with tests, as some of the C++ developers expressed his concerns about the performance and resource usage of the current solution. The old C++ application was able to handle few thousands rows in a table. Instead of discussing the performance of Java we started a spike with 5000 rows in a three row table. The last column consisted of a JComboBox with own model pointing to another 5000 records. It took less than one second to load the table. We increased the number to 50.000 records it took few seconds to load the data and open the application. The we only wanted to break the application and increased the data to 1 million records. ...after about 40 seconds and 1GB heap usage the app opened - it was slow but usable. It is really remarkable because we performed the test without any optimizations. The application was built in object oriented way the domain objects were constructed from REST-like (not really RESTFul) data stream, and were wrapped with a custom table model. Custom renderers and editors were responsible for displaying the data. Every table cell was displayed by a renderer which exposed a domain object. So several instances were involved for a single cell.

We repeated the test within Netbeans Profiler and were able to identify some bottlenecks (unfortunately some of them were written by me...:-)).

Hazelcast is a small library (363 kb, version 1.5RC1), which comes with distributed, transactional collections and a Java EE JCA (shipped with the zip!). The connector is only needed in Java EE environments to transparently propagate e.g. EJB transactions to hazelcast (outbound transactions).

To install you have only to download, extract and start the sample application (run.bat - it worked perfectly in my case). This should take less than 2 minutes. The installation of the JCA connector is even easier - just drop the hazelcast-ra.rar file into e.g. [glassfish]/domains/domain1/autodeploy/ (I tested the installation only with GF v2).

The screencast (12 min) explains the concurrent, transactional access to distributed collections - well done.

I looked at Hazelcast last year - I liked the ease of use and the quality of the screencast, but not so impressed by the unclear licensing. It was free but not open - and without clear licensing. Shortly after I complained about this fact (no idea whether opensourcing of this library was actually my fault :-)), it changed, now it is a Google Code project with Apache license and so interesting for commercial projects. I guess good support is available as well - at least the main committer answered the question about licensing immediately in my case.

Hazelcast is an interesting foundation for creation of clusters, grids - or "Cloud Computing" :-).

I'm building an EJB 3.1 capable ServiceLocator, which works with the global JNDI names (portable and standardized version JNDI-names needed to lookup a local, remote, or even no-interface-view interface) . The implementation relies on parsing java.util.Properties to fetch the current EAR and EJB-JAR (module) names - both cannot be derived via reflection. I was concerned about the performance of parsing and accessing the properties from a file and fired up the Netbeans 6.5 profiler.

I wasn't even able to find the java.util.Properties in the hotspot list at all. ...the reason was - it is lightening fast (took only about 4.5 ms...).

The ServiceLocator 2.0 :-) accesses the annotations as well - which turned out to be the real hot spot. The first access to the annotation takes 55 ms. It is the method Class#initAnnotationsIfNecessary (indirectly invoked by Class#getAnnotation), which takes so long. It uses Sun's internal class sun.reflect.annotation.AnnotationParser, which in turn creates a dynamic proxy. The creation of the dynamic proxy (Proxy#newProxyInstance) takes 44 ms.

The exact performance was: 

55 ms Class.getAnnotation
4.43 ms Creating, loading and parsing  java.util.Properties (two String entries) 

@Stateless
public class SimpleSample{
    public void doSomething() { /*business logic*/  }
}

How to compile:

You will need the the EJB 3.0 / 3.1 API in the classpath, or at least the @Stateless annotation.

How to deploy:

Just JAR the class and put the JAR into e.g: [glassfishv3-prelude-b23]\glassfish\domains\domain1\autodeploy

How to use:

e.g.:

And: there is no XML, strange configuration, libraries, additional frameworks or jars needed... 

See also: EJB 3 series and EJB 3.1 From Legacy To Secret Weapon.

[See also "Real World Java EE Patterns - Rethinking Best Practices", page 36] 

I'm using Netbeans in 80% of all my projects. I started to consider Netbeans as the main IDE at 5.0/5.5 time. Working with Netbeans in Java EE and RIA is extremely efficient - I really enjoy the lack of the plugin-hassle. Right now I have 18 different eclipse installations customized for different customers with different, mainly incompatible plugin sets and distributions. In one project I'm even using three different eclipse installations with different plugin sets for the workflow. But I have only two instances of Netbeans 6.5 (production and experimental) and one of IntelliJ installed. It comes with everthing what I need. Some things, as always, could be still streamlined and approved. Netbeans would be even better, if the following features would be implemented / solved:

1. Hierarchical / nested view of EARs. Right now you see in the explorer EAR, EJB-JARs, and WARs side by side, although they are actually nested. A nested view would save a lot of space.
2. Support for creation of "standalone", non-jta persistence.xml in EJB-Jar projects for unit testing. Right now Netbeans creates always the JTA-version of persistence.xml - there is no way to choose between the data-source and straight-jdbc version. You have to create a persistence.xml in a Java-project, then copy it to the test-source folder of your EJB project.
   
3. Support for profiling of Unit-Tests in EJB and WAR projects. Profiling of unit-tests in regular Java projects works perfectly.
4. Support of executing of single Unit-test methods (as in eclipse).
5. More support for inline-renaming (refactoring), especially inline-renaming of methods.
6. Syntax highlighting with code-completion for JPA-queries, like in SQL-editor right now.
7. Better support for editing of ejb-jar.xml and orm.xml. Sometimes it is necessary to edit XML instead of annotations :-( - even in Java EE projects.
8. Support for conversion between orm.xml and ejb-jar.xml back and forth.
9. Automatic synchronization between the editor views and the explorer (the "Link open editor with contents in the navigator" eclipse feature). I do not miss it very much, but I'm asked about this feature in particular over and over again by Eclipse-switchers.
   
10. Support for EJB 3.1, especially WARs, no-interface-views and inclusion of the EJB 3.1 API.
11. Native Wicket support - there is a plugin out there, but Wicket is important enough to be distributed with netbeans. Especialy useful would be: switching between the HTML and Java editors just clicking on the wicket-id and code-completion of wicket-tags in html.
12. Recognition of changes of html file in the src folder. This is needed for "deploy on save" feature with frameworks like wicket. Right now only changes in the "web" folder are recognized.
    

After posting yesterday's entry I got several requests for the actual screenshots. I uploaded the Vista screenshots to the origin wiki-entry. It is actually a good place to contribute screenshots of Netbeans running on other operating systems....

This interesting article compares the performance of Java on Ubuntu vs. Vista. I had the impression already - but it is nice to read it again :-).

I forget it over and over again, now its here archived :-). The following statement generates DROP TABLE statements which really cleanup the Oracle database:

select 'drop table '||table_name||' CASCADE CONSTRAINTS;' from USER_TABLES

It is very useful for development (JPA will generate the tables for you again), and production (speeds up the performance) :-).

Nice thing: USER_TABLES and Oracle's dictionary is conceptually similar to reflection in Java.