Kito:

Hello, and welcome to the JSF Central Podcast.  I don't remember what episode number this is, but some episode number recorded in October, 2014.  It's been a little while since we've done one of these, but I'm pleased to have with me today Manfred Ream, who is the principle member of the technical staff at Oracle, and the co-spec lead for JSF 2.3, and the co-spec lead for MVC 1.0, which is a new spec, which will be part of the Java EE platform.

So welcome, Manfred.

Manfred:

Thank you.

Kito:

I think it would be helpful for people to hear a little bit more about you.  I think Ed Burns is pretty well known for the JSF stuff, but you're a little newer to the JSF team at Oracle.  So tell us about yourself.

Manfred:

Sure.  Well, basically I joined Oracle in 2011.  And the first task on hand for me at Oracle was working on the implementation of Mojarra, and getting the bugs down, which I think we did pretty well.  Before that, I actually was mostly in consultancy, so been around the road, seen a lot of JSF projects, done a lot of Spring MVC projects.

Kito:

Were you an independent consultant?  Or were you with another company, or what?

Manfred:

I used consultancy companies, yeah. 

Kito:

So, what made you want to take a full-time gig working on a JSF implementation?  I think I remember when your position was open, actually.  So you must've seen something that grabbed your attention there. 

Manfred:

Well, actually back in the day, I reviewed the spec, and I was working on, obviously, JSF stuff as well.  And it was actually Ed who asked me if I was interested.  And I was like, why not?  I mean, it's something that…it's always easy to complain about something, and until you have to start working on the spec, then you realize that there's a lot more to it than you see from the outside as just a user of it.

Kito:

Right, right.  So what was it like moving from that world of consulting?  Because this is -- you know, I can totally see your path here because I've been doing all consulting for many years now.  But, you know, I spend a lot of time looking at the implementation code, and I work a lot with PrimeFaces, so I look at a lot of their code, and I write a lot of stuff that goes around it, and integrates with it.  But, you know, I don't do it day-to-day.

Manfred:

Right.

Kito:

So, what's it been like for you, moving to that day-to-day -- okay, now I'm working on the implementation all the time -- sort of mentality?

Manfred:

It's sometimes a little bit of a struggle because, obviously, when you end up in that particular way of working, then you're like: okay, well, is the developer really going to like it if I do this?  Or how do you determine which bug is more important because that's a little bit of a struggle, too.

Kito:

Right.

Manfred:

Because everybody thinks that their bug is the most important one.  And yes, in their mind it is, but in our minds we're like: oh boy, how do you put the priorities there?  And then, obviously, if you're working on a spec, what is going to end up in the new one?  You know, that's also tough.

Kito:

Yeah, I could imagine.  So, speaking of that…you spent a few years working on implementation, and now, you're actually moving to do some more of this spec stuff as well, right?  With the co-spec lead for JSF, helping out where Roger did many years ago...

Manfred:

True.  Yeah.

Kito:

…and then also, with the new MVC 1.0 spec, which we'll talk about in a minute.  But does it feel like a relief from the day-to-day programming, or just like totally different perspective to work on the spec as well?

Manfred:

Well, the spec is an interesting thing. On the one hand you have that specification document, but that's not really all.  A lot of people would say: well, that's the spec.  But no, it's not, it's java.doc, it's js.doc that also comes with it.  So there's a lot more to it than just writing a piece of prose that says what it needs to do.

It's like basically, if you're looking at feature sets, once you start implementing the feature, then you're really just thinking: okay, what do I need to write to support this?  So, it's kind of an iterative process.  And you know, in the 2.0 recycle we're looking at more of CDI alignment, so in the expert group, we went a little bit back and forth on how do you maintain backwards compatibility, but yet, move forward.

Kito:

Right.

Manfred:

So that's always going to be a struggle with spec stuff because, you know, the spec needs to stay backwards compatible because that's obviously the value-add that we deliver from the platform as well.  But then, yet again, how do you move forward?

Kito:

Yeah, that's definitely a tough challenge.  And I think -- I mean, that's definitely the key thing about Java, right?  Is that nothing ever really goes away -- I'm sorry, now some things are starting to go away, but they're very specific things, you know?

Manfred:

Yeah.  Well, that's the thing.  Obviously, we have a process called pruning, but that doesn't mean that it goes away from the RI. It just means that some other implementers might opt to say: yeah, we're not going to do that anymore.  But the RIs will just keep doing it because that's usually how it goes. It's like slowly moving towards: okay, this is really what you should be using, and this is what you used to be using.

Kito:

Right.  That makes perfect sense.

So let's spend a couple minutes here talking about this other new specification, which you're the co-spec lead of, called MVC 1.0.  And I will let you explain what it is before I give my perspective.  So what is MVC 1.0?  How does it relate to JSF?  What is it in terms of Java EE?

Manfred:

Well, MVC 1.0 really should be called Action-Oriented MVC -- that's one big thing that you need to realize.  It's basically taking a different approach -- writing your application, you look at it from an action-oriented perspective, so it's plugging the hole in the EE platform because, you know, everybody that uses JSF realizes, obviously, that JSF is more component oriented.  So, this one is basically plugging the hole, saying: hey, you know, we missed a part in the EE platform. And now it's time because people have asked for it, and we listened.

Kito:

All right.  And just to give a little bit of background, there was a pretty extensive user survey for the Java EE user community.  Was it this year or last?

Manfred:

Yes.

Kito:

Okay, it was this year.  It seems like it was last year.  And one of the questions was…now, I actually think part of the reason for the result is the wording of the question.  The question was, I think, do you think we should introduce another MVC sort of framework alongside JSF?

And a lot of people said yes.  I think there was another question that was sort of similar to that as well, but basically, the community seems to want it, especially based on that survey.  And you do have plenty of people that are used to more of a Struts -- hopefully Struts 2 -- but Struts or Spring MVC, which is a very popular mindset.  And you can't do exactly the same thing with Java EE, right?  You can use Spring MVC with Java EE, but I don't know how many people actually do that.

Manfred:

I think you would be surprised.

Kito:

Really?

Manfred:

There's a lot of things there in the platform that are used, and then even within Spring MVC they'll just plug into it.  But you know, it really depends on the developers that are using whatever they want.

Kito:

Right.  Which makes sense.  And you know, I think the benefit of the action based frameworks…I think they do make it a lot easier, obviously, if you're working with a lot of custom JavaScript and JavaScript widgets which don't have any server side counterpart. Or if you just have very simple web pages, I guess they work very well for that as well.

Manfred:

Well, you know, it's all about choices. I mean, that's the thing, because if you really look at JSF, you know, it can do it -- it probably can do it -- but the fact is, it's like: what is your developer skill set?  I mean, if your company has been pretty happy in an action-oriented framework, then obviously, that's where your skill set is.

Kito:

So for those who aren't really familiar…and I imagine at this stage, JSF has been around long enough that maybe there are some people who haven't really done work with Struts or Spring MVC, amazingly enough.  So can you kind of explain how that model works? 

Manfred:

Well, as opposed to JSF where your intro into the application is a page in the MVC model, it wouldn't be a page. You're basically mapping the URL to a piece of custom code that does whatever business logic it needs to do.  And then once it's done processing the other piece of code, it says okay, which page do I now need to display?  So it basically turns it the other way around. While in JSF, the first order of business is always: look at a page, then do the action, and then go to another page.  Versus the MVC model is look at the URL, go to your business logic, and then go to your page.

Kito:

Okay.  And when you actually go to a page, what is the page going to be?  Is it like pure HTML?  Is it going to be a JSP?  What is it going to be?

Manfred:

Well, the intent is -- and obviously, we need to think about making a pluggable API, but we're going to have to deliver some defaults, you know, because that's a given.  The intent is, on the one hand, JSP -- I know , it's old, but still a lot of people use it, so make sure that it's easy to migrate to.  And the other intent is Facelets, which really means JSF.  So for people that are using JSF, they could easily also use MVC because the markup will be identical.

Kito:

So what would be the use case for that?  Would that be -- like, if you were writing into JSF stuff, and you wanted some sort of, you wanted to go directly to an action first?  As opposed to, with JSF 2.3, you can do view actions where you can actually dispatch from one view to another before that view is rendered.  But you still have to go to the page first, right?

Manfred:

Correct.  And that's the key difference.  The key difference is really how does the lifecycle work?  In the MVC model, there really is not a notion of a lifecycle, it's just basically: call code, go to review, call code, go to review.  Whereas in JSF you can write a lifecycle.  So, you can also basically change the lifecycle to what you need in your organization.  And obviously, not a lot of people do that, but that is a possibility.  So if you look at it, the initial prototype that I did -- just to see if it was even possible -- it kind of uses that model as well, I just installed a custom lifecycle, and basically did all the steps of first calling the code versus first calling the page.

Kito:

Wait, so you did that in JSF?

Manfred:

Mm-hmm.

Kito:

Oh, I didn't realize you did that.  Interesting.  Okay.

Manfred:

And some people would say well, why is it not done in JSF?  And I would just answer them with: well, the intent of the MVC spec is to stay away from binding it to a specific technology, and we're saying okay, we're having an overarching spec, and then however you want to implement it, that's really up to you.  And that's the discussion that kind of has to happen in the EG, where we're going to have to look at all the different varieties of things…for instance, Spring MVC supports, and/or Struts, either 1 or 2, depending on what you want to look at. 

So the MVC spec itself is more the carrier, versus the implementation, which really depends on who is doing the implementation. Obviously, the RI will be done by Oracle, but I'm assuming that there is going to be some uptake from third parties to do their own RI -- I'm sorry, not RI, their own implementation, obviously.

Kito:

Yeah, that'll be interesting to see if there's an Apache version, or if Pivotal/Spring Source is going to support that at all.  Because they've been really good about selectively supporting many parts of Java EE, so I don't know if they'll feel this is one they need to support, since Spring MVC is doing a pretty good job.  So we'll have to see about that.

Manfred:

Well, the Expert Group is still open, so if they want to join, then they're more than welcome.

Kito:

That would be great.  All right.  So I guess the last question related to that is whether or not a lot of people in the JSF community, especially the ones that can see that you can implement MVC on top of JSF -- and of course, I want to preface that by saying JSF is still MVC…Model View Controller already.  It's just not action-oriented.  But what would you say to those who say: oh, well now you're trying to replace JSF with something else – who think that basically, Oracle is saying don't use JSF, use MVC.

Manfred:

Well, I would want to flip that question around.  It's like, why didn't you ask me why people are not using JAX-RS for that? 

Kito:

Hm, okay.  Interesting.

Manfred:

I mean, that's the whole thing, it's about choices, I guess.  I mean, some people would use JAX-RS, some people would use JSF, and then obviously, once the spec is done, some people will use MVC.  It's all about choices within the platform.

Kito:

Right.  Right.

Manfred:

You know, and there's different types of hammers.

Kito:

And, you know, there was initial talk about putting this as part of a JAX-RS, but the JAX-RS community wasn't too interested in having it as part of that spec, which I think kind of makes sense.  So now it will be its own spec, and we'll see how it goes.

Manfred:

Yes.

Kito:

All right.  So, MVC 1.0 was targeted for Java EE 8, right, which is due in 2016?

Manfred:

That is the current plan of attack, yeah.

Kito:

Okay.

Manfred:

At least as far as I know.

Kito:

And also, part of Java EE 8 will be JSF 2.3, right?

Manfred:

Yeah.

Kito:

So before we get to -- I do want to talk a little bit about JSF 2.3 and what's coming up, or what may come up in the next couple of years.  But I also wanted to ask you in terms of JSF 2.2, what sort of your favorite feature is.  I think especially larger companies are really just starting to use JSF 2.2, even though it's been out for about a year or so.

Manfred:

Yeah.

Kito:

So, I think it's good to just point out some features, which are in there; we did a lot of that in JavaOne.

Manfred:

Right.

Kito:

So, I know what your favorite feature is, but why don't you go ahead and tell us.

Manfred:

Well, obviously, in the sense of simplicity, stateless.  You know, you can make a view stateless, and you're obviously cutting down its runtime memory usage.  But it's also a good thing to do if you're having a public facing site where you really don't need that.  You know, all that state that normally is carried over into the session. 

So, whenever that particular feature came up, I tried to look at it from a perspective of the developer, and said: well, how can I make it easy to enable, and easy to use, but also, easy to implement? Because that's the flip side of doing implementation work -- you're like: okay, where does that plug into?  And actually, it's quite an interesting feature because a lot of people probably don't even know that, but it is actually also available in the 2.1 stack.

Kito:

Oh, really?

Manfred:

Yes.  But it's done in Mojarra specific.

Kito:

Ah, okay. 

Manfred:

So that's when the initial prototype was done, once we came to the conclusion that it was easily feasible in 2.2, because it was pretty late in the spec cycle that that was added.

Kito:

Yeah, I remember that.

Manfred:

So that's why we decided now we really needed to make it a spec supported feature because it's easy enough to do, but the benefits for certain use cases is definitely there.

Kito:

Yeah, I definitely think so.  I really haven't had much of a chance to use it, but there was one project where the pages were all very simple, it was just a lot of navigation, it was a kiosk application, so there's really not a lot of -- there's no big data grids on a kiosk screen, right?  So stateless made a lot of sense for most of those pages.

Manfred:

Right.  Well, there is another one where you can really use it well, and that's if you have basically a mobile app, and you're doing single-page applications.  Combined with Ajax, they work perfectly fine, and then you can just keep your state to a minimum.

Kito:

Oh man, my phone is just going off like crazy here.  All right…okay, I think I got it off now.  Okay.  So I totally missed what you just said. 

Manfred:

I personally haven't tested with an application that is completely a one-page app.  I use stateless views, plus Ajax, which is really kind of funny.

Kito:

Yeah.

Manfred:

And it works perfectly fine.

Kito:

I guess as long as you're not really trying to maintain a lot of state for the page, or you're posting that state back for each request, you're pretty much good to go.

Manfred:

With 2.2 for a mobile client, obviously, I figure the amount of data that you want to keep should be minimal because that's the whole reason why you're doing mobile in the first place.  So, you don't want a big state marker, you want to keep that entire page to an absolute minimum.

Kito:

Right.

Manfred:

And obviously, I'm doing Ajax because I don't want the page to show up during mobile browsing, because it makes it look like a native app.

Kito:

Right, that's a good point.  Okay.  So, what are your thoughts on Leonardo Uribe -- I think is his last name, I can never pronounce it properly.  But he's the implementation lead for MyFaces.  I think one of his thoughts was that the partial state saving, the state impact really isn't that bad to begin with.  Do you have any thoughts on that?

Manfred:

He's right to a degree.  The thing is, you also have clustering in mind.  If you do clustering, then obviously, anything that has to go across the cluster is expensive. 

Kito:

That's very true.

Manfred:

So if you don't do clustering in that particular way, then, yes, it doesn't matter too much.  But once you go in the clustering route, and you're saving stuff in the session, it needs to be replicated, and in an HA environment, that could be potentially very expensive.

Kito:

Right, yeah.  That's a very good point, definitely.  All right.  Any other JSF 2.2 features that jump out at you?

Manfred:

Well, you know, both the flows and the resource library contracts were obviously, big-ticket features.  And a resource library contract is really, really powerful if you're in a situation where you want to support both mobile and a desktop client because you can just switch back and forth between a set of templates that you just define.  So that is a really strong feature.

Kito:

Yeah.

Manfred:

And hopefully, people see that.  But the nice thing about it, it's a stackable feature.  So what that means is you could actually have a resource library contract for a layout, and then a resource library contract on top of that for color styling or something like that.  So you could switch back and forth between -- I'm just using an example, obviously -- a blue and a red styling, and a mobile versus desktop styling.  So that would be four permutations that you would already have.

Kito:

That's a good point.

Manfred:

You know, that's a really strong feature in my mind that, you know, if you want to support different stylings, and/or different clients.

Kito:

That's the other thing that jumps out at me because I've -- I'm sure you ran into this as well.  I had clients who basically have a product that they sell, and either it's a hosted product or it's an on premise product.  But either way, each client wants a different look and feel, and different sets of parameters, and things like that.  And you can do a lot of that in the database, but at some point, you want to actually change the templates, and the resource library contracts makes that very easy to use.  So I think that's one of my favorite features, too.

All right.  So, what else did I have on here?  Oh, yeah.  So JSF 2.3 is the new spec, which just got started.   And we talked a little bit about this at a JavaOne BOF, but what do you sort of see as potential things that we may take on in JSF 2.3?

Manfred:

Well, from the Oracle side, we're this time really interested in aligning the platform better for you guys, so that you have all the best benefits from the platform that you previously had to work harder for…like, in this particular case, CDI alignments.  It doesn't make sense in this day and age not to have proper CDI support all across the board in JSF.

On top of that, obviously, we're going to be looking at a lot more performance analysis so that we could cut down in EL evaluation roundtrips that are not necessary.  So that's really the crux, and on top of that, there's a lot of issues that we've had in the past that asked for clarification on the specification here and there.  So we'll be addressing those because we all know that the JSF spec is an older spec.  So it's time to go through it with a broom, a little bit.

Kito:

Hm.  That's a good idea.  I think it's also a good opportunity. Like, this time around, we have a lot of new members on the expert group, which is great.  And that two of those people are the infamous BalusC and Arjun, who are both OmniFaces committers.  So I think since we've got the OmniFaces guys onboard, there's a lot of room for a lot of little tweaks.  And I don't really want to make OmniFaces obsolete, but there's certainly a lot of things they've done, which we should really do in the spec.

Manfred:

Absolutely.  And that's why, you know, we're really happy to have them.  But that's what I'm saying, it's like from our perspective, from the Oracle side, we're just saying okay, please help us out.  So yes, definitely our goal is to get the community a lot more involved on this spec, than they have been in the past, so that they're driving -- more driving the new features than we are.

Kito:

Right.  Which is an interesting perspective.  And I think just to add a little bit to that, at the Birds of a Feather session at JavaOne, Ian Hlavats, who is also one of my Enterprise Java Newscast members, and I brought up a couple of new ideas.  Mine was pretty simple, it was just based actually on something that we did for one of my clients, which is just that in some cases, rendering a component via JSON can be a lot faster than rendering all the markup.  So basically, the idea is that you render the changes as JSON properties, and then the component, in JavaScript, updates the necessary parts of the DOM. But, you know, it can be faster than a whole DOM replacement.  Also, there's less data going back and forth, which I think is sort of the biggest issue.  So that's one of the things we talked about, and I think that would be an easy thing to get in there. 

And Ian had a lot of stuff to say about ways to possibly integrate with client side frameworks like Angular.JS and Backbone -- oh, I'm sorry, not Backbone, Bootstrap, excuse me.  Very different. 

So that brings me to another question.  So we're server side guys, and I think it's kind of interesting…as a JSF developer, you write UIs that live on the server and the client -- it's kind of a weird sort of role, you know?  Because you're not really necessarily a JavaScript developer, and you're not like a backend Java developer, you're sort of in the middle, right?

Manfred:

Right.

Kito:

So what are your thoughts about that?  About sort of the full-blown client side MVC frameworks versus the older server/client side…you know, server-oriented frameworks like JSF.

Manfred:

Well, I think they both have a place in the world.  You know, even though a lot of people seem to think that everything is going mobile, there are some cases where you're going to have to just bite the bullet, and say: no, this is just better done on a desktop.  I mean, I can't see, for instance -- it's just a specific example -- I cannot see anybody in accounting doing that on a mobile device.  So for day in, day out usage…I mean, for reporting purposes and all that stuff, yeah, probably, but for day in, day out data entering, I don't see that happening.  It's just inconvenient.

Kito:

Yeah.

Manfred:

 So it really depends on, I guess, the organization you're looking at.  It's easy to always say: well, the next big thing is mobile.  I would agree, there is a lot of push in that direction because that is a reality.  However, the older stuff that is out there, or needs to be upgraded, is still there.  So you're going to have to then look at what is really the best way of doing this. 

Because for instance, if you look at a public facing site versus a site that you need to log in to, those are already two different use cases for server side.  So you have to really look at: what is the best technology for the use case that I'm trying to solve.  And instead of saying okay, this is the best use case for everything, you need to take a step back and say okay, what is my skill set as a company, and how can I solve this use case the best?

And then obviously, number three -- and that's usually the one that's forgotten the most -- how can I support this in the long run?

Kito:

Yeah, that's always a good point to bring up.  And you know, it's funny, with the client side frameworks, they definitely push the limits of what a browser can do.  And I know on the project I'm on now, which is nearing a close, but it's one of those technology migration projects that was the migration from Power Builder.  But it's another one of those applications that never is going to be on the mobile device because it's basically managing benefit information for people that live in a state that has the need to save benefits.

So that's something someone at a desk is going to be doing.  But my point is that when we started out on that project, I think they were using IE 7, I think, on very slow, not the best computers.  And now things have moved on, and they've upgraded to newer machines, but they're still going to be using IE 9, I think.  I think, if you put everything on the client, then you're also beholden to the limitations of that particular person's machine -- which you can control in some environments, but in a lot of environments, you can't control it completely.

Manfred:

Absolutely true.

Kito:

So, that's something a lot of people don't always think about.  And what I like about JSF is that you really have the option of deciding how much you want to do in the server, and how much you want to do in the client, which can really be quite powerful. 

Manfred:

Well, that's definitely also one of the things in the Ajax support of JSF, where we have to be very, very careful when we do any changes there.  Because as you already pointed out, some browsers are different between…even versions. 

Kito:

Yeah, definitely. 

Do you think there's going to be any Ajax push support built into JSF at any point?  I just thought about that because there's different frameworks, you know, different libraries that provide that feature, but --

Manfred:

I think we're going to be more looking at -- not more Ajax push but more servlet push because servlets…we're always going to have the push model in there anyway because of HTTP/2.

Kito:

Right. 

Manfred:

And since we, as JSF users, know ahead of time what kind of resources a component would need, we have to go figure out, obviously in the EG, how or where and when we're going to be doing this. But that means basically, if you use a particular component, we can push the resources down at the same time.

Kito:

Hm.

Manfred:

Which means, first, you don't need Ajax push because you're just pushing all the resources down with the initial request because you know it's going to be needed.

Kito:

Right.  I think there are definitely a lot of use cases that HTTP/2 could really open up.

Manfred:

Right.

Kito:

It's very exciting stuff.

Manfred:

It's going to be really interesting, though, because they're changed over from a text protocol to a binary protocol, so that's going to be interesting for everyone who's actually developing it.

Kito:

Yeah.  It's kind of hard to imagine, actually.  Does this mean we won't be able to view source anymore?  That just sounds wrong.  Wow.

Manfred:

Yeah, I'm sure someone will find out…write some JavaScript library to do it.

Kito:

Yeah, but it's just not the same.  I've always liked the fact that it was always very easy to see what was going on with the web.

Manfred:

True.  Well, we will adopt the feature, but we're going to have to make sure that at least from the JSF side, we can give the developer the tools to actually see what's going on because if you can't see what's going on, then it's going be very hard to see any bugs or any issues that you caused yourself.  Because sometimes, you know, bugs are not really bugs, they're just something that you did wrong.

Kito:

Yeah, definitely.  Definitely.  All right.  Well, I think those are all the key questions I had for you, Manfred.  Anything else you wanted to talk about?

Manfred:

Well, you're an expert group member, too, right?  So what do you think about the JCP process itself?

Kito:

You know, I don't really have anything bad really to say about it.  I mean, I know there's been a lot of complaints, but I found -- I mean, the only complaint I could ever think of is that it takes forever to do each new version.  Now, do I have an idea about how to make it faster?  No. 

The JSF expert group is the one I've been on the longest, since 1.2, and it's definitely the one I've been the most involved in, but I've been on CDI, and CDI 1.0, and the portlet, and the portlet JSF bridge ones. And whenever someone tried to do it faster, it just never seemed to happen.  They would have some wonderful schedule -- hey, we're going to do this in a year -- which still seems slow in some ways, but it never happens. 

So I'm not really sure there's a better solution for the speed aspect because there's a lot of things that happen.  You have to deal with a lot of people, we have to write the spec, and the TCK, and the implementation.  And those are nontrivial things to do, unless it's just a very small point release.

But other than that, you know, I found the process pretty great.  And this is coming from an individual, a small consulting company, so it's a different perspective than a large company that has a huge agenda, and I'm sure SpringSource has a very different perspective, or Apache.  They have very different perspectives than I do.  But as an individual, I think it's been pretty great.

Manfred:

Okay.

Kito:

And I'm very glad that…I think all of us were a little worried after the Oracle acquisition that somehow that JCP would die or something.  But it hasn't, so I've been very happy to see that.

Manfred:

Well, I think it actually got an uptake in the last couple of years -- that's at least my perspective.  That more and more people are willing to actually come into the process, and also, the ability for JUGs to be part of the process, you know, that's huge uptake, too, because it makes it slow down.  You know, they actually have more of a say.

Kito:

That's a really good point, yeah.  I have noticed a very…an increased emphasis on the Java User Groups, so yeah, that's very cool.  Definitely. 

All right, Manfred.  Well, I really appreciate you taking time to chat.  Even though we didn't do it at JavaOne, I think Skype seems to be working out okay. 

Manfred:

No problem.

Kito:

And so I guess we'll see you around.  If anyone's interested -- the MVC 1.0 expert group, it's still open, right?  If you wanted to nominate yourself to join.

Manfred:

I would always say -- even from the JSF side -- if there's somebody really good, it's not common that we do it later in the process, but it's not impossible.

Kito:

Yeah.  And the JSF one isn't that far along, so it's really not that late.  So you can always join the expert groups, I think from the JCP site, right?  Or not join, but nominate yourself to join.

Manfred:

Yes. But even if you don't want to nominate yourself, but you do want to keep up-to-date with it, every spec has its user alias that is open that actually gets all the EG emails anyway, so that's the other way of keeping apprised of what's happening in any of these JCP specs.

Kito:

Yeah.  I'm not a member of the Java EE expert group, which is the umbrella for everything, but I'm on that user's list because I want to see what's going on with all those other specs that I don't really work with too much.  So yeah, I encourage you if you're not interested in trying to become a member, but you want to see what's going on, definitely, subscribe to one of the user's aliases.

What's the best way to get to the user alias?

Manfred:

The project sites…would have them listed.  Actually the JCP.org's webpage for each of the JSRs, have them listed as well.

Kito:

Okay.  Cool.

Manfred:

Either or.

Kito:

All right, yeah.  So definitely, check those out.  And also, Manfred is a frequent blogger, too.  So what's your blog site?

Manfred:

It's on Java.net, just look for my name, or Google it.

Kito:

All right.  Well, thank you very much for joining me. 

Manfred:

Yeah, appreciate it.