You may be faced with question "Should I use c++ for my project, or should I use Java ?" As a programming language, Java has some advantages and disadvantages over the other language. One of the most compelling reasons for using Java is that it enhance developer productivity. The main disadvantage is slower execution speed.
Java is Object oriented language. One advantage of using the object oriented language is it promotes reuse of code, results in better productivity of developer. This makes java more attractive than procedure language such as C, but it doesn't add much value to Java over C++.
Java's restrictions on direct memory manipulation boost productivity. In Java, there is no way to directly access memory by arbitrary changing pointers to a different type or by using pointer arithmetic as in C++. Java requires that you strictly obey the rule. For instance, if you have reference to an object of type "Person", you can only manipulate it as "Person". You can not cast the reference to "Animal". because Java enforces strict type rules at a run time, you are not able to directly manipulate memory in ways that can accidentally corrupt it.
Java prevents from inadvertently corrupting memory through automatic garbage collection. Like C++ Java has a new operator to allocate memory for a new object. but Unlike C++ Java has no delete operator which C++ programmers use to free the memory for an object that is no longer. In Java when you stop referencing an object, and some time later, the garbage collector will reclaim the memory occupied by the object.
As C++ program grows in size, it becomes difficult for programmers to determine when an object should be freed or even whether an object has already been freed. This results into a memory leak, in which unused object are never freed, and memory corruption, in which the same object is accidentally freed multiple times. both kinds of memory trouble cause the C++ program to crash. It is very difficult to track down the exact source of the problem that caused a program to crash. In Java, you can be more productive because you no longer have to worry about explicitly freeing memory and program design becomes easier.
Java protects the integrity of memory at run-time by array bounds checking. C++ allows you to declare an array of ten items, then write to the eleventh item, even though that tramples on memory. In Java, arrays are full-fledged objects, and array bounds are checked each time an array is used. If you create an array of ten items in Java and try to write to the eleventh, Java will throw an exception
Java ensures program robustness by checking object references, each time they are used, to make sure they are not null. In Java, using null reference results in an exception being thrown but in C++, using a null pointer usually results in a program crash.
The productivity boost you can get just by using the Java language results in quicker development cycles and lower development costs. You can realize further cost savings if you take advantage of the platform independence of Java programs. Java can make support for multiple platforms easier, and therefore, cheaper.
However, the productivity, quick development cycles, and lower development costs come with tradeoffs. Java is designed as architecture that favors network-oriented features[such as platform-independence], program robustness, security, and network mobility. The primary tradeoff is execution speed.
Java's extra run-time housekeeping[array bounds checking, type-safe reference casting, checking for null references, and garbage-collection] will cause your Java program to be slower than an equivalent C++ program. Yet the tradeoff in speed is made up for in productivity increases enjoyed by the developer and robustness enjoyed by the end-user.
C++ programs are usually compiled to native machine code, which is stored in an executable file, Java programs are usually compiled to Java bytecodes, which are stored in class files. When the Java program runs, a virtual machine loads the class files and executes the bytecodes they contain. When running on a virtual machine that interprets bytecodes, a Java program may be 10 to 30 times slower than an equivalent C++ program compiled to native machine code. Fortunately, other techniques can improve the performance of bytecode execution. For example, just-in-time compiling can speed up program execution 7 to 10 times over interpreting.
Raw execution speed is not always the most important factor determining an end user's perception of a programís performance. In some situations, programs spend much of their time waiting for data to come across a network or waiting for the user to hit another key on the keyboard. In such cases, even executing the program via an interpreter may be adequate. For more demanding applications, a just-in-time compiler may be sufficient to satisfy the end user's need for speed.
For many programs, however, execution speed is extremely important. For such programs, if you want to use the Java language, you may have to execute part or all of your program natively. One way to do that is to identify time-critical portions of your program and implement them as native methods. This yields a program that is delivered as a combination of platform independent class files and platform-specific dynamic libraries. The bytecodes from the class files are executed by interpreting or just-in-time compiling, but the time-critical code stored in the dynamic libraries is executed natively.
One final alternative is to compile the Java program to a platform-specific, monolithic native executable, as is usually done with C++ programs. Such a strategy bypasses class files entirely and generates a platform-specific binary. So when you compile your Java program to a monolithic native executable, you give up binary platform independence in return for speed. In cases where platform independence is not important to you, or speed is more important, compiling to a native executable can give you both fast execution and the productivity benefits of the Java language.
One way to get the best of both the platform independence and speed execution worlds is by install-time compiling. In this scheme, you deliver platform-independent class files, which are compiled at install time to a platform-specific, native executable. The binary form that you deliver (Java class files) is platform independent, but the binary form that the end-user executes (native executable) is platform specific. Because the translation from class files to a native executable is done during installation on the end user's system, optimizations can be made for the user's particular system setup.
Java, therefore, gives you many options of program delivery and execution. Moreover, if you write your program in the Java language, you need not choose just one option. You can use several or all methods of program delivery and execution made possible by Java. You can deliver the same program to some users over a network, where they are executed via interpreting or just-in-time compiling. To other users, you can deliver class files that are install-time compiled. To still other users you can deliver a monolithic native executable.
Although program speed is a concern when you use Java, there are ways you can address it. By appropriate use of the various techniques for developing, delivering, and executing Java programs, you can often satisfy end-userís expectations for speed. As long as you are able to address the speed issue successfully, you can use the Java language and realize its benefits.
This comment has been removed by the author.
ReplyDeleteUsing a program language like Java, Python or anything for that matter, comes with its own bag of goodies and penalties. Java, .Net etc... are predominantly object-oriented langs and they propagate classical way of writing code. A prog lang should make a dev life easy and not difficult, and Java is exactly doing the opposite(IMO). To take an example, a simple webserver can be written in under 5 lines in Go/Node, ~7 lines in Python, ??? in Java.
ReplyDeleteComing to the story....
There's a saying "One size doesn't fit all", which means, pickup a tool which solves the problem :-)
Java runs relatively slow because of its heavy dependence on Heap. You can't fix JVM(no magic tricks too). Alternatively, you can try Erlang and others which is an avatar of JVM and compare runtimes/compiletimes etc... Btw, Erlang supports FuncProg using Elixir wrapper.
Now coming to FP...
FP concepts derive origins from Mathematics. Look it up in the web.(too much to explain)
Haskell, Elixir, OCaml etc... are built from ground-up for FP and I'd suggest any new entrant to first write code in any one of the above, not Java as it is time-consuming and hard to remember during initial stages.
You should get your hands dirty with little bit of Functional Programming too, as I did, where functions are the first class citizens and you them toss around everywhere in your code like how you sauté veggies on a pan.
There's a saying "One size doesn't fit all", which means, pickup a tool which solves the problem. Nice saying.. :)
ReplyDeleteHmmm :-)
Delete