# Convince me that JavaBeans are worth anything

**URL:** <https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718>\
**Category:** In My Humble Opinion\
**Created:** [May 20, 2005, 7:21am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718 "2005-05-20T07:21:00Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![HMS\_Irruncible](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/hms_irruncible/32/7394_2.png) [@HMS\_Irruncible](https://boards.straightdope.com/u/HMS_Irruncible)\
**Post date:** [May 20, 2005, 7:21am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/1 "2005-05-20T07:21:00Z")

</div>

I’m looking to port an application to a JSP/Java-enabled platform… I have some domain logic classes that are completely decoupled from the GUI, and I’d like to reuse these.

In JSP you can embed Java code directly into the page. If I can do that, I can instantiate and use any of my classes right in the JSP. So why on earth would I want to use JavaBeans? It just seems like a needless introduction of another abstraction language.

I’ve searched for answers, but everything I’ve read presupposes that you just use JavaBeans because duh, they’re so great, and don’t ask why.

---

<div class="post-metadata">

**Author:** ![Athena](https://avatars.discourse-cdn.com/v4/letter/a/35a633/32.png) [@Athena](https://boards.straightdope.com/u/Athena)\
**Post date:** [May 20, 2005, 2:26pm UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/2 "2005-05-20T14:26:51Z")

</div>

I’m hardly a Java expert, having only seriously worked with it for a month now, but here’s my take:

I don’t know if this is true of all Java platforms, but on the one I’m working on at the moment, you can’t attach a debugger to code in a .JSP page. This is a serious flaw for any sort of complex code, IMO. Last week it took me a day to track down a bug that would have taken me an hour to find if I could step through the code.

Also, for code maintenance, HTML all mixed in with Java script is damn ugly. I’d much prefer to have the two files separate, for ease of reading.

---

<div class="post-metadata">

**Author:** ![ratatoskK](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/ratatoskk/32/2987_2.png) [@ratatoskK](https://boards.straightdope.com/u/ratatoskK)\
**Post date:** [May 20, 2005, 2:51pm UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/3 "2005-05-20T14:51:11Z")

</div>

Basically I agree with **Athena** for the reasons she gave. Like you, I also get sick of all the hype about whatever they’re calling the latest thing, but in this case the code is a lot easier to maintain and debug if not in the jsp.

---

<div class="post-metadata">

**Author:** ![HMS\_Irruncible](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/hms_irruncible/32/7394_2.png) [@HMS\_Irruncible](https://boards.straightdope.com/u/HMS_Irruncible)\
**Post date:** [May 20, 2005, 10:57pm UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/4 "2005-05-20T22:57:38Z")

</div>

I don’t have any prejudice for or against the JavaBeans or “custom tags” in and of themselves. But introducing Yet Another Macro Language on top of a perfectly adequate language (Java) seems superfluous to me. That’s why I asked.

So what I’m hearing you say is that the main benefit of JavaBeans is that it enables you to move the Java code out of the JSP. Is that about it?

---

<div class="post-metadata">

**Author:** ![rjung](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@rjung](https://boards.straightdope.com/u/rjung)\
**Post date:** [May 20, 2005, 11:42pm UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/5 "2005-05-20T23:42:20Z")

</div>

It’s been ages since I did any Javabeans work, but my vague recollection was that they made it easier to interface between front-end (UI) code and back-end logic.

And JSPs are fun. 🙂

---

<div class="post-metadata">

**Author:** ![minor7flat5](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/minor7flat5/32/258_2.png) [@minor7flat5](https://boards.straightdope.com/u/minor7flat5)\
**Post date:** [May 21, 2005, 12:26am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/6 "2005-05-21T00:26:01Z")

</div>

Making sure we’re on the same page: JavaBeans are simply Java classes that follow a standard: Basically, they implement Serializable and their properties are exposed as getXXX, setXXX pairs. Nothing more.

They were initially conceived of to support GUI objects, like ActiveX controls, that could be plopped on a canvas and have its properties tweaked, and they fill this role quite well when using a GUI designer like JBuilder.  
The more common use of JavaBeans these days is as Value Objects, carriers of data. They are particularly useful for passing business data between the various layers of an application.

Now to your question: Whether or not you are using the convoluted “use bean” syntax of the JSP, you are still working with JavaBeans in most cases.

The “use bean” tag is intended to simplify mapping HTTP POST or GET form parameters to bean properties. I don’t really like using this; in fact, I prefer using a framework such as Struts to handle getting my form properties into Java data objects and back out again.

One of the goals when working with JSPs (and hopefully ASPs) is to minimize the amount of scripting in the page. The original designers of the JSP standard were perhaps a little optimistic when they envisioned HTML developers writing the JSP while Java developers wrote tag libraries, never exposing a line of code in a JSP. Nevertheless, lots of scripting in a JSP is messy and difficult to maintain.

FYI, a JSP is nothing more than a handy way to create a servlet. All JSPs are converted into servlets in your application server, and you can even look at the servlet source code if you know where to find it.  
If all JSPs become servlets, then why not cut out the middleman and write the servlet directly? Because it’s a pain in the butt. DreamWeaver can work with JSPs, but it doesn’t do servlets. Consider why we write JSPs instead of Servlets and this will give a good idea of why we want to minimize the amount of scripting buried in the JSP.

If you find yourself needing to do lots of Java in your JSP, please consider something like Struts. All form submissions go to a special servlet which calls your business interfaces and then forwards the call to a JSP of your choice which can display the result. This “model 2” architecture is much cleaner for larger applications.

---

<div class="post-metadata">

**Author:** ![HMS\_Irruncible](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/hms_irruncible/32/7394_2.png) [@HMS\_Irruncible](https://boards.straightdope.com/u/HMS_Irruncible)\
**Post date:** [May 21, 2005, 11:00am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/7 "2005-05-21T11:00:46Z")

</div>

Thank you for that very detailed response, it really helped to clear up a lot of things for me.

So if I’m understanding correctly, if I “Beanify” my business logic classes, and access them as JavaBeans or custom tags, I can get away without writing a servlet at all? (setting aside the fact that the JSP itself is technically a servlet)

---

<div class="post-metadata">

**Author:** ![minor7flat5](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/minor7flat5/32/258_2.png) [@minor7flat5](https://boards.straightdope.com/u/minor7flat5)\
**Post date:** [May 22, 2005, 3:50am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/8 "2005-05-22T03:50:25Z")

</div>

I think that there still may be a bit of disconnect in what we are discussing.  
At this point, you don’t really have to do anything at all to avoid writing servlets. You always have the option of making liberal use of \<% %\> and \<%= %\> scripting tags to embed scads of Java code in your JSP, avoiding writing a servlet altogether.

Of course, at some point you will find that you have more stuff inside the scripting tags than outside, so your JSP is looking pretty much like your servlet would have.

I tend to steer clear of writing custom tags for business logic and use standard tag libraries for rendering and logic. This is because they are slightly convoluted to write and use, so I would rather just use the ones that have already been written by someone else.

The only “Beanify” part I can see in your business logic classes would be to make them accept and return bean classes in their arguments. For example, you may have a class called “PhoneDirectory” that has a method called “findPeople” which returns a collection of “Person” bean instances, each of which is a simple data carrier with methods like “getFirstName”, “getLastName”, “getPhoneNumber” and the like. This bit would likely be buried in a bit of scripting at the beginning of your JSP.

Now, when you want to actually display the people, you could take advantage of a preexisting custom tag library of things like looping constructs in order to loop through the array of Person bean objects, and use other tags to display individual instances of Person. (though you always have the option of using \<% %\> scripting everywhere, tags for looping and property display are much cleaner.)

See the [Standard Tag Library](http://java.sun.com/products/jsp/jstl/) or [Struts](http://struts.apache.org/) for good tag libraries.

Again, the main point behind the standard JSP bean usage is to provide an easy way to stuff an instance of a bean into one of the four standard JSP scopes (page, request, session, application), as well as an easy means of automatically map the URL parameters to bean properties, as [shown here](http://java.sun.com/products/jsp/tags/11/syntaxref11.fm14.html). I prefer to use Struts instead for this task.

---

<div class="post-metadata">

**Author:** ![HMS\_Irruncible](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/hms_irruncible/32/7394_2.png) [@HMS\_Irruncible](https://boards.straightdope.com/u/HMS_Irruncible)\
**Post date:** [May 22, 2005, 10:02am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/9 "2005-05-22T10:02:05Z")

</div>

> [@minor7flat5](#):
>
> The only “Beanify” part I can see in your business logic classes would be to make them accept and return bean classes in their arguments. For example, you may have a class called “PhoneDirectory” that has a method called “findPeople” which returns a collection of “Person” bean instances, each of which is a simple data carrier with methods like “getFirstName”, “getLastName”, “getPhoneNumber” and the like. This bit would likely be buried in a bit of scripting at the beginning of your JSP.

This is getting at the point of my post, or the “disconnect” as you called it. Like you outlined above, I have business logic classes with behavior that is more sophisticated than “getProperty” or “setProperty”. Thus I was wanting to know if JavaBeans would actually buy me any simplification or reusability. If I’m hearing you correctly, the best practice is to use embedded scripting in the JSP, limited to just what is necessary to instantiate the objects as beans. My reused business logic classes can do the rest of the logical heavy lifting and I don’t have to write a servlet at all.

I guess the following question would be “why would you even use servlets” but I won’t try your generosity if you don’t have any more time for this.

---

<div class="post-metadata">

**Author:** ![minor7flat5](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/minor7flat5/32/258_2.png) [@minor7flat5](https://boards.straightdope.com/u/minor7flat5)\
**Post date:** [May 23, 2005, 2:00pm UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/10 "2005-05-23T14:00:37Z")

</div>

> [@Brain Wreck](#):
>
> I guess the following question would be “why would you even use servlets” but I won’t try your generosity if you don’t have any more time for this.

The answer is the [Model 2](http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html) architecture, preferred by most folks who do good-sized JSP projects.

From [this page](http://java.sun.com/developer/onlineTraining/JSPIntro/contents.html#JSPIntro4):

> [@](#):
>
> The Model 2 architecture, shown above, is a server-side implementation of the popular Model/View/Controller design pattern. Here, the processing is divided between presentation and front components. Presentation components are JSP pages that generate the HTML/XML response that determines the user interface when rendered by the browser. Front components (also known as controllers) do not handle any presentation issues, but rather, process all the HTTP requests. Here, they are responsible for creating any beans or objects used by the presentation components, as well as deciding, depending on the user’s actions, which presentation component to forward the request to. Front components can be implemented as either a servlet or JSP page.
> 
> The advantage of this architecture is that there is no processing logic within the presentation component itself; it is simply responsible for retrieving any objects or beans that may have been previously created by the controller, and extracting the dynamic content within for insertion within its static templates. Consequently, this clean separation of presentation from content leads to a clear delineation of the roles and responsibilities of the developers and page designers on the programming team. Another benefit of this approach is that the front components present a single point of entry into the application, thus making the management of application state, security, and presentation uniform and easier to maintain.

In short, servlets receive input from the users, make business calls, do all of the work; JSPs simply show stuff that was placed there by a business servlet.

Besides serving as controllers, servlets can be particularly handy for handling content that is not exactly standard HTML web page material. For example, we have a servlet that provides an interface to a report generation engine. The servlet delegates the report generation to an SQR server on a remote machine, retrieves the output via FTP, sets the returned MIME type appropriately (PDF, PostScript, Text, SQR are our options), and then returns the report output. This would not be very clean if done in a JSP.

---

<div class="post-metadata">

**Author:** ![HMS\_Irruncible](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/hms_irruncible/32/7394_2.png) [@HMS\_Irruncible](https://boards.straightdope.com/u/HMS_Irruncible)\
**Post date:** [May 24, 2005, 8:26am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/11 "2005-05-24T08:26:07Z")

</div>

I think I’ve got it now, thank you very much for the explanation. The last piece of the puzzle was understanding how much JSP’s are decoupled from the state of session objects and I think I’ve got that now.

---

<div class="post-metadata">

**Author:** ![Greg\_Charles](https://avatars.discourse-cdn.com/v4/letter/g/839c29/32.png) [@Greg\_Charles](https://boards.straightdope.com/u/Greg_Charles)\
**Post date:** [May 25, 2005, 3:13am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/12 "2005-05-25T03:13:57Z")

</div>

Well, separation of presentation and business logic has already been covered thouroughly. Aside from making code more modular, it also gives your web developers a fighting chance of being able to redesign a page without breaking the logic. I remember having to waste my time recoding servlets because the web team decided fields in a form should be presented in a different order, and they had no idea how to make the changes themselves.

**Athena** : the debugger I work with can attach to a JSP. You can even put breakpoints on puely HTML statements. It’s part of the Rational Application Developer, but I think the same debugger is included in Eclipse, which is free.

---

<div class="post-metadata">

**Author:** ![Greg\_Charles](https://avatars.discourse-cdn.com/v4/letter/g/839c29/32.png) [@Greg\_Charles](https://boards.straightdope.com/u/Greg_Charles)\
**Post date:** [May 25, 2005, 3:16am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/13 "2005-05-25T03:16:51Z")

</div>

BTW, “puely” is, in fact, an archaic form of purely. When will JelSoft implement “Quick Fixes”? :smack:

---

<div class="post-metadata">

**Author:** ![Athena](https://avatars.discourse-cdn.com/v4/letter/a/35a633/32.png) [@Athena](https://boards.straightdope.com/u/Athena)\
**Post date:** [May 25, 2005, 1:16pm UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/14 "2005-05-25T13:16:54Z")

</div>

> [@Greg Charles](#):
>
> **Athena** : the debugger I work with can attach to a JSP. You can even put breakpoints on puely HTML statements. It’s part of the Rational Application Developer, but I think the same debugger is included in Eclipse, which is free.

Eclipse is what we use, and we can’t debug .jsp pages. It really sucks.

---

<div class="post-metadata">

**Author:** ![Greg\_Charles](https://avatars.discourse-cdn.com/v4/letter/g/839c29/32.png) [@Greg\_Charles](https://boards.straightdope.com/u/Greg_Charles)\
**Post date:** [May 26, 2005, 6:31am UTC](https://boards.straightdope.com/t/convince-me-that-javabeans-are-worth-anything/304718/15 "2005-05-26T06:31:06Z")

</div>

> [@Athena](#):
>
> Eclipse is what we use, and we can’t debug .jsp pages. It really sucks.

Drag. I’m never sure what’s an added feature of RAD, and what comes standard with Eclipse. I guess “Debug on Server” is an addition. Well, assuming your company won’t buy you RAD, maybe you could still get them to spring for one of the Eclipse plugins that supports JSP debugging. Or, you could “keep source” and debug the generated servlet.
