Wednesday, 16 November 2016

Should I use c++ for my project, or should I use Java ?

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.

Is Java platform independent ?

Java was designed for networks. Rapidly increasing Network presents new challenges. One challenge presented by networked computing environment is the wide range of devices that the network interconnects. A typical network has different kinds of devices with diverse hardware architecture, Operating Systems and purpose. Java architecture addresses this challenge by creating platform independent programs.
Java architecture has four distinct but interrelated technologies:
  1. Java Programming language
  2. Java class file format
  3. Java Application Programming Interface [API]
  4. Java Virtual Machine [JVM]
When you write Java program, you are tapping the power of these four technologies. you write the program in the source file, compile to Java class file, and run the class file containing bytecode on JVM. You access system resources in your program by calling methods in the classes that implements Java API methods.
JVM and Java API forms a platform. Java programs can run on many different kinds of computers because the Java Platform can itself be implemented in software.
When you compile java program on one Operating System the java compiler generates bytecode. You can run that bytecode on any Operating System which has its own implementation of JVM. JVM interprets bytecode and generates native code for the corresponding Operating System. Because of bytecode and JVM, Java is called platform independent [Write once, run anywhere]. But there are few exceptions.
Java is mostly platform independent because of below exceptions:
  • If you are relying on libraries that make calls to OS functions: you can either code and compile for each platform or write in OS detection & conditional function calls. For more details click here.
  • Java Native Interface [JNI]: JNI is used in case standard java class library may not support platform-dependent feature needed by your application. You already have library or application written in other language and you wish to make it accessible to the java application, then JNI can be used. In a way, you're losing platform portability when using JNI. We will discuss more on JNI in the next post.
  • If you are using GUI frameworks, components are displayed according to the view of Operating System.
  • You are coding/compiling for a JVM that is not widely supported.
  • Your code has higher/more/different hardware requirements than your target platforms support (e.g. relying on a specific input mechanism; or coding software meant to run on a smart TV or refrigerator [yes, some fridges run Java now] that needs 1G of memory, 2 cores & an always-on internet connection).
Despite all these exceptions, Cross-platform incompatibility should not cause you to completely rewrite code.