Kito:

Hello.  This is Kito Mann; I am here at JaxConf 2012, and JSFSummit in beautiful San Francisco, California.  And today, I'm here with Lincoln Baxter.

Lincoln:

Hello.

Kito:

Senior software engineer at…

Lincoln:

At Red Hat.

Kito:

Yes.  Yes.  And so, what do you think of the conference this year, Lincoln?

Lincoln:

Well, I love the JAX Conferences.  I've been to a couple of them before, and they always manage to pull in a great set of speakers.  I always enjoy meeting everyone who attends, and they're very involved, very engaged, and that makes it fun for me.  So, I'm having a great time.

Kito:

Yeah.  And I think—I've been very happy with the food.

Lincoln:

Yeah.  The food is great.  They've got healthy and very flavorful choices for us.

Kito:

Yeah.  And lots of great speakers.  There's Lincoln, but there's also Dan Allen from Red Hat…

Lincoln:

Brian Leatham…

Kito:

Brian Leatham.

Lincoln:

We had Jason Lee from Oracle.

Kito:

Yeah.  And Ian Hlavatts, who is also on the JSF and JavaEE newscast with me.

Lincoln:

Yeah.  Rich Hickey, the creator of Closure.  Also, Douglas Crockford, the discoverer, as he would call it, of JSON. 

Kito:

Yeah.  And a whole bunch of other great speakers.  And also, Ted Neward, as well, Neal Ford, et cetera, et cetera.

Lincoln:

Okay.  Sorry if we forgot you.

Kito:

Yes.  We still think you're a great speaker.  But yeah.  I think that's been great because what I—you know, some conferences, they may have a few good speakers, but then they have a lot of mediocre speakers.  Like, I really haven't seen that here, which is nice.

Lincoln:

Yeah.  I mean, like I said, they really know how to pull together a good bunch of speakers.  Not to put out too much of a plug there, but I would definitely—if I were looking to attend a good Java conference and really learn something, JAX is definitely really, really high up there on the list.

Kito:

Cool.  So, for those who don't know, do you want to tell us a little bit about yourself?

Lincoln:

Yeah.  Sure.  Well, I said I am a senior software engineer at Red Hat.  I work mostly in the R&D group at JBoss, but I also have some personal projects that I've been working on since I basically started doing software development professionally.  And those are at OCPSoft.org, my own personal brand is OCPSoft, and there are projects there that are ranging from URL rewriting libraries to Java libraries to help you format timestamps into the most appropriate human readable time.  And our latest project is we're trying to get a new social project management tool kicked off the ground—got some good interest in that, which is fun. 

But aside from software, I like to do swimming and sports, I try to stay active and get outside as much as I can because you can really stay at the keyboard for so long during the day.

Kito:

Yeah.  I need to start doing that more myself.  Getting up and…

Lincoln:

Well, you're a father now, so you have a…

Kito:

It's not helping with that.  Actually, we have been trying to do walks almost every day, but really, I join the walk like once a week or so…  It doesn't really help that much.

So, why don't we start with JBoss stuff and then, we'll move onto the OCPsoft stuff.

Lincoln:

Yeah.  Sure.

Kito:

So, right now at JBoss, you are the lead for the JBoss Forge project?

Lincoln:

That's right.

Kito:

So, tell us a little bit about Forge.

Lincoln:

So, Forge, if I could describe it in a sentence, is a command line tool to help you get started quickly.  It's a new project we're working on to try to help bridge the gap between…the problem we have when we get started with a project, and we're trying to integrate a new technology.  I mean, we really think at JBoss that what we do during the day for our jobs or maybe for fun or on the weekends should be—like I said—fun, productive and really attainable. So that when you want to try a new technology, when you want to get started with something you've never tried before, you should have a good experience upfront.  Like, you should be able to get it up and running in a couple of seconds.  This whole, like, going out to Google, finding a tutorial that may or may not help you, and then, you have to find like another tutorial to get the other part set up…that's okay, right?  We're all familiar with that.

But I think we can do a lot better.  And JBoss Forge is really designed to let projects create simple tools, simple plugins that are going to let their users get started really quickly.

Kito:

Alright.  So, for someone who hasn't seen it, what is it?  Do I go to a Web site and pick a button?

Lincoln:

Right.  Right.

Kito:

…and like, you know, what happens?

Lincoln:

So, the best way to get JBoss Forge is—if you're an Eclipse user—to get the JBoss tools plugin suite, and that's a set of extensions for Eclipse that provides…just features that Java, JavaEE developers are going to find useful to make their coding experience more fun and more productive.  And that includes Forge.  Once you're in JBoss tools, you can just press Ctl 4, and Forge is going to open up for you.

Or if you want to, you can go to jboss.org/forge, and you can just download the Forge zip file and you can run it straight in a terminal.

Kito:

Okay.  So basically, the interface that the developer gets is a terminal, right?

Lincoln:

That's right.  Forge is a command line tool that provides some features to it to make that a nice experience, so like when you start typing a command, you can press tab, it's going to help you figure out what you have to do next in order to get done what you want to do.

And it's very extendible.  Like, we don't want to have Forge require a certain set of technologies in your project.  When you use Forge, you can pick and choose whatever technology you want; you can go out and ask Forge to install the plugin for that technology, and then just ask, again, Forge to set it up in your project and it will guide you through that process.  It'll walk you through, step-by-step, what you need to do to get a working configuration up and running.

Kito:

So, it's really more about kick starting the project or trying to use it in other situations.

Lincoln:

So yeah, kick starting, but also, if you have an existing project—maybe you have something you've been working on for a while and you want to bring a new technology into that—you can apply Forge to that as well. You don't have to start a project with Forge in order to use Forge.  You can…as long as it's a build tool that Forge supports—in this case Maven is the most common tool—Forge will be able to understand your project, figure out what you've got already, and then guide you through getting from what you've got to where you want to be. 

Kito:

So, what other build tools does it support?

Lincoln:

We have preliminary support for Ant, but it's really—it's difficult to do because Ant doesn't have the concept of dependency management.  And we're not really sure we want to continue with that because, just out of principle, I think it's going to cause more complications than it's going to help with.  Because it's going to require that you have some extra constraints set on your project, and that's really not what Ant is about.  We just don't feel like it's a good match up.

But Gradle is something we're also playing with.  The Gradle guys have been working with us to get Gradle as an alternative to Maven.  So, that's pretty cool.

Kito:

Yeah.  I'm still not a big Maven person, but more importantly, a lot of the shops that we work at…even if I were a big Maven person, I can't always make them instantly switch to whatever I think is the coolest or best tool.

Lincoln:

Well, it'll be interesting to see what happens when Java finally gets modularity because as we start building Java modules, Forge is probably going to be able to handle those as well.  Because I think that's probably ultimately going to be what Maven becomes, or maybe what replaces Maven once we finally get a central Java module repository.

Kito:

And that'll be nice.  Really nice.  So, let's say I sat down one day and I want to start a project that uses JSF 2.0 and CDI and JPA and Bean Validation.

Lincoln:

Okay.  Sure.  So, the first thing, if you're starting from scratch, then I would say is you probably want to use the Forge Java EE plugin suite because when you deploy to an EE container, you're not going to have to worry about setting up a container that is going to be able to provide you all these features.  So, your life is a little simpler to start with.

But the Forge EE plugins, if you wanted to get all those things started, you can just say…you just start Forge, and the first thing you're going to type is "new project".  The new project command asks you for what you want to call the project—the project name—and it's going to set up your project build structure by default, which is Maven.  So, it's going to set up your source directory, your source test, your source main, resources, et cetera.  And also, a pretty barebones pom.xml file with no dependencies, just the name of your project.

Once you have that, then you will, say, set up Faces, EJB, JAX-RS, you know, all of the technologies you want.  You just list them out in the setup command, hit enter, and then Forge will walk you through setting up each one.  And also, make sure that they are set up so that they work together.

Kito:

So basically, you can do all of them in one command line, essentially.

Lincoln:

Yeah.  You can do all of them at once, you can do one at a time—it's all up to you.

Kito:

Cool.

Lincoln:

And Forge isn't going to assume too much.  If it knows something is safe, it will probably go ahead and do it.  But if it gets to a point where it's not sure—say if you were working in a JAR project, and it comes across a situation where now you actually start wanting to work in a web context, and you want to turn this project into a WAR—then it's going to ask you: do you want to make this change?  Because usually, you wouldn't want to change a JAR into a WAR, unless you're starting, you're integrating or building something more complex. 

So, it's going to ask you when those types of major changes come up.

Kito:

Alright.  Cool.  So, how is this different than something like Spring Roo, or something?

Lincoln:

Or maybe Maven archetypes?

Kito:

Or maybe archetypes, yeah, sure.

Lincoln:

I think those are probably both the most common questions we get.  And I would say in terms of Spring Roo, Forge is probably most similar just because it is a shell, it is a command line tool.  So obviously, things are going to look pretty similar from that regard.  But Forge isn't really tied to a specific technology.  Roo is more of an application framework than it is a tool suite.  And Forge is really trying to be a tool suite so that we can all provide this experience for whatever technology we want.

In fact, nothing even ties Forge to Java other than the fact that it has some Java plugins that come with it out of the box.  You can write a plugin for Forge that maybe modifies something in your operating system, maybe you have a home automation system with some APIs that you can call and you want to write a plugin to do some more complex home automation tasks, or print out the status of your system, or something like that.

These are all things that you can use a Forge plugin to do.  And the fact that there are Java EE plugins is just a result of the fact that it's a JBoss project and we want to promote the Java EE programming model.

But in Forge 2.0, we're actually stripping all of that out, we're going to deliver Forge as a standalone tool without any plugins.  And then, when you start it up, you'll be able to pick which plugins you'd like to have it go fetch for your first experience.  You can pick nothing or you can pick as many as you want.

Kito:

So, where does it fetch these plugins and how does it know what plugins are available?

Lincoln:

So, Forge today has a central plugin repository—a central plugin index.  And that index is a list of all of the plugins that people have written and contributed to the Forge community.  Those plugins are listed in the index, and basically it says this plugin is called such-and-such, and it does this thing, and the sources for that plugin are located in a get repository somewhere on the web.  That's all the index has. 

So when you search the index, you're just searching for listings.  Then, you can ask Forge to install one of those listing, and it'll say "okay, I know where that plugin is located." It goes out, fetches the sources, does a build, and then installs that into the system while it's running.  Then, you have access to use that plugin.

The reason we chose to do it that way as opposed to, say, distributing plugin JAR files, is because we really want to promote the Open Source programming model.  Now, if you use a plugin and there's a problem with it, you've got the sources on disk.  And you can actually check out what happened and maybe contribute a fix back right away.

Kito:

Interesting.  So, is that a requirement then?  Can I write a Forge plugin and have it be a Closed Source plugin or something?

Lincoln:

Yeah, you can.  The Git style distribution isn't a requirement, but if you wanted to, you could just write a plugin, package it up as a Forge module, and distribute that completely and independently, or you can set up your own plugin index and distribute pre-built plugins.  So, it's again up to you.  We don't want to limit anyone from doing anything, either commercially or for their own independent reasons.

Kito:

If you want to be added to the index, how does that work?

Lincoln:

Well, the index itself is hosted on GitHub, just like all the plugins.  So, if you want to add yourself to the index, just send a pull request and we'll check out your plugin and if it's appropriate and doesn't have any nasty content in it, we'll get you in there.

Kito:

As long as it doesn't print out naked ladies and stuff.

Lincoln:

Yeah.  We try to skip that stuff.

Kito:

And another question about Forge.  Some of the stuff you talk about, I mean, basically it's sort of a—it sort of sounds like a command line plugin system, right?  Where the plugins can do whatever you want, essentially.  Have you ever looked at Windows PowerShell at all?  Just curious.

Lincoln:

A little bit, not too much.  It's a little bit similar to that, in that you can sort of aggregate more compound operations.  And consequently, another similarity there is Forge actually also provides its own scripting language.  So, if you don't want to write a full-fledged plugin, you could just write a Forge script, which is based off of the MVEL scripting language written by Mike Brock, another Red Hat engineer.

And you can write native Java code in your script and have it run, interpreted by Forge, to get the functionality you want.

Kito:

OK.  So, you have a new project…actually, one last question: is Forge 1.0, is it GA?

Lincoln:

Yeah.  Yeah.  Forge 1.0 is final, we're actually on 1.06 final at this point.  And we're mostly working on getting rich, nicely formed plugins out there, and thinking about Forge 2.0 for the future.  How can we take what we've learned from this experience over the past few years and deliver a really, really efficient solution.

Kito:

Cool.  So, you guys—your personal stuff, OCPsoft, has a new project, right?

Lincoln:

Yeah.  So, my personal projects have for a while been PrettyFaces, PrettyTime, and SocialPM.  PrettyFaces is a URL rewriting tool that I wrote to solve a lot of problems in JSF.  And over the years, people have started asking for some features that were difficult to do in PrettyFaces, and we've been sort of tacking things on and tacking things on to try to address these issues, which are really actually important use cases—otherwise we would probably say maybe we should figure out a different way to do it.

But it became clear that the architecture of PrettyFaces was not really designed to handle these kinds of general URL rewriting applications.  So, I looked at the features that we introduced in PrettyFaces, and said okay, well, this is pretty much a fix-all solution for what people want, if PrettyFaces' core functionality doesn't handle it.

So, it seems like that's a good starting point for more general applications.  So, I took that architecture, which was the PrettyFaces Rewrite processor, which basically lets you run custom Java class on a request, when it comes inbound and goes outbound. 

And I took that program model and said okay, this is really applicable more generally, and said well, what if we based the framework around that?  What if we based the framework around something that says whenever we have an inbound request, we can modify it, we can wrap it, we can perform some operations?  And we can also consequently wrap the outbound response—what happens if we can change values in the HTML as things go out back to the client browser?  What happens if we can change link addresses as they go out? And just make a framework around that that's really solid, and then, base PrettyFaces on that new Framework?  And so, that's where the Rewrite project came from.  Rewrite is really a set of APIs for interacting with the HTTP lifecycle.  In my opinion, it's what the servlet API should've been in the first place because it gets rid of all of the dead code in the servlet and says "what do you want to do?"

The syntax of that pretty much tells you the whole story.  You specify a configuration provider, and in that configuration provider you say configuration.begin().defineRule().when() and then you start making insertions.  So, when the request is inbound, and the dispatch type is forward, and the domain matches local host or ocpsoft.com, then you can .perform some action.  So, it's really taking a fluent style approach to saying there's some runtime condition, what response or what action do you want to have performed when that condition is met?  Because that in essence is the core of URL rewriting and HTTP manipulation.

So, by providing that in the Java API, which has never really been done before—we have had it in Apache mod Rewrite, we have had it in a couple other URL Rewrite filters, but they've all provided configuration based solutions.  It's never been a Java DSL that we can really interact with.  And that's just opening up new worlds of possibilities for what we can do.  Like, we're starting to see the ability where…we can define a rule and if a CSS request is intercepted, and we see that there is a .less file on the server, we can actually say okay—well, and there's a .less file in the server with the same name—we can say okay, this CSS request maps to that .less file and we're going to compile the .less file on the server, and then send it back as CSS to the browser.  So, there's no lag time doing browser side compilation of .less files.

We can, say, do the same thing for JavaScript and HTML. We can now, say, if someone requests the JavaScript file, and it's not minified, minify it before we send it back to the client, and we can cache the results of these things so that they are not burdening the server with any more intense operations that might take time or bog the server down.

So, it's really just opening up new possibilities of things that we would normally have had to write hundreds of lines of code to do in our own custom filters.  Now, these are just all providers' extensions that people are contributing to the Rewrite framework.

Kito:

So, when did Rewrite come out?

Lincoln:

I started working on it with Christian Kaltepoth, a guy over in Germany who has been a heavy—he's actually a committer and now the new project lead of PrettyFaces—probably last year, around this time at JAXConf.  And I've been working on it with him for the last 14 months, I guess.  We finally released version 1.0 in about February, and we're up to 1.05 final now in July.  1.06, actually. I think we're going to release 1.1 instead of 1.06 because there are a few API changes that we want to introduce.  Just a few things we realized that we needed to remove from the API because it was, in a sense, too dangerous.  Like, the ability to use regular expressions in some of the text pattern parameters.  It just…regular expressions are good, but if people aren't expecting them or don't really know how to use them, then they can easily get themselves into trouble.  And it's easy enough to get themselves into trouble as it is.  So, we said alright, by default, regular expressions are off. If you want to use them, there's a very fluent API to do that and the power is still in your hands. But 1.1 is probably going to be our next release.

Kito:

Yeah.  I tweeted about this during the conference…I think the API is very nice…it's very nice, easy to use, very…

Lincoln:

Thanks.

Kito:

I like fluent APIs, this one looks pretty good to me. 

Lincoln:

Well, it's…I don't know.  I think that there are a lot of…people give Java a lot of…they harp on Java for having bad APIs, and I've sort of made it my personal vendetta to fix that problem as much as possible wherever I can.  So, Rewrite, PrettyTime—they've both got nice fluent APIs that you can interact with.  So, when you interact with a Java API, you shouldn't think oh gosh, I have to type all these lines of code to do something, right?  It should just flow off your fingertips and you should feel good.  You should be happy when you're finished.

Kito:

Yeah.  And it should be somewhat intuitive what to call…sometimes it's really not.

Lincoln:

Yeah.  Yeah.  And actually, as it turns out, that's one place where Java makes it difficult because if you want to make a fluent API, you end up having sort of a class explosion in order to present the right interfaces to people at the right time.  And then, to remove some of the available functions you can call off of your builder objects.  Otherwise, you end up having too many options, or maybe an option that's inappropriate or would be correct programmatically, but inappropriate for the way the person would read the code as it's typed.

Kito:

Interesting.

Lincoln:

So, it's sort of an interesting thing to try to do because we're taking the English language and the way we comprehend the grammar of the English language and then, applying that to a programming language that's not necessarily a good mapping for that.

Kito:

Right.  Alright.  So, you have a couple of other products, right? 

Lincoln:

Yes.

Kito:

Well, first of all, just tell us a little bit more about PrettyFaces for those who want to use Rewrite style capabilities in JSF context.

Lincoln:

So, PrettyFaces is basically Rewrite for JSF.  Actually, the PrettyFaces project as it stands now can be used in any servlet application, but with Rewrite coming out now, we want PrettyFaces to really focus on what it's good at, which is handling taking a JSF-UID and turning it into a pretty URL.  Taking query string parameters and putting them in the path of the URL so that you can clean up and structure information so that people can read it more easily, and also, fix a couple of problems that JSF has. 

Even still, with 2.0, it's a little bit difficult to navigate sometimes.  They've done a lot of good to make that simpler by letting you return or simply specify the page you want to go to when you're navigating, but it's still complicated once you get to that page to actually have data loaded so that you can display it.  And those are some of the problems that PrettyFaces tries to address.  Because in my opinion, when you're writing a web application, you should just be able to say okay, this address goes to this page, this action happens, and take it from there.  And that's what PrettyFaces does with JSF. 

Kito:

Alright.  So, a couple of other projects that you have—PrettyTime is one. 

Lincoln:

So, PrettyTime is one of my earlier play toys, I guess.  While I was working on SocialPM, the first iteration, I saw these things that Twitter and Facebook were doing—where when someone would post to their wall or post to Tweet, it would say how many minutes they posted it ago.  Like, they posted it five minutes ago or ten minutes ago, or maybe two weeks ago, or something like that.

And I started thinking oh, well that's cool.  I want that for my Web site.  And I looked around and there really wasn't a library around there to do it.  So, I figured well, I'll just make one.  And I put it up as Open Source, and this was really at the beginning of my Open Source adventure, not really knowing what was going to happen.  As it turned out, people really liked the idea, and Thomas Weitzel, another guy in Germany saw it and he said hey, this would be really great if we could support other languages, not just English. And so, we worked together to bring in an internationalization feature to PrettyTime.  And now, we've got human readable timestamps in 23 different languages.

Kito:

Twenty-three.  That's a lot. 

Lincoln:

Yeah.  Currently working on Arabic. 

Kito:

Cool.

Lincoln:

So, it's really simple.  If you want to use it, you just go to the OCPsoft Web site, get the Maven dependency.  And you just say newprettytime.format, your date.  And it will print you—or return to you the string of the time in human readable format between now and that date. 

Kito:

Oh, okay. 

Lincoln:

So, if I just say newprettytime.format, a date that was from ten days ago, it's going to print out ten days ago.

Kito:

Nice.  So, is that always one of those X ago, or are there other sorts of formatting it can do?

Lincoln:

So, you can actually specify your own formats if you want.  By default, it will do like three months from now or ten centuries from now, or…

Kito:

Okay.  So, you can…

Lincoln:

Three millennium ago or whatever.  So, it comes by default with a whole set of time units.  But if there's a time unit that's maybe more specific for an application you're developing, you can tell PrettyFaces to use your custom set of time units instead.  And that might look something like maybe you're developing a game and your game has a time unit called a tick.  And you can remove all of the time units from the default set and add your tick unit in.  And then, it would say something like 40 ticks ago or 40 turns ago or something like that.

And it's just open and it's extendable.  It's sort of my philosophy.  I mean, provide a tool that does the core functionality of what you want.  Keep that tool simple, but let people extend it.  And in fact, that's what OCPsoft stands for, it says closed for modification, open to extension.  Open to extension, closed for modification—or the open/closed principle.

Kito:

Okay.  That's good to know. 

Lincoln:

So, that's one of the philosophies we use when we're doing software there now.

Kito:

So, and you mentioned earlier that you wrote PrettyTime when you were working on the first version of SocialPM?

Lincoln:

Yes.

Kito:

So, what is SocialPM?

Lincoln:

SocialPM is a project that I've had in my mind for a long time.  I actually started it with a bunch of my coworkers a couple of years ago.  And we've sort of been working around a bunch of technical issues.  We started doing it in JSF, and then, we realized that a project management tool should be responsive and I think it should be real time.  And we just kept running into some issues with JSF that made our lives difficult.  We eventually ended up switching to GWT, and now we're rewriting it in GWT but that has cost us some time.

But basically, the goal is that project management shouldn't be this painful, formal process.  It should be as much or as little structure as you want.  And in this case, we're starting with the agile methodology because we think that there is a lack of a good Open Source solution for an agile project management tool.  There's a bunch of for-pay solutions out there, there's a bunch of free Closed Source solutions out there.  But if you just want to host something in your own company and have the comfort of knowing that the data is all in your hands and that if something goes wrong, you can fix it and all that, then the SocialPM project is what we're trying to do that with.

So, I'm excited actually.  We just got three more contributors to the project.  It's still relatively in its infancy, but we're resetting the visions now and if you want to get involved, now is a good time because we want to solve this problem and we want it to be really good.

Kito:

Alright.  I don't think I have any other specific questions.  Although, I think I'm going to start asking people kind of generic questions.  So, what is your favorite—I don't know who I stole this from but it was somebody.  But it seems like a good question.  So, what's your favorite feature of Java?

Lincoln:

My favorite feature of Java.  I don't know if I can even call it a feature of Java, but I would say the interface.  I have this passionate relationship with interfaces.  I may be using them too much, but I think that it's the best thing that we've ever done in the software industry to be able to define a contractive behavior, and then define the implementation later.  It's just—it's what I go for every time.

Kito:

Okay.

Lincoln:

Because interfaces let you extend.

Kito:

True.  True.

Lincoln:

But if I had to pick a feature of Java that I liked the most—that's a tough question.  I mean, the features of Java, I would say are more features of the JVM.  But features of the programming model…I would say interfaces.  If we're looking at the Java Ecosystem, I would say probably CDI is the thing that I'm most excited about, because dependency injection really lets us decouple our systems and bring more architectural purity to the chaos we've had for a long time.

And in the far reaches of the Java Ecosystem, I would say that GWT, the Google Web Toolkit is what I'm really excited about. Because now we can write Java and have that compiled down to JavaScript that will work in the browser so that we can build rich Java applications—or rich clients set applications—in Java with all of the power of JavaScript. We can write native JavaScript if we want.  And we don't lose any of the programming model we expect and have to come to really enjoy, like type safety or refactoring.  In fact, we even have CDI compiling into the browsers.  Now, we have dependency injection in the browser.  And the possibilities of this are really exciting, and that's one of the other things I'm working on at JBoss right now, it's called the Errai project.  Mike Brock is the lead of that, along with Christian Sadilek and Jonathan Fuerth up in the Toronto office.  We're hoping to bring some really, really exciting things out pretty soon.

Kito:

Okay.  Alright, Lincoln, well I appreciate your time.  I'm glad we were able to finally sit down and do this. 

Lincoln:

Yeah.  This was good.

Kito:

Good.  Good.  Alright.  So, thanks for joining us and enjoy the rest of the conference.

Lincoln:

Thank you.  You, too.  And I'll talk to you soon.

Kito:

Alright.