The MyFaces team is pleased to announce release the release of 1.0.2 Alpha.

Release Notes | Download

Perhaps this belongs under blatant advertising since I'm a committer but this is my blog :-)

I'm humbled by the success of the Eclipse M8 article @ JDJ. Of course the front page posting on TSS did not hurt :-)

I'm honored to share this review of Jakarta Pitfalls, and as usual Jonathan's stuff gets the best accolades!

There is a link for the book @ amazon on the right hand side if you feel the need to jump out an buy 100 copies :-)

I'm using tomcat5.0.18 in my current testing of MyFaces, anyway I've recently been doing some refactoring of the build and I started getting error messages from tomcat like this

tomcat-deploy-app:
BUILD FAILED: /Users/Shared/Applications/Eclipse-3.0-M8/workspace/myfaces/build/cactus-webapp/build.xml:46: 
  Following error occured while executing this line
  /Users/Shared/Applications/Eclipse-3.0-M8/workspace/myfaces/build/tomcat/tomcat-build.xmlf:12:
  java.io.IOException: Server returned HTTP response code: 401 for URL:
    http://localhost:8080/manager/deploy?path=%2Fmyfaces-cactus-tests
Total time: 5 seconds

Which made me very confused and frustrated as it took more than 30 minutes just to figure out that the login was invalid. Bone headed of me? Why of course, 401 means authentication is required so I should have picked up on it right away but I didn't. It would be great if the catalina-ant tasks would help out bone heads like me and just say 'hey idiot you did not provide a good uname/passwd combo'. Ah but alas I'm back on my soap box where it is so easy to get knocked down...

The build fragement looked like this, FYI.

<target name="tomcat-deploy-app" description="Deploy the App to Tomcat">
  <deploy url="${tomcat.manager.url}"
          username="${tomcat.manager.username}"
          password="${tomcat.manager.password}"
          path="${tomcat.context.path}"
          war="file:${tomcat.war.file}"/>
</target>

The Eclipse Live title hit Amazon.com today. Very cool stuff. If you've got the book from either the JavaLobby promo or you are a normal subscriber I'd love to get some reviews. So please post away.

Thanks!

Recently Arthur submitted a bug report on MyFaces (an open source impl of JSF, its cool check it out if you are interested) and instead of putting a lot of time into tracking down the bug he built a very small and simple example app that demonstrated the bug and attached it to the bug report. What a fantastic way to report a bug. I was able to track down the problem very quicly with his sample app and get it fixed.

Thanks Arthur!

On the Eclipse 3.0 JDT mailing list there has been a lot of talk about the new JDK 1.5 features. They are working hard at adding generic support (along with other 1.5 features and things are coming along. But something struck me again today about how much I dislike generic types. It has been a long time since I've done any serious C++ work but without a doubt generics was something that made normal peoples brain hurt. So here we are about to have this lovely feature delivered to us and I find myself not wanting it.

I mean really how much more complex is this bit...

List myList = new ArrayList();
...
Iterator itr = myList.iterator();
while(itr.hasNext()) {
  String foo = (String)itr.next();
  ...
}

than this bit...

List<String> myList = new ArrayList<String>();
...
Iterator<String> itr = myList.iterator();
while(itr.hasNext()) {
  String foo = itr.next();
  ...
}

In reality most developers who don't understand the cast will not understand the 'generic type' stuff either and will just copy and paste the code and modify where necessary. I know we get a bit of additional type 'saftey' from the compiler here but once you get a ClassCastException once and figure out what caused it you tend to not make that mistake again.

My hope is that we will, as an industry & community, develop some 'best practices' that are borrowed from our C++ colleagues. I guess I don't really expect this to happen, I'm just hopeful.

Anyway this is a recent email from the list with an example of what has become possible in Cheeta. BTW: I love the little animated gif! Even if you are not interested in generics you should check out the gif :-).

Basic support for generic methods is now in, with argument type inference.
For instance, in the example below, U is inferred to be of type String for
the invocation of #foo(...) in #main(...) method.

public class X <T> {
    public static void main(String[] args) {
            new X<String>().foo(args, new X<X<String>>());
      }

    <U> void foo(U[] us, X<X<U>> xxu) {
        System.out.println("SUCCESS");
    }
}

We still need to test it a bit before updating the Cheetah with it.

So what I expect will happen is over the next year or two everyone will make all the same mistakes that have been made in the past with generic types in the C++ world. Here is an example of the kind of ugly stuff that we perhaps will be foisting upon ourselves. Not that meta-programming will be possible with Java generics but equally krufty stuff will be possible I'm sure. Just look at the above example. Try to explain that to the average 'business programmer' that the Simplify Java and J2EE crowd is aiming at.

I know I'm sort of too little too late here but my hope is that we as a community will learn from all the bad stuff that has been done in C++ with generics and not repeat the mistakes made there...

[Update:] Thanks to Ben's comment I figured I'd post the JSR homepage and a mail address for feed back. Let the expert group know your opinion.

[Update 2:] If only I'd read for myself and not rely on others comments... As David Flanagan points out in his blog the time for comment is long since passed so don't hassle the expert group :-)

Well I'm sick of fighting the referrer spam. I've just deleted the referrer log from the front page...

I went to a Sun developer briefing yesterday @ Sun's campus in Broomfield on what has become of Project Rave. Its renamed to JSCreator for one thing and is finally in EA. You can download a copy here.

My general reaction is very positive. The tool basically lets you build the simple apps very simply. So for example if you are a mom & pop shop that needs an app to do some custom business process you might have formerly bought VB for dummies and programmed a quick and dirty app. With JSCreator you can build a quick & dirty Java app with the relative ease of the VB app. Sun has built a tool that will allow you to easily attach controls on your pages to JDBC rowsets.

Some will have a headache with this approach, 'where are my toplink/hibernate/cocobase type collections' etc. My take is that this criticism is misplaced. Java needs a dev tool that is easy enough to build apps with that mom & pop can put together an application in 8 to 16 hrs that does what they need. You certainly are not going to build an app that scales to 25 million users with JSCreator but that is not the market the tool is aimed at anyway. Its aimed at the space that VB fills so well now. The one off app that is built not by the IT department but by the guy in finance who is tired of waiting on IT to build his simple app. This person runs off and buys a copy of VB (or even just whips something together in Excell) and spends a day or two hacking and the app is done. The app won't scale but it only has 3 users anyway so why worry about scale...

Ok so enough rambling, here are my notes from the presentation;

• Main focus is making java development easier - for simple stuff this looks like a winner in this category
• Its a full fledged IDE (basically netbeans on the back end with some minor to major mods, will resync later with 3.6 it sounds like)
• Visual design tool that keeps the visual design in the code instead of a third model. It appears that it can visually render any JSP and will allow you to edit that JSP. Overall this feature looks great in a demo but I want to play with it before I get to jazzed about it. Been burned too many times in the past with these claims :-)
• Does not expect to rule the whole development process - you can build the war related stuff (jsp's, servlets etc) in JSCreator and import them into another tool like Eclipse or NetBeans and do other stuff then go back to JSCreator. In the preso this point made it sound as if you had to jump back and forth but for simple apps you would not need to. I think the point was that you and use other tools to do the more complex stuff (backend stuff, webservices, persistence stuff like hibernate, etc).
• At some point in the near future (6 months to a year, I was thinking during the roadmap slide...) they will add rich client support as well as mobile stuff - this sounds really cool
• The team has been contemplating some type of integration with JDO or other object persistence mechanism, but for now works with jdbc rowsets.
• One very cool bit was that it works with web services. The demo was a bit canned, the webservice returned a block of html. But form the options in the properties page it appeared that you could do much more. I can't wait to mess with this feature!
• The idea behind simplification is to standardize all the SW dev on Java, not just the super starts in the IT staff but the normal person at a company that needs software but also has a life and does not want to sacrifice it to learn EJB's
• Will go FCS @ Java One
• Supports CSS 2
• maintains an ant build script on the back end
• In building the demo no part of any web.xml or faces-config.xml file was ever manually edited. This is a majorly cool thing. The tool has a very nice visual navigation editor that was just fantastic!

Over all I'm very impressed with what I've seen so far. I just finished down loading the EA so I'll be spending way to much time over the next few days messing with it. I'd love to hear about your experiences!

Matt Raible was there too and has posted a great review.

In case you have not seen or heard the JSF Source code is available here.

I just got it. It looks good. There are lots and lots of tests, makes you feel good about the code to see all the tests :-)

So many people these days are asking if JSF can be used on its own or does it need the Struts integration to be useful.

As I recall back pre EA4 JSF did not have a navigation model and thus you either had to write it yourself or use an existing one. Craig McClanahan was kind enough to work the wee hours to make the integration possible. So with the Struts/JSF stuff you could use the JSF components for rendering and Struts to manage your navigation.

When EA4 shipped though JSF got its own navigation support and could manage everything that Struts did and became a full-fledged framework for building web apps and thus no longer needed Struts to be useful.

Now there seems to be confusion that you have to use Struts to make JSF useful. The way I see it (please correct me where wrong) you should not be using the Struts integration except for a peaceful migration path from Struts to JSF.

There, I've finally gotten that off my chest. Please comment if I'm being a bone head.