jsf vs (jsp+jquery) developement

[abdelouahab khan]

Hi everybody,

firstly ,this is my first topic in this helpfull forum where i have looked for resolutions of all my problems for years and i decided to write something about my small experience in web developement.

i work in company and we are many developpers but i am the only one who developpe in jsf ,the others developpe with jsp/jquery .
and they developpe very fast with nice design the only thing to do is to look for a template and some jquery plugins using only dreamweaver and the work is done.
but in my case i must have netbeans or eclipse to copile and build the project and when i make some changes in beans i must compile them .
the other probleme is that when i make changes to classes or jars in tomcat that make memoryleak ,unlike jsp pages its simple with them with no memoryleak.

my question is why tomcat make memoryleak when a class or jar file is changed or reloaded and how to prevent that ?
the seconde question is how to deploy fastly beans and servelts like jsp files

finaly , i am so glade to meat you in this area of java developpers
thanks

[Ulf Dittmer]

and they developpe very fast with nice design the only thing to do is to look for a template and some jquery plugins using only dreamweaver and the work is done.

This suggests that they are putting Java code into JSP pages, which is really bad design that the industry moved away from 10 years ago. They should separate out Java code into proper classes, at which point their development cycle becomes very much like yours.

my question is why tomcat make memoryleak when a class or jar file is changed or reloaded and how to prevent that ?

Tomcat has gotten better at that with recent releases, but the issue is likely not going away any time soon. But reloading a web app should not take more than a few seconds, restarting Tomcat running that web app maybe 30 seconds once you run into the PermGen issue. How often does that actually happen?

[Dieter Quickfend]

Hi,

The main difference in choosing between JSF and JSP/JQuery is which project you're working on. If it's something simple and you don't need a component based, stateful application, JSF will be overkill. If you're using mostly Javascript to create a rich ui with stateless integration, even JSP is not really necessary. A stateful project with a lot of business functionality and lower requirements for scalability (the application will never need to serve millions, for example an internal application), JSF is a very good choice and will simplify development (especially since 2.0). So will an application where you need to reuse many components, and/or a lot of conversation with the server is necessary. But in a company with loads of JQuery specialists with a focus on rich UI development making mostly web applications with high performance / scalability needs, I doubt JSF is the way to go.

I'm a big supporter of using JSF in java EE applications, but even I will tell you that using JSF 1.x is suboptimal and there are few reasons left to choose it for your project. For me, it is generally my first choice, as I'm good at it and I can develop an application very fast using JSF, but I have to tell you I generally make internal applications with high security, availability and extensibility requirements, and low performance/scalability requirements.

I'm trying to make some inroads in some more lightweight front-ends for a Java EE application, but I don't believe in client-side non-UI state management and the options (JAX-WS, JAX-RS, Websockets) are not very good at stateful stuff or still too new and low-level. If you've got big applications with a lot of business functionality using long-running conversations that need to be transactional and secure, that is the perfect reason to use JSF. The fact that it integrates so nicely with EJB's these days is just fantastic.

But is it the future? I don't think so. I would definitely learn some new stuff so you can't get pegged in the JSF hole.


As for your problems:

JSP files you can just copy manually onto the server, they will be translated and compiled at page load time.
As for code, hot swapping generally does have some issues. I can recommend you to ask your company for a JRebel license, but even that won't solve everything. for instance, creating a new interface for an ejb will require a server restart. It all depends on what you're doing.

A good idea is defining your business process before you start development, including all your classes and methods, and defining them all. Then you can change your implementation and you won't have to restart.

Oh, and don't worry, you're seeing all the glitter and glamour of JQuery and client-side development, but there's a lot of issues that go with it. It's not easy or simple by any means. Using only JQuery and REST on the wrong project may well mean bad scalability/performance, even when that's the selling point of the combination.

[abdelouahab khan]

hi, Dieter and thanks for reply it was very beneficial to me.

but the question is can jsf with primefaces be more productive than jsp/jquery?
i work now with primefaces it is better than the old webuijsf .

Good day

[abdelouahab khan]

Ulf Dittmer wrote:

and they developpe very fast with nice design the only thing to do is to look for a template and some jquery plugins using only dreamweaver and the work is done.

This suggests that they are putting Java code into JSP pages, which is really bad design that the industry moved away from 10 years ago. They should separate out Java code into proper classes, at which point their development cycle becomes very much like yours.

my question is why tomcat make memoryleak when a class or jar file is changed or reloaded and how to prevent that ?

Tomcat has gotten better at that with recent releases, but the issue is likely not going away any time soon. But reloading a web app should not take more than a few seconds, restarting Tomcat running that web app maybe 30 seconds once you run into the PermGen issue. How often does that actually happen?

hi, Ulf and thanks for reply

i agree with you for separating the java code with the design its for that thing i am using jsf and i dont accept and admite that jsp/jquery are better and productive than an MVC developement ,
i must make arguments to my boss that still using jsp is not appropriate and the good way is to look to the future .but jquery broke all my arguments .

for the memory leak i can escape it with adding some jvm arguments .but i couldnt liberate the old class still loaded in memory .
Good day

[Ulf Dittmer]

abdelouahab khan wrote:i must make arguments to my boss that still using jsp is not appropriate

There's nothing wrong with JSP. What would be wrong is to put code into JSPs (if that's what your colleagues are doing). JSF has not replaced JSP, despite all efforts by Sun/Oracle, in fact I would say it's significantly less used. It's a viable approach as of JSF 2, though.

and the good way is to look to the future .but jquery broke all my arguments .

I don't see how. jQuery can be used with JSP just as well as with JSF.

[Tim Holloway]

Too often, "productive" means "Git 'r Dun!", which means hacking in the old-fashioned sense of taking an axe to a tree and expecting to produce delicate art with it.

JavaScript (as in jQuery) has its uses, but it also has its downsides, which is one reason why so many attempts have been made to make javascript frameworks (including jQuery) to try and address those downsides. Of course, the same can be said of Java!

The major downside of the JSP approach is that it makes it too easy to make a page that looks right long before the page works right. As I've said before, the difference between traditional architecture and software architecture is that when a traditional architect builds a model, it's obviously not the real thing. It's small, made of bits of cardboard and sponge and obviously not functional. In a GUI model, the façade looks just like the presumed final product and the fact that inside it's a hollow shell is not apparent to external observers. Who then expect the entire app to be in production by Thursday. Because "All You Have To Do Is..."

JSF provides a complete framework for MVC-driven forms. In fact, it's about the purest implementation of the MVC paradigm that the web can offer. However, not every webapp is primarily about forms, and even the ones that are may not scale. So it's a solution, not the magic "Silver Bullet" that Solves All Problems (there isn't any such thing, anyway).

JSF and jQuery get along quite well, especially since a lot of the JSF extension taglibaries such as RichFaces and PrimeFaces use jQuery internally to manage their AJAX functions. The only catch is that in some cases the actual versions of jQuery that they incorporate can be pretty old. But that's something that can be managed.