Michael Borgwardt

Originally posted by Maulin Vasavada:
hi all,
because any lanuage has overheads of recursion like stacks and believe me i have experienced it...

The overhead is usually not the problem. The main disadvantage of recursion is that if implemented clumsily, it can easily cause the stack to overflow.

once i had a program to write in ACM comptetion practice i was doing..i forgot what was the problem but i did it using recursion. one of my friend who was good at math applied some math and did the same problem iteratively.
result??
my program seemed never completing and his program came out in < 15 seconds (which was the limit we had to follow as per the program specification)...

I suspect strongly that your recursive implementation was simply too naive, computing the same thing many times, while he reused results. A typical example are Fibonacci numbers:
http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Recn/Binary/

Trish, you are not doing a SJIS-to-UTF8 conversion, at least not with the code you posted. That code first converts from bytes to characters forth and back using SJIS, which is a waste of time, then converts the bytes to characters using UTF-8, which is simply incorrect if the bytes are in SJIS.
If it works, then some other code is reversing the errors yours is creating.

First of all, the data in this table can be Chinese/Japanese/English/Korean encoded.
So when I retrieve the data, I will need to invoke:
String localStr = new String(rs.getBytes(CONTENT_INDEX),"SJIS");
String utf8Str = new String (localStr.getBytes("SJIS"), "UTF8");
where rs is java.sql.ResultSet
Then I will need to store the utf8 String to a new database table.

You're doing something horribly wrong there. First you take the bytes and interpret them as a SJIS-encoded string. Then you reverse the operation and re-interpret the bytes as an UTF-8 String. Then you store it into a a DB using god knows what encoding. The result is very likely incorrect.

Since the default encoding is "ISO8859_1" and that I have no idea whether the data is
Chinese/Japanese/English/Korean encoded, how can I make the proper conversion?

Simply put, you cannot. Different encodings may well encode different legal character sequences into the same byte sequence.

So far, all discussion in this thread seems to have missed the main points.
First, System.gc(): Whether or not it does anything has nothing to do with whether the VM implements garbage collection. All serious VMs implement garbage collection. However, System.gc() is merely a suggestion to the VM that now would be a good time to do garbage collection. It may or may not heed the suggestion, but it will perform garbage collection when it's running out of memory.
Then, Aaron's observation about memory utilization. You have to realize that there are two levels of memory management involved: that of the VM and that of the OS. The VM takes memory from the OS when needed, up to its maximum heap size. However, it is not obliged to give the memory back to the OS after the objects that took up the memory have been garbage collected! Most VMs will keep hanging on to more memory than they need right now, because it would be a waste of time to give memory back to the OS just to request it again soon afterwards.

Servlets are not "the closest to CGI", Servlets are a CGI implementation in Java. Remember: CGI is nothing but an interface specification for the communication between a HTTP server and programs it executes to react to certain HTTP queries.

I'm currently working on Part II myself, and I have two questions:
- Could you desribe roughly what you put into the
component diagram? I'm a bit unsettled about it
controbuting 40% of the total score. I don't really
know what to put into it, while on the other hand
I don't think one class diagram will be sufficient.
- What kind of question is asked in part III?

That would be a deployment diagram, not a component diagram.

How are you supposed to deal with bad/insufficient requirements? How tight-assed are the graders? Will you lose points if you violate "the letter" of the requirements, even if you can justify it because it allows you to confirm better to "the spirit" of the requirements?
Specifically, would it be OK to eliminate one of the use cases if it allowed a simpler design and faster response times (with a performance criterial part of the requirments) while not resulting in any change to the external behaviour of the system?

Is one supposed to create only one sequence or collaboration diagram per use case (for the basic flow), one one for each flow?