Christopher B. Browne's Home Page
cbbrowne@acm.org

Java

Christopher Browne


Table of Contents
1. Java and Distributed Computing

1. Java and Distributed Computing

1.1. Java

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.

  • Simula introduced object-oriented programming in the 1960s, long before C was a popular language.

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.

1.2. Licensing Concerns

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.

It is also worth taking a look at the FreeBSD discussion at Java on FreeBSD .

Viva - Open Source Java - Operation Java Freedom is trying to promote deployment of improved " open source" options...p

1.3. Free Java Implementations and Critical Components

1.4. About J2EE

Web Frameworks

(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.

1.5. Non-free Java Implementations

1.6. Secondary Java Libraries and Apps

1.9. Some Java Apps

1.10. Other Distributed Computing Systems

  • Lucent's "Inferno" Networking system

    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.

  • Frequently Asked Questions (FAQ) re ActiveX and "Exploder"

    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.)

    • Extensive object-orientation

    • An original target as an embedded system. (It was designed as a component of the Amoeba OS.)

  • Parrot is a VM being built to support Perl Version 6.

    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 .

Many of these languages (and others) have been proposed as reasonable platforms for Mobile/Intelligent Agents.

Google

If this was useful, let others know by an Affero rating

Contact me at cbbrowne@acm.org