Angus Ferguson wrote:I did the code using stringbuilders which are not as efficient as using some Java objects
What makes you think that ? Did you profile your application or did you read it somewhere ? If the latter, did they suggest alternatives ?
It all depends on what you are doing with the StringBuilders.
At the moment your question is like asking - "At the moment I'm walking. What can I do that is more efficient ?"
If you're visiting a neighbour, then walking is probably the most efficient. If you want to get to the other side of the world, then taking a plane might be a good idea.
Angus Ferguson wrote:but I want use some Java objects on the session and a JSP include to generate the html in order to improve performance...
Joanne's absolutely right: you've got this bass-ackwards.
1. Does your program work? Don't even think about efficiency until you can say 'yes'.
2. Is your program running too slowly? If not: see 1 (and you'd better have some good metrics to back it up).
3. Do you KNOW that the reason it's running slowly is because of your StringBuilder? If not: again, see 1.
Basic lesson: Don't worry about efficiency until you have a well-designed, and well-written, working solution.
W.A. Wulf wrote:More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity.
I mean don't generate the HTML in the Java, use a JSP to do that based on an object.
What I meant is create an object based on the back end and stick it in the session after that retrieve the object in the session from the .JSP. Is that correct for you?
Use the object from the session and a JSP to generate the html. Then you only create the object once per session and the slow string manipulation is done by tomcat which is optimised for that kind of work
What way you would do that?
Angus Ferguson wrote:and the slow string manipulation is done by tomcat which is optimised for that kind of work
Again, you still seem to be assuming that it's the string manipulation that's slow. Do you have any proof?
That said, it's certainly better to only have something done once if you can; and in a client/server environment, that generally means doing it at the server end.
However, we (or at least I) still have no idea what your actual problem is; and in the absence of other information, my first port-of-call would be your network pipeline. You can make all sorts of things server-centric, but if you don't have the network to support it, no amount of Java-based efficient code is going to change things.
But you do this because it's the right way to do it; not because it may (or even may not) have some infinitesimal performance gain.
As said before, worry about performance when and if a performance problem raises its head. Always code for clarity; not supposed performance.