| Kito | Hello this is Kito Mann and I am here at the JSF Summit 2009 in Orlando, Florida, where normally it is very sunny but today it is raining. Today I am here with Martin Marinschek. Martin is one of the co-founders of IRIAN, which is the main company backing the MyFaces project. So we are going to talk today about MyFaces, IRIAN, and related topics. Martin why don’t we just start with a little bit about yourself, your background, and your company?
|
| Martin | I wrote the first productive application in JSF 0.3 of the specification, and of course in the MyFaces implementation. It was in 2003. It was fun. I have done a lot of JSF development, consulting, and training since then. I founded the company IRIAN together with two other people. A lot has changed in the JSF world since then, to the good I think. As of now, I am really satisfied with the developments that have happened in the last years in JSF, and I am really happy that JSF is as good as it is right now.
|
| Kito | Why don’t we talk a little bit about the types of projects you work on?
|
| Martin | Currently I am mostly involved on one side with running the company, which definitely would be a job of its own. I am also full time at a project at Credit Suisse, which is our biggest customer. They are revamping the whole credit application suite. Basically it is the third largest Credit Suisse application that is out there on the web. They are revamping it from a small web application, and doing it all based on JSF. They developed their own component suite for this and other projects that are using JSF. They have made it clear that JSF is the standard they use for new projects that are doing web development. That is actually a pretty nice environment to be in as a JSF consulting company.
|
| Kito | Yes it is.
|
| Martin | A lot of my guys are sitting at Credit Suisse right at the moment, having fun there.
|
| Kito | Can you say anything about the technologies, like what they use there?
|
| Martin | Apart from the UI, they are not very state-of-the-art based in many cases. They have some projects which use JPA, and they are actually evaluating it in many places and are thinking about using JPA. I think they did a lot of performance testing and decided to go with…what was it? It wasn’t Oracle…
|
| Kito | Was it OpenJPA?
|
| Martin | No it wasn’t OpenJPA either. Does WebLogic have a JPA offering?
|
| Kito | I don’t know.
|
| Martin | I think it was a WebLogic product that they want to use. They decided the performance was the best. Apart from that, they are using a strange architecture with a lot of CORBA services.
|
| Kito | CORBA?
|
| Martin | Yeah yeah yeah…
|
| Kito | I remember CORBA.
|
| Martin | Yeah, I don’t want to remember CORBA. To be honest, if you do CORBA well it can be quite nice, but it’s not very well done in the CS environment. The JSF part is very well done. It is a nice component suite. I wish it was open source so that others could use it as well. There are some pretty nice features, for example with tables, it has really very sophisticated fields for sorting -- whatever you are thinking about you can do it with these tables. Plus it also has a JavaScript-free fallback. That would be an interesting feature for a lot of people.
|
| Kito | Yeah definitely.
|
| Martin | Especially for government agencies who want to be fully accessible. You can be accessible with JavaScript as well, but if you need to be WCAG 1.0 fully covered then you would have to have a JavaScript-free fallback as well.
|
| Kito | And WCAG is?
|
| Martin | It is one of the standards for web accessibility.
|
| Kito | Ok.
|
| Martin | Given out by WAI -- Web Accessibility Initiative.
|
| Kito | Right, ok.
|
| Martin | It’s not the current one. There is a WCAG 2.0 which doesn’t enforce JavaScript-less fallback. But the 1.0 version does, but usually on a per-organization based, not like a government law -- it wouldn’t enforce that.
|
| Kito | Ok, cool. Why don’t you talk a little bit about MyFaces? Your company provides some training and support for MyFaces and also you have several committers as well, right? Doesn’t the founder of the whole project work with you guys?
|
| Martin | The founders of the project were Manfred [Geiler] and Thomas [Speigel]. Both working for…..
|
| Kito | That’s right Thomas was a founder too.
|
| Martin | Manfred and Thomas, they both are working for us. Not currently so much on the implementation anymore; we have other people doing that. They want to do the project based stuff more so they really don’t work on the fundamentals and stuff. They like to do a project where they have contact with the business, and then sort something out and then come up with something which is useful for the client. They want to keep it like that, to bridge the business technology gap somehow. We have other people working on the infrastructure part. From the 62 committers in MyFaces, there are 20 from Irian and close to 20 from Oracle. Then the rest are from a lot of companies from all over the world.
|
| Kito | Let’s talk a little bit about the project. MyFaces was originally just an implementation but now it has grown into a very large set of projects. Tell us a bit about some of the different projects that are part of the MyFaces umbrella.
|
| Martin | I hope I don’t miss anything. Of course there is the core MyFaces implementation and API. For the JSF implementation you have to do the API and the Impl, so it is actually two jars which are developed in the core section. Then there are the three component libraries: Trinidad, Tomahawk, and Tobago. Then there is Orchestra, which is a conversation scope implementation for long running conversations with integration to JPA as well. Then there is the JSF Portlet Bridge, and there is ExtVal validation integration for JSF, where you can put annotations on your managed beans and domain objects. It will directly be converted into JSF converters and validators, pretty nicely done. Now that bean validation has been standardized, it is also an implementation of bean validation, so you can use the bean validation annotations together with ExtVal.
|
| Kito | Is that currently shipping? Are they finished with that yet?
|
| Martin | I do think there is a version which already has support for the annotations. I am not sure if the full TCK compliance is out there, but you can use the bean validation annotations as of the release that is out there currently. I have a sample app written for the book, and we used one of the releases of ExtVal for doing that, and we are already using the bean validation annotations.
|
| Kito | Nice. I should say that there is currently a series on ExtVal on JSFCentral so if you are interested in more about that you can take a look at the article series.
|
| Martin | Then there is Ext-Scripting, which tries to provide Groovy support for having artifacts written in Groovy for MyFaces. I thought it was out already, actually, but it isn’t. It is going to be released in February. Then Ext-Scripting also – if you use Java 7, it supports you if you reload everything you have written in Java as well, so you can use managed beans, converters, validators, whatever. You can write that completely in Java and have that reload even while you work on it. Even if you put annotations somewhere, it is going to reload the whole thing.
|
| Kito | Nice.
|
| Martin | That is going to be a nice feature. Ext-Scripting is independent of the implementation so you might be able to use it with Mojarra as well. Let’s see how it works out in February. Did I cover everything now?
|
| Kito | Isn’t there a kind of commons project?
|
| Martin | Yea there is, but actually I don’t think there is a lot in there as of now.
|
| Kito | Ok.
|
| Martin | There is a shared project, which is stuff that is shared across the component libraries. That is not actually for usage by end users, more to share stuff between the libraries themselves. There is a common project which is supposed to be, in the end, a place where you can put stuff which is really the same all over the JSF world. Where a common API can reside and everybody can use that in their projects on top of the specification. Something which is long lived but more dynamic than adding something to the core specification. Let’s see how that works out in the end.
|
| Kito | Is that where -- if you were to address an issue like a limitation in the specification, is that something you would try and put there?
|
| Martin | You could possibly put stuff there, yes.
|
| Kito | Ok.
|
| Martin | If it is something that is useful for all the implementations.
|
| Kito | Right.
|
| Martin | It is possible to detach it from the implementation in the API.
|
| Kito | Ok. So just for people who aren’t really familiar with the different MyFaces projects, can you explain what’s different about the different component suites? Like why do you have three different component suites?
|
| Martin | They were coming from different sources. We had long discussions on should we have only one component library, or should we allow other people to also donate their component libraries and make them available as open source under the umbrella of MyFaces. We decided to be more open and to include other component libraries as well. In hindsight, a choice is always a good and a bad thing.
|
| Kito | So what’s different about them?
|
| Martin | They would have been open source anyway.
|
| Kito | This is true.
|
| Martin | They just would have been somewhere else, then.
|
| Kito | They are pretty different, right?
|
| Martin | They are definitely pretty different. They all have a distinct mindset behind them. If you look at Trinidad, it’s the mindset of Oracle, where they have a lot of features, very data entry based features, where you can do a lot of cool stuff with Trinidad if you are working with data entry. Especially client side validation is very well done, the messaging part. Also they were one of the first ones to support Ajax in the component suite. Actually I think they were the first ones.
|
| Kito | I think they were.
|
| Martin | ICEfaces is kind of detached from component suite, right?
|
| Kito | Right.
|
| Martin | For maybe the component library, they were the first ones to support this
|
| Kito | What about Tobago?
|
| Martin | Tobago was donated by a small company, which is now Irian Germany. So Tobago is also a very cool component library. It’s a very homogenous experience. A nice component library with a lot of features. Everything that is necessary is there. Really the only thing that is missing for Tobago is marketing.
|
| Kito | Right.
|
| Martin | It still doesn’t have that big of a user base and it really should have, because it was really one of the first component libraries which had a full feature set and a very homogenous experience.
|
| Kito | Isn’t one of its core principles that you can… like layout and that kind of stuff?
|
| Martin | Layout is very nicely handled in Tobago so you can have the dynamic layout managers. You can even exchange the layout managers that they have. They are a little bit Swing based, right? They are doing an absolute positioning flavor as well in the latest version.
|
| Kito | Really? Interesting. I imagine that might work better now than it would have a few years ago.
|
| Martin | Definitely. They say it was only possible with the latest enhancements to support that the browsers are getting right now. Tomahawk – I always call it bizarre – because you have hundreds of components and they all kind of work together or not. They are all useful in a sense. In many cases for the project you find out you need one or two components.
|
| Kito | Exactly.
|
| Martin | The nice thing is that Tomahawk is so close to the standard that you can add it to the project and it won’t blow up the rest. It was interoperable with all the component libraries right from the beginning, which was good.
|
| Kito | I always recommend, basically any team no matter what component suite, I always say you are going to need at least one or two Tomahawk components. I think maybe with JSF 2, some of the ones that provide some of the core features won’t be necessary, like that style sheet component.
|
| Martin | Yeah.
|
| Kito | In JSF 2 you don’t really need it, but there are a lot of little goodies in there.
|
| Martin | Yeah, a lot of little stuff. Things that other component libraries just don’t have. As I say, it’s a big community and everybody who had missed something and added it, just added their missing feature to the component library. It’s kind of nice. The JSF 2.0 version of Tomahawk is not going to take that long because it is so close to the standard, so there is not that much to do. The only thing that will take some time is the resource handling. The rest is really basic stuff and not a big problem. We expect a JSF 2.0 release of Tomahawk soon. We will do it right after we have finished the 2.0 core implementation.
|
| Kito | Nice.
|
| Martin | I expect it to be done in the next half of the year.
|
| Kito | Do you think that you will deprecate any of the components that duplicate JSF 2 functionality?
|
| Martin | If there is no added functionality we are certainly going to deprecate it. For the 2.0 version we can do that. There is certainly not going to be a , for example.
|
| Kito | Right.
|
| Martin | If you use flash scope replacement that we had in Tomahawk, it is not going to be necessary in JSF 2.0 anymore.
|
| Kito | Speaking of JSF 2.0, this week I noticed that you released MyFaces 2.0 Alpha. Tell us a little bit about that whole process. I saw a lot of activity on the mailing list and everything.
|
| Martin | It has been a lot of work to get MyFaces 2.0 out the door. We have a few committers who are working on the fulltime, for example Leonardo and a guy from IBM as well. It was nice to implement all of this hard work. We are now close to done. We have actually tried it with a lot of sample apps. We have run the TCK and it runs through except for certain tests which we need to discuss with the Sun guys, so it’s really nothing anymore which would be on our side. There are two minor issues that can be done with Ajax support exception handling, especially in the Ajax case. Then 2.0 will be done right. You probably want to use it and then see what else we have to do. That is certainly going to be quite a few bugs….
|
| Kito | It still sounds pretty good for an off release status. It’s pretty much passing the TCK and getting most of it.
|
| Martin | What we did as a company as well is we published a German JSF 2.0 book in November and we partially wrote it in Mojarra for parts which weren’t done in MyFaces yet. We made sure that all the samples are running on MyFaces as well.
|
| Kito | Nice. What's the name of the book?
|
| Martin | JSF 2.0
|
| Kito | Simple name.
|
| Martin | Simple names are good. It is for the German speaking listeners. If you are interested there is a JSF tutorial, which is essentially this book, completely online, freely available, if you need to look stuff up on JSF 2.0. You can find it on tutorials.irian.at/jsf. That would be the online JSF book, you can read it if you are studying a project and want to do JSF 2.0. I hope that in the next week there is definitely going to be a good release of MyFaces 2.0 that passes the TCK, that’s ready for prime time.
|
| Kito | That’s actually really cool because I know with JSF 1.2, it took about a year or so for MyFaces.
|
| Martin | We were way late. We didn’t have any people who really worked on the implementation who were spending only time working on the implementation. That has changed now. We have people working on the implementation, at least part time, as well as the component libraries… dependant also on our revenue stream.
|
| Kito | Yes exactly. I remember at the time people were saying that since there was stuff that dealt with some of the JSF 1.2 features in MyFaces Tomahawk, they were like, well….
|
| Martin | And you could use Facelets.
|
| Kito | Right.
|
| Martin | And then 1.2 didn’t add so much benefit, so the community really didn’t have to scratch the itch. For 2.0 it’s really a very different thing. There is a lot of cool functionality in 2.0 that we will all want to use in our everyday projects. It’s just so much of a difference if you really need these features. That’s also the reason why we see a bunch of activity going on for the MyFaces 2.0 release. Also IBM recently joined the team.
|
| Kito | That brings up and interesting point. I have some of IBM’s customers that are using their WebSphere application server, and I met a few at the conference too. IBM has a reputation for being very slow with the new standards. Do you have any idea about when they might start trying to include support for MyFaces?
|
| Martin | They are completely secretive about this.
|
| Kito | At least it’s good to tell people – I know they are definitely committed.
|
| Martin | Obviously, they put their stakes in MyFaces right now.
|
| Kito | Right, so that’s good. Let’s look at a couple months out – now it is December – when MyFaces 2 is beta or completely stable. I am not tying you to any particular dates but just whenever that happens. Why would someone want to pick MyFaces versus Mojarra?
|
| Martin | For now there is not so much in implementation that would be different. As always, we try to give the developer a better development-time experience than Mojarra did, right from the beginning. We can definitely say in the first version, 1.0, MyFaces was the only implementation you could really use for big projects. Quite a few flaws in Mojarra, which made that impossible. Synchronized statements where they shouldn’t have been and stuff like that. It’s not like that anymore, so you can definitely use Mojarra for your everyday project. What MyFaces always did was… like make sure that messaging was alright. You would get the right exception messages if you did something wrong. Really small stuff. A feedback page like the one that you have in Facelets -- we had that early on in MyFaces as well, so that you could see… even for stuff that wasn’t happening during rendering, you would see proper error messages. Reloading off configuration so you didn’t have to restart the server if you changed something in your configuration – MyFaces offered that from early on. Mojarra has picked it up as well.
We will try to innovate further in this regard. For example the Ext-Scripting support will be something like that, which will also enhance your development-time experience. When that February Ext-Scripting is out, we will try to have a version of MyFaces together with Ext-Scripting support where you really don’t have to restart your server at all anymore. That would really be cool. I think that will be a feature edit which will help a lot of people, even without using Groovy. You can do that with Groovy but not a lot of the big shops are going to jump on the Groovy train just for this development-time experience. It makes a huge difference for the developer, I think. Also for error handling, debugging, I don’t know, we will try to innovate in this area more. We cannot really do much with the API specification, right in the implementation. This is one of the areas that we can concentrate on.
The second area we can concentrate on is performance. Currently in the 1.2 versions, Mojarra and MyFaces don’t deviate much, and it’s really the same thing if you look at the benchmark results. For 2.0 we might try to enhance partial state saving a little bit more in the MyFaces implementation. We see a saving of 80% of the state as of now with Mojarra in the benchmarks. We will certainly try to reduce that number for MyFaces even more. That would be a cool thing to do.
|
| Kito | Nice. Is that something that Oracle might be interested in with Trinidad?
|
| Martin | Definitely.
|
| Kito | I know they have always been really into state saving.
|
| Martin | For example Credit Suisse, our largest customer, they also have that problem to a large extent.
|
| Kito | Makes sense. One of the questions that people might have is which pieces are in Tomahawk and which pieces are part of the MyFaces core? For instance, I know there is a security manager.
|
| Martin | We tried to move everything which is not in the specification out of the MyFaces core. So MyFaces core is really supposed to be plain JSF implementation, which will implement the specification, nothing else. Whatever is additional features should really be in MyFaces common or one of the component libraries, or in Orchestra, or in the JSF portlet bridge, so that it also works with both implementations. You can certainly use both implementations working together with this project.
|
| Kito | It is probably worthwhile to point out that the JSF Portlet Bridge part of the MyFaces overall project is a reference implementation for JSR 301.
|
| Martin | There are a lot of other standards coming up in this regard. Mike has to do a new standard for all of the versioning issues, right?
|
| Kito | Yeah, it’s a lot of accommodations. I kind of wish we could clone Mike. Mike, by the way, is the spec lead for the JSR 301 Portlet Bridge stuff. He is an Oracle employee but I kind of wish there were like two or three of him…
|
| Martin | Definitely to work on the different versions.
|
| Kito | Such is life. I think those are all of the key questions that I had for you Martin, do you have any other things you want to add? Are you having a good time at the conference?
|
| Martin | Definitely yes. I brought my sister, had some fun with her as well. We went shopping and to theme parks, it was a nice experience. Thanks for inviting me Kito.
|
| Kito | I am very glad to have you, and that does bring up another topic, which is another JSF conference coming up in February.
|
| Martin | Thanks Kito. We have JSFDays in Europe, so if you are listening and are from Europe, please come to JSFDays 2010. JSFDays 2010 will be from the 22nd to the 24th of February in Vienna. If you are interested in the JSF ecosystem and want to hear the important speakers in the JSF world, come to us, you certainly won’t be disappointed.
|
| Kito | That was a pretty good plug there. There is also some Java EE and Spring stuff there too, right?
|
| Martin | Sure, it’s not only JSF. It is one track JSF plus Web. Then there is one track Java EE, Spring, whatever you need on top of JSF 2 to make your project work.
|
| Kito | What are your thoughts on CDI by the way? Context and Dependency Injection for Java? The new name for the Web Beans spec.
|
| Martin | Yeah, it’s definitely a cool thing to have the conversation scope finally standardized, and that’s what we see in 299. We are talking about JSR 299 with CDI and then we have JSR 330 which is basically the base for JSR 299. So those two together are a very important step forward for the Java ecosystems. I definitely think the whole dependency injection stuff has shown its merits in the last years.
|
| Kito | Definitely.
|
| Martin | It should definitely be in all the standard based projects out there as well. Thankfully this has happened now. So there are going to be topics on this, of course as well. For the reference implementation, but also on the Spring side, Jurgen Holler is going to be there. It’s all going to be covered at JSFDays.
|
| Kito | So if you couldn’t make it to the JSF Summit, which most people from Europe didn’t, then you should definitely check out JSFDays. You can get some of the same content with different people, and some of the same people. It should be good. Thanks again, Martin.
|
| Martin | Thank you, Kito.
|
| Announcer | That's it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann. Thank you for listening.
|
