Akin Kaldiroglu

MVC-State Pattern is actually is the combination of MVC and State patterns. Main idea is based on a servlet that acts like a controller to get the requests from the web clients and delegate it to the model. So far it is pure MVC. The effect of State pattern comes when your model have different states and all these states are represented with different JSP. So the Context in the State pattern of GOF corresponds to the servlet itself. It sends the requests to State interface and depending upon the state which your state-dependent object is the servlet redirect the response to a different JSP, which is specificaly designed for that state. In this scenario, of course your servlet should know about which state is active.
Akin Kaldiroglu

In my opinion, GOF is a really good catalog of patterns. It gives you very good understanding and very broad sense of patterns. Then PLOPD volumes are a great treasure upon those more basic books. For example you can find a great discussion on State pattern in vol. 3 where you will know some design issues when implementing that pattern. They are really good.
Akin Kaldiroglu

Originally posted by Avi Abrami:
Prabhjyot,
Java is known as a "hybrid" language - not pure OO - because it has - as you mention - "primitive" data types. By the same token, C++ is also known as a "hybrid" language. On the other hand, smalltalk is a "pure" object oriented language since <em>everything</em> is an object and there is no concept of data type. However, smalltalk also has inheritance. As far as I know, inheritance is one of the things that makes an object-oriented language "object-oriented", and smalltalk - being the first OO language - in defining inheritance, gives me the impression that inheritance does not "go against OO".

Hope this has helped you,
Avi.

I don't think we can call Java "hybrid language". Being OO is a matter of paradigm, not type. OO languages try to picture the reality as it is, i.e. in terms of entities, their attributes and their interaction between themselves. Having primitive types doesn't make a language "hybrid". If Java hybrid, what would you call C++? I don't mean that issue of types don't matter. Think about ML. It is totally dynamically typed, or JavaScript, which is typless. But they are no way object-oriented. Having a type system or being strongly-typed have some other implications, pros and cons of course, but I don't think we can call a language "hybrid" just by looking at the types system it provides. A language may have a strongly-typed system and support OO paradigm through a type hierarchy such as the one in Java.
Akin Kaldiroglu

Originally posted by Mark Herschberg:
FYI "Java Platform Performance" notes the following sizes (in bytes):
1 byte
2 char
2 short
4 int
4 float
8 long
8 double
4 reference (8 on a 64-bit system)
Although different JVMs may use different (probably larger) sizes.

--Mark
hershey@vaultus.com

Hello,
I agree with Peter that the sizes of all primitive types in Java are standard. For composite objects, it is not that clear.
And I don't know of any API call to get the size of an object. There might be two methods to estimate the size of an object:
1- Adding up the sizes of all the fields in the object. We know the sizes of primitives. For references, Steve Wilson and Jeff Kesselman notes in their book "Java Platform Performance" it is 4 bytes.
2- Other method would be measuring heap memory before and after you create your object.
Of course these wouldn't give you the exact amount but you can have more accurate guess after them.
Pages 57-61 of the book I mentioned above gives you some info and
a simple implementation to measure the size of an object.
Akin Kaldiroglu

You can get the full version of TogetherJ free if you are a student and if you get your professor's signature. This is only for educational purpose.
I have used TogetherJ for a while. In my opinion it is preferable to Rose. I believe developers find TogetherJ more attractive while more high level people like architects and system people find Rose more comfortable. I guess this is because TogetherJ is more code oriented. If you use Java, I believe TogetherJ is the way to go.
TogetherJ of course has some serious and stupid bugs. And due to the fact that it is written in Java and Java GUIs are still slower from their native counterparts, you should be patient while working with TogetherJ.
Akin Kaldiroglu

I believe questions like "Which one is faster, C++ or Java?" does only make sense if we mention some more information about the situation. Specific platforms, implementations, algorithms, and skills of the person who writes the code will definetely determine the execution efficiency of the code, whether it is in Java or C++. But apparently , as in every aspect of the reality, there are tradeoffs in language design issues, too. What kind of problems or issues you like to address will determine your choice for languages too. Problems that are waiting in front of software engineers are getting more and more complex. Most of the time handling the complexity correctly and efficiently precedes performance. I mean, you will definetely to implement all of the requirements in an efficient and correct way and sacrifice from your performance in a reasonable range. If the performance is your only concern, then you will most like look for good machine code writers.
I believe Java has been created to handle the complexity better. In fact this is the promise of OO theory. Encapsualtions, inheritance, polymorphism, reusability and all other buzzwords are here to reflect the relationships between the entities in the real world on software area. Anybody who has a little experience in procedural and oo languages would confess that writing code with an oo language would require more line of code such as creating a class and instantiating its objects etc. So there are some intrinsic drawbacks of oo theory and languages implemented in that way. And when you add some other concerns and decisions such as beign platform independent, more secure etc. you will definetely give up some of other aspects such as performance. Java is more secure, using exceptions are mandatory and excellent way for project efficiency and user interaction in the software. This list goes on.
I have just read an article, I don't remember exactly where, but it was about Microsoft's new language, C#. The writer was talking about the fact that Microsoft realized the fact that C++ is capable but too complex and hard to use to develop giagantic and/or web based applications. He claimed that as a result of its experince from VisulaBasic and C++, Microsoft is now trying to incorporate best aspects of VisualBasic and C++ and creating its own "Java". I am not knowledgeable about C# but what I understood from the article is that Microstf is trying to address the complexity problem I mentioned above in its way.
Akin Kaldiroglu

I believe what you are saying is true. Most of the performance
benefits come from HotSpot VM not from static compiler (javac) of JDK1.3. And my experience says to me that javac of JDK1.3 is not much different from javac of JDK1.2. Here are a buch of benchmarks regarding this isuue. I have run James Gosling's QuickSort algorithm (http://java.sun.com/applets/jdk/1.1/demo/SortDemo/QSortAlgorithm.java) with different compilers and JVMs. My system is WindowsNT 4.0 with SP5, has 256 MB of RAM and 730 MHz. Pentium III.

I created an array with 10000000 integers. Ther are totally reversed, i.e. array[0] = 1 and array[9999999] = 10000000


jdk1.2.2 jdk1.3 jdk1.3 -classic jdk1.3 -server
-------- ------ --------------- --------------
3896 5308 43552 6119
3955 5328 43723 6128
3955 5308 43593 6148
3955 5328 43623 6159
4005 5348 43612 6089
---- ---- ----- ----
3971.2 5324 43620.6 6128.6


Compiled with jdk1.2.2 but run under jdk1.3
--------------------------------------------
5387
5277
5368
5238
5258
----
5305.6

Compiled with jdk1.2.2 but run under jdk1.3 -classic
---------------------------------------------------
43443
43532
43713
43603
43383
-----
43534.8

Compiled with jdk1.2.2 but run under jdk1.3 -server
---------------------------------------------------
6159
6219
6099
6079
6099
----
6131
Although the algorithm I choose is too specific to reflect comparisions correctly, it would give us an idea about what we have been talking about.
Some of the things that we can withdraw from the results:
1- VM of jdk1.2.2 seems the fastest one. Notice that it has JIT.
2- Client HotSPot (jdk1.3) is faster than Server HotSpot (jdk1.3 -server) for this case. This is expected because Client HotSpot makes fast and easy optimizations whereas Server HotSpot takes more time to show its effect on the performance.
3- jdk1.3 -classic has an awful performance since its JIT is turned off.
4- It doesn't make any difference, at least for this case, whether you compile your code with jdk1.2.2 javac or jdk1.3 javac if you run it in jdk 1.3 JVM, whether it be Client HotSpot or it be Server HotSpot.
5- You are dead if you don't use any run time environment that somehow compiles some of your bytecode into the native code!
Thanks.
Akin Kaldiroglu

Hello,
Do you have any idea about the differences, if any, between compilers (javac) of jdk1.2 and jdk1.3. I know and have experienced many times the difference between their VM's, i.e. 1.2's VM and HotSPot1.0 and 1.3's HotSpot2.0. How about static compilers, javac? Any new technique, optimization introduced with javac of jdk 1.3. I haven't heard anything about that so far. Have you?
I am asking this question because of following situation: We have a code in production. It is compiled with jdk 1.2.2. We want to compile it with 1.3 and run it in HotSpot. But we are using some third party components, which are compiled with jdk 1.2.2. And it seems that we won't have the opportunity to have them compiled with jdk 1.3. Can we say that if we can have those components compiled with jdk 1.3, we can gain some extra performance that comes from the new features of javac of jdk 1.3?
Thanks
Akin Kaldiroglu

And there was a report by Cutter. You may want to go to their site and look for it: http://cutter.com/itgroup/reports/index.html
Akin Kaldiroglu