"Java. The elegant simplicity of C++; the blazing speed of Smalltalk." -- Jan Steinman
This is why many folk find Java unacceptable now - Hard Language in terms of maintenance, Soft Language in terms of performance. Ruby On Rails used in an Alternate Hard And Soft Layers combo can easily outperform a Java Language only solution in both speed and productivity. Enterprise Service Bus makes us all language/VM agnostic. So why would you consider Java Language nowadays? I really wanna know. -- Peter Merel
"Java is a DSL for converting large XML files into Stack Traces" -- twitter.com
(See Xml Sucks)
The Java language attempts to protect the programmer from common C and C++ gotchas: Java provides garbage-collection for unreferenced objects, and does not allow direct memory pointers except through its Java Native Interface API. Its scoping is not as complex as C++, but provides separate name spaces via packages and a range of other protections surrounding classes. Operator overloading and multiple inheritance have also been eliminated.
Java sources are usually compiled into platform-neutral machine code called Java Byte Code. This machine code is run by a Java Virtual Machine (JVM); some JVMs interpret the byte code, but it is more common for the JVM to perform just-in-time (JIT) compilation of the byte code to the native machine code of the underlying platform (e.g. x86).
This and a standard windowing environment (AWT, and Swing are from Sun with SWT and JFaces from Eclipse, QT and others are of use here also) allow for a degree of Platform Independence (pushed by Sun as Write Once Run Anywhere). There are also Other Languages For The Java Vm.
The Java system's third important piece is its ample class library (usually referred to as "the Java APIs"), which has evolved and expanded with each major release. The APIs aren't perfectly designed, but typically, you only need to learn (and load) the part of the library that's relevant to the task you want to accomplish.
Java has been positioned as an excellent language for developing network-based applications. It is multi-threaded, and many of its libraries are thread-safe.
jwz included the security model as a fourth separate thing. Sun now (2006) seems to be backing away somewhat from this marketing position. They're now working to support Other Languages For The Java Vm.
"Java -- the COBOL of the 90's." (See Java Is The New Cobol)
Java Sub Topics:
Interesting Java-related Discussions:
For comparisons with other languages, see:
And, of course, Language Pissing Match.
See also Java Links (updated)
Java is a hack grown committee wild. Even like that, it is great language to program, mainly because of its packages.
Execution in the Kingdom of Nouns by Steve Yegge is a magnificent complaint about the use of nouns in Object Oriented Java Language. His Java version of "For want of a nail..." is worth the entire article alone.
For the lack of a horse, R''''''idersGuild.getRiderNotificationSubscriberList().getBroadcaster().run( new B''''''roadcastMessage(S''''''tableFactory.getNullHorseInstance()));
I would add that the authors of Java have written an influential White Paper that described their design goals and accomplishments (java.sun.com ). The goals read like a list of buzzwords:
I am amazed that they really believed that a virtual stack machine could achieve high performance. All the other goals are true, but it is impossible to be high perfoming and portable at the same time.
From the original description: While Java is not Type Safe, it does attempt to protect the programmer in other ways.
Okay, why does Stephen Wynne claim that Java is not Type Safe? It is true that Java allows casting of reference types from one class to another, but such casting is always constrained by the actual runtime type of the instance. For example, classes B and C extend (inherit from) class A. An instance of B can be used in a variable of type A. A checked downcast then allows that instance to be assigned to a variable of type B, but not to one of type C.
A a; B b; C c; b = new B(); a = b; // implicit upcast - OK b = (B)a; // compatible downcast - OK c = (C)a; // incompatible downcast - will throw ClassCastException
Java never allows you to invoke a method on an instance of a class that does not implement that method. The worst that can happen is you get a Null Pointer Exception when you invoke a virtual method on the null reference.
Oops, I oversimplified. From what I understand, Java would need Parametric Polymorphism to provide typesafe, generic containers similar to C++'s Standard Template Library (as David Gauthier infers below). There's some talk about problems related to the lack of type checking in the new Collections API in the FAQ under java.sun.com . -- Stephen Wynne
Generics (templates) are on their way of becoming a new part of the java language: look for version 1.5 coming out somewhere in 2004
"Java never allows you to invoke a method on an instance of a class that does not implement that method." This is not 100% true. The following code has no explicit casts and calls an operation that is not implemented by the target object, yet the compiler does not flag a type error:
Integer int_array = new Integer; Object object_array = int_array; // This line demonstrates a hole in the Java type system ''No'' object_array = "putting a String in an Integer array";
There is an implicit cast there, and that is is fine. You have not refuted the writer's statement in the least, since your code does not invoke a method. An Integer *is* an Object, so to say that the assignment operation is not implemented is also false. Assignment of an object to an object reference is always valid, and that's no quirk of Java. Name a language that would not allow a string to be assigned to what at compile time is known only to be an object reference, and I'll bet we'll find a rather useless language. But the key fact is that your code produces a runtime exception. Even though it is not a method call, your assignment demonstrates what the writer stated, that casting cannot not subvert the type system.
A common meaning of type error is an attempt by a program to perform an operation on a value that is invalid because of the value's type. Thus, Java type errors include both casting failures and failures to assign a value to a variable. Then again, 'type safety' might include dynamic type safety, wouldn't it? In that case, both Java and Smalltalk would pass as type safe. At any rate, ignoring difficulties with the various terms, Java is as well typed as Smalltalk as far as guarantees go. You have to run the program to find your type errors, but at least type errors will halt the program when they happen.
Two things I am missing about Java is (1) assertions (pre- and postconditions) and (2) templates (to avoid frequent casting). Interestingly, both are listed at the so-called "Bug Parade" (number 4071460 and 4064105, respectively), where you can vote for the bug fixes and language enhancements you think are most important. To vote, you have to register with the "Java developer connection" (developer.java.sun.com ), which is free. -- Falk Bruegmann
The newest JDK (1.4) code-named Merlin includes support for an assert keyword.
... and JDK 1.5 will include generics
But adding generics now is far too late too save the existing class libraries. Guy Steele's famous OOPSLA '98 "Growing a Language" speech might never have been feasible had he only started with one letter words as Gosling's language did.
There's no need for templates/generics to "save" existing class libraries. Some might have been more concisely written with them, but it's certainly not a requirement. Remember the first versions of C++ also did NOT have templates. Of course, neither the lack of assertions nor templates should ever have been a "bug" in the first place. Asking for them is a Feature Request, not a Bug Report.
we'll see in Java Three...
Have people here checked out Pizza Language or GJ (Generic Java)? Pizza was designed to add Parametric Polymorphism, first-class functions, and class cases with pattern matching to Java in a way so Pizza programs compiled to Java Byte Code. GJ is a less ambitious attempt to add template-like behavior to java, with a compiler that turns it into standard Java Byte Code. See www.cs.bell-labs.com and www.cs.bell-labs.com . -- Java 5's generics were based on GJ
One other note: assertions are often mentioned by James Gosling as the one language feature he wished he had put in to Java. It was in an early version, back when it was called Oak, which he has a reference to on his web site.
One of Java's strengths is its ample class library, which has evolved and expanded with each major release.
This is one thing I am beginning to hate about Java. You think you are getting a handle on how things work, and wham, Sun introduces a whole new mess of classes. Swing is probably the worst offender in that regard (itself a major extension of some changes to things like event handling between 1.0 and 1.1). Me, I think I'll pin my hopes on Biss Awt... -- Bill Trost
These ample class libraries are contributing to some horrible bloating. Each new release of the JDK includes more and more classes (APIs) that were previously marked as "extensions". Examples include Swing, JDBC and now XML Data binding, Secure network transfer APIs, etc. Sun should limit the distributions to a small core that implements the basic functionality (the java.lang package) and all other APIs should be dynamically updated (or updatable) from their site as they become available. Requiring people to download and install a new (20Mb, 30Mb, 40Mb, 50Mb, etc) JRE every 6-18 months (the promised turnaround time for Sun) is ridiculous. -- Iain Lowe
Installing a new JRE isn't a big deal. Upgrading my company's software from Java 1.3.1 to Java 1.4 took me about a day and was straightforward. The advantages of Java (extensive built-in APIs with excellent documentation, automatic memory management, etc.) far outweigh the upgrade inconvenience. -- Jared Levy
I don't understand Bill's objection. AWT was generally regarded as mostly broken, so all the Swing Gui Toolkit classes were added in 1.1, along with a new event-handling model. But AWT wasn't removed: you can still use it if you want, and in fact, Swing explicitly uses some big chunks of AWT to get things done. It's not like they pulled the rug out from under you: they just gave you a bigger, better rug that happens to partly overlap it.
-- George Paci
On the other hand... Microsoft are scaling down the Win32 APIs for personal devices - for example windows CE devices.
Uhh... Ever heard of J2ME? -- Rune Andersen
An important difference is that the architecture of the Java language and APIs don't result in hordes of giant DLLs being loaded when all you want is a few simple functions. For example, writing import java.awt.* doesn't pull in all of AWT automatically, the classloader only loads the classes you need at run time. -- Steven Newton
Then, why does the Java Swing demo application die ungracefully if you reduce the amount of available dynamic memory to e.g. 20 MB? Why does it die at all? Why does it without an "out of memory" message? -- Helmut Leitner
All things considered, I'd rather take a huge Java Object-Oriented API collection than the pathological Win32 APIs any day (let's see how many ways we can return a string, or iterate over a collection of things). Hopefully, this will be better with the Dot Net architecture. Most real environments will have a huge library. I will go out on a branch and claim that this is an Essential Complexity. -- Johannes Brodwall
I've found that Java Swing applications run noticeably slower than their native counterparts (Ever try to use Forte?) and for this reason, I consider Java a poor choice for end-user applications that are more than a simple form or two. The slowness and slight variation from the look and feel of native widgets are the two things the users will notice, not how it is able to run on multiple platforms (honestly... who says "oh this is neat, let me download it to my Mac now and see if it runs there"?). If running on multiple platforms is critical, you can use something such as Qt to write your GUI without having to rely on language builtin widgets that suck. -- Jacob Cohen
The problem with slow Swing apps is in large part due to the design of the individual applications and in part due to lack of optimization in older JREs. The latter has been largely removed from the 1.3 and 1.4 releases, so now Swing is/can be quite fast (though never as fast as native GUIs on Windows due to the fact that there is code under the hood being executed translating Java calls into native calls, code that a native application would lack.
I find it depressing that I have a job where my conversations include phrases like "visual jay sharp dot net". -- Kris Johnson
You should rejoice you have a job at all. :)
My company works with Java. Here are the clear advantages we get:
Large and well-documented class library
Lots of packages around to buy, use, copy, be inspired by
Portable code (never had a portability problem!)
Easy to spot some types of bugs (compared to C++ and VB)
Here are the clear problems we have:
Very slow performance
Very slow IDEs (so we don't use them)
Large memory usage
Did I mention slow?
So, as I see, the language itself has very small effect in our active work, but for the programming bugs. However, this are much less important than logic and specification bugs.
In this way, Java is a questionable decision for a company (i.e., the discussion you [??] be endless between pro and cons), but seems to be a great Language For Teaching?
You should really consider re-evaluating IDEs; unless you use very old machines with little memory, IDEs such as Intellij Idea on a Pentium IV with 512MB can give huge (really, really huge) productivity boost to your team. -- Davide Baroncelli
Performance problems are mainly a thing of the past. If your app runs slowly usually the problem is your coding (or that of the person that supplied the class) rather than the Java environment.
Inconsistent libraries, not so well documented (may I edit this returned object?)
lack of expressiveness... see Object Enumeration Idiom
I knew const, and final is no const :-) -- classes of immutable objects are a lame substitute for restricted references
interfaces are the Java equivalent of C++ const references.
See also: What Is Duke (explanation of Javas mascot)
The "slowness" above is something I really can't say I see, 99% of the time - and I use Java a lot. Some GUIs are terribly slow, but usually this seems to be more due to the code than due to Java. As for a fast IDE: try Eclipse Ide: www.eclipse.org .
-- Jon Skeet
Sun is touting Java Hot Spot VM as a remedy for the often mentioned slowness. To quote their propaganda, "The Java Hot Spot VM architecture addresses the Java language performance issues described above by using adaptive optimization technology."
This optimization technique sounds reminicent of "PV singular extensions" made notable in Behind Deep Blue.
Wow... I tried eclipse, expecting something similar to forte or netbeans... in other words, expecting it to be slow, or at best, fast enough to be barely usable... it's usable all right, and plenty fast.
Retrieved text from deleted JavaLanguage page which was nearly a copy of this one: Hateful? Maybe if you're still trying to use the Microsoft VM, but that's known to be broken. I'm guess about Microsoft because of the very vendor-specific mention of COM objects. By the way, the story mentions that the technology is called Eclipse. Wonder how that will fly with Eclipse Ide folks?
Java does pretty well performance-wise on the Computer Language Benchmarks Game.
I really do not know what to do with periodic calls from companies who see my Smalltalk affiliation and interest and ask me to do a sifting project where they want to rewrite some Smalltalk application in Java. Apart from being torn emotionally about doing this, feeling that I'm somehow driving another nail in Smalltalk's coffin, I question the wisdom and reason for doing so, even if it is the client's nickel. Then I wonder how such a thing would go.
Re-expressing Smalltalk in Java syntax is not a big deal at all, but how would you go about dealing with:
reconciling their class libraries
handling Smalltalk dynamics like reflection
exploiting Java's penchant for using vastly different class libraries to achieve better performance and effects
Worse, I have the feeling the original application isn't well documented and they need a Smalltalker to interpret it.
You were not able to find java.sun.com ?
Q. Is Java On The Palm a good way to learn Java, or is it so different from "normal" Java programming that I would have to unlearn it and start over when I switch to Java on a desktop / server?
A. If you want to program on the Palm, learn Java On The Palm. If that isn't your primary goal, for God's sake don't.
Q. I hear that there are a few free IDEs for Java; any Java Ide recommendations for the newbie?
A. Eclipse Ide is good; I don't know how newbie-targeted though.
Eclipse 3.0 looks very newbie-friendly.
I didn't like Eclipse when I first used it, but after getting it configured the way I like it, it's my IDE of choice. Don't give up on it until you've taken the time to work your way through the preferences options. And don't forget to search for plugins that might be useful for you.
1.0 Java pretty much implements the minimal subset needed to express any OOP concept in a C-like syntax. Unfortunately, that's where the design stopped. This means that there are nearly no mechanisms to ease code-reuse. Later versions of Java (up to 1.4) added features to make it easier to keep like things together and reduce boilerplate class declarations... but still the fundamental problem of cumbersome reuse remained with the lack of generics. Java finally added generics in 1.5... and by this point it could no longer claim to be the simple, clean language that was supposed to replace the confusing C++, and still was missing numerous features like operator-overloading that allowed a C-like language to look pretty.
Java 1.0 would have been fine if it had been marketed as a legible intermediate language and had arrived with a suite of metaprogramming tools. Instead coders were hand-developing in Java, resulting in the horrors of excessive typecasting, endless boilerplate code, and the frustrations only having single-inheritance for easy code-reuse. -- Interfaces and Delegation remove the fustration somewhat.
Every.single.bloody.application.written.in.java.is.god.awful.slow.com - Pat
Really? Are you sure you're not confusing Java with PHP? See benchmarksgame.alioth.debian.org
See original on c2.com