Remind me, what did they said about the most used browser? My Google Analytics is sure that the most popular browser is Firefox with almost 55%, than Chrome with 23.7%, and only then IE. And I am happy at last Konqueror got into list, with 0.67% share.
From time to time you need to set up some project at home. There are plenty of reasons: you are starting new opensource project, want to write few HelloWorlds with new frameworks, or you just don't want to go to office today.
And of course you want to use some VCS with your project, because it allows you to perform development in steps, plus standard VCS features like revert/diff.
I worked with CVS, SVN, Perforce and a tiny bit with VSS. And few days ago I tried Mercurial. Mostly because great support from NetBeans. But now Mercurial is total winner for home usage, only two simple steps and your repository is up and ready to be used from your favorite IDE. With Mercurial you don't need to start servers, use network connection, configure some system files using root privileges, just install and init project. And enjoy lightweight source control system that will provide you with all benefits of versioning.
Java EE 6 specification released not so long ago, and now includes release of JPA 2.0 specification. Obviously, you'd like to use JPA 2.0 for your new project. But the problem is, how to choose good implementation and where to get it?
First you will go to Sun's persistance page. You'll read a bit and click on "download" link that will take you on Glassfish Persistance page. But the problem is, you will not find JPA 2.0 reference implementations on that page.
Ok, next step - ask google. Google sais that EclipseLink is reference implementation for JPA 2.0, and wikipedia confirms. Let's go to EclipseLink downloads. Yea, there are some files to download, but again everything is packed into single huge JAR with dozens of features we don't really need (yea, I have "classpath paranoia"), and the main component is missing - sources for JPA 2.0 API, that can be added to NetBeans libraries to read javadocs and to help it with method argument names (do you remember that Library Manager in NetBeans?).
We must not give up. Let's go to JSR page and take a look. Wikipedia states it's JSR 317. After clicking on "Download" link we can see another link, that will direct us to "EclipseLink's Reference Implementation Downloads". After downloading both and taking a look inside of each package we can see that "EclipseLink 2.0.0 - minimal bundles that are shipped in the Java EE6 RI" is what we really need. Finally, everything we may need and packed in separate small JARs, so we can include only features we need.
Now, let's make it work. I have project that used JPA 1 with EclipseLink 1.2.0. I removed all EclipseLink libraries, added javax.persistence_2.0.0.v200911271158.jar (JPA 2.0 API) and org.eclipse.persistence.jpa_2.0.0.v20091127-r5931.jar (one that contains org.eclipse.persistence.jpa.PersistenceProvider). First few starts of application ClassNotFound were reported, I searched for required classes and added their JARs. Finally, here is the full list of JARs you need to work with standard JPA 2.0 feature set:
javax.persistence_2.0.0.v200911271158.jar
org.eclipse.persistence.jpa_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.core_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.asm_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.antlr_2.0.0.v20091127-r5931.jar
and files to add to Sources tab (NetBeans will be able to show you sources, javadocs and read method argument names from those sources):
javax.persistence.source_2.0.0.v200911271158.jar
org.eclipse.persistence.jpa.source_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.core.source_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.asm.source_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.antlr.source_2.0.0.v20091127-r5931.jar
That's all. Use JPA 2.0 with pleasure, support new versions and software evolution, because otherwise we all will become stupid monkeys and will return back on palms.
When you're constructing Widget in GWT - it's size is 0 until it's rendered. It's different from Swing, Swing assumed that you're working in EventDispatcher and calculated all sizes instantly. It is not announced but looks like GWT have it's event dispatcher too, and you can use DeferredCommand class to place Command into events loop. Using this approach you can construct Widget, place it into some Container, and then add some Command to DeferredCommand to work with widget's size after current construction operation will be complete and Widget will get it's size.
It looks like problem of all young widget toolkits, like Swing itself many years ago. They are showing it, its simple, its cool. But when you start coding real application using that toolkit - you'll get many problems, many different "hidden" features and many tricks and workarounds. After many years they'll tell you about EventDispatcher, then they'll implement different kinds of BackgroundWorkers, and different rules how to "use correctly" this toolkit. You can remember situation with "EventDispatcher rule" of Swing and how it was changed from Java5 to Java6 (while nothing inside was changed). Now we can see similar situation with JavaFX, and GWT goes the same way.
NetBeans 6.8 is just released, introducing many new features. It's pity there is nothing interesting for me as for Java-GWT developer. And even nothing interesting for other guys I worked with - they are still using MyFaces 1.1 for some reason, OpenJPA 0.9.7 bundled with WebLogic 10.0.0.0.0, and other EE4 or EE5 stuff. New JIRA plugin can't authentificate into my JIRA server, and I'll better wait for next GWT4NB version, which I hope will support GWT 2.0 and NetBeans 6.8.
Honestly, it's a pity that the most powerful Java IDE/editor is not improving it's Java stack, but working on some thirdparty features like Kenai, PHP, Ruby...
I have some experience with many different UI toolkits. The most with Swing, QtJambi, GWT, and some with SWT and Echo2. Some of them providing you with their own i18n techniques. Let's take a closer look...
Swing is the most comfortable tookit because it gives you full Java API, with source code, possibility to dive deep into it's internals and no external libraries or dependencies. And it gives you standard Java i18n engine: ResourceBundle. It's simple, powerful and effective. And it's customizable (if you know Java of course).
Qt Jambi gives you Qt's native internationalization engine. It works in other manner than ResourceBundles. API is clean and simple, every Qt widget have method tr(String) where you can specify default value, but not the key as ResourceBundle suggested. From one point of view it's good because you're hardcoding default values, and you will be sure that on any system it will at least show default version. From the other side - those messages can take a lot of space in your source files, plus they are actually keys in internationalization files, similar to properties files. Having keys like this is not very good, because modifying single char you have to modify all resource bundles, while in ResourceBundle you can leave code "as is", modifying only value but not key.
GWT is totally different. It's using properties files too, but you have to extend Constants interface, and add all your keys as String methods to interface. As for me GWT is the total winner, because you have properties files with key-value pairs and IDE support, and you have compile-time safety because you're getting those strings from Java class. In ResourceBundle you're operating mostly with Strings, and simple typo can waste lots of your time, while using GWT approach you must ensure your keys only once, then you're totally saved from any kinds of typos using Java methods to get your internationalized messages.
GWT 2.0 released yesterday, but almost reached 6000 downloads already!
Well, I am agree that GWT is pretty cool thing, especially if you must do something for web browsers, but 6000 in 33 hours... Can you remember any other toolkit with same download rate? Even Java developers are not bothering themselves with downloading of new versions.
Few minutes ago I read about release of GWT 2.0. It's great new release, with many useful features. Except one: UiBinder. HTML and XML both have their problem - they are page-oriented. You can't just replace some widget as long as it's Widget subclass. You need to repaint all page if you want to layout it in some other manner. GWT allowed you to avoid those drawbacks, providing you with great feature-rich component-based framework. You could do everything in plain Java, and as for me it's big advantage, because average quality of GWT project were relatively high (you at least need to know Java, and maybe some component-based framework like Swing, right?). And now any novice HTML coder can feel something native and ugly using GWT, lowering average code quality and writing another crappy application with cute HTML-like interface. Impossible to debug, impossible to apply any Java techniques, and even making harder to use version control system (I hope you noticed that modern DIFF algorithms are not very good with XML?).
