Most C/C++ developers think Java is slow.
Java is usually faster than C/C++.Take a look at Cassandra. 100% pure Java, one of the fastests databases, and it can scale infinitely. Nothing in compares. Taking a snapshot of the database is almost instantaneous.
HSQLDB, arguably the fastest database, also is 100% pure Java. You look at the code and it makes you cry on how simple it is.
There are some exceptions though. Some code in Java looks like some C++ programmer did it. The libraries in Java are too many to elaborate and some XML parsing libraries I've met are ridiculous, the use to much memory, they even create classes on the fly (meaning they are incredibly slow, use too many resources, you get Permgen space errors, because they create new classes and the classes are stored in a special place called Permgen in Java <= 1.6), so yes, working in Java usually means selecting libraries carefully and monitoring your application to replace the offending libraries as soon as you find out.
Java beats C/C++ because of the memory management. In Java, the new operator always return in just what it takes to increment a pointer, which is blazing fast. In C/C++ you go into a special part of the program, you need synchronization, and then there is an algorithm to find the right place and right amount of memory, scavenging through a linked list of memory. It can take a while.
Garbage collection is not a problem if you use the parallel collector. Now all computers have several cores, so if one of the cores is dedicated to garbage collection it is not a problem.
Java is not a difficult language, like C and C++ are. Any competent programmer can learn Java in 6 months. The same programmer would need 3 years to learn C++ at the same level.
The problem with Java are the set of libraries. They are too many. And the information for using them is sparse. The documentation for some of them explain so few things that makes it look that it is so simple, while in practice using them is quite complex. One example is Hibernate. Hibernate has a concept of managed object, so objects that can be persisted, once you persist them, Hibernate keep track of them, and associate them with a Hibernate session. a hibernate session can be thought as a database transaction. So if you performed an operation in a Hibernate session, you can't mix an match objects in one session with another session.
This create a lot of problems. And this is explained where? Nowhere. So you realize the problem, you need to create a document explaining the problem and then you need to device a whole architectural design in order for developers to follow so that this doesn't happen anymore.
Most libraries operate with he wrong set of assumptions. Hibernate operate on the assumption that you will keep objects in RAM between Hibernate sessions (and then complain if you reuse them). That's the wrong assumption. How could you store those objects in RAM if the database is the object that persists those objects? Are they supposed to fit in RAM? Is the database supposed to update the objects in RAM when another process changes them in the database? Those are the wrong assumptions. Keeping them is RAM is the worst assumption ever.
The same goes true for Vaadin. Vaadin assumes that all objects representing the model stay up in RAM. If I need to refresh those objects from the database every time I need to display them, it is kind of obvious the same will be true for screen objects.
Isn't that obvious?
So yes, developing in Java usually means you need to figure out what the library developers were thinking and correcting your code to handle things gracefully.
I would say 90% of the effort is finding the right libraries and correcting your code to handling the library code correctly. That of course is documented nowhere and when Java projects get late, they blame it on the language rather than on the libraries, because for most people those libraries don't even exist, and for the ones who have heard their name, they are so new... that they couldn't possibly be wrong.
0 comments:
Post a Comment