Has the whole J2EE game changed?

[Rehan Zahoor]

I programmed using J2EE some time ago when there were no Java Server Faces, Dependency Injection and less was known about Web Services. I have come across a few articles, which stated the old J2EE as hard work, difficult and time consuming. and termed new things especially the Java Server Faces as the game changer. So at the risk of people calling it a silly question, , Is it true? Has Java Server Faces changed the J2EE completely and has made it easy to use, fast and quick to develop. Have not studied JSF much, Coming after a break to J2EE. Is use of Servlets and JSP still relevant as before or techniques have changed 80-90 %?

[Bear Bibeault]

While you may get opinions to the contrary, I've found just the opposite. JSF was heavily pushed by Sun/Oracle, but hasn't made much headway. In fact, three of my most recent jobs have been to take monstrosities implemented in JSF, and re-engineer them to something less over-complicated. YMMV.

These days, what I see most often is the server-side code relegated to serving up data via a RESTful API, and JavaScript MVC (or MVVM) used for the client-side application. I think the days of creating the client-side code on the server to send to the browser are numbered. Big, over-complicated systems like JSF have, in my opinion, the stink of the tar pits on them.

So to answer your question in the topic title: Yes, the game is changing. But JSF isn't the game changer.

[Junilu Lacar]

Bear Bibeault wrote:These days, what I see most often is the server-side code relegated to serving up data via a RESTful API, and JavaScript MVC (or MVVM) used for the client-side application. I think the days of creating the client-side code on the server to send to the browser are numbered. Big, over-complicated systems like JSF have, in my opinion, the stink of the tar pits on them

This aligns with my experience. Seems like Javascript and (ostensibly) RESTful APIs are all the rage these days. Many so-called RESTful APIs are at Level 0 of the Richardson Maturity Model though and many Javascript MVC implementations are themselves monstrosities that have supplanted previous monstrosities. It just reaffirms my belief that you need to understand basic principles first because lacking that, you'll make a mess no matter how shiny and new your technology hammer.

[Ulf Dittmer]

Slightly off-topic, if your experience is only with J2EE -and not JEE, which is how the APIs have been called since 2006-, then the game has indeed changed drastically. Notably in the EJB area (probably the most-maligned part of J2EE), but lots of other stuff is new, like JPA, JAX-WS and JAX-RS.

As regards JSF, Oracle is still pushing that, but it seems to have missed the point were it could become as dominant as Struts 1 once was. Instead, lots of 3rd party web frameworks are in widespread use apart from JSF.

[Bear Bibeault]

Junilu Lacar wrote:... and many Javascript MVC implementations are themselves monstrosities that have supplanted previous monstrosities.

True that -- proper discipline is required regardless of choice of language or frameworks.

[Rahul Mahindrakar]

Hi

I also see the above. It seems like RESTful APIs are in demand.

If you have a small project with not much of a fancy UI need then maybe JSF is a way to get started.

Here the Java Programmer might be able to get everything done.

But then building a RESTful API needs more than plain Java/JEE skills. It needs skills on the Javascript framework, and we have dedicated people for this.

Rahul

[Joe San]

Rahul Mahindrakar wrote:

But then building a RESTful API needs more than plain Java/JEE skills. It needs skills on the Javascript framework, and we have dedicated people for this.

Rahul

I've never seen a RESTful API implemented using Javascript. Did you mean that the API is served by some Java EE stack exposed via HTTP?

[Ulf Dittmer]

I've never seen a RESTful API implemented using Javascript.

He's obviously talking about the client side.

Did you mean that the API is served by some Java EE stack exposed via HTTP?

That's pretty much the definition of a WS, isn't it? :-)

[Joe San]

Ulf Dittmer wrote:

I've never seen a RESTful API implemented using Javascript.

He's obviously talking about the client side.

Isn't an API in this context of RESTful on the server side? A client is just a cosumer of this API.

[Ulf Dittmer]

I think you're interpreting the words too literally. Building an API requires considering the client side as well.

[Joe San]

Ulf Dittmer wrote:I think you're interpreting the words too literally. Building an API requires considering the client side as well.

May be it depends on the situation. In one of the projects that I currently work, we need to access a REST end point to get some data. This REST endpoint is served by a Java EE compliant server which we call the REST API's. I came up with a small client to access this API. I agree with you for the fact that developing an API should also have a client!

[Rahul Mahindrakar]

But then building a RESTful API needs more than plain Java/JEE skills. It needs skills on the Javascript framework, and we have dedicated people for this.

Here I meant two layers

1) Client Layer : The client layer is static content with the needed Javascript libraries. This layer is servered by the backend. This layer might need specialist Javascript developers

2) Backend REST API Layer. This is the Java EE backened using the needed Java EE stack for REST etc. This layer needs Java developers.

Rahul M.

[Tim Holloway]

As forum moderator for JSF and a regular user of JSF, I'll have to play Devil's Advocate here.

JSF's biggest problem is that people WANT to make it nastier and more complicated than it is.

It's true that internally things can get pretty murky, but that's the point. The murky stuff is supposed to be internal so that the user-written stuff won't be.

JSF is a virtually pure implementation of Model/View/Controller. Its architecture is ideal for handling forms input where people often enter invalid data. The View is defined in a template, so no logic need be present, the Controllers are all pre-supplied, so you don't have to code any. The Models are (supposed to be) POJOs. Which is why I always tell people that the more JSF-specific your code is, the more likely it is that you're not doing it right.

I like the fact that I don't have to set up explicit code to populate and extract data from forms. I like that much of the validation of data can be done in a simple declarative fashion instead of logic. I like the way it can automatically report validation errors without me having to code error and reporting logic. I like the fact that AJAX support is relatively straightforward. And above all, I like the fact that it plays well with others, integrating naturally with systems such as the Spring Framework, and raw servlets and JSPs. Not to mention that I can do unit testing without actually having to fire up an entire JEE server.

What I don't like is seeing people attempt to use JSF for things it wasn't intended for. Most notably generating non-HTML output such as PDF's and Excel spreadsheets. I don't like seeing people try and ramrod it into a non-IoC mode of operation just because that's what they're used to or because it's a "JSF app". Or bypassing the UI models and their ability to simplify the app just because making the domain model be the UI model saves them a few lines of coding - and no performance benefits at all, since the same structures get built either way.

JSF is very polite, and if the data formats aren't appropriate, you need web services or other non-MVC interactions, or performance/resource usage isn't up to par for a given operation, you can use something more suitable without forfeiting JSF's benefits on the parts of the app that are suitable. So I'm going to continue to prefer it until something better comes along.

And I'm going to continue to try and help people learn to build simple JSF apps instead of baroque hack jobs just because they think it's too simple to be true.

[Junilu Lacar]

Joe Harry wrote:I've never seen a RESTful API implemented using Javascript. Did you mean that the API is served by some Java EE stack exposed via HTTP?

Then take a look at some Node.js projects when you get a chance. In all likelihood it will have some sort of RESTful API implemented. Whether or not it's truly RESTful is another story.

[Joe San]

Junilu Lacar wrote:

Joe Harry wrote:I've never seen a RESTful API implemented using Javascript. Did you mean that the API is served by some Java EE stack exposed via HTTP?

Then take a look at some Node.js projects when you get a chance. In all likelihood it will have some sort of RESTful API implemented. Whether or not it's truly RESTful is another story.

An API in my sense is something that I can code against and use it as though it is a library. I've heard about node.js, but I have never seen any production grade server side code written as node.js script. I would be glad to see one!

[Tim Holloway]

If you'll check the Wikipedia entry on node.js, you'll see some big names who've bought into it, although specific apps/functions they're using it for aren't given. I know how that works. Some hole-in-the-wall department in a Fortune 500 company buys a product to piddle around with and the whole company is listed in the product's ads as a client, so caveat emptor.

On the other hand, I've been toying around with a "to-do" list publisher that posts out checklists on a periodic basis (for example, monthly house maintenance tasks). Node.js looked like a good quick-and-dirty basis for that, although I only have some really raw code so far. I'll publish it if/when I get something fit for the general public.

[Junilu Lacar]

Joe Harry wrote:I've heard about node.js, but I have never seen any production grade server side code written as node.js script. I would be glad to see one!

If you've used ebay, PayPal, LinkedIn, Yahoo! maybe you already unknowingly have. See http://nodejs.org/industry/

[Junilu Lacar]

Tim Holloway wrote:Node.js looked like a good quick-and-dirty basis for that, although I only have some really raw code so far.

Node.js has very active user and developer communities. If you survey the kind of modules being made available through NPM, you'll get a sense that it's not just some hole-in-wall department piddling around thing. We have some internal projects going into production that use Node as an important component in a distributed system. That said, as with every other technology out there, it's very easy to write a big mess with Node.js. In fact, the next couple years of my life will probably be devoted to cleaning up the Node.js code that we're going to inherit from other teams.

[Joe San]

I see the point. If the whole point of going for node.js is performance which is achieved by being async, I see a reason why there should be a lot of traction. If this is the only prime reason, I feel that I'm better off using Scala and Play. But anyways, I do not want to divert the topic.

[Junilu Lacar]

I think the biggest change in the Java landscape is the advent of JVM-based tech like Groovy, Clojure, and Scala. Soon after he left Oracle, James Gosling said that he could hardly care less about the Java language; he cared about the JVM. These newer technologies have opened up a world of possibilities to Java programmers. At this point, I think only senility or my wife are going to be compelling reasons for me to retire. Well, maybe if I win the lottery... nah, I'll probably be puttering around the Ranch until the day I hang up my boots

[Bear Bibeault]

Junilu Lacar wrote:In fact, the next couple years of my life will probably be devoted to cleaning up the Node.js code that we're going to inherit from other teams.

Doncha just hate when you see the big boulder rolling towards you?

[Junilu Lacar]

Bear Bibeault wrote:Doncha just hate when you see the big boulder rolling towards you?

It's more like a big old garbage truck, Bear. I can smell it coming from a mile away, I can see the pile steaming from 10 miles away.
Yeah, I often say FML but then again, it's why they keep me around - because I can and will do the dirty work of cleaning things up