 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2006java object oriented - integer
Hi to everyone, When we say java is an object oriented language, I guess everyone will agree then, my question is why do we have integer data type as int in java which does not fit into object oriented scenario. > Hi to everyone, > > When we say java is an object oriented language, I guess everyone will > agree then, my question is why do we have integer data type as int in > java which does not fit into object oriented scenario. Because those who say Java is an OO language are not correct. Java is a language that lends itself to being programmed in an OO way, but there are others eg SmallTalk that do an even better job. -- Mike W > Hi to everyone, > > When we say java is an object oriented language, I guess everyone will > agree then, my question is why do we have integer data type as int in > java which does not fit into object oriented scenario. its a performance compromise > > [...] my question is why do we have integer data type as int in > > java which does not fit into object oriented scenario. > > its a performance compromise Or a failure of imagination... -- chris >>> [...] my question is why do we have integer data type as int in >>> java which does not fit into object oriented scenario. [quoted text clipped - 4 lines] > > -- chris true >>>[...] my question is why do we have integer data type as int in >>>java which does not fit into object oriented scenario. >> >>its a performance compromise > > Or a failure of imagination... Or a strategy to appeal to the C/C++ community...  SignatureJohn Bollinger jobollin@indiana.edu >>>> [...] my question is why do we have integer data type as int in >>>> java which does not fit into object oriented scenario. [quoted text clipped - 4 lines] > > Or a strategy to appeal to the C/C++ community... ;) There is java.lang.Integer and int primiative. The two are conducive towards different use. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > Hi to everyone, > > When we say java is an object oriented language, I guess everyone will > agree then, my question is why do we have integer data type as int in > java which does not fit into object oriented scenario. Who said Java is a completely OO language? It's a performance hack. Alun Harford >> Hi to everyone, >> [quoted text clipped - 3 lines] > > Who said Java is a completely OO language? Or that such a thing is desirable? > > Who said Java is a completely OO language? > > Or that such a thing is desirable? Me. (But not in this thread. Yet....) -- chris Montu skrev: > When we say java is an object oriented language, I guess everyone will > agree then, my question is why do we have integer data type as int in > java which does not fit into object oriented scenario. Java is not purely OO, but has some OO concepts like inheritance and encapsulation. The reason for having special primitive types that are not objects, as others have written, is because when Java was created there were no aggresively optimizing JVM's and they thought it was a good compromise to get decent performance. It would certainly be possible to create a language/VM that was fully OO and obtained as good (if not better) performance than todays Java. The key to this is escape analysis which enables stack allocation of objects and storing object field values in local variables. EA would also enable optimization of closure expressions (blocks in Smalltalk), which allows you to remove all special 'if', 'while', 'for' etc. constructs from the language without performance loss. Basicly you would have a language like Smalltalk with the performance of Java or C++. Actually EA is performed by Sun's new JVM, but no stack allocation optimization will be performed in Java 1.6, only synchronization lock elimination. /JN > Java is not purely OO, but has some OO concepts like inheritance and > encapsulation. The reason for having special primitive types that are [quoted text clipped - 11 lines] > by Sun's new JVM, but no stack allocation optimization will be > performed in Java 1.6, only synchronization lock elimination. Do you have a good source which states the optimizations performed by Sun's JVM? I often hear statements like "The jit-compiler could optimize this" or "A good JIT compiler removes that", but the documentation of the JRE and SDK do not give much hints about compiler optimizations. Jens Auer skrev: > Do you have a good source which states the optimizations performed by > Sun's JVM? No, I would be really interested in such a document myself. All I've found are some very general descriptions about Hotspot, but no details on which optimization are applied and when they are applied (IBM is superior in this regard). My statement about EA is based on this thread: http://forums.java.net/jive/thread.jspa?threadID=2248&tstart=30 where 'steved' from Sun writes: 'No, the stack allocation of non-escaping objects is planned for the release after Mustang.' Which is unfortunate. /JN >No, I would be really interested in such a document myself. All I've >found are some very general descriptions about Hotspot, but no details >on which optimization are applied and when they are applied (IBM is >superior in this regard). My statement about EA is based on this >thread: With JET you can look at the generated machine code without even using a debugger or disassembler. You just ask the compiler to generate you assembler listings to examine. I have been very impressed so far. See http://mindprod.com/jgloss/benchmark.html http://mindprod.com/jgloss/jet.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.