Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Scripting Languages for Java vs. Pure Java

Java as a New (S-l-o-w)  Cobol

Java is a rather backward, badly designed but brilliantly marketed language that has all attractiveness and advantages of Cobol in the sixties of the last century. Still it proved to be "good enough" as a Cobol replacement and due to this it managed to achieve the dominant position in commercial application development. The rest is history. As of June 2005 it's share is probably around 25% and is the largest if we believe O'Reilly book metric. The next largest share by this metric still belongs to C/C++ and Visual Basic, both at ~15% and the PHP & C# (both at ~10%).  If we count C# as a better dialect of Java then Java share would be higher. Perl, JavaScript and Python has approximately 5% each.

But like many other popular IT programming products, Java achieved it dominant position in a wrong way. I do not know what was the major factor but being in the right place at the right time definitely does not hurt; the level of hype connected with the possibility of using it in Web applets in 1995-1999 was simply deafening. Incredible amount of money was spend by Sun and later IBM on Java marketing.  And money talk...

Also the progress in hardware since was really tremendous for the first 10 years of Java existence. This fact alone greatly helped adoption of the second after Visual Basic (and non-Microsoft controlled) commercially viable virtual machine based language: CPU speed improved almost 50 times (from ~100Mhz to almost 5GHz),  memory on a typical server 1000 times (from several megabytes to several gigabytes), hardware disks capacity more then 1000 times (from hundreds of megabytes to hundreds of gigabytes).  Only in 2007 this pace started to slow down and CPU speed increases switched to increases in the number of cores. Capabilities of  a typical produced in 2007 laptop were considered to belong to the class of high end servers ten year ago and supercomputers 15 years ago (we assume 2G of memory and dual core 2-3GHz CPU with a single 120G drive)

Here we will discuss Java in the context of existing scripting languages but even in comparison with best compiled languages Java is not impressive and as a language badly lacks expressive power. In a way Java is a language that requires scripting language run time support without providing scripting language expressive power and as a language as Stepanov noted "has no intellectual value whatsoever."  When I program in Perl or PHP or Python, and my application is slow, I know perfectly well that there is no free lunch: my code is probably ten times shorter then in C and I need to pay for the luxury of maintaining shorter, easier understandable codebase. When I program in Java and have code that is actually longer then the equivalent code in C,  this explanation does not work.  Actually none of the explanations work because the progress in languages if first of all the progress in expressive power. If I need a longer program then in C then assembler is a natural choice ;-). At least it greatly simplifies debugging: you can see both executable code and your data the way the computer is seeing them without additional layers of abstraction in between. 

Also the key criteria of an advance in language design, the productivity of programmers working in Java is open to review.  Even with such frameworks as Eclipse Java remains very expensive language to develop commercial applications.  Costs overruns for Java website in comparison with PHP based website are probably close to an order of magnitude. Moreover java Web sites typically require more expensive hardware, special middleware and load balancers (F5 is popular and is not cheap).   If we adopt the concept of  the  lifecycles of programming languages, and the "survival of the fittest" in language area, I think chances of Java to survive in the next 50 years are far from being certain.

While run-time environment in Java eventually become pretty sophisticated, the language itself stagnated on the level it was released. The level that makes Java a suitable (portable) lowest denominator for commercial applications development, the development that previously was done in Cobol and that can be done in Java slightly cheaper than in C++.  But not much more. As a language Java became frozen into some sort of  "C++ for dummies" niche. Neither in control structures area, not is data structures area Java breaks any new grounds (like Perl, PHP, and Python did).  It has a couple of minor innovations on runtime level (jars, multithreaded garbage collection, etc).  In many areas of language design Java represents one step forward and two steps back (it is essentially scripting language internal implementation without scripting languages expressive power; in most critical areas of language design Java represents either preservation of bad features of C family ("status quo") or just one step back in misguided attempt to improve the compile time error detections capabilities.  

Even in comparison with old languages (like PL/1, Algol 68 and Ada) Java does not looks like a step forward. Actually PL/1 which fell victim of structured programming fundamentalism (and subsequent rise of Pascal and later C) is even today very competitive to Java. It was a solid, small by today standards and expressive language with its incredible quality of optimizing and debugging compilers on IBM mainframes: both were real masterpieces of software engineering. If we are talking about browser's applets Java is the right language for the wrong problem (AJAX might be a better way to address client side programming).  If  we are talking about server side, then for Web page generation it is a wrong language for the right problem :-). 

If we are talking about language design, I hate languages which presuppose that they know what I need (and what I do not need) and try to enforce "right" constructs on unsuspecting public, although dynamic memory allocation is nice. In essence Java "fixed" C++ by adding dynamic memory allocation into the language, but in the process it abandoned a lot of useful things and made it too OO-oriented for its own good. I have strong  doubts about Gosling as a language designer. As Stroustrup aptly notes in his "The Design and Evolution of C++" [page 113]:

Programmers are smart people. They are engaged in challenging tasks and need all the help they can get from a programming language as well as from other supporting tools and techniques. Trying to seriously constrain programmers to do "only what is right" is inherently wrongheaded and will fail. Programmers will find a way around rules and restrictions they find unacceptable. The language should support a range of reasonable design and programming styles rather than try to force people into adopting a single notion.

This does not imply that all ways of programming are equally good or that C++ should try to support every kind of programming style. [...] However, moralizing over how to use the features is kept to a minimum, language mechanisms are as far as possible kept policy free, and no feature is added to or subtracted from C++ exclusively to prevent a coherent style of programming.

I am well aware that not everyone appreciates choice and variety. However, people who prefer a more restrictive environment can impose one through style rules in C++ or choose a language designed to provide the programmer with a smaller set of alternatives.

Michael Swaine aptly put it in "10 reasons why Java is bad for you" ( Some Observations on Apple and Java in Dr Dobbs, February 1997:

1. We don't need another C++. One is bad enough.
2. It's too stripped down for many programming purposes, the legacy of being designed originally to run on smart toasters or something. Needed or desired features may be added on later, but having the right features designed in from the start is the way to go.
3. Multithreading is a pretty obscure feature to include considering the things left out.
4. Multithreading will rot your teeth.
5. Java is slow.
6. It'll never be fast. Without explicit memory management and the use of pointers, Java can never match C for fast executable code. And it's interpreted, so the user has to wait for the interpretation phase to see the application or applet execute. Just-in-time compilation doesn't help.
7. Most of Java's alleged virtues (portability, ability to deliver functionality over the Internet, ability to screen code for security purposes) come from its being interpreted. Other interpreted languages have or could easily have these same virtues and are at the same time easier to program in than Java. Some interpreted languages also have large libraries to draw upon to speed development. We don't need another Visual Basic.
8. The development environments currently available leave something to be desired.
9. How open a standard is it when a runtime environment license costs $125,000? And when Sun controls the development of the language? And licensees are required to turn any improvements the make over to Sun?
10. In the late 1997, what we need are more and higher high-level languages that can speed development of more powerful, media-rich applications and that can call upon compiled routines written in an efficient low-level language when they need to. We don't need another C.

That means that the risk to J2EE to be overrun by something better still exists, although now with the current level of industry adoption it might become lower. But Microsoft's CLI  technology can run Java faster than any JVM. No amount of JVM tuning can make up for the architectural deficiencies. CLI is close to the intermediate stage of the standard C++ compiler and contains all the optimization information that might be needed to make faster code. Expect a rash of server advertisements benchmarking a .NET server against J2EE. Moreover Microsoft is a better language developer than Sun; and when Borland was in trouble they managed to hire a lot of top people, people that created Turbo Pascal and Delphy. 

From the other point of view it's sad that to promote Java Sun killed their TCL project. TCL was/is a really interesting scripting language and Sun could make it a standard application level macrolanguage in Solaris, but unexplainably and miserably failed (to be more exact  "changed the course")...

The development of Java was partially shaped by Sun-Microsoft antagonism. MS's attitude was that there was no way they were going to allow Java to take over the Windows programming market in a way that might make Windows irrelevant. And Sun helped Microsoft to eliminate this threat by taking out the fastest JVM implementation and the best Java development environment from the desktop ;-).

Sun's attitude was that there was no way they were going to allow Java to become "a better way to write Windows apps." They succeeded beyond any dream, especially in view of Microsoft launching of C# as an alternative to Java ;-). As a result, Java now is virtually irrelevant to "pure Windows" client-server application development. Also since Windows is the vast majority of all clients, Java is irrelevant for almost all client programming outside small (but important and growing) niche of Web-based clients.  It is still relevant as a cross platform language for writing client-server applications for Unix, working in a WEB browser environment, and that provides some hope for the future.  But is this enough for long term survival remains to be seen...

On the server side Java enjoyed a reasonable level of success for writing commercial server-based applications, especially financial applications.

Moreover, one should not evaluate Java as a language alone. As we already discussed as a language Java is far from being interesting and probably can be considered  a (failed) attempt to create a better C++.  But the development environment for Java as a whole is top notch and it's prudent for developers not to consider a language alone, but to take into account the quality of libraries, VM, debugger, IDE, etc.  Millions of dollars that were spent  on the development of Java compliers libraries and tools created an environment that is competitive with others languages despite all the flaws of the language. As Donald Knuth aptly put it:

All through my life, I've always used the programming language that blended best with the debugging system and operating system that I'm using. If I had a better debugger for language X, and if X went well with the operating system, I would be using that.

While with all those money spend Java definitely is an OK environment I am convinced that as for programming productivity in WEB development environment scripting languages has an edge. Java environment is more mature and attracts more development dollars, but major scripting languages are better , higher level languages and at least some of them now have decent development environments as well. For example Jython has most of the features to compete successfully with Java  productivity wise even if you are forced to use Websphere by your VP.  Jython deserve mentioning as an interesting alternative to J2EE.  TCL (especially TCL+C combination) is another under appreciated  alternative for those who want job to be quickly done and are far from being OO fundamentalists ;-)

Even within Java framework something constructive can be done by providing a macro language for the applications: Beanshell is an interesting macro language based on Java, promising for Java programmers a more comfortable environment than Jython, as it does not deviate much from Java syntax and semantic and has a nice capability of  macro programming for applications. Here is a small description from the home page:

BeanShell is a small, free, embeddable, Java source interpreter with object scripting language features, written in Java. BeanShell executes standard Java statements and expressions, in addition to obvious scripting commands and syntax. BeanShell supports scripted objects as simple method closures like those in Perl and JavaScript(tm).

You can use BeanShell interactively for Java experimentation and debugging or as a simple scripting engine for your applications. In short: BeanShell is a dynamically interpreted Java, plus some useful stuff. Another way to describe it is to say that in many ways BeanShell is to Java as Tcl/Tk is to C: BeanShell is embeddable - You can call BeanShell from your Java applications to execute Java code dynamically at run-time or to provide scripting extensibility for your applications. Alternatively, you can call your Java applications and objects from BeanShell; working with Java objects and APIs dynamically. Since BeanShell is written in Java and runs in the same space as your application, you can freely pass references to "real live" objects into scripts and return them as results.

All-in-all I think that a decent scripting programmer can wipe the floor of a pure Java programmer of the same qualification productivity wise, unless he/she are forced into an environment that gives Java an significant edge (for example, if Websphere is adopted as an application server). Still, due to huge investment in Java enterprise tools, the mere mass of existing Java programmers and related enterprise applications create a sustainable moment for its preservation and even grouth. I think that we might need to wait until the next generation of scripting languages to really challenge Java on the server side.  One might say that Gosling did two bad things for programming community: saved Emacs from obsolesce and created Java :-)

In any case the historical truth and development momentum is on the scripting language side and Java really looks like Cobol in the early 60th: a dinosaur almost from the very beginning. Algol 60 was much more elegant than Cobol, PL/1 was much more powerful. Similar situation exists if you compare Java with Python and Perl. Still we need to remember that Cobol survived and neither Algol 60 nor PL/1 did, although an attempt to mix PL/1 concepts with BCPL proved to be very fruitful and led to the creation of C.  Also until recently Cobol programmers financially did very well, which is extremely important factor in the current environment.

Contrary to an emotional (and wrong :-) opinion of too many open source enthusiasts I would like to stress that the closeness of the Java per se might not be detrimental, unless Sun try to put too tight a grip on the language (it actually don't). It more like a keeping a tennis racket: too loose and you will lose it; too tight and you will not be able to play well. Here I would like to mention the opinion of Dennis Ritchie on the subject:

An Interesting question arise, if Java is viable mainly on the server side, why do we need and what is so interesting in JVM ? Why it should be there instead of a portable compiler? JIT is not an answer in server-side environment, it's kind of an additional problem for WEB applications (slow start, overhead during execution, etc).  One plausible answer paradoxically is that Java provides a capability to move between competing Unix platforms with relative ease (for example it is possible to move applications from Solaris to Linux or from AIX to Linux  or vice versa), so Java does provide some important hardware portability that C++, for example, does not provide.  But it is important to understand that currently it seldom works for really complex applications, the applications where it really matters. Java helps but still there are problems. The story of IBM Tivoli Advanced Monitoring 5.1 is a very interesting cautionary tale here. It was a Java application that caused Tivoli customers (and by extension IBM) so many problems and headaches that it was recently replaced with complied one in version 6.1 (actually replaced with a new product), and not without a reason.

I already mentioned that Java's language design is very conservative. Moreover to a certain extent Java is a "police state" language, meaning that its designers have decided that they are smarter than everyone else, so they will dictate the programming style everyone has to use. In fact, because Java's language design is so conservative and restrictive, it is actually not all that much easier to write Java programs than, say, C++. Some people would claim otherwise, but I strongly believe that Java does not provide significant productivity advantages over C++ (that does not mean that as a language it does not have advantages, I only mean that advantages are compensated with shortcomings). In any case, Java's advantage over C++ isn't convenience...

I am convinced that scripting languages like Python, Perl, and TCL are more convenient, expressive and in important way more modern. And in no way Java is more portable than scripting languages: I have no axe to grind against Sun (actually I believe that Solaris is the best of commercial Unixes and in many cases it is preferable to Linux),  but I haven't experienced the cross platform nirvana Sun advertised.

Among scripting languages Python is probably most comparative and it does provide a richer functionality making programming with Python more higher level, easier, and generally more productive. The amount of typing in Python might be three to five times less than in Java for a typical commercial applications. When you have that much less code, it's easier to maintain, and also to less prone to introducing additional bugs if  changes are made by people other then the original developer. It also stimulate you to spend more time of choosing proper data structures and algorithms...

But Java did evolved in the direction of new Cobol, new business language for masses of commercial programmers, becoming essentially a standard de-facto in financial community. Partially it's "anything but Microsoft" syndrome in effect, partially there was a need for a better standard business language than Cobol and Java fits the bill. But that means that for the foreseeable future Java is here to stay no matter what new languages are or will become available.

And what is really big in Java is its "enterprise" libraries which as as important or more important then the language itself. For example Java's database libraries are already good and will become even better with time.  Bottom line is that Java2 performance is reasonable although IBM seems to be determined to prove otherwise with the Enterprise Commerce suit ;-) It is still ss-ll-oo-ww and will never be as good as Cobol or C++, but with 3GHz CPUs and 4G of RAM on a low-end server it becomes reasonable for a wide variety of commercial application-space tasks.

That's why despite all shortcomings Java is on its way to become the major business language (unless Microsoft will be able to derail it with C# and .Net).  I would say that it took best features from Delphi and mixed then with Java framework. For those people who consider C# to be a Java clone I would like to quote Hejlsberg [oreilly.com]:

"First of all, C# is not a Java clone. In the design of C#, we looked at a lot of languages. We looked at C++, we looked at Java, at Modula 2, C, and we looked at Smalltalk. There are just so many languages that have the same core ideas that we're interested in, such as deep object-orientation, object-simplification, and so on."

Future is unpredictable by definition, especially if IBM's money are on the table ;-). But in Aug, 2002  ZDNet published eWeek paper about study that claims that Java to overtake C++ in 2003. Please keep in mind that in this paper treatment of C# is very superficial, if not worse; in reality it's a viable threat for both C++ and Java: The quality of Microsoft Windows development environment / compiler / runtime engine is quite amazing. Visual Studio.Net is very cool:  

SAN FRANCISCO -- Developers using Sun Microsystems Inc.'s Java programming language will outnumber those using the C/C++ languages by next year, the findings of a series of studies conducted by Evans Data Corp. and released late Wednesday show.

Presenting the firm's research findings at IBM's Solutions technical developers conference here on Wednesday afternoon, Janel Garvin, vice president of research at Evans, said that more than half of North American developers use Java today, with that number expected to rise by 10 percent next year.

The research also shows that Java usage has been rising at the expense of Visual Basic and C/C++. "This means that, for the first time, more North American developers will be using Java than Visual Basic or C/C++ next year," Garvin said. "Java usage is even stronger outside North America, with almost 60 percent of developers expecting to spend some part of their programming time using Java."

Initial surveys have shown that only a small portion of developers intend to try Microsoft Corp.'s C# language, which is relatively new, and those developers will predominantly be ones already using Microsoft programming languages, Garvin said. There is no evidence of any significant adoption to date, she added.

Please note that the rumors about C# death (or to put it in ZDNet speak "no evidence of any significant adoption ;-) are greatly exaggerated: we do need a modern, productive system for producing new high-performance GUI apps: apps that look and feel as if they'd been written in C++, but  without the crashes, memory leaks and slow development cycle. Java here is not an answer and I think that's here C# will definitely flourish.  Whether it will become a competitor to Java in other areas and outside Windows platform it's difficult to say. The true worth of a programming language that is intended for use outside of academia is how quickly the language evolves to adapt to the changing technological landscape and what kind of community surrounds the language. Here I think Microsoft has an edge, but nobody can predict the future...

What is really interesting is the fact that most server side applications are I/O bound and even the fact that interpreted Java is slow as hell does not kill the language on the server even if  your return on investment in JVM is definitely negative. It is true that you really do not benefit from JVM on the server -- you control the platform, not the user; actually even JIT is a mixed blessing in this environment -- it makes startup even slower than it is already. I can see how a native code compiler could speed things up, but that trick reveals that there is no point of being based on a JVM (and that problem was corrected in .NET). IMO, unless absolutely necessary (Java applets running on client side browsers) using a JVM is weaker implementation then .Net, it's generally an unnecessary layer of abstraction that both complicates and slows things down. Dynamic recompilation and serving native executable from the cache on the server like in .Net case can substitute JVM in 80-90% of cases and is much faster.

All-in-all Java stuck somewhere between a scripting language and a "serious" system programming language.  That's why sometimes I hate Java despite its excellent programming environment. And I am not alone. In his short note Why Java is Not My Favorite Programming Language Michael Walker wrote:

A newly designed language has recently been the subject of much excitement in the programming world. This language – Java – claims to be safer, more portable, and on the whole, better designed than languages currently used for large-scale applications, and because of these claims, many programmers have been quick to pick up the language in preparation for a newfound demand in Java programmers. The demand, although growing, has not yet reached the level many programmers first anticipated, and the reasons are neither coincidental or trivial. In fact, Java may never be in demand like C and C++ have been for years, because Java is not suitable for many critical programming tasks.

In his WEB note Java sucks Jamie Zawinski mentioned several language flaws:

(I'm separating my complaints about Java the language, and Java the class library, despite Sun's repeated attempts to blur this important and fundamental distinction.)

• It's hard to live with none of: lexically scoped local functions; a macro system; and inlined functions.
• I really hate the lack of downward-funargs; anonymous classes are a lame substitute. (I can live without long-lived closures, but I find lack of function pointers a huge pain.)
• The fact that static methods aren't really class methods (they're actually global functions: you can't override them in a subclass) is pretty dumb.
• It's far from obvious how one hints that a method should be inlined, or otherwise go real fast. Does `final' do it? Does `private final' do it? Given that there is no preprocessor to let you do per-function shorthand, and no equivalent of Common Lisp's flet (or even macrolet), one ends up either duplicating code, or allowing the code to be inefficient. Those are both bad choices.
• Two identical byte[] arrays aren't equal and don't hash the same. Maybe this is just a bug, but:
  • You can't fix this by subclassing Hashtable.
  • You can't fix this by subclassing Array because it's not really an object. What you can do is wrap an Object around an Array and let that implement hashCode and equals by digging around in its contained array, but that adds not-insignificant memory overhead (16 bytes per object, today.)
  • Gee, I know, I'll write my own hash table. I've only done that a thousand times.
• I can't seem to manage to iterate the characters in a String without implicitly involving half a dozen method calls per character.
• The other alternative is to convert the String to a byte[] first, and iterate the bytes, at the cost of creating lots of random garbage.
• Generally, I'm dissatisfied with the overhead added by Unicode support in those cases where I'm sure that there are no non-ASCII characters. There ought to be two subclasses of an abstract String class, one that holds Unicode, and one that holds 8-bit quantities. They should offer identical APIs and be indistinguishable, except for the fact that if a string has only 8-bit characters, it takes up half as much memory!
  • Of course, String being final eliminates even the option of implementing that.
• Interfaces seem a huge, cheesy copout for avoiding multiple inheritance; they really seem like they were grafted on as an afterthought. Maybe there's a good reason for them being the way they are, but I don't see it; it looks like they were just looking for a way to multiply-inherit methods without allowing call-next-method and without allowing instance variables?
• There's something kind of screwy going on with type promotion that I don't totally understand yet but that I'm pretty sure I don't like. This gets a compiler error about type conflicts:

          abstract class List {
            abstract List next();
          }
  
          class foo extends List {
            foo n;
            foo next() { return n; }
          }

  I think that's wrong, because every foo is-a List. The compiler seems to be using type-of rather than typep.

• This ``integers aren't objects'' nonsense really pisses me off. Why did they do that? Is the answer as lame as, ``we wanted the `int' type to be 32 bits instead of 31''? (You only really need one bit of type on the pointer if you don't need small conses, after all.)

  The way this bit me is, I've got code that currently takes an array of objects, and operates on them in various opaque ways (all it cares about is equality, they're just cookies.) I was thinking of changing these objects to be shorts instead of objects, for compactness of their containing objects: they'd be indexes into a shared table, instead of pointers to shared objects.

  To do this, I would have to rewrite that other code to know that they're shorts instead of objects. Because one can't assign a short to a variable or argument that expects an Object, and consequently, one can't invoke the equal method on a short.

  Wrapping them up in Short objects would kind of defeat the purpose: then they'd be bigger than the pointer to the original object rather than smaller.

• And in related news, it's a total pain that one can't iterate over the contents of an array without knowing intimate details about its contents: you have to know whether it's byte[], or int[], or Object[]. I mean, it is not rocket science to have a language that can transparently access both boxed and unboxed storage. It's not as if Java isn't doing all the requisite runtime type checks already! It's as if they went out of their way to make this not work...

  Is there some philosophical point I'm missing? Is the notion of separating your algorithms from your data structures suddenly no longer a part of the so-called ``object oriented'' pantheon?

• After all this time, people still think that integer overflow is better than degrading to bignums, or raising an exception?

  Of course, they have Bignums now (ha!) All you have to do (ha!) is rewrite your code to look like this:

      result = x.add(y.multiply(BigInteger.valueOf(7))).pow(3).abs().setBit(27);
  

  Note that some parameters must be BigIntegers, and some must be ints, and some must be longs, with largely no rhyme or reason. (This complaint is in the ``language'' section and not the ``library'' section because this shit should be part of the language, i.e., at the syntax level.)

• I miss typedef. If I have integers that represent something, I can't make type assertions about them except that they are ints. Unless I'm willing to swaddle them in blankets by wrapping Integer objects around them.
• Similarly, I think the available idioms for simulating enum and :keywords are fairly lame. (There's no way for the compiler to issue that life-saving warning, ``enumeration value `x' not handled in switch'', for example.)

  They go to the trouble of building a single two-element enumerated type into the language (Boolean) but won't give us a way to define our own?

• As far as I can see, there's no efficient way to implement `assert' or `#ifdef DEBUG'. Java gets half a point for this by promising that if you have a static final boolean, then conditionals that use it will get optimized away if appropriate. This means you can do things like

      if (randomGlobalObject.DEBUG) { assert(whatever, "whatever!"); }
  

  but that's so gratuitously verbose that it makes my teeth hurt. (See also, lack of any kind of macro system.)

• By having `new' be the only possible interface to allocation, and by having no back door through which you can escape from the type safety prison, there are a whole class of ancient, well-known optimizations that one just cannot perform. If something isn't done about this, the language is never going to be fast enough for some tasks, no matter how good the JITs get. And ``write once run everywhere'' will continue to be the marketing fantasy that it is today.
• I sure miss multi-dispatch. (The CLOS notion of doing method lookup based on the types of all of the arguments, rather than just on the type of the implicit zero'th argument, this).
• The finalization system is lame. Worse than merely being lame, they brag about how lame it is! To paraphrase the docs: ``Your object will only be finalized once, even if it's resurrected in finalization! Isn't that grand?!'' Post-mortem finalization was figured out years ago and works well. Too bad Sun doesn't know that.
• Relatevly, there are no ``weak pointers.'' Without weak pointers and a working finalization system, you can't implement a decent caching mechanism for, e.g., a communication framework that maintains proxies to objects on other machines, and likewise keeps track of other machines' references to your objects.
• You can't close over anything but final variables in an inner class! Their rationale is that it might be ``confusing.'' Of course you can get the effect you want by manually wrapping your variables inside of one-element arrays. The very first time I tried using inner classes, I got bitten by this -- that is, I naively attempted to modify a closed-over variable and the compiler complained at me, so I in fact did the one-element array thing. The only other time I've used inner classes, again, I needed the same functionality; I started writing it the obvious way and let out a huge sigh of frustration when, half way through, I realized what I had done and manually walked back through the code turning my

      Object foo = <whatever>;

  into

      final Object[] foo = { <whatever> };
  

  and all the occurence of foo into foo[0]. Arrrgh!
   

• The access model with respect to the mutability (or read-only-ness) of objects blows. Here's an example:

  System.in, out and err (the stdio streams) are all final variables. They didn't used to be, but some clever applet-writer realized that you could change them and start intercepting all output and do all sorts of nasty stuff. So, the whip-smart folks at Sun went and made them final. But hey! Sometimes it's okay to change them! So, they also added System.setIn, setOut, and setErr methods to change them!

  ``Change a final variable?!'' I hear you cry. Yep. They sneak in through native code and change finals now. You might think it'd give 'em pause to think and realize that other people might also want to have public read-only yet privately writable variables, but no.

  Oh, but it gets even better: it turns out they didn't really have to sneak in through native code anyway, at least as far as the JVM is concerned, since the JVM treats final variables as always writable to the class they're defined in! There's no special case for constructors: they're just always writable. The javac compiler, on the other hand, pretends that they're only assignable once, either in static init code for static finals or once per constructor for instance variables. It also will optimize access to finals, despite the fact that it's actually unsafe to do so.

• Something else related to this absurd lack of control over who can modify an object and who cannot is that there is no notion of constant space: constantry is all per-class, not per-object. If I've got a loop that does

      String foo = "x";
  

  it does what you'd expect, because the loader happens to have special-case magic that interns strings, but if I do:

      String foo[] = { "x", "y" };
  

  then guess what, it conses up a new array each time through the loop! Um, thanks, but don't most people expect literal constants to be immutable? If I wanted to copy it, I would copy it. The language also should impose the contract that literal constants are immutable.

  Even without the language having immutable objects, a non-losing compiler could eliminate the consing in some limited situations through static analysis, but I'm not holding my breath.

  Using final on variables doesn't do anything useful in this case; as far as I can tell, the only reason that final works on variables at all is to force you to specify it on variables that are closed over in inner classes.

• The locking model is broken.
  • First, they impose a full word of overhead on each and every object, just in case someone somewhere sometime wants to grab a lock on that object. What, you say that you know that nobody outside of your code will ever get a pointer to this object, and that you do your locking elsewhere, and you have a zillion of these objects so you'd like them to take up as little memory as possible? Sorry. You're screwed.
  • Any piece of code can assert a lock on an object and then never un-lock it, causing deadlocks. This is a gaping security hole for denial-of-service attacks.

    In any half-way-rational design, the lock associated with an object would be treated just like any other slot, and only methods statically ``belonging'' to that class could frob it.

    But then you get into the bug of Java not doing closures properly. See, you want to write a method:

        public synchronized void with_this_locked (thunk f)
        {
          f.funcall ();
        }
    

    but then actually writing any code becomes a disaster because of the mind-blowing worthlessness of inner classes.

• There is no way to signal without throwing: that is, there is no way to signal an exceptional condition, and have some condition handler tell you ``go ahead and proceed anyway.'' By the time the condition handler is run, the excepting scope has already been exited.
• The distinction between slots and methods is stupid. Doing foo.x should be defined to be equivalent to foo.x(), with lexical magic for ``foo.x = ...'' assignment. Compilers should be trivially able to inline zero-argument accessor methods to be inline object+offset loads. That way programmers wouldn't break every single one of their callers when they happen to change the internal implementation of something from something which happened to be a ``slot'' to something with slightly more complicated behavior.
• The notion of methods "belonging" to classes is lame. Anybody anytime should be allowed to defined new, non-conflicting methods on any class (without overriding existing methods.) This causes no abstraction-breakage, since code which cares couldn't, by definition, be calling the new, ``externally-defined'' methods.

  This is just another way of saying that the pseudo-Smalltalk object model loses and that generic functions (suitably constrained by the no-external-overrides rule) win.

As I mentioned in my old (circa 1997-8)  review  Nikolai Bezroukov's Devil's Advocate Commentary on "Thinking in Java" by Bruce Eckel. Chapter 1

Java design flaws can prevent widespread use

No language is perfect. But some people that I respect are very critical of Java. Linux Torvalds (do not take his words for granted -- all he is doing all his life is just debugging Linux kernel ;-) in his interview to Inforword (see Linus Torvalds talks economics and operating systems)    said:

InfoWorld: What do you make of Java?

Torvalds: I dislike the hype. I think it's way overhyped. I'd like it to have a more proven track record and I think the licensing restrictions are hurting it. I understand why Sun wanted to have them in place, but I also think that it means Java does not get as well maintained. Right now, if somebody notices a bug in Java, it's pretty hard to fix unless you're inside Sun. But the major issue is that it's a good idea whose time has come. It's an idea that's been done before, but you didn't have the same kind of hardware power you have today. Also you didn't have the same kind of software interfaces, so right now it is possible to make Java efficient? Potentially, it's a great technology, but it's unproven and there's been way too much hype.

The author of STL Alexander Stepanov in an interview for Edizioni Infomedia srl  took an extremely critical view on Java. He said:

I spent several months programming in Java. Contrary to its authors prediction, it did not grow on me. I did not find any new insights -- for the first time in my life programming in a new language did not bring me new insights. It keeps all the stuff that I never use in C++ -- inheritance, virtual -- OOP gook -- and removes the stuff that I find useful. It might be successful -- after all, MS DOS was - and it might be a profitable thing for all your readers to learn Java, but it has no intellectual value whatsoever. Look at their implementation of hash tables. Look at the sorting routines that come with their "cool" sorting applet. Try to use AWT. The best way to judge a language is to look at the code written by its proponents...

Of course one can argue that Stepanov is interested in defending C++ as his STL library is now included in standard. Still IMHO there are several design flaws in Java, some of them probably serious. Among them:

• Very limited way for defining constants (static final).
• The Java's mix of objects and native types is confusing and over reliance on object paradigm makes procedural programming problematic even for tasks that should be better solved using procedural approach.
• String manipulation is complex. Java has immutable strings (I remember only one system programming language that has had a similar model for strings -- XPL; also string are immutable is script languages -- REXX is one example)  that are not byte oriented (they are Unicode strings with 16 bit per character) and StringBuffer class. The library of string manipulation functions is much weaker than in Perl or REXX.
• Control structures are pretty weak. Labeled break similar to PL/1 "leave" statement is the only "innovation".   With such a limited repertoire of control structures the absence of GOTO is IMHO a design flaw.
• I/O model is simplistic. As for formatted input it's even weaker than in C.
• Parameterized types (see for example  Parameterized Types for Java for possible extensions of the language).
• Java is too much based on OOP and there are many pitfalls involved in the OOP (see below) -- than mean they become pitfalls of the language.  These pitfalls threaten to undermined the acceptance and use of Java before its promises can be achieved.
• Garbage collection make language higher level, but at the same time less reliable in real-time situations.

There are also several implementation issues:

• The current generation of integrated environments are still pretty primitive and buggy. Jbuilder 2.0 is probably the best, but it still has a long way to go before it become a viable development tool for complex applications.
• JVM currently is not very reliable and can die during execution of the program that do tricky things with memory and data. In such a case debugging became a nightmare.  

The acceptance of Java on the client site is very limited. According to WSJ Java applets are used on less than 1% of all WEB pages with many sites abandoning the multimedia Java applets for simpler technologies such as Flash  and/or animated GIF’s.

OOP nirvana can be a fake

One should understand that OOP is an old hat and several OOP-based languages are 10 or more years old and still fail to achieve wide acceptance and are limited to narrow niches. The classic example of such a language is Smalltalk -- paradoxically only financial institutions used it to a limited extend in real world projects. Success was mixed although Smalltalk programmers were very well paid ;-)

OOP attempts to decompose the world into objects and claims that everything is an object. But saying that everything is an object not always provide an useful insight into the problem. Just think of sorting. Will it help to sort the file efficiently if you thing that the records are objects. Most probably not.

OOP starts with classes. But  the essence of programming are algorithms. Only when you understand them well, can you come up with optimal storage structures for solving the problem.

The words "religious" outline the last problem. Many people/authors now tend to look at programming styles and languages like religions. Object-oriented programming (OOP) is often treated like a new Christianity and religious zeal of converts is often border with stupidity. So it definitely attracts charlatans which propose magic cures like various object methodologies ;-).

IMHO OOP more looks more like a paradigm shift that a language breakthrough. Much like a religion OOP introduced entirely new and quite obscure terminology with the purpose of mystifying the real underling mechanisms. It has not added a single novel concept, but it emphasizes two old, and definitely useful, concepts:

• The binding of procedures to a data a structure (called object). New procedures are now called methods. But all we need for that is the procedure variable stored as a record field, available in languages since the early 60s (PL/1). What is really important is that it permits nice hierarchical partitioning of variables namespace using class boundaries...
• The second concept is that of constructing a new data structure (called subclass) by extending a given structure (the superclass). It's  essentially a variation of  like construct in PL/1.  The new concept here is to consider any structure as a new type and use type checking mechanism to prevent certain errors.

Thus, whereas in reality in Java you activate a procedure by calling it, sometimes in Java books it is incorrectly called sending of a message to the method. A new structure is no longer built by extending an existing structure, but by defining a subclass which inherits its superclass. A positive site of all this OOP blah-blah-blah is that many people learned for the first time about the important notions of data type, encapsulation, and of information hiding. This alone would have made the leaning of Java worthwhile, even if one didn't actually make use of its later on.

From the point of view of teaching OOP should probably be treated as an important aspect of programming in the large more like a methodology that a basis for a universal language. IMHO it should logically follows programming in the small and requires sound knowledge of procedural programming. And it should be compared with alternative method of integrating components like traditional shells, REXX and Perl.   In any case due to complexity Java is far from being the best first programming language. It's too far from the underling machine architecture of Pascal, C,  Modula. Even Perl and REXX are somewhat better.  They are much easier to understand than OOP approach and  they are sufficient in most cases for writing small and medium size programs.

Perl is a interesting example from the point of view of viability of OOP as a universal paradigm for programming in the large. Object-oriented features in Perl are somewhat counter-intuitive to the Perl way of life. At its heart, Perl is a language for creating scripts to handle routine text-processing tasks. Object-oriented design requires careful planning and adds a additional layer of complexity to the software development process. Why add this complexity to Perl?  It's a very useful language even without this layer.

OOP-orientation should not be a language issue. It is more a methodology, which, ideally, should be available in any language, but it is not suitable to any problem. Things that have state and change their state are natural candidates to be represented as objects.  Here are some guidelines to help decide if an object-oriented approach is appropriate:

1. Does your code manipulate a data structure that directly corresponds with a real-world object or that you can
   naturally think of as an object?
2. Is there a group of variables that you can group into structure or that are processed by the same set of functions?
3. Is there a group of functions that only operate on a defined set of variables?

If the answer to any of the above questions is "Yes", then you might benefit from an object-oriented approach.  Otherwise you will be in much better shape using regular procedure-oriented approach.  I think that GUI-centered programs benefit from OOP approach most.

I would like to stress the importance multithreading in Java. As for paradigm shift, multithreading can be compared to introduction of a local LAN instead of mainframe. That mean that we now have a bunch of small, autonomous PCs each with own CPU, communicating with each other via messages over the net. It takes some imagination to see a simple procedure call as a real  message passing mechanism -- only threads communicate through real messages. So true object model is intrinsically connected with multithreading, yet this connection is not understood well. True message mechanism presuppose that object (autonomous PC with its own CPU) was active before receiving it and will be active after processing it.  To certain extent this is a special case of concurrent programming. 

I would also like to see comparison of polymorphism, encapsulation, and inheritance with other approaches to programming in the large, for example with UNIX paradigm of using scripting language to glue small C-programs. For example as for encapsulation UNIX paradigm is as good or better then Java. All we have to worry about is what will be visible from the outside of UNIX utility are parameters one input and one output stream. Unix utilities are limited to one input and one output stream. But this is not critical limitation of the pipe model: for example VM/CMS pipes can have multiple input and output streams. That means that scripting language  + C approach is competitive with Java monolingual approach for a wide variety of problems. 

Polymorphism simply means that object type can vary. Probably the easiest way to achieve polymorphism is to represent everything as a text string.  Of course there is no free lunch and you need to pay for this but it is simple and pretty universal approach that now gets traction (XML, etc).  BTW polymorphism has nothing to do with inheritance or any other OOP mechanism.  Moreover polymorphism and generic programming to certain extent contradict OOP idea of inheritance.

If one discard all this OOP-oriented blah-blah-blah, inheritance is just a useful mechanism of working with structures. It is simple, yet a very powerful mechanism to identify and extract repeated part of structures. Inheritance brings "classification" into focus.  So programmers with a good classification skills will benefit from this approach most. Those that do not have these skills this apprach would most probably be a pain a the neck. BTW not only for them but also for those poor folk that will maintain their programs...

I would like to stress it again that  from the point of view of design the most important part of Java is a built-in multithreading. Other than that Java is pretty much "politically correct" C++. Threads are active objects, much like actors in actor based languages. They do not need to receive a message to be in the "active" state. They are independent and concurrent objects and really can communicate through asynchronous messages. Name of the method became like a kind of unique mail addresses.
... ... ...

Conclusions

Java should be considered a competitor/replacement  to VB and PowerBuilder, not C/C++ as originally intended. Java lacks the efficiency necessary for good GUI program even on a modern CPUs and that essentially created a niche for C#.  Beans and threads are the most important productivity enhancements in Java and are especially important in a corporate environment.  Good quality Java implementations appeared on the scene after its competitors in scripting world (especially VB and Python) were already established. Whether Java advantages are enough to persuade the hundreds of thousands of VB developers out there to switch remain to be seen. I think not. PowerBuilder probably will eventually be replaced by Java.

Java (and OOP in general, disregarding the amount of books published or money OOP missionaries make ;-) still needs to stand the test of the time. Don't put all eggs into one basket. It's more wise to consider Java as yet another (although important) programming language. Java is more suitable to programming in large than, say C or Fortran, but still it lacks the qualities of a real scripting language like Python. Knowledge of C is still very important for top Java programmers -- in real projects the critical parts (probably up to 20%) are better written in C as native methods. See classic Knuth paper for more details.

It is important to understand that Java sunset is also happening because there is a distinct element of fashion in today's programming culture and time for Java spot under the lights expired. New times requires new stars, so decision to open source Java while controversial still make strategic sense as it extends the momentum behind the language.  Still  consultants, language evangelists, academics and IBM brass all want the next new big thing to talk about. Java now is an old hat. That means that for me as perma-skeptic is probably a time for me to start to defend Java instead of attacking it: my views on "Java vs. scripting languages" in 2007 became too much part of the mainstream thinking :-) As Bryan W. Taylor in his paper   Java Is Dead, Long Live Java! – The Future of Java @ SYS-CON AUSTRALIA aptly noted:

The first big arena of innovation is the addition of scripting support. Some people rightly claim Ruby or Python is better the Java for some tasks. Groovy and Beanshell solve these same problems and will become a standard (in the JSR sense) part of the Java stack. Each offers something better than standalone scripting. Both integrate into a truly mixed environment with compiled bytecode and interpreted scripts interoperating smoothly. Beanshell's syntax offers as little surprise as possible for the Java developer and Groovy gives a Ruby-like syntactic efficiency, but can also be compiled to pure bytecode and reused seamlessly, a big improvement over JRuby or Jython.

Dr. Nikolai Bezroukov

Notes: Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected. This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books. The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link. Search Amazon by keywords:     Open directory Research Index

Old News ;-)

[Apr 23, 2008] The Sleep Scripting Project 2.1-b23

Changes: Command line options were added to dump script execution time and profile statistics. Java 1.4.2 compatibility was restored by removing an errant Java 1.5 call. The ordered hash miss policy mechanism was made more flexible.

[Mar 28, 2008] The Sleep Scripting Project 2.1-b21  by Raphael Mudge

About: Sleep is a Perl-inspired scripting language for the Java platform. Sleep has its own library of functions for performing common tasks as well as being able to utilize the Java class library. Sleep includes closures, coroutines, built-in debugging, and it is very extensible.

Changes: This release adds pushl and popl for managing local scopes and readAsObject and writeAsObject for interoperability with remote Java applications. It fixes a memory leak caused by long running loops and fixes several callcc issues.

[Jan 2, 2008] Java is becoming the new Cobol InfoWorld Analysis  by Bill Snyder

It took some almost ten years to realize that Java is a new Cobol ;-)

2007-12-28 | Infoworld

Simply put, developers are saying that Java slows them down. “There were big promises that Java would solve incompatibility problems [across platforms]. But now there are different versions and different downloads, creating complications,” says Peter Thoneny, CEO of Twiki.net, which produces a certified version of the open source Twiki wiki-platform software. “It has not gotten easier. It’s more complicated,” concurs Ofer Ronen, CEO of Sendori, which routes domain traffic to online advertisers and ad networks. Sendori has moved to Ruby on Rails. Ronen says Ruby offers pre-built structures — say, a shopping cart for an e-commerce site — that you’d have to code from the ground up using Java.

Another area of weakness is the development of mobile applications. Java’s UI capabilities and its memory footprint simply don’t measure up, says Samir Shah, CEO of software testing provider Zephyr. No wonder the mobile edition of Java has all but disappeared, and no wonder Google is creating its own version (Android).

These weaknesses are having a real effect. Late last month, Info-Tech Research Group said its survey of 1,850 businesses found .Net the choice over Java among businesses of all sizes and industries, thanks to its promotion via Visual Studio and SharePoint. Microsoft is driving uptake of the .Net platform at the expense of Java," says George Goodall, a senior research analyst at Info-Tech.

One bit of good news: developers and analysts agree that Java is alive and well for internally developed enterprise apps. “On the back end, there is still a substantial amount of infrastructure available that makes Java a very strong contender,” says Zephyr’s Shah.

The Bottom Line: Now that Java is no longer the unchallenged champ for Internet-delivered apps, it makes sense for companies to find programmers who are skilled in the new languages. If you’re a Java developer, now’s the time to invest in new skills.

[Jan 2, 2008] Java is Becoming the New Cobol

I think that the author of this comment is deeply mistaken: the length of the code has tremendous influence of the cost of maintenance and number of errors and here Java sucks.

Linux Today

Timh - Subject: Java DOES "slow you down" ( Jan 3, 2008, 01:59:40 )

It's true. putting together an Enterprise-scale Java application takes a considerable amount of planning, design, and co-ordination. Scripted languages like Python are easier - just hack something out and you've a working webapp by the end of the day. But then you get called in at midnight, because a lot of the extra front-end work in Java has to do with the fact that the compiler is doing major datatype validation. You're a lot less likely to have something blow up after it went into production, since a whole raft of potential screw-ups get caught at build time. Scripting systems like Python, Perl, PHP, etc. not only have late binding, but frequently have late compiling as well, so until the offending code is invoked, it's merely a coiled-up snake. In fact, after many years and many languages, I'm just about convinced that the amount of time and effort for producing a debugged major app in just about any high-level language is about the same. Myself, I prefer an environment that keeps me from having to wear a pager. For those who need less sleep and more Instant Gratification, they're welcome to embrace the other end of the spectrum.

[Dec 14, 2007] Java vs Ruby a Comparison of the Key Elements

Not in depth but better then nothing...  conclution is exptemly weak: "Although Ruby is similar to Java and has parallel features, Ruby is not a replacement for Java as implied by an ONJava article Ruby the Rival. Just as Java EE is the enterprise framework for developing Model-View-Controller applications with Java, Ruby on Rails is the Model-View-Controller framework for Ruby."

Exception Handling

In Java, exceptions are handled using the try-catch-finally construct; this consists of one try block, followed by one or more catch blocks, optionally followed by a finally block. In the try block, some statements are run that might generate an exception. Each of the catch blocks handles an Exception. In the optional finally block, some statements may be run to close objects. The finally block is always run after the application exits the try block. An example of a try-catch-finally block is as follows, in which the try block creates a Connection object with a MySQL database, in the catch block SQLException is handled, and in the finally block the Connection object is closed.

try {
   String url="com:mysql:jdbc://localhost:3306/test";
   Connection connection=DriverManager.getConnection(url, "root","");
} catch (SQLException e) {
   System.err.println("Caught: SQLException: "
                      + e.getMessage());
} finally(){
   connection.close();
}

In Ruby, exceptions are handled using begin-rescue-ensure-end construct. The construct consists of one or more rescue clauses that consist of statements to run when a specified exception occurs. The optional ensure clause consists of statements that are always run whether an exception occurs or not. The rescue clause in Ruby is equivalent to the catch clause in Java. The ensure clause in Ruby is equivalent to the finally clause in Java. The begin-rescue-ensure construct is shown below.

begin

rescue RubyException1
Statements to run when RubyException1 occurs.
rescue RubyException2
Statements to run when RubyException2 occurs.
ensure
Statements to run whether an exception occurs or does not occur.

end

[Jul 10, 2007] chandanlog(3C) The Story of OpenGrok - the Wicked Fast Source Browser

[Jul 10, 2007] OpenGrok at OpenSolaris.org

OpenGrok is a fast and usable source code search and cross reference engine. It helps you search, cross-reference and navigate your source tree. It can understand various program file formats and version control histories like SCCS, RCS, CVS, Subversion and Mercurial. In other words it lets you grok (profoundly understand) the open source, hence the name OpenGrok. It is written in Java.

OpenGrok is the tool used for the OpenSolaris source browser and search.

Downloads

• opengrok-0.4.tar.gz (4M) - Source and required binaries
• OSOLopengrok-0.4.pkg (3M) - Solaris Package

Requirements

• Latest Java
• A servlet container like GlassFish or Tomcat
• Exuberant Ctags
• Subversion 1.3.0 if subversion support is needed
• Mercurial if Mercurial support is needed

[Jun 12, 2007] Open Sources InfoWorld If LAMP is so easy, why isn't Java dead June 12, 2007 1027 AM By Matt Asay

Nice, Cobol-style arguments ;-). As one reader noted in his comment "the extension of that logic is that any hard-to-dismantle legacy technology is here because of quality. "

This is the question that Peter Yared asks in his blog, and it's fascinating given that he founded a company (ActiveGrid) based on the premise that Java was going to get shunted aside, as Stephen O'Grady notes. My company, Alfresco, is Java-based, so I'm biased in this, but it's interesting to hear the reasons Peter gives for Java's resilience:

1. Java has become easier.
2. It's really hard to move the world off a platform (Java) it is happy with.

On this latter point, Peter writes:

Even if it was quicker and cheaper to build a LAMP application than a Java application, the cost of getting a new software platform approved is pretty astronomical at a lot of enterprises. Adding staging servers, management software, security auditing, training staff in new technologies, etc. is very expensive. Linux and Apache have been enormously successful in the enterprise since they were brought in as a horizontal solution. Bringing in Linux to replace Solaris and running Apache for all static content significantly reduces costs. But running PHP or Python for some applications when an enterprise is already supporting Java and perhaps .Net is not viable for most enterprises, as the cost each added platform multiplies support costs.

This has certainly been my experience. Enterprises are heavily invested in J2EE (or .Net), and just aren't throwing out that expertise. They're adding PHP expertise, but there is still the lion's share of the enterprise market for J2EE/.Net applications.

On the other side of the ledger, Google et al. are building massive businesses on the LAMP stack. Is LAMP the future of the enterprise and J2EE/.Net are its resilient past? I'm not sure, but based on the deals with which I'm involved, it's a past with a healthy future. I suspect there's ample room for both.

=========== Feedback ==============

hmm. you don't quite take a firm stand here, but i'll say this: the extension of that logic is that any hard-to-dismantle legacy technology is here because of quality. that may be true of some things. but it also happens just because organizations feel no rush to rebuild, but at the same time are not investing deeper.

i really don't like Java. I just don't. Our enterprise any Java apps, and they are not popular. Many Java devs respond to negative Java experiences saying that the problems lay at the feet of the developer, not the language.

Fine, that may be true. But I will not approve any *new* project or tool that is Java-based.
I will not rush to kill off existing ones, but no more new Java stuff will come in to our organization. On the server and the client, it's been way too slow for us.

On a different note, I quite enjoy your blog. Keep it up!

Posted by: jose wvh at June 12, 2007 05:32 PM

---

FWIW, Blogger was written in Java, and Gmail was written largely in Java.

Posted by: Scott Mace at June 13, 2007 11:22 AM

---

Why isn't java being clobbered by the likes of the LAMP stack, ROR and etC?

For one, those other platforms are domain specific, web only.

Java on the other hand is general purpose. You can write Desktop Apps with it, Mobile Games (don't Blue Ray DVD players use Java now too?), Server Apps (not everything is a web-app), it has great interconnectivity api's with legacy systems (databases, ERP's).

Moreover, there's been alot of open source innovation in the Java Space during the last couple of years. Just look at Apache's Java Portfolio, or even SourceForge.

It's clear from the amount of code produced that Java as a platform is stable and that people are generally more productive in it than the competition (C++, C) and definitely more secure to boot.

It's also the only platform that I know of that let's you choose. Multiple JDK's are available (Sun, IBM, Bea, and now OpenJDK), moreover - there's a myriad of enterprise quality capable application servers for you to choose from. A few examples from the open source camp includes the JBOSS App Server, Apache Geronimo, Sun Glassfish and etc. That's not counting the commercial offerings.

If one looks at 800 lb gorilla's in the enterprise space (eq. SAP, Oracle, IBM), there's one thing that's common - Java Based middleware stacks (interoperable) middleware stacks (eq. SAP Netweaver, Oracle Fusion, IBM WebSphere).

The only other platform stack that matches it is .NET (and we all know what happens when MS gets involved).

Posted by: Funks at June 14, 2007 01:40 AM

JavaOne 2007 Prodigal Sun returns to the client by Elliotte Harold

Many language proposals

Numerous sessions addressed language proposals such as closures, reified generics, type inference, and more. These topics were even more discussed in hallway conversations and at various bars after the conference.

I can't rule out the possibility that my internal filters were steering me into the conversations I already agreed with, but I really got the impression that there's a growing disconnect between the developers designing the next version of the Java language and the developers using it. While Sun speakers kept repeating the message that we should all be using Java 6, many of the attendees had only switched to Java 1.4 for production in the last year, and most were just starting to get comfortable with Java 5. Java 6 wasn't even on their radar.

Going forward, attendees were hugely enthusiastic about breaking with the past and cleaning up the Java libraries, even at the expense of backward compatibility. By contrast, Sun speakers continued to stress the need for backward compatibility at all costs.

As for new features in the language, most attendees were lukewarm at best, even when discussing sexy topics like closures. To the extent that the Java language wasn't meeting their needs, most attendees seemed to prefer learning a a new language entirely, such as Scala, rather than adding more features to the Java language. Fortunately for them, Neal Gafter predicted that there will be no new language features in Java 7. Closures and other such major changes will have to wait for Java 8.

Ruby and Scala were the big winners here. In this much, at least, Sun and the rest of the Java world are in sync. Sun is beefing up support for dynamically typed scripting languages in the virtual machine and in its NetBeans IDE. It seemed there were almost as many talks about using NetBeans for Ruby and Rails development as there were about using it for Java development. TextMate finally has some real competition for the Rails community.

JavaOne 2007 Prodigal Sun returns to the client by Elliotte Harold

Besides authoring, deployment has been a classic problem for rich Internet applications written in Java code. Major consumer applications such as LimeWire stick with outdated Java Runtime Environments (JREs) because they don't want to incur the hassle of bundling larger, more recent VMs. Various sessions at JavaOne this year discussed ongoing efforts to address deployment issues. In particular, Ethan Nicholas told us that "Easy Deployment Is Finally Here," though he may have jumped the gun a little bit. Most of the proposed solutions he described (discussed below) should see the light of day in Java 7 early next year. Some of the more under-the-hood changes may even be released in an update to Java 6.

Redesign the Installer

Step 1 is an installer your parents could use unassisted. The current installers are ugly, complicated, and don't do what you expect half the time. They're really only adequate for developers. The next JRE installer will be cleaned up and aimed at end users.

Sun is also working on improving the ActiveX controls, plug-ins, and JavaScript programs that enable a browser to detect whether a Java VM is installed and, if so, in which version. A new Deployment Toolkit should make it easier to prompt the user to install a Java VM if they don't have it or don't have the right version. The Deployment Toolkit is for the Windows® operating system only for now, but it will work on Firefox as well as Internet Explorer®.

For the Mac, Sun is still relying on Apple to ship a Java VM with every Mac sold. This works well enough until Sun starts saying silly things like "It's time to move to Java 6" (a mantra repeated by various Sun employees throughout the conference). Apple likely won't even have a Java 6 VM until this fall, and most Macs won't be upgraded for some years to come.

The JRE should be in much better shape on Linux®. Sun supports Linux officially, and now that the JDK is under the GPL, client-focused distros like Ubuntu can start bundling the JRE. (A lot of laptops were running Ubuntu at the conference. It has clearly become the desktop distribution of choice.) By this time next year, users shouldn't have to download or install the JRE onto Linux at all. It should just be there.

Warm up cold starts

Step 2 is reducing VM startup time, especially for applets. The 10-second pause the first time a browser encounters an applet would be considered a denial of service attack if we actually cared about users. Sun could launch the VM as soon as the browser starts up, but that would occupy a lot of memory that wouldn't be needed most of the time. Instead, Sun is planning to preload .class files into the disk cache. This doesn't occupy RAM or take up CPU like starting the virtual machine would, but it does allow for much faster startups when the VM is launched the first time. Look for this technology to appear in a "Consumer JRE" late this year or early next year.

For standalone applications, it may be possible to go even further. Class file verification and just-in-time compilation can be done before the application runs, or perhaps just the first time the application runs. The verified, compiled code can be stored. Subsequent runs can start right away with the real compiled native code rather than stopping to do verification and compilation first.

Shrink the JRE

Step 3 is to shrink the JRE and even allow custom VMs for custom apps. Work is ongoing to produce a small (maybe 4MB) basic distribution that is just smart enough to run "Hello World" and download whatever else it needs on the fly. Let's face it: who really needs org.omg.CORBA and javax.imageio anyway? Third-party developers will be able to create virtual machines that bundle just the classes their application requires. For many applications, the custom VM could reduce the memory needed by half or more.

From JARs to JAM

Finally, step 4 is to eliminate classpath hell. As explained by Stanley M. Ho and Michal Cierniak, Java 7 will introduce a new JAR format called Java Archive Module (JAM). A JAM file is a JAR file (which itself is just a ZIP file with a different extension and some metadata), but it contains extra metadata and allows JARs to be nested. That is, a JAM file can contain one or more JAR archives. Thus it will be possible to bundle all the classes an application needs into a single file. Furthermore, the additional metadata will enable classes to declare dependencies not just on other JARs but on specific versions of other JARs. If you know your application works with Xerces-J 2.6.1 but encounters subtle bugs with 2.6.2, you can ask for 2.6.1 explicitly. Finally, there will be repositories for storing all the different JARs. You can have separate global, bootstrap, application, local, and even network repositories. (Sounds like an opportunity for conflict to me, actually.) jre/lib/ext should be emptied.

None of these features is earth shattering individually, but taken together they do add up. The end result will be a small but noticeable improvement in the end user's Java client experience.

Java Community News - Groovy or Java How Does a Developer Decide

Summary

A recent DeveloperWorks article compares Groovy and Java code side by side, demonstrating Groovy's conciseness. Given the tradeoffs between Java and Groovy, where have you used one versus the other?

In a recent IBM DeveloperWorks article, Reducing Code Noise with Groovy, author Scott Hickey, shows several code examples written in both Java and Groovy to demonstrate how Groovy can reduce the volume of code to express the same idea.

For example, he shows a Bike JavaBean in both Java and Groovy. The Groovy example takes advantage of Groovy's default property semantics. If you simply provide a type and a name for an instance variable, such as String manufacturer, Groovy will make that variable private and provide a public set and get method. This makes the code much smaller, if what you want is a private instance variable with public get and set methods.

In addition, he shows an example where Groovy's duck typing (invoking methods based solely on descriptor, irrespective of the type of object) obviates the need for an interface that was required by the corresponding Java example. In this case Groovy allowed you to provide the same functionality with one type instead of two.

In a sidebar, the author admits that although modern Java IDEs can facilitate the coding of the Java version, because code is read more than it is written, Groovy's more concise code is still advantageous.

IDEs such as Eclipse make it easy to automatically create getters and setters. These tools also make it easy to extract interfaces from concrete classes to facilitate refactoring. I'd argue, however, that code is read more often than it is written. Unfortunately, developers still have to wade through generated code and source files to discern what a program is really doing. With the high quality of Java tooling available, it is debatable whether or not there is a huge savings in the keystrokes to create the Groovy source, but at a glance, you can see that the Groovy code is more concise, easier to decipher, and less complex. In practice, this is a powerful advantage across the scope of applications that have hundreds of classes and thousands of lines of code.

In the conclusion, the author makes the point that Groovy helps reduce the "noise" level required by Java:

All in all, using Groovy removes a significant amount of noise that accompanies our typical Java programs. And that's a pleasant sound indeed!

The author doesn't mention tradeoffs of that noise reduction, such as the fact that duck typing makes it harder for IDEs to perform refactorings, or for JVMs to optimize for speed. Nevertheless, the greater code conciseness that Groovy offers is important. For what kinds of tasks have you used Groovy? Where was it a good fit, where not?

------------

 Groovy at No-Fluff-Just-Stuff conference Posted: Sep 23, 2006 10:57 AM

Just attended a Java No-Fluff-Just-Stuff conference last week and was interesting from this perspective. Last year's conference had a significant Ruby theme (with Dave Thomas, Bruce Tate, and others) talking up Ruby and Ruby on Rails.

This year there were no Ruby sessions and no presentations had much occasion to mention Ruby (or JRuby or Rails).

Instead there were sessions on Groovy the language and another on Grails. A session on embedding scripting languages dealt mostly with Rhino and Groovy as thematic examples. A session on Java embeddable rules engines (JESS, Drools, etc) used Groovy as the example rules script language. At a panel discussion where the question was asked what is the most significant thing on the horizon, one panelist said that 2007 would be the year of emergence for Groovy as a significant tool for Java developers.

Despite Sun's endorsement of JRuby it is Groovy that was center stage as the scripting language for the JVM at this conference.

Groovy is further along than JRuby, as for instance, it already does byte code generation and indeed Groovy scripts can be compiled to a .class file as opposed to executed-only. Hence you can write Java classes using Groovy and Groovy features while still generating a .class file that is incorporated into an application .jar file (will still need the Groovy .jar runtime at deployment).

There is also a feature that works similar to .jsp where a script file can be deployed, but is compiled and cached. When modified, that is detected and the script file gets automatically compiled again.

Grails is also quite far along. It could perhaps reach 1.0 milestone in a few months. So in 2007 both Groovy the language and Grails should be at 1.0 release status.

[Apr 5, 2007] Dynamic language in Java or otherwise, specifically Groovy and Grails by David Herron

April 30, 2006 (weblogs.java.net/blog/robogeek/ ) The Java Posse gang just posted Interview with Graeme Rocher of Grails which serves as a great introduction and/or overview of both Groovy and Grails (a.k.a. Groovy on Rails). I've used Groovy just a teensy bit, so I won't go into the language at all. If you want to look further, there is groovy and grails home pages chock full of information.

What I want to do is contrast the state of different dynamic languages.

There are a wide set of the dynamic languages ... and many prognosticators have proclaimed Java would die due to the growth in popularity for these languages. But what's interesting in this story is the various dynamic languages that ride on top of Java, as Groovy does. For a language implementer to ride on top of Java, that gives a strategic advantage the other languages do not have.

Namely ... the rich swath of libraries existing for Java, and the infrastructure such as Java EE and web services that already exist and can be reused by the language author.

I should mention again -- as I've written before -- given the scripting language support in Mustang (the JSR223 javax.script packages), it should become easier for new languages to ride on top of Java.

In any case, in the interview Graeme Rocher makes a good case for the strategic advantage I'm talking about. e.g. in the Groovy/Grails system, they can use the Hibernate persistence engine, and they don't have to invent their own. e.g. they've made sure they can run inside a Java EE container, giving them all the deployability, infrastructure, web and other services, etc, all at a relatively small cost to them.

In comparison the other languages have to reinvent the world in order to bring some feature or infrastructure item into their environment.

[Apr 4, 2007] Book excerpt Your way to Groovy - Java World

Groovy is often referred to as a scripting language—and it works very well for scripting. It's a mistake to labe