Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Threading Essentials course 

Newsletter no. 24, November 26th, 2002

Get rid of your performance problems and memory leaks!

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

The PetStore debacle runs and runs. If I was the The Middleware Company, I'd be saying "Ouch". Whatever you may think about Microsoft, love them or hate them, you have to have respect their marketing department. If you don't, you're letting yourself in for a big fall. The Java world as whole certainly does, and spends significant amounts of time and money battling them. Unfortunately The Middleware Company didn't quite realize that they were being maneuvered by Microsoft. They aren't the first company nor will they be the last to find that a clever idea to use Microsoft to gain publicity is taken over and used against them.

My own analysis of the Pet Store wars showed that Oracle applied valid performance tuning adjustments to increase the performance of the Pet Store by 400 times, and the scalability was improved to many thousands of users. (The analysis is in Chapter 18 of the 2nd edition of my book Java Performance Tuning). Microsoft's competing figures never came near this, instead they simply argued that Oracle's tests were invalid.

In order to level the playing field a bit, here is "The Cheats Guide To Benchmarking", so that you can identify when you are about to get screwed:

  1. Specify the benchmarks that will make your job the easiest. Avoid real-world tests like the plague, they are much harder to fiddle.
  2. Choose the tests and environments that will show your improvements in the best light. This can take a little work, so give yourself more time and resources than any opposition or examining bodies.
  3. Always keep in mind the cheats ideal proverb: "Shoot first, and whatever you hit call the target". An excellent way to do this is to privately try multiple tests until you find the combination that wins for you. Then make only that one public.
  4. The last resort: If you can't achieve the targets (such as beating the opposition), analyze until you can invalidate them in some way. All targets are invalid with respect to some set of criteria, so the trick here is actually to determine a set of criteria which invalidate the targets.

A note from this newsletter's sponsor

Java Performance Tuning, 2nd ed. covers Java SDK 1.4 and
includes four new J2EE tuning chapters. The best value Java
performance book just got even better! Order now from Amazon

This month, we've added yet another section to our newsletter. We have started an interview section, and our initial interview is with Dr. Heinz M. Kabutz, the author of the popular "Java Specialists Newsletter". Heinz has some very interesting things to say about Java performance, so don't miss the interview.

In addition, this month we have all our other usual sections. I list a host of quality in articles. Normally, I just list the article categories. Occasionally, I single out articles which really caught my attention as especially worth viewing. This month, I hardly know where to start. Alexandre Polozoff's article, ostensibly about WebSphere performance testing, provides a detailed thorough outline of how to build any performance plan to maximize your chances of attaining your performance targets; Nokia gives an excellent summary of all the techniques needed to get your MIDP application fully efficient; Mauro Marinilli provides a nice clean introduction to issues encouraging an efficient UI design; Gupta and Doyle cover HotSpot GC parameters with admirable detail. This last article shows that while Java GC technology is improving all the time, it's still at least a few years away from maturity. Which is good in one way, because that means there are more efficiencies still to come.

Plus we list many more interesting articles, including all the recent articles with Java performance interest; we extract all the tips from those articles; we have tool reports, new tools, new tips categories, the latest news, ... The roundup is back. Yes really, honestly, its actually there, I promise. Sorry about last month, I really cocked up. And Javva is also here as usual.

A note from this newsletter's sponsor

JProbe helps developers understand precisely what is causing
problems in Java applications - right down to the offending
line of source code. Download a free evaluation of JProbe today.

New Tips Categories

Tool Reports


Java performance tuning related news.

A note from this newsletter's sponsor

Get a free download of GemStone Facets 2.0 and see how this
patented technology supports JCA 1.0 to seamlessly integrate
with J2EE application servers to enhance performance.


Recent Articles

Jack Shirazi

The Roundup

First off, I thought I'd check out the other general performance discussion groups listed at There are a couple more beyond JavaRanch/TheServerSide/JavaGaming. Well, those others are all dead, so that was quick. Now on with the active three.

The JavaRanch

The question of what resources are available for performance tuning Java apps comes up periodically in the various discussion groups. This time it was the JavaRanch's turn, but the discussion groups seem to take turns in having some new denizen pop up and ask this question. Of course the answer is to look on the resource page. The only real question for me is how many posters reply to the original question before this definitive answer ends the discussion. Increasingly that number is one.

A question on encryption performance came up. This is pretty rare, I can barely remember any questions on encryption performance previously appearing. I can remember those few times that the question has been raised, the answer was "encryption is slow". This time, Mark Herschberg gave a more useful answer that "public key encryption is far more expensive then symmetric key encryption". He went on to recommend hybrid SSL solutions: "create a symmetric key for each session and first send it using a public key encryption scheme. This means you only need public key encryption in the beginning of the protocol, and the rest of the time you use the faster symmetric encryption". Sounds like a pretty good compromise.

Would making everything possible final improve performance? Responses to this question suggested that possibly it would have in earlier Java implementations, but in more recent implementations HotSpot does the kinds of runtime code analysis that means using final does not give any significant performance boost. Some interesting analysis of what HotSpot does in different situations followed, producing the interesting result that HotSpot keeps track of when a method must remain polymorphically called, and hence has a high runtime call overhead; and when a method can be statically called (which is the supposed performance benefit of using final), so can be called much more quickly.

Finally, a developer looking for help with garbage collection of windows was given the useful advice that he should be calling frame.dispose() on his windows to release the resources. Two hours was all that was needed between the original question being posted, the resulting comments and the original poster psting back that it had worked. Now that's efficiency for you!

As an aside, the same thread generated further discussions on how implementing finalizers are bad for performance because the object hangs around for longer and puts more work into the GC thread; and also about how explicit gc() calls should be used very carefully (i.e. not at all) so as to avoid adding further overhead to the system.

JavaGaming is going through a reorganization at the moment, but the old discussion forums are available as archived discussions, and new discussions can be started in the new section of the site. For the moment I'm still running through the old discussions.

Over in the gaming performance forum one poster was asking how to speed up his 2-D interpolation algorithm. It turned out that he was painting each pixel individually when he should have been painting them in a block. A code fragment showing how to manipulate the pixels and get the resulting image was given:

ColorModel cm=new DirectColorModel(24,0xFF0000,0xFF00,0xFF); 
int[] pixels = new int[x*y]; 
source = new MemoryImageSource(x,y,cm,pixels,0,x); 
Image output=Toolkit.getDefaultToolkit().createImage(source); 

The poster who gave the answer also pointed out that BufferedImage was what should be used in Java 2, but was not available for 1.1 (which the original poster specified). This resulted in further discussion as to whether gamers should carry on supporting 1.1, because of MSIE, or whether 1.1 support should be dropped in order to encourage upgrades to be made. The resulting posters seemed to be split fairly evenly as to their preference.

A huge thread was started by one developer of a Z80 emulator finding that the old (1.1) MS JVM ran his emulator significantly faster than the latest Sun JVM. He tried to show that local variable access was the problem, using a microbenchmark. However, it turned out that most of the difference in performance was due to the coding style. The results of the thread:

Finally, an old discussion on GC was given new life by a poster asking about his code. The older discussion produced an interesting idea: to minimize GC pauses, you can deliberately retain references to objects so that the GC cannot reclaim those objects, hence causing fewer shorter pauses for the program. The thread also requested Sun to introduce a GC algorithm with explicitly settable limits on pauses. The newer thread threw up the interesting logging parameter for tracing core 2-D graphics, -Dsun.java2d.trace=log.

The Server Side

The Server Side produced its usual crop of challenging enterprise performance questions. First up was an interesting question on Weblogic pooling, coupled with queries possibly producing 50,000 records from the database. One poster wrote "If you have employees who can read and do anything useful with 50,000 rows of data I would love to hire them". Basically, the advice was to use stateless session beans, with a separate data access layer to obtain the database rows. Further suggestions inlcuded lazy initialization, data on demand and fetching only a few rows at a time, holding a marker of which rows have been accessed so that future continuation accesses from the same client could start from that marked row, using a query like


Another question on how to improve JBoss performance produced a list of generic tuning tips:

Another thread asked which resources to monitor for improving performance. This gave another useful list: Garbage Collection, HTTP sessions, ORB threads, JDBC Connections, CPU utilization and hardware memory, all pooled resources (make sure you are not exhausting your free elements in the pool). Further useful advice included suggesting running the system over a long period of time with varying load, and adjusting pool sizes to accomodate the expected load.

Finally, a very brief discussion on commit options: commit option A reduces I/O overheads but limits concurrency; commit option C supports a higher level of concurrency but has higher I/O overheads.

Javva The Hutt

Have you ever been through a "choose our programming language" (or "choose the really expensive product") exercise? Let me describe how it works in an enterprise site from my experience (having been through a couple of language choices and a couple of expensive product choices). First, someone is mostly in charge of the process, usually partially overlooked by someone else with equal or greater authority. The person in charge (PIC) sets up a small committee which has the job of setting up a decision matrix which is used to objectively choose the language/product amongst the competing alternatives. The decision matrix criteria are chosen according to the needs of the project. The languages/products are evaluated according to the matrix criteria, assigned scores for each criterion, scores are added and the winning language/product chosen based on the best score. This should result in the language/product most appropriate for the project.

Does this look nice and objective? If it does, you need more experience of enterprise sites. The whole process is usually completely rigged in a way that cannot really be criticized. What actually happens is that the PIC and his close advisors first decide on the language/product they want, in private, using completely irrational criteria. Then committee members are chosen who will be mostly sympathetic to this choice. The decision matrix criteria are then chosen to emphasize the advantages of the chosen language/product, and identify problems with the alternatives. As a final fail-safe, if despite all of this the chosen language doesn't win, the decision matrix criteria are weighted so that the chosen language/product can't lose. The result is a language (or product) which appears to have been chosen objectively by the committee. But believe that and you're one of Barnum's customers [the famous phrase "there's a sucker born every minute" is generally, though erroneously, attributed to P.T. Barnum].

When I saw the process by which Yahoo seems to have chosen php as its site language, all of my previous experiences came flooding back. Of course, I'm not for a moment suggesting that the choice for Yahoo was made in the prejudiced fashion I described previously. I'm sure that the Yahoo committee members would have been at least as open to alternatives as you or I would be, and made their choice thoroughly and objectively.

What I found most interesting from that talk was how haphazard the evolution of the Yahoo site seems to have been. This is one of the world's major internet sites any way you look at it. And yet the talk gives me the impression that the site was bolted together bit by bit, held together by spit and glue. Yahoo isn't the fastest of sites, but it certainly has adequate performance, which is pretty impressive considering the number of hits it gets and the amount of work it is doing 24/7. Which makes me think that perhaps they actually got the development model right. Evolve the site, add in the functionalities you need as you need them, rather than plan the whole thing up front. Isn't that part of the extreme programming model?

Diary of a Hutt

October 9. Ah, time. It's nice to have so little pressure. I've decided it's a good time to update my skills. I've started looking through the tools listed at My God, so many that I've never heard of! And I'm supposed to be the company expert on these things. Excellent. I can justify multiple training requests and, by the look of these J2EE monitor thingies, it looks like I'll be able to up my tool budget too. Of course I need to make a compelling case for needing one of these, but that is what salesmen are for. I'll arrange for a demo to be run at the company.

October 10. I could almost hear the ker-ching sound of a cash register as I was telling the vendor about the systems we have running and under development. He was so eager to come and demo their system that he wanted to come today. But of course, I need to set this up. First I need to do some research so that I know how to sell the requirements too. After all, this is my budget we're talking about, I don't want to go into this half cocked. I've set up a demo for next week at a time when HasntGotAClue can attend. But I want to go even further up. If you want your boss to be enthusiastic, get his boss to be enthusiastic. Luckily for me Parsons likes to think he's always up-to-date. So it should only be a matter of sitting next to him at lunch to get him to come along to the demo out of interest. By the way, here's a clue for you if you are ever planning this sort of thing. Demos take time to set up. And there are things that always go wrong. So the meaty part of any demo is much nearer the end of the demo. Don't invite people to the demo until then, otherwise they just bend the salesman's ear, ask some stupid questions, get bored and go before they see anything good.

October 17. Am I good? The whole thing went flawlessly. Actually, I feel sorry for the sales guy. He's probably gone home salivating at his bonus, maybe even already started spending it. Of course he might well get the sale, but it's not as done a deal as he thinks. Of course, he thought he was selling to me, and when I started talking the same talk to my boss, and then the boss's boss came along and loved what he saw, well, it must have been a salesman wet dream. I even chose a test environment with a straightforward bottleneck that would be easy to find, and did the "wow, that would have taken me a week to find with my usual tools" speech. Now I've done the initial groundwork, I need to check out the competition. But at least I'm pretty sure that I have the budget to buy something. J2EE performance monitors, here I come!

October 23. Well there was a whole bunch of these things labelled "J2EE profilers". Nine is too many to evaluate. So I went through the standard elimination process. One was just a development environment tool, another couple were new companies (sorry guys, but new equals risk for enterprise environments), I didn't like the look of a couple of the other's websites. That's better, four left. Easy to do a paper evaluation for four products. Get the bumpf, find the features they all have, eliminate all the common features and see what's left. A couple of them always look much better on paper (they did). So now I have two left, one of which we've already seen demo'ed. So time to get the other demo, then start the auction (never go for the quoted price, there's always a lower price and extra stuff they'll throw in for free).

October 30. It's been a pretty productive month. Adding another skill to your CV is always good. And these things actually look like they'll be helpful. I've yet to sweat the sale though. Let's see, it's the end of October, so I need to get a month's evaluation to kill November, then wait a couple of weeks in December to sweat the sales guys. Hmm, closing around Christmas week will be a pain, but with the I.T. world in it's current doldrums, it's a buyer's market, so I'll leave it until right at the end of the quarter to close. That gives them plenty of time to try to butter me up. I need a new mug, and it's always nice to get a new t-shirt.


Javva The Hutt.

The Interview: Dr. Heinz M. Kabutz

For years, Heinz has entertained us, made us think hard, and often surprised us in his popular newsletter "The Java Specialists Newsletter". This month, asked Heinz a few questions:

Q. Can you tell us a bit about yourself and what you do?

Sure. I was born and raised in Cape Town, South Africa. My parents are of German origin, so I grew up speaking mainly German, even though English is common in Cape Town. South Africa has 11 offical languages, but German is not one of them [;-)]

When I was in junior school, I started playing around with the ZX Spectrum, and my love for programming (not computers - I hate computers with a passion) developed back then. At the time when I finished school in 1989, our country was in a lot of turmoil, with compulsory military service for "white" males. You could delay military service by attending university, so I enrolled for a BS in Computer Science at the University of Cape Town. Seven years later, at the tender age of 25, I emerged with a PhD in Computer Science, having skipped the MS. By the time I finished, South Africa was already a real democracy and so I managed to avoid conscription altogether.

My doctorate title was: "Analytical performance evaluation of concurrent communicating systems using SDL and Stochastic Petri Nets". You see, even then I already had a keen interest in how well computer systems perform, although my thesis was of more theoretical nature and not that useful for day-to-day work.

For many years, my wife and I were considering leaving South Africa for greener pastures in Europe. 9/11 and the .com fallout have made it clear that the pastures are greener down here. There is a lot of Java technology being used in Cape Town. Besides all that, Cape Town has been voted as the #5 place to visit for a holiday before you die. A Russian, who settled in South Africa, once said: South Africa is THE BEST place in the world to live, because, if you want to go on holiday, you are already here!

I have my own software development company ( where we write contract software, consult and hold courses on Java and Design Patterns. Due to various recent circumstances, I am also director of a drinking straw factory. Diversify! - they said.

Q. You make it sound like South Africa I.T. hasn't been affected by the current I.T. recession in many other countries. Is that how you see it?

I would rather say that South Africa was not as strongly influenced by the ridiculous .COM boom that hit the world. Salaries were at a reasonable level (for the employers) during the good years in other countries. As a result, a lot of good people left the country to go to England and USA. However, now that the good times are over, quite a few of them are coming back to this beautiful country.

It is difficult for foreigners to come to South Africa and live here due to restrictive labour laws (which might be changing for IT jobs). The locals therefore have very little competition on the job market. I am not saying that there are a lot of golden opportunities, but you have to take salaries in relation to how much things cost here. I bought my first 2 bedroom house about 5 years ago for US$ 15 000. It would be worth more now due to house prices climbing, but for US$ 50 000 you would get a very nice place. Fresh food is also very cheap, as is petrol. All-in-all it is probably the best place on earth to live [:-)]

Q. How did you get started writing the Java Specialists newsletter?

One of the things I love doing is exchanging interesting programming ideas with my friends. Back in 2000, one of my friends kept on bugging me to start writing a book, called "Java Argot, Things your Dad never told you". On one of my many consulting trips to Germany, I started writing down topics for such a book. I started writing with the objective of creating a book, and started to really enjoy just writing newsletters. So much so, that I now have no desire to ever go through the headache of writing a real book. My father's cousin is a famous South African writer, so I suppose it is somewhere in my genes.

Once I started writing, I discovered the amazing marketing potential that is locked up in producing an original piece of writing. Not to mention the fun when I get comments from my readers telling me that they are enjoying what I'm writing, and asking me what food they should eat in order to think like me. BTW, if you know of anyone who would like a course on Design Patterns, here is my brochure: Ok, that was a joke. I'll try not to be too much of a used-course salesman [;-)]

My first "The Java Specialists' Newsletter" was sent on the 30th of November 2000 to 75 friends, colleagues and former students. The newsletter is now read by over 5000 people in 89 countries ( However, what really distinguishes this newsletter is the readership. I have some of the top Java & OO people on my newsletter subscriber list: Bruce Eckel, John Vlissides, Cay Horstmann, Jack Shirazi, Craig Larman, William Grosso, Erik Hatcher. The list just goes on and on.

Q. What do you consider to be the biggest Java performance issue currently?

That is a really difficult question to answer. My focus during the last five years has been J2SE and its supporting role in J2EE. However, Java is so huge, and within every part of it (JSP, Servlets, EJB, J2ME, JMF) you can find serious performance problems if you look for specific situations.

I personally do not think that performance is really a problem in Java. I think the real problem is one of perception. Java has received plenty of bad press from C++ and Delphi programmers about its supposed performance problems. I remember a time not too long ago when "serious" applications were not written in C++, because that was so much slower than C. That is why I think that the performance "problem" is not a real problem, it is an illusion that people have held on to.

If you want to write an application in Java, you could use Swing. Swing is sluggish and slow. It is improving, but it is still not as snappy as native user interfaces. However, if you need a snappy user interface, what is stopping you from using SWT?

Another topic that people like to focus on with Java is that you cannot easily create an executable under Windows. Again, in real projects, I have never found that to be a problem in any way.

So, the biggest issue to me is that people have this IMPRESSION that Java is SLOW.

Q. Do you know of any requirements that potentially affect performance significantly enough that you find yourself altering designs to handle them?

Yes, remote method invocations. Whilst a nice idea, it can bring any application to its knees if overdone. The first thing you would look at is the architecture, and whether it fits the problem. The second thing you do is look at the design of how that architecture was implemented. For J2EE, you would look at using Session Facades, Value Objects, etc. to make J2EE run fast.

Q. What are the most common performance related mistakes that you have seen projects make when developing Java applications?

Wow, another tough question! I think that the reason that Java has received the reputation of being slow is because of mistakes that the dear programmers have made in ignorance.

I think the most common mistake of Java programmers is that we forget to think! We do not bother to look under the hood of how the ArrayList really works. As a result, we start collecting anecdotes from colleagues of little tricks that supposedly improve Java performance. My tip - never believe anybody when it comes to Java. Check for yourself. That's why Sun publish the source code.

Some of the worst problems I've seen:

1. Strings - A simple thing like adding a String to an Integer can cause quite a few objects to be created. Using Strings incorrectly can cause serious degradation of your application. Don't take my word for it. READ java/lang/, then read java/lang/

2. Dates - especially converting them to Strings.

3. JDBC Drivers can really slow you down. You have to evaluate them in your context. I have found that for some queries, the JDBC/ODBC bridge beat ALL other JDBC drivers for MS SQL Server by a large margin.

4. Arrays - creating new arrays is very expensive. I always try to reuse them where possible. Sun's programmers unfortunately do not.

When I tune code, I prefer working with code that is well factored. Lots of classes, lots of small methods. It makes the tuning much easier.

Q. Which change have you seen applied in a project that gained the largest performance improvement?

The best performance improvements were from changing the design and educating the programmers. In one project, we improved the performance incredibly just by counting the bytes that were going over the sockets and working on reducing network calls.

Once we had optimised the "obvious" things, we also went from Serializable objects to Externalizable, which greatly increased the speed of sending and receiving of objects.

Q. Have you found any Java performance benchmarks useful?

I find them quite amusing, especially the latest one by "The Middleware Company", where they compare .NET and J2EE. My focus is Java, not middleware, but if it was, I would also want to get into the .NET market. Just in case. What better way than to be instrumental in developing the .NET blueprint?

Unfortunately, the lack of the very rare commodity of "thinking" will cause J2EE to become less attractive. If you look at the bigger picture, you must ask yourself - do you really want to be locked in with one vendor? Even if they are faster? According to Rickard Oberg, the report was *seriously* flawed. If that is true, then do you want your future to be 100% on such a company?

Q. Do you know of any performance related tools that you would like to share with our readers?


I try to steer away from commercial tools because I find I work better through using the tricks that I talk about in my newsletter. I have used OptimizeIt with some success in the past, but I found some other popular tools to be too resource-hungry, and they also interfered too much with my code.

The best way that I have personally used is to alter some of the core classes of Java, and put my performance measuring directly into the JDK classes. I then load the classes with the bootclasspath and let my application execute "naturally". You cannot ship your product with modified JDK classes due to license restrictions, but you can do your performance tests like that.

I prefer writing performance code directly into my code. That way I measure only what I am currently focusing on.

Another approach that William Grosso (author of Java RMI) uses is to include the performance code with Aspect/J. I have not done that myself, but I have been told that it is very effective.

Q. Do you have any particular performance tips you would like to tell our readers about?

My #1 tip to anyone doing performance evaluation is this: Make 110% sure that you are measuring the right things!

I have wasted weeks of precious time chasing after performance issues that were no issues. They perhaps showed up in some of the commercial tools, but when I eventually got rid of them, did not make any difference in the overall picture.

Of course, Jack and I cannot tell you the secret of how we know what to measure. We want you think that we know by some dark secret which we are not allowed to divulge by the threat of a horrible death. We'd prefer that when you get to wanting to tune your application, that you give us a call and pay us lots of money [;-)]

(End of interview).

WebSphere performance testing (Page last updated November 2002, Added 2002-11-27, Author Alexandre Polozoff, Publisher IBM). Tips:,35452,1_0_10_10,00.html
Efficient MIDP Programming (Page last updated June 2002, Added 2002-11-27, Author Forum Nokia, Publisher Nokia). Tips:
1.4 HotSpot GC (Page last updated November 2002, Added 2002-11-27, Author Alka Gupta and Michael Doyle, Publisher Sun). Tips:
User Interface Design (Page last updated November 2002, Added 2002-11-27, Author Mauro Marinilli, Publisher Tips:
The final keyword (Page last updated October 2002, Added 2002-11-27, Author Brian Goetz, Publisher IBM). Tips:
J2ME benchmarking (Page last updated October 2002, Added 2002-11-27, Author Wang Yi, C.J. Reddy, and Gavin Ang, Publisher JavaWorld). Tips:
Multiple layers of dynamic proxies (Page last updated November 2002, Added 2002-11-27, Author crazybob, Publisher Tips:
Handling unexpected thread death (Page last updated November 2002, Added 2002-11-27, Author Roy M. Pueschel, Publisher JavaWorld). Tips:
Nybbles of Development Wisdom (Page last updated October 2002, Added 2002-11-27, Author Terence Parr, Publisher ?). Tips:
Capacity Planning (Page last updated November 2002, Added 2002-11-27, Author Arunabh Hazarika and Srikant Subramaniam, Publisher BEA). Tips:
Socket connection timeouts (Page last updated November 2002, Added 2002-11-27, Author John Zukowski, Publisher Sun). Tips:
WebLogic Server Performance Tuning (Page last updated October 2002, Added 2002-11-27, Author Arunabh Hazarika & Srikant Subramaniam, Publisher BEA). Tips:
Fast authentication (Page last updated November 2002, Added 2002-11-27, Author Larry Ashworth, Publisher ZeroPoint). Tips:
Speeding JVM startup (Page last updated November 2002, Added 2002-11-27, Author ?, Publisher IBM). Tips:
Thread pooling (Page last updated November 2002, Added 2002-11-27, Author Vishal Goenka, Publisher JDJ). Tips:
HTTP sessions vs. stateful EJB (Page last updated October 2002, Added 2002-11-27, Author Peter Zadrozny, Publisher BEA). Tips:
HashSet, LinkedHashSet, and TreeSet (Page last updated November 2002, Added 2002-11-27, Author Glen McCluskey, Publisher Sun). Tips:
WebSphere performance tips (Page last updated October 2002, Added 2002-11-27, Author Arvind Shukla, Publisher ). Tips:
The effect of Slow download speeds (Page last updated October 2002, Added 2002-11-27, Author Steve Sampsell, Publisher EurekaAlert). Tips:

Last Updated: 2017-12-29
Copyright © 2000-2017 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us