Java

From Juneday education
Jump to: navigation, search

Our books on Java

We have two books on Java on this wiki. Programming with Java which is an introductory book on programming with the Java programming language and technology. We also have a book (which is work in progress!), More programming with Java which addresses some more advanced topics on programming with Java such as design patterns. Another book on this wiki related to Java technology is Android (also work in progress).

About Java

Java is both a programming language and a software platform. When we're writing (or developing) Java programs we usually do that in the Java programming language and use Java tools. When we run our programs written in the Java programming language we use the Java software platform.

The Java platform is a suite of programs that facilitate developing and running programs written in the Java programming language. A Java platform will include an execution engine (called a virtual machine), a compiler and a set of libraries; there may also be additional servers and alternative libraries that depend on the requirements. - Java Software Platform

Install Java

Download page for jdk8

Download page for jdk7

Installing in GNU/Linux

Debian, Ubuntu

Install Java jdk:

sudo apt-get install default-jdk

Or if you want to go for a specific Java version, you do any (or both) of the following:

sudo apt-get install openjdk-7-jdk
sudo apt-get install openjdk-8-jdk

Fedora

sudo dnf install java-1.8.0-openjdk

Installing in Windows

On the download page click on Windows x64 link and follow the instructions. For your convenience we have prepared a video on how to install Java SE JDK 8 on Windows 10.

Installing in MacOS

On the download page click on Mac OS X link and follow the instructions.

Java Virtual Machine

The heart of the Java platform is the concept of a "virtual machine" that executes Java bytecode programs. This bytecode is the same no matter what hardware or operating system the program is running under. There is a JIT (Just In Time) compiler within the Java Virtual Machine, or JVM. The JIT compiler translates the Java bytecode into native processor instructions at run-time and caches the native code in memory during execution. - Wikipedia on Java

Java source code

A textfile with source code written in the Programming Language. The encoding of the file can be Unicode (so Unicode characters can be used where legal).

Java bytecode

Java bytecode is the instruction set of the Java virtual machine. Each bytecode is composed of one, or in some cases two bytes that represent the instruction (opcode), along with zero or more bytes for passing parameters. - Java_bytecode. The bytecode is created by the compiler javac and put in a binary file with the suffix .class .

Java tools

java

java is a program that can execute (run) programs written in Java. java actually executes classes as found in so called class files (see bytecode above). The argument to java can be the qualified name of a compiled class which contains the special "main method". The java command starts the virtual machine (JVM) which will read the corresponding class file and execute the instructions of the bytecode in the file.

Example use

If you want to execute the class Hello, as found in the file Hello.java, in the package org.exampleproject:

$ java org.exampleproject.Hello

Note, that the Hello class must define a special "main" method in order to be possible for the JVM to execute.

javac (the compiler)

javac is a compiler that reads Java source code and transforms that into Java byte code (which it stores in a binary file with the .class suffix).

Example use

Simple case of compiling one file

If you want to compile the file Hello.java in the package org.exampleproject

$ javac org/exampleproject/Hello.java

If you want to compile the file Hello.java in the package org.exampleproject and put the class files in a separate directory called bin:

$ javac -d bin org/exampleproject/Hello.java
Compiling a class which imports other classes

Sometimes you need to give javac a classpath.

Let's say we have this directory structure:

.
|-- bin
`-- src
    `-- org
        `-- exampleproject
            |-- domain
            |   `-- DomainOjbect.java
            |-- main
            |   `-- Hello.java
            `-- util
                `-- HelperClass.java

The packages are called

  • org.exampleproject.domain
  • org.exampleproject.main
  • org.exampleproject.util

If we want to remain in the . directory, above both src and bin, and compile Hello.java and get the class files in a structure under the bin directory, we'd do this:

javac -d bin src/org/exampleproject/main/Hello.java

The argument to javac is a flag for where to put the class file(s) -d bin and the most important argument src/org/exampleproject/main/Hello.java which is the text file we want to compile.

But, if Hello.java imports for instance org.exampleproject.util.HelperClass, how can javac find the corresponding source code file for that class?

Remember, we are standing in a directory above src. The compiler javac will look for the class org.exampleproject.util.HelperClass in the current directory, beginning with looking for the org directory. But the only directories here are src and bin!

So the compiler will complain about not finding the package org.exampleproject.util when we try to compile the file src/org/exampleproject/main/Hello.java (because the Hello class imports org.exampleproject.util.HelperClass).

At first, you might think this is strange. But think about it! How could the compiler find src/org/exampleproject/main/Hello.java? That was simple! We gave the compiler the full relative path to the source code file, from our current directory. It didn't matter that src is not part of the package name for the package of Hello. The compiler javac wants as argument the relative (or absolute) path to the file we want to compile.

So that it could find the Hello.java, wasn't so strange, since we gave the full path to the file (relative to our current directory). But the compiler discovered that the Hello class imported org.exampleproject.util.HelperClass. So the compiler must check if it needs to compile also that class. But the only clue as to where to find the source code file for HelperClass comes from the package name org.exampleproject.util. Now, the compiler knows that a package corresponds to a path. So it starts looking for the org directory. But our current directory only contains the directories src and bin. That's why it complains that it can't find the package!

So if we are in a directory which is not immediately above the top package directory (in our case org), and the class we're trying to compile imports classes from another package, we must help the compiler to find the top-level package directory (again, in our case src).

This can be accomplished using another flag to javac, namely the -cp (for "class path") flag:

$ javac -d bin -cp src src/org/exampleproject/main/Hello.java

Think about that command as meaning the following: Dear javac, put the class files under the bin/ directory (-d bin), and look for packages in the src/ directory (-cp src) when you compile the textfile with source code in src/org/exampleproject/main/Hello.java.

Note that when compiling a class in a package and directing the class files to e.g. bin/ then javac will create the directories corresponding to the packages of the compiled classes. So if we compile Hello.java which is a class which imports org.exampleproject.util.HelperClass, we'll get the following directory structure as a result (note the new directories under bin/):

.
|-- bin
|   `-- org
|       `-- exampleproject
|           |-- main
|           |   `-- Hello.class
|           `-- util
|               `-- HelperClass.class
`-- src
    `-- org
        `-- exampleproject
            |-- domain
            |   `-- DomainOjbect.java
            |-- main
            |   `-- Hello.java
            `-- util
                `-- HelperClass.java

The DomainObject.java source code wasn't compiled, since neither Hello, nor HelperClass imported it.

External Links on compiling Java source code

javadoc

Javadoc is a tool that parses the declarations and documentation comments in a set of source files and produces a set of HTML pages describing the classes, interfaces, constructors, methods, and fields.

External links about javadoc

jar

A program that combines files into one file in the Wikipedia: JAR file. This program can be used to combine class files (with Java byte code) into one single file.

Example use

If you want to pack class files in the bin directory:

$ jar cf exampleproject.jar org/exampleproject

External links about jar

javah

javah produces C header files and C source files from a Java class. These files provide the connective glue that allow your Java and C code to interact.

External links about javah

jdb

The Java Debugger, jdb, is a simple command-line debugger for Java classes. It is a demonstration of the Java Platform Debugger Architecture that provides inspection and debugging of a local or remote Java Virtual Machine.

External links about jdb

javap

The javap command disassembles one or more class files. Its output depends on the options used. If no options are used, javap prints out the package, protected, and public fields and methods of the classes passed to it. javap prints its output to stdout.

External links on javap

Generics

Generics are a facility of generic programming that were added to the Java programming language in 2004 within the official version J2SE 5.0. They were designed to extend Java's type system to allow “a type or method to operate on objects of various types while providing compile-time type safety.”[1] This was not achieved though, since it was shown in 2016 that compile-time safety is not guaranteed.[2] The Java collections framework supports generics to specify the type of objects stored in a collection instance. Generics in Java