Java is a language that was originally created to be used to program toasters, microwave ovens, and other embedded systems. It combines:
A C/C++-like language structure;
Object oriented features in the form of classes and methods (multiple inheritance is specifically omitted);
An assumption of the use of garbage collection to manage dynamically-allocated memory;
A Java bytecode machine. Java compilers generate "machine code" in this bytecode form; every Java platform must then have a bytecode interpreter to execute the code. This provides platform independence at the cost of reduced speed of execution; "Just In Time optimizers" have dramatically reduced the performance loss that results from this approach. Java code is not much slower than languages like C for many applications.
A security model for executing code obtained over networks that tries to protect users against the ill effects of "rogue code."
I'm not particularly a firm believer in Java. Actually, I think that to this point most of what has been said about it has been marketing droid snake-oil. It's not that great a language; the "great benefit" is supposedly in the security model that seems rather flawed to this point in time (no authentication mechanism) along with purported portability that has not lived up entirely to the claims. It's not so much "compile once, run everywhere" as "compile once, debug everywhere".
On the "theory" side, it did not introduce to the world all the things that marketeers suggest it did:
Smalltalk has been doing platform-independent bytecode for a lot of years, as have many other systems.
LISP systems have been dynamically allocating memory for decades, not to mention Scheme or other newer variants.
While it's not available on every computing platform, it's certainly more platform-independent than Win32, it provides the dynamic memory allocation that LISP -like languages provide that should reduce the crashes caused by memory leaks caused by less-than-careful C and C++ programmers and buggy memory management, and probably is fast enough when applications are primarily bound by user response times.
If you are interested in deploying Java-based applications on any Linux distribution, the "soft" issues discussed in the Debian Java FAQ concerning licensing are well worth a read.
The "Java world" is a realm involving considerable dueling between licenses. While there is a fair bit of software available "gratis" (free of charge), there are considerable barriers to the production of "libre" (free of restrictions) software based on "Java 2" aka "JDK 1.2." It seems fairly likely that Sun might mount legal challenges to anyone attempting to implement a system interoperable with JDK 1.2 as free software. Of course, as of 2010, Java belongs to Oracle, and the language has reached version 1.7, but that doesn't necessarily change the issues.
On the one hand fair to say that the Debian folk tend to be "more paranoid than others" about licensing considerations; an uncareful interpretation of that might lead to the assumption that they are concerned over nothing here, that they're just a bunch of "GPL zealots." Despite the presence of some such, that would be an unwarranted and unwise assumption. The Questions on platforms and license concerns discussion discusses substantive questions concerning Java specifications use that are not merely quibbling over "which free license is better." It appears impossible to closely track Sun or Oracle's "technology initiatives" without having to sign non-disclosure agreements or licensing software that is decidedly not free software.
The lack of widespread deployment of applications written in Java as part of all Linux distributions is a natural outcome of the tight licensing restrictions applied to the Java-related technologies from Sun, IBM, and others.
Viva - Open Source Java - Operation Java Freedom is trying to promote deployment of improved " open source" options...p
Java Compiler for the EGCS compiler project.
Kaffe A JIT virtual machine for Java bytecode
Kaffe is a complete, Personal Java 1.1 compliant Java environment. As an independent implementation, it was written from scratch and is free from all third party royalties and license restrictions. It comes with its own standard class libraries, including Beans and Abstract Window Toolkit (AWT), native libraries, and a highly configurable virtual machine with a just-in-time (JIT) compiler for enhanced performance.
This provides a standards compliant Java compiler for Linux and a number of other platforms, on Alpha . It generates Alpha machine language on the fly, and is reportedly a lot faster than other Java environments on Alpha hardware.
Debian packages available here.
Glass is a Java Bytecode front end to GCC, obsoleted by GCJ
(Python versus Java and such...)
J2EE is so many things, but I'll try and summarise them instead of pointing you back to the Sun J2EE site, which is almost as badly-designed as Sun's other sites.
In many respects, J2EE attempts to address the same kinds of areas that various Python Web frameworks (blatant promotion of Web page - see below) cover:
Servlets - server-side programs which respond to requests, typically over HTTP , although other protocols aren't exactly ruled out.
JSP (JavaServer Pages) - a templating technology which is much like ASP and countless "Python Server Pages" technologies.
EJB (Enterprise JavaBeans) - unlike the much-hyped, but easy-to-grasp JavaBeans concept, components written to the EJB specifications specifically attempt to cover the area of "business logic", and provide support for things like transactions involving many different objects and databases.
Object-relational support is only really addressed in "container managed entity beans" which form a small part of the whole EJB thing. Prior to version 2.0 of the EJB specification, the "container managed" part - meaning that the mapping to relational database tables was done on your behalf - was more or less a toy, in my opinion, because there apparently wasn't a standard way of describing relations between objects.
Really, the benefit of J2EE is the standardisation of the way people write their server-side applications; that's something which we haven't yet seen in the Python community, but then there's still a lot of diversity on top of J2EE in terms of frameworks which actually provide application-specific solutions to real-world problems.
Jini - Sun's "Herd of Java Machines"
WabaVM is essentially a Java Virtual Machine implementation for some PDA platforms including PalmComputing / PalmOS. It does not provide a full Java implementation, lacking a number of the SunSoft standard Java classes, but can run JVM code that uses WabaSoft classes.
GNUJSP is a free implementation of Sun's Java Server Pages.
A GUIed RAD tool for building Java applications.
OpenSymphony project to provide "open source" J2EE components
The Open For Business Project - providing "open Source" J2EE components
This subset of Lisp may be used to generate Java bytecode...
This is a set of authentication infrastructure that integrates with the Eclipse development tools for use with Java applications.
This tool takes Java bytecode and turns it into Java "source" code. As it won't include comments, and may not preserve all symbol names, it won't be quite identical to the original code used to generate the bytecode, but it's supposedly reasonably close. It appears that Java bytecode is pretty expressive, which makes the translation back to Java a pretty good mapping.
This also permits the possibility of reverse-engineering code in other languages that can produce Java bytecode into Java.
A tool that decompiled JVM code into (say) Scheme might allow a similar conversion between languages.
Inferno is a C-like language created at Lucent Technologies (aka Bell Labs; progenitors of UNIX). Like Java, Inferno is intended to be an embeddable programming environment providing a robust, secure, portable computing platform, typically for fairly small applications.
ActiveX is Microsoft's alternative to Java; it naturally is rather Windows 95/NT-oriented. Unfortunately, it appears that it has significantly worse security problems than those Java is contending with.
FORTH bears quite a lot of resemblance to Java:
Many implementations of FORTH use bytecompiled code;
FORTH is a highly stack-based system, much like the JVM;
FORTH is commonly used for embedded applications (like toasters, thermostats, radio telescope antennas, and other industrial controls); Java was originally designed to be used with embedded systems;
Proponents of both languages often seem to be unreasonably opinionated;
The most conspicuous difference is that along with the longstanding FORTH emphasis on embedded applications, there are not the strong ties to use in distributed applications.
Python is another language remarkably similar to Java; like Java, it has:
Lots of LISP/Scheme-like features under the skin including garbage collection
A portable bytecode compiler, allowing semi-compiled code to run on many systems. (Indeed, more systems than Java runs on.)
An original target as an embedded system. (It was designed as a component of the Amoeba OS.)
Unlike the Java VM and MONO and .NET, which are oriented towards static languages similar to C and Java, Parrot is intended to support dynamic interpreted languages like Perl, and may also be good for other interpreted languages like Python , Ruby , and Lisp .