Java software engineering – reference resources

Official Java and JEE

Java Technology Reference

Java Standard Edition (JSE)

Java Enterprise Edition (JEE)

The official Java tutorials

The official JEE 7 tutorial

JEE 7 Technologies index

Java language spec and JVM spec

Java community

Oracle Java community

OpenJDK

Java Community Process (JCP)

Apache Commons

Apache.org Java projects

JBoss.org

Spring

Google Guava

Trending Java projects on github

JEE and Java web servers

Apache Tomcat

JBoss Wildfly

Glassfish

Build and test automation

Sonatype Maven books

Jenkins documentation (wiki)

JUnit reference documentation

Source and version control

The SVN reference book

Git reference documentation

Java IDEs

Intellij IDEA documentation

Eclipse documentation

Netbeans knowledge base

Vim configuration for Java coding

Java remote debugging JVM options

Java 5, 6, 7 and newer

The Java™ Platform Debugger Architecture (JPDA) supports certain JVM invocation options.

Usually this boils down to:

-agentlib:jdwp=transport=dt_socket,server=y,suspend=y

This will cause your JVM process to execute but wait (suspend=y) and listen for a socket connection from a remote debugging client on a free port (which it will write to stdout. The suspend=y option is especially useful if you need to debug code that runs during the start-up phase of your application.

If you don’t want the process to do the initial waiting, then use suspend=n.

Java 1.4

If you are for some terrible reason stuck on Java 1.4, then you must use the older approach like this:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n

Tomcat

To enabled remote debugging for a Apache Tomcat on Windows, create bin\setenv.bat in your Tomcat installation, with this content:

set "CATALINA_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n"

Network port

If you use the settings above, i.e. server=y and no “address” option, JPDA will pick a free port and write a message about this to stdout. Look for something like this:

Listening for transport dt_socket at address: [PORT]

Intellij configuration

Add a debug configuration via Run menu:

“Why do I have to pay for Redhat if it is ‘Free Software’?”

Unfortunately but quite naturally, there are many many people who are surprised when they first learn that “Free Software” is not necessarily available as a free-of-charge download in immediately usable (i.e. compiled binary) form.

“Free” is an ambiguous word in the English language: Free like “free beer” (= gratis, free of charge) versus free like “Free Speech” (= libre, based on guaranteed freedoms, liberties).

This ambiguity is an old problem of the term “Free Software” – first coined by the “Free Software Foundation” (FSF) in the 1980s – and was actually one factor that motivated the foundation of the “Open Source Initiative” (OSI) and its official definition of “Open Source”.

Both definitions use the same criteria and are essentially different names for the same category of software. To acknowledge and peacefully combine both of these naming conventions some people also speak of “Free/Libre Open Source Software” (FLOSS).

The Redhat Linux distribution is Free/Libre Open Source Software. The source code is licensed under the GPL and similar Open Source licenses and can be downloaded from Redhat’s ftp server. The binaries are not available as gratis download, which is perfectly in line with FLOSS rules.

For almost every IT professional these days, it is very beneficial to understand what “Free/Libre Open Source Software” (FLOSS) is. It might seem like a complex and dry subject at first, especially when some business folks confuse things further by using the vague term “Intellectual Property” for everything from copyright, trademarks, patents to license agreements, etc.

My first ~/.vimrc

I recently progressed from “the little vim-avoider who would if he only could” level to someone who actually edits his ~/.vimrc sometimes. So now I don’t want to forget the little I have learned and post it here:

" pointless reminder how i fixed vim issues on cygwin 
" existence of ~/.vimrc already triggers nocompatible mode
set nocompatible

" highlight all search pattern matches
set hlsearch

" i use light or even white background, vim to use readable colors
set bg=light

" use syntax highlighting
syntax on

Minimal Debian Wheezy netinstall – no network after reboot

I just installed Debian Wheezy on a Toshiba laptop using the netinstall CD.

During installation everything worked fine, ethernet and wireless interfaces were both detected and functional. I actually did the installation using the wireless connection. On the “Task selection” screen I only selected “Laptop” and “Standard system utilities”.

However, after the reboot at the end of the installation, I had no network anymore. Here is what I did to fix it:

Edit /etc/network/interfaces and add this block:

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

Then run as root:

/etc/init.d/networking start

If the machine is connected via ethernet cable to a router, you should see messages about your network being configured via DHCP, i.e. receiving its local IP address.

If you get error messages, then you might have to install firmware for your network card:

On another computer, download firmware.tar.gz and save it to a USB stick.

Then do the following as root on the new Debian system:

Plug in the USB stick and mount it. You might have to run “dmesg” to see which device file to mount. In my case it was /dev/sdb

mount /dev/sdb /mnt

Unzip the firmware tarball:

cd /mnt
tar xvzf firmware.tar.gz

Install the core firmware packages:

dpkg -i firmware-linux-*.deb

Install additional firmware packages as necessary. Use the output of the lspci command to identify your network cards. Consult the “Firmware” Debian wiki page to find out what package you have to install.

If you are done installing firmware, restart the system:

shutdown -r now

Hopefully you will have a network connection after the reboot.

Open Source / Free Software : Beware the Black Duck

I usually refer to the OSI list of popular Open Source licenses when someone asks me which FLOSS licenses are relevant and recommendable.

Recently someone pointed out the Black Duck list of popular licenses as a “more recent” reference list.

After some reviewing, I would strongly recommend against that Black Duck list, for several reasons:

Lack of neutrality

Open Source Initiative (OSI) is the foundation that first officially defined the term “Open Source”, as a non-profit, vendor neutral organization, free from any commercial goals.

Black Duck Software is a venture-capital-funded, for-profit entity with strong ties to certain big software vendors.

Irrelevant licenses

The licenses that Black Duck added relative to the OSI popular licenses list, include several unpopular, problematic licenses with less than 1% market share, like for example:

Misinformation

Black Duck has been repeatedly accused of bias against copyleft licenses like the GPL and having spread misinformation about the popularity of those licenses.

Questionable patents

Black Duck has managed to be granted patents on trivial “software methods for detecting and resolving open source software licensing conflicts”. This not only contradicts the spirit of sharing and software freedom by most definitions of common sense but also illustrates the aggressive for-profit focus of the company.

Professor Bradley Kuhn from the Software Freedom Law Center (SFLC) went so far as to say: “Black Duck again shows itself as a company whose primary goal is to prey on people’s fear of software freedom.” (quoting from an article on arstechnica.com)