The question of Java performancd can be quite subjective. For example, I run jEdit, a 100% Java text editor. It's fast. Unforunately, its not as fast as native Win32 editors like UltraEdit or TextPad. However, my mind and body can only work so fast. Both jEdit and the other text editors are faster than I need them to be for my day-to-day operations. So, by that measure, Java is fast.
Of course, some people interpret the statement to be a comparison to C or C++. Now, Java has a lot of behaviors that are slower than C/C++.
For example consider array access. Java implicitlu checks the bounds of an array whereas in C/C++, that is leftas an exercise for the programmer. Unfirtunately, most pogrammers are lazy and don't exercise that. Hence with C/C++ you have buffer overruns where nasty clients can execute arbitrary code. In Java,you'd have an ArrayIndexOutOfBoundsException which would prevent the malicious data form being pushed into memory. This, it was a trade-off between security and speed.
Garbage collection is another one of these. Ever seen a C/C++ program with memory leaks (why, I even remember the X11 libraries leaking)? With Garbage collection, your memory consumption is slower and your memory freeing slower (since Java has to determine using an algorithm what isn't used anymore whereas in C/C++ its coded into the logic). Java also seems slower becaus ethat GC overhead is generally experiences as "pauses" whereas n C/C++ the object deletion occurs through the execution of the program. But this was a trade-off. A trade-off between making developers lives easier and the programs more stable versus the speed and risk of developer-coded memory deallocation.
Java also has immutable Strings With a mutable String class, I know I could eliminate a lot of Object creation. But the String class was made immutable so everything could be final, and thus optimized better for. This was a trade-off between the speed of Strings themselves and the speed of creating a new String everytime you need to concatenate.
There are many more cases, but I think you get the point. Java does things ways that are slower. But many of these are trad-offs -- trade-offs to make the programs more secure, development faster and syntax/API simpler. Then they go and address the speed in other ways by improving the VM (HotSpot, incremental/concurrent GC, etc.)
In my opinion, I would've accepted a 100% Java version of Microsoft Outlook, even if it was slower, if I didn't have to worry about the nex buffer overrun exploit hijacking my computer.
One of the things that worries me about generics is how they could be abused, or at least lead one to think things are good enough. Consider a HashMap. Because of boxing, it's really a HashMap. If you've ever looked at HashMap's code, you know it calls.hashCode() on the key objects (Integers in this case), as well as.equals(). However, if you just broke down and wrote an IntHashMap, you could iuse the int value itself as the hashcode, and use == instead of.equals(). Of course, this would no longer adhere perfectly to the Map interface which of old, but with generics, that's supposed to be a thing of the past.
Don't get me wrong, there are also benefits to generics. A lot of people forget that casting in Java is not a compile-time operation alone. It is performed at runtime and actual instructions are executed to verify the types can be casted. By using generics in collections, for example, you eliminate the need to do runtime casting, and thus eliminate the associated overhead.
Well, we might or might not be saying the same thing. The important thing in OODBMS is that there is no "impeadance mismatch". That is, you store the data as objects, not homogenous rows of primitive data types. I think the ODBMSFacts.com site's FAQ may explain it better than I do. But then again, maybe we are on the same length -- I can't tell.
OODBMS are not supposed to objectivy rows, and tables. In fact, XL2 (whcih is the only OODBMS I've worked with) does nothing of the sort. It's more like serializing the graph of objects and references you have in memory to disk.
Now, perhaps some OODBMSs are really object-relational mapping solutions behind the scenes, but I know for a fact that XL2 is not. I've been through the source code and was awed at the simplicity. It is very much like a snapshot of memory on disk.
Now XL2 is primitive in that it doesn't have an Objective query language. You must query it yourself. In pseudo-code, you would work with it like this:
XL2Database db = new XL2Database(...); AddressBook addresses = (AddressBook)db.getRoot(); Person trinition = addresses.findByUsername("Trinition"); db2.startT ransaction(); trinition.setKarma(50); db2.endTra nsaction();
Note that the AddressBook class defines "findByUsername". Internally, it could just be a HashMap. Or, if you wanted to be slick, it would be an XL2Map (which can lazy-load individual members). But the point is, I didn't write a query like "SELECT * FROM USERS WHERE USERNAME='Trinition'", convert the result into an object, change an attribute, and then take each attribute of the User object and stick it into a Prepared statement and update the record.
It is much simpler. Now, if you have 50 million users in your AddressBook, and XL2Map might not be the most efficient mechanism for performing lookups. Relational databases rock at that sort of thing.
But then again, as I said before. OODBMSs are still young, and XL2 especially is poor-man's OODBMS.
What's after relational?
on
Java Data Objects
·
· Score: 2, Interesting
In my databases 102 class in college (yeah, I passed databases 101), we covered heirarchial, network, and relational databases. More recently, I've learned of object oriented databases (for a free, 100% Java poor-man's OODB, see XL2). From everything I've read about OODBs, they would be better solution than RDBMSs for 90% of the stuff I've seen as a Java programmer.
The negatives I've heard from people in coversation are "they're not as fast", "there ae no tools", etc. BUt each of these are either false, not entirely true, or jyst due to immaturity:
Too slow Actually, because there is no impedance mismatch (converting from related rows into an Object, and converting the data types between disparate systems), they can be faster than an RDBMS. Where you might have to pull up a person record, and then their home address record, convert their homepage into a URL object, etc... in an OODBMS, your data is (can be) already in the proper Object format. You wouldn't needs things like JDO.
Tools no available Well, the haven't been around for as many decades as RDBMSs either. And, one of the other things that makes RDBMS tools so numerous is that they have a standard language, SQL. However, you must still rebuild what the data means in your reporting system separately from your online system. In an OODBMS, you would theoretically only build the Classes for the Objects once, and they would have with them the business rules.
Any thoughts? I'm not an OODBMS bigot, but I'm trying to be an advocate in the hopes that it will have some truly educational dialogue.
The United States is no more dangerous than a loaded gun. The problem is, our current administration is like a testosterone-laden teenager waving the thing around to impress girls and get what he wants. But its not that simple.
Did we do this for oil? Well, we certainly import a lot of oil. We would cetrainly feel the pain if the oil market were disrupted. But, also, what do you thinkwould happen fi left Iraq in shambles without fixing things up a bit first? The arab world would hate us, causing more instability nd probably disrupting the oil supply. What if we fixed it up, but paid for it ourselves. Well, we're rich, but we never invest in anythign that indirect and that uncertain. It would be too costly. So what if we used Iraq's ONLY MAJOR REVENUE SOURCE to rebuild Iraq? it's not so far fetched. Some people see one idea as more prominent than the other. The problem is, people usually state an "either/or". The truth is, all of those factors are part of the equation.
Its not the best solution, by far. In fact, my 8-year-old can come up with a better solution to the oil problem, mideast affairs, iraq, civil liberties, etc. But stop painting this as a black and white picture. Take what the left says, then what the right says, then realize that half of what each says is true, and the other half you throw away.
Translation: "An authority exists which has the potential to abuse it's power, therefore this authority must be kept weak by other methods, particularly ignorance."
Hey, I wouldn't mind the government wiretapping me if I knew when it was going on. The thing is, they're taking away my privacy but not theirs. They want to keep ME ignorant of what exactly it is they're doing.
I recall a feature of DNS when Iwas researching SIP (session initiation protocol). It seems DNS has a way to list the default host names for particular protocols by using SRV records. For example, I could query DNS for the "sip.tcp" SRV record for my ISP and find the host to be "sip-server.myisp.com".
So why use DHCP to do something new when DNS can already handle it? Even if itsn ot fully realized in all DNS servers, it's still closer than DHCPs are, sin't it?
Or does DHCP have this inate ability too? Still, I would think DNS is more pervasive than DHCP.
So if something is a crime, no additional laws or needed? I've often wondered this myself. Consider drunk driving. It's illegal? Why? Because in your inebriated state, you *might* kill someone via vehicular manslaughter.
But killing someone is already illegal. Why have a law that aims to prevent something that is already illegal? The keyword is *prevention*. If you can stop someone before they've killed, you may have saved a life.
Granted, I forgot about some of the other overhead. There is the class pointer, among other things, that Java uses to remember what type of object everything is. Still 64 sounds high, but it is less important too as the size of a String grows.
Thanks for the tip, though! I wasn't criticizing, but I did want to know where 64 bytes came from!
OK, so I was curious, so I checked up on this. Maybe I'm wrong, but I don't see 64 bytes. Here's a reduced snippet of the member variables in a String class (1.4.1_06):
public final class String
implements java.io.Serializable, Comparable, CharSequence {/** The value is used for character storage. */
private char value[];/** The offset is the first index of the storage that is used. */
private int offset;/** The count is the number of characters in the String. */
private int count;/** Cache the hash code for the string */
private int hash = 0;
There are 3 ints, and a char array. each int is 4 bytes, the reference to the array is 4 bytes, and the array has a length attribute (another int) that is 4 bytes. That's 3*4 + 4 + 4 = 20 bytes. Then you would add 2 bytes for each character. But an empty string would be 20 bytes by my count.
Where did you come up with 64 bytes?
Re:Not free but ... IntelliJ is by far the best
on
Eclipse 2.1 Released
·
· Score: 1
I've read the feature list many timesz, and it is impresive. And I've talke to people who've used it any they love it! However, I'm starting to see eclipse catch up (and maybe others?).
Can you point out some of the featuresin IntelliJ that you have yet to see in another IDE? Heh, maybe it will be a starting poi9nt for the next feature list to ecipse!
It's as if you know me! I never took a typing class. What I do is probably about as far from ergonomic and proper as possible. But, then again, I feel most typing classes are oriented for eltters, but curly braces, underscores, function keys, etc. So between my speed, and the computers ability to correct what I type for me (except, of course, in HTML textareas), even someone ashandicapped at typing as me can get stuff done.
Just for contrast, I first tried NetBeans/Forte. I hated having to "mount filesystems" (gee, did someone from the *nix world write this thing?). I couldn't get anything to work agaist my current projects.
I actually had the same feeling when I tried eclipse 1.x. It turns out, eclipse 1.x was just too primitive. 2.0 is great. 2.1, which I'm downloading now, looks like it will be fantastic!
The biggest thing I would miss if I went back to a text editor would me the auto-completion. Some call it code-sinsight, aother code-completeion, other auto-complete. But he fact that I can get a quick in-place list of methods/members without referring to another file, or documentation, ro header file, is awesome.
I know, I know, it sounbs so trivial. But I believe this to have been the biggest efficienncy in IDE design ever! And, I'm sorry, notepad just doesn't have it.
jEdit, on the other hand... that's what I would call a text editor that gets confused smetimes and thinks it's an OS.
Right. Going to college for CS doesn't make you better at programming. It does force you to learn other areas you might not normally care to consider. It forces you to learn time and resource management. Its a much better example of beauracracy than one could ever find in high schools.
Now since the real world of programming isn't 100% CS, it turns out all of these other implicit things you pick up in college help you more than you would ever expect.
Yeah, knocking college is great. Grades don't indicate how smart you are. They indicate how well you play the game. And guess what people the real world is just a game too.
The probelm is that the "bad-ass coders" and "computer science geniuses" work for the MBAs who would rather force you to cut corners to make a short-term deadline than worry about long-term costs and other repurcussions. In an ideal world, the "bad-asses and geniuses" would refuse to work, but there's nagging thing about food on the table and clothes on the backs.
As long as we're throwing money at the problem, then include solar in it. Even nuclear has an exhaustable fuel supply. Solar has a supply on the order of billions of years. If we can engineer cheaper (mass produce), more efficient (already being accomplished), less polluting solar panels... and keep them running for a long time before replacing, this will be a moot point.
Don't disregard a technology becuase its not at the right levels today. If you really want it, you can make it better.
Slashdot Mirror
A lot of the features added to 1.5 are syntactic sugar for laziness. I guess that means this is true progress, according to your signature.
It's not just for laser pointers -- there's a whole spectrum of opportunities!
The question of Java performancd can be quite subjective. For example, I run jEdit, a 100% Java text editor. It's fast. Unforunately, its not as fast as native Win32 editors like UltraEdit or TextPad. However, my mind and body can only work so fast. Both jEdit and the other text editors are faster than I need them to be for my day-to-day operations. So, by that measure, Java is fast.
Of course, some people interpret the statement to be a comparison to C or C++. Now, Java has a lot of behaviors that are slower than C/C++.
For example consider array access. Java implicitlu checks the bounds of an array whereas in C/C++, that is leftas an exercise for the programmer. Unfirtunately, most pogrammers are lazy and don't exercise that. Hence with C/C++ you have buffer overruns where nasty clients can execute arbitrary code. In Java,you'd have an ArrayIndexOutOfBoundsException which would prevent the malicious data form being pushed into memory. This, it was a trade-off between security and speed.
Garbage collection is another one of these. Ever seen a C/C++ program with memory leaks (why, I even remember the X11 libraries leaking)? With Garbage collection, your memory consumption is slower and your memory freeing slower (since Java has to determine using an algorithm what isn't used anymore whereas in C/C++ its coded into the logic). Java also seems slower becaus ethat GC overhead is generally experiences as "pauses" whereas n C/C++ the object deletion occurs through the execution of the program. But this was a trade-off. A trade-off between making developers lives easier and the programs more stable versus the speed and risk of developer-coded memory deallocation.
Java also has immutable Strings With a mutable String class, I know I could eliminate a lot of Object creation. But the String class was made immutable so everything could be final, and thus optimized better for. This was a trade-off between the speed of Strings themselves and the speed of creating a new String everytime you need to concatenate.
There are many more cases, but I think you get the point. Java does things ways that are slower. But many of these are trad-offs -- trade-offs to make the programs more secure, development faster and syntax/API simpler. Then they go and address the speed in other ways by improving the VM (HotSpot, incremental/concurrent GC, etc.)
In my opinion, I would've accepted a 100% Java version of Microsoft Outlook, even if it was slower, if I didn't have to worry about the nex buffer overrun exploit hijacking my computer.
One of the things that worries me about generics is how they could be abused, or at least lead one to think things are good enough. Consider a HashMap. Because of boxing, it's really a HashMap. If you've ever looked at HashMap's code, you know it calls .hashCode() on the key objects (Integers in this case), as well as .equals(). However, if you just broke down and wrote an IntHashMap, you could iuse the int value itself as the hashcode, and use == instead of .equals(). Of course, this would no longer adhere perfectly to the Map interface which of old, but with generics, that's supposed to be a thing of the past.
Don't get me wrong, there are also benefits to generics. A lot of people forget that casting in Java is not a compile-time operation alone. It is performed at runtime and actual instructions are executed to verify the types can be casted. By using generics in collections, for example, you eliminate the need to do runtime casting, and thus eliminate the associated overhead.
Well, we might or might not be saying the same thing. The important thing in OODBMS is that there is no "impeadance mismatch". That is, you store the data as objects, not homogenous rows of primitive data types. I think the ODBMSFacts.com site's FAQ may explain it better than I do. But then again, maybe we are on the same length -- I can't tell.
OODBMS are not supposed to objectivy rows, and tables. In fact, XL2 (whcih is the only OODBMS I've worked with) does nothing of the sort. It's more like serializing the graph of objects and references you have in memory to disk.
T ransaction();a nsaction();
Now, perhaps some OODBMSs are really object-relational mapping solutions behind the scenes, but I know for a fact that XL2 is not. I've been through the source code and was awed at the simplicity. It is very much like a snapshot of memory on disk.
Now XL2 is primitive in that it doesn't have an Objective query language. You must query it yourself. In pseudo-code, you would work with it like this:
XL2Database db = new XL2Database(...);
AddressBook addresses = (AddressBook)db.getRoot();
Person trinition = addresses.findByUsername("Trinition");
db2.start
trinition.setKarma(50);
db2.endTr
Note that the AddressBook class defines "findByUsername". Internally, it could just be a HashMap. Or, if you wanted to be slick, it would be an XL2Map (which can lazy-load individual members). But the point is, I didn't write a query like "SELECT * FROM USERS WHERE USERNAME='Trinition'", convert the result into an object, change an attribute, and then take each attribute of the User object and stick it into a Prepared statement and update the record.
It is much simpler. Now, if you have 50 million users in your AddressBook, and XL2Map might not be the most efficient mechanism for performing lookups. Relational databases rock at that sort of thing.
But then again, as I said before. OODBMSs are still young, and XL2 especially is poor-man's OODBMS.
The negatives I've heard from people in coversation are "they're not as fast", "there ae no tools", etc. BUt each of these are either false, not entirely true, or jyst due to immaturity:
Too slow Actually, because there is no impedance mismatch (converting from related rows into an Object, and converting the data types between disparate systems), they can be faster than an RDBMS. Where you might have to pull up a person record, and then their home address record, convert their homepage into a URL object, etc... in an OODBMS, your data is (can be) already in the proper Object format. You wouldn't needs things like JDO.
Tools no available Well, the haven't been around for as many decades as RDBMSs either. And, one of the other things that makes RDBMS tools so numerous is that they have a standard language, SQL. However, you must still rebuild what the data means in your reporting system separately from your online system. In an OODBMS, you would theoretically only build the Classes for the Objects once, and they would have with them the business rules.
Any thoughts? I'm not an OODBMS bigot, but I'm trying to be an advocate in the hopes that it will have some truly educational dialogue.
B. Entity beans also offer security, transactions and remoteness. None of that you get inherently with JDO.
The United States is no more dangerous than a loaded gun. The problem is, our current administration is like a testosterone-laden teenager waving the thing around to impress girls and get what he wants. But its not that simple.
Did we do this for oil? Well, we certainly import a lot of oil. We would cetrainly feel the pain if the oil market were disrupted. But, also, what do you thinkwould happen fi left Iraq in shambles without fixing things up a bit first? The arab world would hate us, causing more instability nd probably disrupting the oil supply. What if we fixed it up, but paid for it ourselves. Well, we're rich, but we never invest in anythign that indirect and that uncertain. It would be too costly. So what if we used Iraq's ONLY MAJOR REVENUE SOURCE to rebuild Iraq? it's not so far fetched. Some people see one idea as more prominent than the other. The problem is, people usually state an "either/or". The truth is, all of those factors are part of the equation.
Its not the best solution, by far. In fact, my 8-year-old can come up with a better solution to the oil problem, mideast affairs, iraq, civil liberties, etc. But stop painting this as a black and white picture. Take what the left says, then what the right says, then realize that half of what each says is true, and the other half you throw away.
From the people with a 1-button mouse, who then moved to a NO-button mouse, we now have a mouse with an extra 4+1 directional button?!?1
Translation: "An authority exists which has the potential to abuse it's power, therefore this authority must be kept weak by other methods, particularly ignorance."
Hey, I wouldn't mind the government wiretapping me if I knew when it was going on. The thing is, they're taking away my privacy but not theirs. They want to keep ME ignorant of what exactly it is they're doing.
I'll show them mine if they show me theirs.
I recall a feature of DNS when Iwas researching SIP (session initiation protocol). It seems DNS has a way to list the default host names for particular protocols by using SRV records. For example, I could query DNS for the "sip.tcp" SRV record for my ISP and find the host to be "sip-server.myisp.com".
So why use DHCP to do something new when DNS can already handle it? Even if itsn ot fully realized in all DNS servers, it's still closer than DHCPs are, sin't it?
Or does DHCP have this inate ability too? Still, I would think DNS is more pervasive than DHCP.
So if something is a crime, no additional laws or needed? I've often wondered this myself. Consider drunk driving. It's illegal? Why? Because in your inebriated state, you *might* kill someone via vehicular manslaughter.
But killing someone is already illegal. Why have a law that aims to prevent something that is already illegal? The keyword is *prevention*. If you can stop someone before they've killed, you may have saved a life.
So what does this law prevent?
Granted, I forgot about some of the other overhead. There is the class pointer, among other things, that Java uses to remember what type of object everything is. Still 64 sounds high, but it is less important too as the size of a String grows.
Thanks for the tip, though! I wasn't criticizing, but I did want to know where 64 bytes came from!
OK, so I was curious, so I checked up on this. Maybe I'm wrong, but I don't see 64 bytes. Here's a reduced snippet of the member variables in a String class (1.4.1_06):
/** The value is used for character storage. */ /** The offset is the first index of the storage that is used. */ /** The count is the number of characters in the String. */ /** Cache the hash code for the string */
public final class String
implements java.io.Serializable, Comparable, CharSequence
{
private char value[];
private int offset;
private int count;
private int hash = 0;
There are 3 ints, and a char array. each int is 4 bytes, the reference to the array is 4 bytes, and the array has a length attribute (another int) that is 4 bytes. That's 3*4 + 4 + 4 = 20 bytes. Then you would add 2 bytes for each character. But an empty string would be 20 bytes by my count.
Where did you come up with 64 bytes?
I've read the feature list many timesz, and it is impresive. And I've talke to people who've used it any they love it! However, I'm starting to see eclipse catch up (and maybe others?).
Can you point out some of the featuresin IntelliJ that you have yet to see in another IDE? Heh, maybe it will be a starting poi9nt for the next feature list to ecipse!
It's as if you know me! I never took a typing class. What I do is probably about as far from ergonomic and proper as possible. But, then again, I feel most typing classes are oriented for eltters, but curly braces, underscores, function keys, etc. So between my speed, and the computers ability to correct what I type for me (except, of course, in HTML textareas), even someone ashandicapped at typing as me can get stuff done.
Anyone have a miror?
I've tried both the FTP and HTTP links. I'm currently getting 2.58kb/sec on my fancy broadband connection.
Military? Resource management. I too have worked with peopl from the military. It's just as wasteful as the rest of the government.
Just for contrast, I first tried NetBeans/Forte. I hated having to "mount filesystems" (gee, did someone from the *nix world write this thing?). I couldn't get anything to work agaist my current projects.
I actually had the same feeling when I tried eclipse 1.x. It turns out, eclipse 1.x was just too primitive. 2.0 is great. 2.1, which I'm downloading now, looks like it will be fantastic!
The biggest thing I would miss if I went back to a text editor would me the auto-completion. Some call it code-sinsight, aother code-completeion, other auto-complete. But he fact that I can get a quick in-place list of methods/members without referring to another file, or documentation, ro header file, is awesome.
I know, I know, it sounbs so trivial. But I believe this to have been the biggest efficienncy in IDE design ever! And, I'm sorry, notepad just doesn't have it.
jEdit, on the other hand... that's what I would call a text editor that gets confused smetimes and thinks it's an OS.
Right. Going to college for CS doesn't make you better at programming. It does force you to learn other areas you might not normally care to consider. It forces you to learn time and resource management. Its a much better example of beauracracy than one could ever find in high schools.
Now since the real world of programming isn't 100% CS, it turns out all of these other implicit things you pick up in college help you more than you would ever expect.
Yeah, knocking college is great. Grades don't indicate how smart you are. They indicate how well you play the game. And guess what people the real world is just a game too.
The probelm is that the "bad-ass coders" and "computer science geniuses" work for the MBAs who would rather force you to cut corners to make a short-term deadline than worry about long-term costs and other repurcussions. In an ideal world, the "bad-asses and geniuses" would refuse to work, but there's nagging thing about food on the table and clothes on the backs.
As long as we're throwing money at the problem, then include solar in it. Even nuclear has an exhaustable fuel supply. Solar has a supply on the order of billions of years. If we can engineer cheaper (mass produce), more efficient (already being accomplished), less polluting solar panels... and keep them running for a long time before replacing, this will be a moot point.
Don't disregard a technology becuase its not at the right levels today. If you really want it, you can make it better.