Return to Course Content Home

Introduction to Java

Optional Reading

Learning the Java Language on the Java Tutorial Site. I provide this site as a source of (sometimes) required reading in later chapters, but it is an excellent online resource.

Java and the Web

There are many misconceptions about Java and Web Development. Mostly because people still don't understand just what Java really is.

Java is a programming language that was developed in 1999 by Sun Microsystems to provide a platform independent language that supported not only classic "C/C++" style programming, but also a complete windowing environment letting users build Graphical User Interfaced that would run on PCs, Macs and Unix platforms.

The original versions of Java were somewhat crude compared to today's versions, but one thing that was included from the start was the notion of supporting web pages through Applets.

It turns out, the evolution of Java didn't quite go the way Sun planned, and Applets are no longer a real player in the world of web programming. What did start to evolve was a different version of Java, Java EE or Java Enterprise Edition in addition to the Java SE or Standard Edition.

Java as a whole is a collection of libraries and Application Programming Interfaces (APIs) that provide certain functionality to the software developer. The Java SE is designed to support desktop applications that run like any other program on your computer. Applets really don't have anything to do with web servers as we know them today, they were originally designed to provide dynamic content, but the overhead of downloading the required graphic libraries was to great for the dial-up connections that most people had at the time, and they quickly lost favor with many web programmers.

Java EE was an effort by Sun to extend the core Java libraries to provide tools to web programmers that would allow them to write more powerful servers than simple static HTML web servers. The idea was to have code run on the server that would produce dynamic pages that reacted to the users interaction with the browser, rather than static HTML. It turns out that Oracle, now the owner of Java, has decided that it no longer wanted to own Java EE, so it gave it to Apache to run...but of course they didn't give the "Java EE" name, so Apache is calling it "Jakarta EE", which of course will confuse people later on...so Java EE is in a bit of a transition in 2018-2019.

So, getting back to Java and the web, here are some some useful truths and myths about Java.

False: Web browsers can run Java applets.

This used to be true. It turns out, Microsoft killed off good applet support long ago. Microsoft saw Java as a real threat to its monopoly on the desktop and stopped supporting Java back in JDK 1.1.4 (we are now on JDK 1.19+!). Now, most browsers have disabled the Java plugin as being too dangerous. In fact, as ofJava 9, the Applet API is officially deprecated.

Of course, one of the biggest things against Applets is that in the last few years, the evil people on the internet have really stepped up using Java vulnerabilites on web pages. Since neither Microsoft or Apple made it easy to update Java automatically, it is on the user to do so, and this often isn't done, which leaves vulnerabilities open. Current guidance tells people to disable Java in their browser, and only enable it when needed. Because of this, Applets really aren't a good option anymore.

One of the great benefits of Applets was the fact that the deployed code was easily maintained, because it only lived on the server. Sun now has a product called Java Web Start which shares this maintainability while still having many of the advantages of a host based application.

Basically, Applets are dead.

Truth: Java's network library is easy to use

This one is actually quite true, and newer version of Java have only made this easier.

Myth: Java is only for the web

No, Java is very network friendly, but there are many applications still based Java projects.

While the number of Java applications has dwindled compared to server usage, Java still has some very strong application areas, and due to its free availability and cross platform support, it is the most widely taught programming language in college environments.

Truth: Java is Safe

Granted, this is still a relative term. Microsoft was quick to try to educate people on how dangerous Java was when it first came out, but basically Java was designed from the first to be a safe language.

Truth: Java is cross platform

This is true in more ways than one. Yes, Java will run on PCs, Solaris, Macs and Linux computers, as long a a JVM (Java Virtual Machine) has been written for that platform. Sun currently supports the major operating systems. Other companies also have written JVMs that will run Java code. The Java code that you run is byte compiled into a format that can be moved around these Virtual Machines.

The above "classic" graphic shows how the Java development/running process work (try not to laugh at the depictions of the computers!)s. The Java developer writes the Java source code, which is then compiled to Java Bytecode. This bytecode can be run on any other platform with a JRE.

In the world of web programming, Java is cross platform in a different way. Vendors of web servers have a Java specification. The J2EE spec, that they can guarantee compatibility with. This means that if you write a web applications that runs on the BEA Weblogic Server, you should be able to move your application, without modification, to a Tomcat Server.

This combined with the operating system cross platform ability is very important to the web developer. It means that you are not locked into a single operating system or web server. If somebody comes out with a new improved web server, you can move your project if you keep to the J2EE spec. Try that with a .Net application!

Of course, there are still versioning issues. If you write an application and compile it under JDK 1.7.0 (now known as Java SE 7.0), and then try to run the bytecode on a computer that has an older JDK, the code may no longer run, because the older JVM may not support the features you used.

Myth: Java is slow

Well written Java code is now on par with compiles C++, and on servers where the Java Hot-Spot compilers work best, the code may sometimes be faster than C++.

In the early days of Java, the code was about 20% slower than C++, but Sun has focused much effort on making the running of Java more efficient.

Remember, anybody can write bad code that runs slow. Once you see a large application running quickly you realize that Java does not have to run slow.

Myth & Truth: Write Once Run Anywhere

Many Java applications really are write once, run anywhere. Many developers actually code on different platforms during the development process. Yes, it is true that there can be some minor variations in fonts/graphics, and different operating systems handle threads differently, but all-in-all Java does an excellent job in this area.

As mentioned before, the real trick with J2EE applications is to try to avoid using vendor specific extensions that lock you into using that vendor's J2EE implementation. The safest way to do this is to first keep with the standards, and then test on the other platforms to prevent any unwanted surprises.

Truth: Java features make programming easier

Well, this is a sort of Truth as well, technically. Java has several features that make programming easier and "safer".

C# (C Sharp) is comparable to Java in many ways, and I think was modeled after many of Java successes.

But, as much as people, and tools, would like to make it easy to make complex programs, there is not substitute for knowledge about your tools. Java's large amount of libraries with many tedious functions already implemented do make programming easier because you can focus on the larger picture at times, but even then, detailed knowledge of how your software environment works always makes for better programs.

Myth: Java is just for web servers

Nope, there are several large applications (Tomcat and Netbeans for example) that are written entirely in Java. Java applications have fallen out of favor because you can get tighter Windows integration with Windows-only code, but with the rise of Linux and Macs, Java applications may yet to make a comeback.

Truth: Java is powerful

Java has an incredible amount of functionality built into the core system, and even more included with the J2EE version

Myth: Java should be used for everything!

No, for as powerful as Java is, it is not the end-all programming language. There are many popular languages that may be more suitable for a particular project than Java. However, one of Java's strengths is that it does a pretty good job of covering all the bases, so you don't have to keep learning a new language for each project.

What is included in Java

The core technologies supported in Java (Java SE) are:

Standard Extensions to Java SE are as follows:

JDBC

JDBC is a set of libraries that provide a uniform interface to databases. Each database vendor provides a JDBC driver that is loaded by the programmer. This driver allows very efficient and direct access to the database.

You still have to provide the SQL statements to access the database, but the process of connecting, and sending/receiving the SQL statements is standardized. If you only use standard SQL statements, this allows you to change databases without having to change your code.

Everything returned by a SQL query will be in the form of a ResultSet. This is a table that contains data and Meta-data from the result of the query.

JavaBeans

JavaBeans let you package a Java object as a software component. This allows you to use this component in other visual tool environments by just dropping it it.

Swing

Swing is a standard GUI-control library packaged in Java SE. It is a mature, flexible environment that lets you develop applications that interact with the user. Swing includes things like buttons, tabbed panes, toolbars, tables, trees, etc... that allow you to build a rich user interface. Swing also supports several look and feels (Windows, Mac, Motif, Linux and more) that allow you to have your application look like the native operating system, or use the "Java Look and Feel" for a uniform look across all operating systems.

Java 2D

Standard graphics drawing library included in Java SE. This library allows you to draw arbitrary lines and shapes, draw text in arbitrary fonts, and draw patterns and images to the screen. The library supports mixing of shapes, and coordinate transformations (Affine transforms).

Java2D may be used in tandem with Swing to produce very customized user interface components.

JavaFX

Yeah, this sure didn't work out.  JavaFX is no longer bundled with JDK distributions, it is effectively an open source add-on.

Okay, even I have a hard time describing why this is needed. Somebody at Sun decided that Swing was too hard for mortal man, so they came up with an entirely new language (it is NOT Java), that lets you write graphics code, which in turn is turned by the compiler back into Swing, and then run on the JVM. JavaFX is no longer supported in the latest releases of the JDK.

Java 3D/Advanced Imaging

These are standard extensions to Java SE.

Java 3D is built on top of DirectX or OpenGL. Like many of Java's libraries, it provides a standard set of APIs to allow you to draw and manipulate 3D images to the screen.

World Wind is open-source software, developed by the National Aeronautics and Space Administration (NASA) that allows you to zoom from satellite altitude into any place on earth. Leveraging Landsat satellite imagery and Shuttle Radar Topography Mission (SRTM) data, World Wind lets you experience any part of earth's terrain in visually rich 3D form, just as if you were really there.

Mount St. Helens, viewed with NASAs World Wind software (Java3D)

The Advanced Imaging package allows programmers and users to manipulate large/complex images in a very efficient manner. Besides splitting images up into tiles, it supports custom CODECs that allow you to read in any image format, besides several built in formats.

Image Preview Tool built with Java Advanced Imaging extensions

 

Servlets and JavaServer Pages (JSP)

These very widely supported extensions to Java SE are included in Java EE. They are supported by basically every vendor except Microsoft, and used in web sites of Ebay, Travelocity, Walmart, NY Stock exchange, Sears, IRS, Army, Navy...well lets just say that it has become such a standard technology, that most sites use them.

The idea behind these two packages is to provide dynamic content to web pages. In the early days of the web, there was something called CGI, that was prone to many problems, both stability and security wise. Servlets were first introduced as an alternative to CGI because:

JSP came after servlets, as a more convenient and efficient way to combine servlets and HTML. In truth, JSP pages are turned into servlets on the server before they are used.

Enterprise JavaBeans (EJBs)

Enterprise JavaBeans were created to allow programmers to build standardized objects that could be re-used between web servers. The idea was to provide standard access to services like load balancing, persistence, failover and naming services.

EJBs allow you to develop very complex web applications. As vendors build web servers that support EJBs, it allows you to once again access complex functionality in a standard way. Your code can be moved from on vendors web server to the next without recoding.

Web servers such as BEA Weblogic, IBM WebSphere, SunOne Application Server, and more support EJBs.

EJBs have had an ongoing evolution. Their complexity has often outweighed their usefulness, and even Java is supporting less complex, more flexible versions of EJBs.

Java Versions (ugh)

As I mentioned in the Syllabus, Oracle is going down the questionable path of "rapid" releases, so instead of the nice steady Java version with the incrementing "update" values, we'll see new "versions" every 6 months, with many of them being short term releases that aren't meant to be used for any amount of time (Java 9 and everything after fall into this group).

The following is from release notes for Java 9 I had never read such a good explanation of the numbering scheme before, so I included it for your enjoyment!

Which release contains all of the most recent security fixes: JDK 7 Update 55, or JDK 7 Update 60?

It looks like JDK 7 Update 60 is five releases later than Update 55, so therefore it must include more security fixes, right?

That conclusion is, sadly, incorrect: These two releases both contain exactly the same security fixes. To understand this answer, you first need to understand the current numbering scheme for JDK Update releases. Minor releases containing changes beyond security fixes are multiples of 20. Security releases based on the previous minor release are odd numbers incremented by five, or by six if necessary in order to keep the update number odd. To understand whether a minor release is actually more secure than an earlier release ultimately requires looking at the release notes or the source code.

What's the difference between releases named "JDK 7 Update 60", "1.7.0_60", and "JDK 7u60"?

These are just different names for the same release. These differences make it difficult to identify and verify equivalent releases. A simple pointwise comparison of sequences of parsed tokens does not suffice; instead, a fairly sophisticated algorithm is needed. The use of the lower-case 'u' is not an industry standard and is not language-neutral.

It's long past time for a simpler, more intuitive versioning scheme.

Description
Version numbers

A version number, $VNUM, is a non-empty sequence of non-negative integer numerals, without leading or trailing zeroes, separated by period characters (U+002E); i.e., it matches the regular expression ^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$. The sequence may be of arbitrary length but the first three elements are assigned specific meanings, as follows:

$MAJOR.$MINOR.$SECURITY

$MAJOR --- The major version number, incremented for a major release that contains significant new features as specified in a new edition of the Java SE Platform Specification, e.g., JSR 337 for Java SE 8. Features may be removed in a major release, given advance notice at least one major release ahead of time, and incompatible changes may be made when justified. The $MAJOR version number of JDK 8 was 8; the $MAJOR version number of JDK 9 will be 9.

$MINOR --- The minor version number, incremented for a minor update release that may contain compatible bug fixes, revisions to standard APIs mandated by a Maintenance Release of the relevant Platform Specification, and implementation features outside the scope of that Specification such as new JDK-specific APIs, additional service providers, new garbage collectors, and ports to new hardware architectures. $MINOR is reset to zero when $MAJOR is incremented.

$SECURITY --- The security level, incremented for a security-update release that contains critical fixes including those necessary to improve security. $SECURITY is reset to zero only when $MAJOR is incremented. A higher value of $SECURITY for a given $MAJOR value, therefore, always indicates a more secure release, regardless of the value of $MINOR.

The fourth and later elements of a version number are free for use by downstream consumers of the JDK code base. Such a consumer may, e.g., use the fourth element to identify patch releases which contain a small number of critical non-security fixes in addition to the security fixes in the corresponding security release.

The version number does not include trailing zero elements; i.e., $SECURITY is omitted if it has the value zero, and $MINOR is omitted if both $MINOR and $SECURITY have the value zero.

The sequence of numerals in a version number is compared to another such sequence in numerical, pointwise fashion; e.g., 9.9.1 is less than 9.10.0. If one sequence is shorter than another then the missing elements of the shorter sequence are considered to be zero; e.g., 9.1.2 is equal to 9.1.2.0 but less than 9.1.2.1.
Version strings

A version string $VSTR consists of a version number $VNUM, as described above, optionally followed by pre-release and build information, in the format

$VNUM(-$PRE)?(\+$BUILD)?(-$OPT)?

where:

$PRE, matching ([a-zA-Z0-9]+) --- A pre-release identifier. Typically ea, for an early-access release that's under active development and potentially unstable, or internal, for an internal developer build.

When comparing two version strings, a string with a pre-release identifier is always less than one with an equal $VNUM but no such identifier. Pre-release identifiers are compared numerically when they consist only of digits, and lexicographically otherwise. Numeric identifiers have lower precedence than non-numeric identifiers.

$BUILD, matching (0|[1-9][0-9]*) --- The build number, incremented for each promoted build. $BUILD is reset to one when any portion of $VNUM is incremented.

When comparing two version strings with equal $VNUM and $PRE components, a string without a $BUILD component is always less than one with a $BUILD component; otherwise, $BUILD numbers are compared numerically.

$OPT, matching ([-a-zA-Z0-9\.]+) --- Additional build information, if desired. In the case of an internal build this will often contain the date and time of the build.

When comparing two version strings the value of $OPT, if present, is always ignored.

A short version string ($SVSTR), often useful in less formal contexts, is simply $VNUM optionally ended with -$PRE.

The following table compares potential version strings for JDK 9, using the existing and proposed formats:

 

  Existing Proposed
Release Type long short long short

Early Access

 1.9.0-ea-b19 9-ea 9-ea+19 9-ea
Major 1.9.0-b100 9 9+100 9
Security #1 1.9.0_5-b20 9u5 9.0.1+20 9.0.1
Security #2 1.9.0_11-b12 9u11 9.0.2+12 9.0.2
Minor #1 1.9.0_20-b62 9u20 9.1.2+62 9.1.2
Security #3 1.9.0_25-b15 9u25 9.1.3+15 9.1.3
Security #4 1.9.0_31-b08 9u31 9.1.4+8 9.1.4
Minor #2 1.9.0_50-b45 9u40 9.2.4+45 9.2.4


This proposal drops the initial 1 element from JDK version numbers. That is, it suggests that the first release of JDK 9 will have the version number 9.0.0 rather than 1.9.0.0.

After nearly twenty years it's clear that the second element of the current version-number scheme is the JDK's de facto $MAJOR version number. We increment that element when we add significant new features, and also when we make incompatible changes.

We could start treating the initial element of the current scheme as the $MAJOR version number, but then JDK 9 would have the version number 2.0.0 even though everyone already refers to it as "JDK 9". This would help no one.

If we retain the initial 1 then JDK version numbers will continue to violate the principles of Semantic Versioning and developers new to Java will continue to be confused about the difference between, e.g., 1.9 and 9.

There is some risk in dropping the initial 1. There are many ways to compare version numbers; some will work correctly, while some will not.

Existing code that compares version numbers by parsing their elements and comparing them numerically will continue to work, since nine is greater than one; i.e., 9.0.0 will be considered to be later than 1.8.0.

Existing code that skips the initial element when it has the value 1 will also continue to work, since in the new scheme the initial element will never have that value.

Existing code that assumes the initial element to have the value 1, however, and therefore always skips to the second element when comparing version numbers, will not work correctly; e.g., such code will consider 9.0.1 to precede 1.8.0.

Anecdotal evidence suggests that existing code in the third category is not very common, but we would welcome data to the contrary.

 

An important note For Apple Users:

The following was found on a Mac Forum that has important implications for Netbeans on a Mac.

Issue:

I am experiencing issues with the new MBP Retina 15 Inch Mid 2015 model with Force Touch.

Even I do have the same issue. Before Macos Siera update all worked fine. After OS update 'm unable to run my java applications with netbeans. If I start run any project in netbeans after some time tomcat server does not start and shows tomcat port XXXX is already in use and failed to start.

As well as the fan sound to noisy and macbook pro gets hot on backside. If I stops netbeans the fan sound stops and macbook gets cool within few minutes.

After closing the netbeans tomcat server does not stop. If you put localhost:XXXX on browser it shows tomcat installation success page.

Solution:

I've found this solution which was blocking my development system and caused fan sound,fast battery drainage and heated the macbook.

Reasons: In mac OS SIerra ,the new update blocks the sites which uses system proxy settings, where localhost,127.0.0.1 all connections are blocked.

Solution:

Step 1:  Go to system preference >Network>Select your wifi connection>Advanced>select proxies tab.

There check 3 options 1) Auto proxy Discovery 2)Automatic Proxy configuration 3) web proxy(http)

Step 2: Go to Netbeans>preferences>General> select use system proxy> reload> test connection

You may get connection successful.

If connection gets successful, Now Clean & build your Applications in netbeans and press run .

Hope it will work . In my case it works