Last Updated:

Eight myths about Java

The article will look at eight of the most common myths and misconceptions about Java.

Java is slow

It's a pretty old myth, but it was once really true. Initially, virtual machines on which Java bytecode was executed were imperfect, and besides, the Java language and the virtual machine were developed not for computers in their usual sense, but as a kind of universal environment for various devices, where the speed of programs was uncritical, and the amount of data was insignificant. The difference in the speed of execution of identical tasks between ordinary compiled code and interpreted Java code could reach hundreds of times.

But despite this, currently the speed of bytecode on modern virtual machines is inferior to the best compilers of machine code by only a few tens of percent, and in some cases even surpasses them! Can interpretation overtake a compiled program? Of course not.

The fact is that Java bytecode is no longer interpreted by a virtual machine, but is compiled and even optimized, and dynamically, based on the data collected by virtual machines about the progress of program execution.

According to the tests for the "rate of fire" Java is very good, but what about real applications? Unfortunately, things are not so good with custom applications. The reason for this is the slow operation of the graphic components of the system.

Java programmers know that the language has two standard features for working with the user interface - AWT and Swing. AWT is a platform-dependent implementation of a graphical user interface. The speed of most of its implementations is quite satisfactory, but the number of functions is very limited. As an alternative to AWT, the Swing library has been developed. It is entirely based on the capabilities of the language, has many functions and is platform-independent, but the speed of its work is low.

Java is difficult to program

The myth about the complexity of programming in Java is based mainly on the fact that the standard class library has a multi-level tree structure and includes a huge number of various objects and applied algorithms. But it is thanks to the standard classes that it is easier to create and maintain applications.

The Java programming language is completely object-oriented. In syntax, it is similar to C++. At the same time, redundant, error-prone C++ functionality (such as operator overloading or multiple inheritance) is discarded.

Instead of multiple inheritance, Java uses the much simpler concept of an "interface," i.e., a named convention for calling a set of functions. Java uses strong typing and will not allow incorrect passing of the parameter, in addition, it is much stricter than C++ refers to negligence in the source code and, for example, will not allow you to create a method with a knowingly unused part of the code. Also, Java will not compile a program with an uninitialized variable.

One of the main sources of problems in the development of programs is the incorrect use of dynamic memory, or rather, the incorrect release of previously occupied blocks. Java uses the concept of a "garbage collector". This means that the programmer does not need to worry about freeing up the occupied area of memory. The system itself will add it to free memory when it detects that there are no references from the program to this object.

Java uses the fashionable concept of "exceptions" to signal errors. An exception is a special event that signals an error in a program. Most programming languages (and APIs) pass the result of a function call ("bad" or "good") to the caller for error signaling. As a result, the code for analyzing the returned value is mixed with the code of normal program execution, this makes it difficult to read programs and modify them.

More importantly, however, exceptions not only improve the readability of the source code, but also prevent the calling function from ignoring the error. The programmer must either "catch" the exception or shift this responsibility to the calling function.

To this we can add that Java has "built-in" support for multitasking. When creating multithreaded applications, the developer usually has to use operating system tools (semaphores, mutexes) to synchronize tasks. Java offers a universal solution based on the constructs of the language itself.

Summarizing, we can say that in terms of the complexity of Programming, Java cannot be compared with C++ or Pascal. Advanced language capabilities, support for "garbage collection", a single standard class library, compiler control - all this greatly simplifies the creation of applications and speeds up their debugging.

Java works the same everywhere

"Write once — run anywhere" ("Write once — run anywhere"). The second part of this slogan of the creators of Java contains the statement that the Java program works the same everywhere. Unfortunately, the reality is not that simple. Java machines of different companies on different platforms are NOT one hundred percent compatible with each other.

Differences in the work of Java machines on different platforms exist both in the implementation of multitasking and in the work of the window library (AWT). Complex Java programs need to be "run" on different platforms to make sure that everything is in order. Generally speaking, even on the same platform, but on different machines, such programs can be executed in different ways.

For example, a programmer may encounter a situation where his code behaves differently on a multiprocessor machine than on a single-processor machine. Special mention should be made of the Java machine created by Microsoft (hereinafter referred to as MS JVM). It is called Java not quite legally (which was confirmed by a recent court decision).

In MS JVM, you won't see support for RMI or CORBA, but here you can use ActiveX objects, a technology that is specific only to the Windows platform and does not exist anywhere else. Microsoft has extended the standard Java class library with types that reflect some of the features of the Windows platform.

We must also not forget about the different speed of Java machines. This difference can lead to unacceptable delays in the program or other problems. The conclusion from the above is simple: when creating Java programs, you should test them on a wide range of platforms and not use non-standard language extensions.

Java is a programming language

There is an opinion that Java is only a kind of programming language. But that's just a fallacy. Yes, Java is also a programming language. This includes a whole range of other technologies.

Java is a platform, a modern software platform, by and large, seeking to replace all the functions of the operating system. Perhaps this will happen in the near future (although there have already been similar attempts, but have failed). The main feature of Java is platform independence, that is, the independence of software running on a virtual machine from hardware and the operating system.

It should be noted that there are several dozen different programming languages for the Java platform. Some of them can be compiled by the Java compiler itself, while others are able to work directly with the virtual machine.

Java is the younger sister of C++

Does the Java programming language really derive from C++? More likely no than yes. Sun's idea was to simplify the learning of Java by making its syntax similar to that used in the most common programming language. This was to eventually encourage and simplify the transition to Java for C programmers.

At the same time, Java incorporates ideas and mechanisms drawn from a number of other systems and programming languages. Take, for example, the control of access to the border of the massif (Pascal). Or the fact that the compilation of Java programs is separate, the classes are broken down into packages. This is one of the variants of modular programming (as, say, in Module-2), which differs from the concept of independent compilation of C++ files.

Some innovations were taken from languages and systems unknown to the general public.

For example, the principle of the class interface is transferred from the Objective C language developed by NeXT. The mechanism for handling exceptional situations is almost completely borrowed from Modula-3. The principles of internal implementation of such an important component of the Java language as "garbage collection" are drawn primarily from Lisp. Some "normal" languages, such as Eifel, Modula-3, Oberon, also initially had this mechanism.

Summarizing the above, we can conclude that Java has absorbed a large number of ideas and approaches from different programming systems, including the syntax of the C++ language.

The Java language is only suitable for applets and the Internet

Java is inextricably linked to applets. Indeed, applets are an integral part of both the language and the Java platform as a whole. In addition, their creation is a successful marketing step of Sun. Without applets, the world would not have learned about Java so quickly.

The idea of embedded applications in hypertext documents (HTML) is not so new. Many firms have tried to promote their technologies to this sector of the market, but currently Java has few competitors here. Today it is, perhaps, JavaScript, ActiveX and Flash technology. The last two, however, work only under Windows.

What attracts programmers to Java? A powerful security model, a single code for all platforms, ample opportunities for using ready-made libraries, ease of programming. In reality, things are not as rosy as we would like. The security model is certainly not bad, but its implementations made by different manufacturers differ. As a result, code that works fine under one browser does not work under another.

Well, if there is Java in browsers, what about applications that run without a browser, but under the control of a virtual machine directly in the operating system? Here the situation is similar, every modern OS already has some version of the JVM installed. And users are able to use it to execute their existing applications for the JVM, although most are not even aware of this possibility.

Do not forget about server applications, including access to databases and network applications. And this is the main area of application of Java technologies at this time. This classification includes not only middle-tier applications, but also the server applications themselves.

And if you add client applications or even applets here, you get a complete set for automation.

The Java platform is not just about applets. It is used everywhere, from the client to the server. And if you remember that Java is used not only on computers, but also in cell phones, household appliances and smart cards, it seems that it has already penetrated into all sectors of the market, where at least somehow it is possible to use programming.

Java is ideal, it needs no improvements

Java was created in 1994-1995, by which time information technology had received intensive development both due to the "personalization" of computers, and partly due to the spread of the Internet. The authors of Java tried to embody in it all the achievements of the information industry, but the ideal, as you know, is unattainable. Some things were left behind, including checking the conditions for the correctness of the program, "programming under the contract", templates, etc.

In C++, there is a condition checker called asset. This function checks some condition set by the programmer for "truth". If the condition is "false", asset stops the program and indicates that the valid operating conditions are violated, and the compiler drops calls to asset when creating the final version of the program. In Java, this is not possible. Of course, you can use condition checking and throwing exceptions based on them, but as a result, all these checks will fall into the executable code of the program.

There is a more powerful technology than asset. This is Design By Contract, a "contract programming" that makes it easier to create large applications that use previously generated code. Java does not support "contract programming" either.

Class templates in C++ are the ability to generate code "under" the user-specified class (in fact, Java developers quite consciously abandoned templates, believing that they are more problems than useful. – Editor's note). A collection of objects implemented using a template will be compiled each time for each type of object stored in that collection. A typical collection of objects in Java stores instances of the Object class, the ancestor of all Java classes.

A programmer, when retrieving objects from a collection, is forced to use type casting to take advantage of his "working" class. Such an application works fine until another programmer accidentally adds an instance of a completely different class to the collection. Then the error does not occur at compile time, but it occurs later, when you retrieve the instance and try to cast it to the wrong type.

Currently, Java continues to evolve. It is possible that in the near future we will see in it some of the opportunities mentioned above.

Java costs a lot of money

Is Java really expensive? It all depends on the complexity of the software being developed. For example, for a small application (one to three man-months), Java may cost nothing at all. Of course, this technology is not completely free. A qualified Java programmer costs money.

There is also a need for tools for designing applications, profiling Java programs and other tools used when creating large projects. But, generally speaking, the competition in the market for such software is quite high, and therefore, prices are decreasing. The choice is diverse, and the developer is not tied to a specific company.