CHAPTER 2
How JAVA is Being Used Today
As of 2016, JAVA is now being utilized by over 9 million software developers around the globe and is also one of the most utilized programming languages available especially for client-server applications. Regardless of a computer’s architecture, the applications of JAVA are able to be compiled into code which runs on all JVMs. JAVA used to be identified mainly with slow performance, with having to wait for Sun Microsystems to drop upgrades, with bytecode interpretation, and with the use of Applets. Today however, JAVA has become more associated with reliably high performance, with dynamic compilation of hotspots, with a more and more independent open source community, and with service oriented architecture, or SOAs, with web services, and with web applications. This chapter will go into depth on the uses of the JVM, the JAVA programming language, as well as JAVA platforms.
Using JAVA Programming Language
The JAVA programming language operates on a high level and was inspired by Smalltalk, and by both C and C++ programming. The JAVA programming language has also borrowed a few ideas from other languages. The syntactic design of JAVA programming language was made to be familiar to those already versed in "curly brace", C-descended languages, but has stronger (at times arguably) OO principles than the principles used in C++. Also, garbage collection is fairly automatic, which does away with the need of the developer to have to free up memory used by objects that have become obsolete and are no
longer in use.
JAVA is philosophically referred to as a "fail early" language. Since it has syntax restrictions, most programming failures are just not actually possible with Java at all. Because of the fact that JAVA does not have access to pointers directly, errors specific to its arithmetic simply just do not exist. Utilizing a certain object as a type other than what it originally was named as requires a straightforward cast conversion, which allows the code compiler the obvious chance to deny programming that may be illogical and therefor unable to be used.
A varied number of Java enterprise frameworks make it necessary to use the deployment descriptors or configuration files, which are usually written in XML in order to identify a function. This could include the order of the steps that are needed to execute within a rule engine or which class may handle a particular request in HTTP. In other words, they must go beyond the language at hand in order to implement their function properly. JAVA 5.0 adds footnotes to this language, and this allows for classes, fields, and methods to be tagged with values that are then able to be developed and inspected at the time they are run, and most often via reflection. A lot of software programmers prefer these footnotes, usually referred to as annotations, because they are able to simplify the things that may be otherwise called out by certain descriptors or other ways. They are also able to make it difficult to interpret the Java code, though. Whether or not a footnote or annotation is in place may actually affect the execution of the code and also may affect it in ways that may not be completely obvious from the footnote or annotation itself.
Aside from this one singular criticism, JAVA is mainly regarded as the most popular general-purpose computer programming language utilized in the world at the present. The benefits of JAVA programming language are extremely vast. The main benefits include but certainly are not limited to:
The benefit of a vastly immense knowledge base.
The benefit of a vastly enormous amount of software developers who are always readily available.
The benefit of free tools which are widely available on numerous platforms such as Windows, Solaris, Linux and Mac. All of these platforms are able to execute and compile all Java applications.
The JAVA programming language itself hits a unique and valuable point in the quid pro quo between code performance and software developer efficiency. While CPU (central processing unit) cycles continue to steadily reduce in cost factor, software developers, however, usually do not continue to reduce in cost.
If anything, the cost of software developers continues to rise for many reasons, among them being rising inflation and an increase of technical education costs. Because of this fact it may inevitably lead to the acceptance of yet an additional piece of abstraction inbetween the CPU opcodes being executed and the software developers themselves – as long as it allows for the software developers to be able to create a higher quality software and at a much more efficient rate.
Explanation of the use of JAVA platforms
JAVA is regarded generally in terms of three different platforms. These three platforms were briefly regarded previously in this book. Note that the JAVA FX Edition is not included here.
1. The Enterprise Edition, also known as JAVA EE
2. The Standard Edition, also known as JAVA SE
1. And
2. The Micro Edition, also known as JAVA ME
Each of these different platforms utilizes a combo of a specific group of libraries, virtual machine, and a language version that is used to execute its code. The EE version contains everything that the SE version does and more, so that means that any EE application can access and utilize the entirety of the SE libraries. Also, the EE's use of the programming language is identical to that of the SE's as well. This means that the SE version is a subset of the EE version.
JAVA Micro Edition, or ME, is significantly different than its counterparts because of the fact that a small device (such as a smart phone) are just simply that much more limited on space and capabilities as well. The Micro Edition is not able to be considered as a subset of the Standard Edition (therefore, cannot be considered a subset of the EE), because of the fact that a number of its libraries only exist in the Micro Edition. In addition, the Micro Edition version completely eliminates some of the programming language features because of the computation limitations of the platform on which it is run. Examples of some such eliminated features include Float class and the float primitive. This means that Micro Edition requires a slightly different set of tools than the Enterprise Edition version and the Standard Edition version. With such deep seated differences in the devices, it makes the complete portability of code much less realistic in the micro space. In fact, a lot of Java developers view ME as a completely different animal altogether, almost a separate entity even.
What to expect when using the JAVA Virtual Machine (JVM)
JAVA source code has to translate into executable platform native code at
some point along the way. Typically, doing so requires the use of a two-step process:
1. The software developer needs to compile the source code to JAVA
code.
2. The JVM then has to translate that information, for the platform in use, into that platform’s native code.
The second step was originally executed by interpretation, or by taking each single JAVA Virtual Machine (JVM) instruction and converting that instruction in an instant to one or more instructions native to the platform. Then after that is accomplished, the just in time compilers, referred to by software developers as JIT compilers, convert the program from bytecode on the JVM into code native to that particular platform as the program is run. There are several ways to achieve this conversion at this present time. Sun Microsystem's HotSpot compiler initializes this process by translating the code and then profiling it at runtime, optimizing and compiling the particular areas that have been concluded to be the first priority in order for that program to continue to work efficiently. IBM’s "mixed mode interpreter" of its JVMs operates in a very similar fashion. These procedures circumvent the startup performance lag entailed by utilizing JIT compilers on the whole program, but then this also means that performance is accumulated, arriving consistently over a period of time, when crucial sections of code are detected and made to work more efficiently. Because of this procedure, client applications are far less benefitted by this approach than the long-running server processes.
What to expect when using JAVA without using the JAVA Virtual Machine
It is entirely possible to run JAVA without the use of a JAVA Virtual Machine. Since JAVA source ends up becoming bytecode, then which in turn becomes platform-native code, as it stands, this can actually be accomplished all at one time. The GNU (GNU recursively refers to the term “GNU’s Not Unix”) Compiler for JAVA, also referred to as GCJ, allows for an up front, one-time, compendium of JAVA code to a command that is able to be executed on a singular platform. Though there is enough information to compile command line and server side applications when using this process, it is not actually able to allow for the support of the Abstract Windowing Toolkit (AWT), which would
obviously render it unsuitable for AWT programming and also Swing GUI
programming as well.
This obvious downside to using this process is that cross platform code ends up becoming bound to only one platform and only in one single step. What is more, that static type of compilation does not automatically negate the workings of the HotSpot's dynamic compilation. The author of said compilation did work on a piece of research in which the GCJ performance gain was concluded as being fewer than a mere 5% above the performance gain of the HotSpot version. Even still, GCJ does have the performance gain advantage and has the ability to solve crucial problems, such as the ability to succinctly deploy a particular Java application that is completely able to be ran regardless of which version the JVM is running and whether or not it’s even available.
What to expect when using the JAVA Virtual Machine without JAVA
It is also absolutely possible to get straight to the JVM level immediately and successfully bypass the JAVA language entirely. C-to-JVM bytecode compilers are already in existence; compilers like the Axiomatic Multi-Platform C, which is commercial and supplies a partial version of ANSI C. What is more, the progress of the manipulation of JAVA bytecode allows for the creation of classes at runtime that are completely executable in Java applications. This means that what you will be working with will no longer be JAVA, but instead will be an effective form of programming language used for assembly in the JAVA Virtual Machine.
Explanation of the JAVA Community Process
There is a JAVA community that exists beyond virtual machines, beyond libraries, and beyond programming language. In spite of the overwhelming amounts of software that is considered to be open source and utilized by and written in the JAVA programming language, there is a continuously obvious and open conflict at large between the open source community and the JAVA community.
The JAVA Community Process, sometimes referred to by software developers as simply the JCP, was established in 1998. The JCP is the formalized mechanism by which any interested parties may be allowed to offer input in the development of standard technical specs of the JAVA technology. It is open to the public and anyone may become a member of the JAVA Community Process by simply submitting the appropriate form available at their website.
A hugely varied number of JAVA aspects exist entirely without the JCP’s standardized acceptations. A lot of independent projects have gained in size enough to actually compete with the actual JCP benchmarks in the level of awareness in the minds of JCP consumers. As a whole though, these independent projects have also been able to be quick in adapting to modifications completely without the use of JAVA and also simultaneously utilize the best features of those modifications, as in the feature AJAX, which is a feature that simplifies code. This is a Direct Web Remoting, or DWR project or the Rails-inspired Trails project.
Post a Comment