lundi sept. 29, 2008

SDPY - JavaEE 5, Java 5, ...

•   POJOs and ABAP (SAP now Java EE 5-certified) (2006)
I was asking who would be last ship a Java EE 5-certified product. So, IBM or JBoss?

•   Tiger is here! (2004)
Java SE 5 shipped four (!) years ago. Are you there yet?

vendredi août 06, 2004

Generics: First steps, first questions

when generics lead to generics... So, moving along in my summer homework, I finally took some time to start playing (not just reading) with Generics.

Option 0 (Default):
        List<String> list = new LinkedList<String>();    // default (no issue here)
        for (Object element : list) {
            System.out.println (element.toString());

Option 1:
        // this code compiles (with lint warnings) and runs without type-safety
        List list = new LinkedList<String>();   // valid but what's the point?
        list.add(new Float(10));
        for (Object element : list) {
            System.out.println (element.toString());

Option 2:
        // code does not compile due to 3rd line
        // if you take it out, behaves like Option 0.
        List<String> list = new LinkedList();   // valid syntax
        list.add(new Float(10));   // compile error - cannot find symbol : method add(java.lang.Float)
        for (Object element : list) {
            System.out.println (element.toString());

Option 3:
        // does not compile, types need to be the same. Inheritance doesn't work here.
        // but Abstract types are allowed (replacing Float with Number fixes the error).

        List<Number> list = new LinkedList<Float>();   // "Incompatible types" compile error
        list.add("ABC");    // compile error - cannot find symbol : method add(java.lang.String)
        list.add(new Float(10));
        for (Object element : list) {
            System.out.println (element.toString());

Option 1 is strange, I'm not sure what it means and why it's allowed. Compatibility with previous versions probably.

Sounds like Option 2 is nice because it does the same as Default, only it doesn't require you to type in twice the generic type. The only advantage to Option 0 may be that it's more readable.

Option 3 simply shows abstract types are allowed.

Update: On a similar note, check out this post

jeudi août 05, 2004

Summer homework (NetBeans & Tiger)

NetBeans 4.0 Blogs are usually a good place for reviewing new stuff. The issue for Sun employees is that it's tough to review non-Sun products because you can be accused of biased criticism. But it's also hard to review home-grown products for the exact opposite reasons.

So I settled on things I had to do (sort of my summer homework): NetBeans 4.0 (the post-Eclipse release), Tiger (JDK 5.0) new language features, and the O'Reilly "Java 1.5 Tiger" book. So this is really meant  to be a review of this combination and this is only the first post.

I've had Tiger installed for a while but mostly played with its experimental monitoring tools (sort of the successor to
jvmstat) as well as with the new Ocean/Synth look-n-feel. After picking up the latest netBeans 4.0 Q-Build (I did try using NetBeans 3.6 and managed to do quite a bit, but 4.0 has proven to be so much better), I went on to download the book's companion source code which comes with an ANT build file to compile and build the book examples. NetBeans 4.0 smoothly created a project based on this archive and custom ANT script. The project system is now fully built on ANT which makes its targets (build, compile, clean, ...) available outside the IDE, allowing nightly builds and easier sharing with other developers.

The other good surprise was the IDE look-n-feel (tiger's new Ocean/Synth lnf certainly helps) and the window manager enhancements (some things remind me of Creator), it's really neat. See these snapshots (click to enlarge) :


Back to the project I just created. ANT being so integrated in the tool, I first had the feeling that it was the only way to go even for running a simple file, which I though was overkill. This prooved to be wrong, you can use a "Run File" or "Debug File" menu. There's also the clean notions of a platform (set of libraries) and a project properties (a compiler, an interpreter, a debugger, etc.). A platform and project settings are now first class citizens and not buried in the tool's options. For those using NetBeans today, note there's no more "mounting" to do. Those that were used to it will probably miss the feature, not everyone else ;-).

Having created this new project, I was all set and ready to develop/run/debug my Tiger examples. No extra step needed to use the appropriate compiler and options to recognize the new syntax, to provide code completion, etc. You can use NetBeans 3.6 to develop with Tiger, but this is where I found using the latest version was so helpfull.

Chapter 1 was a pretty soft introduction to Tiger new language features, I'm off the Chapter 2 (Generics!). More here as I move along.

So far so good, very good.

mardi août 03, 2004

Tiger not "compatible"?

tiger What does compatible mean?

I just read this article claiming people are afraid compatibility will be broken with Tiger (JDK 5.0).

My experience so far is that existing applications run just fine with Tiger (just did another validation today with an ISV who's last Java certification was on 1.3.1 and everything just worked fine). As a matter of fact, Tiger's #1 objective is to provide quality (read Compatibility, Compatibility, Compatibility). I really think it's delivering the promise so far. The whole point here is that you can benefit from the implementation improvements (performance, tuning, management tools, etc...) by moving to a new version without having to adopt all the new features of a newer JVM and without breaking your development. I have to admit that not all parts of Java were created equal when it comes to upward compatibility and your mileage may vary.

Of course, using Tiger's new language features will require a 5.0 runtime, but this is the same as for Reflection, RMI, or EventModel in 1.1, JFC/Swing or Collections in 1.2, JNDI in 1.3, Assertions, regular expressions or NIO in 1.4, etc.... Also the article confuses MSVM (which was never really Java) migration with the adoption of the upcoming 5.0 platform. These are really separate problems : moving away from MSVM often requires rewrites (use the Java Upgrade Tool to assess), moving to Tiger just shouldn't (never say never).

There are too many good things in Tiger to ignore it.

mercredi juil. 28, 2004

enum Topic {JavaOne, Rich Java, Tools, Creator}

So, I'm back home from JavaOne. I must say that I had a good time. This may sound very politically correct, but for starters, this year's conference was more technical and more united (IBM, JBoss, etc...) and the networking was great as always.

But hey, one big news is that I'm now blogging! This is really a Sun corporate thing as even Jonathan Schwartz has started his own blog and I believe all this blogging ecology is a very natural thing given Sun's culture. One of the best things about JavaOne is that you can meet people and be curious. I was lucky enough to meet Tim Bray at a Sun-internal conference a few days before JavaOne. His talk was concise and pretty fascinating. Tim seems to be very curious (see here) and has this wonderful ability to explain in simple words pretty much any concept or technology. This, together with Pat's repeated suggestions (thanks for the comment, I now have to live up to the reputation!), is really what got be started with this whole blogging thing. Hopefully I talked my French colleague Eric Mahé into starting his blog real soon.

But back to JavaOne, the things I'm taking back are mainly these :

Tiger: huge release (I'll probably spend the next few week reading O'Reilly's Developer's Notebook) and long release. Still need to wait until late September before it's final. So far, compatibility has been the good surprise of this release. I'm still tracking performance figures, but they already seem pretty good (broader OS/Processor support certainly is a plus there).

Creator / JSF: this was a big topic at the conference and since I've been meeting with many customers lately on the subject I'm glad the product is finally out. It still has a long way to go compared to its non-Java competition, but the basis are very good - JSF for Corporated Developers rather than the "Now my tool does JSF too" approach. One interesting experience I had was with a J2EE customer looking for a RAD tool. He gave Creator the advantage (even before it hit final release) over Microsoft's Visual Studio arguing standard J2EE applications and integration with his existing infrastructure were more important to this him than a mature full-featured product like Visual Studio. Now you can't comment Creator without mentionning JSF. While it is still pretty early in the game, I think that it can do most of what STRUTS does (STRUTS really needs to inovate to keep being up to speed technically) and that while it lacks some features from other frameworks, it is leveling the ground for a great UI component market, providing standard and scalable MVC2 infrastructure but most importantly it was built with tools in mind from day one.

JDNC / JDIC / JavaWebStart: this is really about rich clients and I must say that I like GUI development, that I share many ideas with Amy Fowler (once a JSF spec-lead!) but also that many customers are looking into a better alternative to web clients trying to behave like rich ones. These customers need to have better end-user experience, not require a server for simple things like sorting, but also notification, keyboard-driven application, off-line usage, etc. So, when talking about rich clients using Java on the desktop, there's really three issue: (1) JRE deployment, (2) Application deployment, (3) Java client technology. In the enterprise, (1) can be solved using Windows/Linux masters, Active Directory deployments, or silent installs. (2) is really Java Web Start's job and the technology really got better with version 5.0 - better desktop integration, single instance, lock-down feature, extensive enterprise configuration, smart card support, Pack200 compression, etc. (3) is about Swing vs. SWT and which protocol to choose to talk back to the server. I believe that Swing's increased performance and look-and-feel, JDNC's ease of development (although it's not final and tools are not yet available), JDIC and the Netbeans Platform (not the IDE) are many good reasons for making a strategic choice for Java and Swing as the base technology for competitive rich-based Java clients. The protocol is something I may address in another blog, but let's just say Web Services are not the cure for now as there's no portable stub API and JAX-RPC is not yet part of J2SE, sorry JDK 5.0.

Tools: even looking just at Sun, there's more to tools than just Java Studio Creator! A few things worth noting: Borland joined the JTC (Java Tools Community, Beehive (BEA's new open source project) gained support from Eclipse. Borland now provides some of their tools for Eclipse developers! Meanwhile, NetBeans is making huge progress with its upcoming 4.0 release:refactoring, performance tuning using JFuid technology, ANT-based build system, Tiger (JDK 5.0) support, and J2EE support including EJB and Web Services. I guess an eclipse just can't last forever! Also, Java Studio Enterprise (the commercial version of Sun's tools) previewed UML two-way-editing-with-no-annotation support (nice reverse-engineering demo), collaborative tools (instant messaging for the developer), integrated profiling tools (most of them demoed during James Gosling's general session). Also showed during a technical session was a very nice-looking real-world (i.e. document-centric, long-runing, asynchronous, and conversational) Web Services developement prototype based on Crupi's J2EE extented design patterns (this is all part of the Kitty Hawk project focusing on SOA). Most other tool vendors are coming out with support for things like "visual" Struts, EAI, BPEL, etc. As always, timing is everything and future will tell if UML or JSF are more relevant than BPEL and Struts in 2005. I don't have the answer.

Java & Open Source: no, Sun has not open sourced Java and I believe the debate with James Gosling and others did a good job of asking the main questions: what does Open Sourcing Java really mean and what's in for the developer? To have at least one Open Source implementation of Java? That's already true for J2EE and certainly possible with J2SE JDK. Sun could stick an open source license on Java and not solve the developers pains (this isn't necesseraly true for die-hard OSS bigots who are said to be looking at Mono as a java replacement). The belief is that Sun can fix many issues developers face (bug fixing is probably the top one) without open sourcing java, and weekly builds are a visible first step. It's sun's Glasnost experience.

Among other hot topics, AOP, scripting (Groovy, JSR 223) and EJB 3.0 (J2EE 5.0) were on my todo list and still are (at least before I can comment them here). All have in common great potential, but also the risk of fragmenting either the platform or the community.

Wow, this was a long blog, maybe too long. Next ones will be more bistro-style.

This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected


« juillet 2016

No bookmarks in folder


No bookmarks in folder