May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Scripting Languages for Java vs. Pure Java

Java as a New

It's not a real ad


Programming Languages Design

Recommended Links

Introductions and Tutorials



Reverse Engineering Security
Beanshell Jython Groovy Rhino Sleep Pipes for NetREXX JAWK Coroutines Regex
Gosling on Java Java Hype Coding Style Java Prettyprinters Open source Websphere Random Findings Humor Etc
The temperature is great. It's just hot enough that your taste buds say, "Ouch! Hot! We must be drinking coffee!" However, were it not for that, they might not know. The taste is almost nothing initially. The flavor seeps in gradually, but it's never strong. It's quite weak, in fact. It's like getting coffee breath without drinking the coffee
I fear the new object-oriented systems may suffer the fate of LISP, in that they can do many things, but the complexity of the class hierarchies may cause them to collapse under their own weight.

(Bill Joy)

C++ is history repeated as tragedy. Java is history repeated as farce. (Scott McKay)
Over the years I've used and created a wide variety of scripting languages, and in general, I'm a big fan of them. When the project that Java came out of first started, I was originally planning to do a scripting language. But a number of forces pushed me away from that.

James Gosling, Dec 15, 2005

Sun is gone but Java won the marketplace and became a new Cobol. In a sense Java is a winner and probably will not be displaced by other language anytime soon.

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 without its speed. 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 is even 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 (may be the need for a mainstream language with dynamic storage allocation), but being in the right place at the right time definitely is of paramount importance. Java initially was sold as a Web development language; 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. After something is entrenched, many things that are crucial for a new kid on the block simply does not matter. Inertia is a huge force. 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 are such that it would be considered to belong to the class of high end servers ten year ago and supercomputers 15 years ago (we assume 2-4GB of memory and dual core 2-3GHz CPU with a single 120-250GB 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. It is a language that, as Stepanov aptly 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 is 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 (like IBM's Webshere, which IBM will happily sell to you ) 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 good, but far from being guaranteed. It cut too many corners.

While run-time environment in Java eventually become pretty sophisticated, the language itself stagnated at 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 much cheaper than in C++. Also Java is language for dummies. It is castrated language as all things that can cut you like pointers are surgically removed. Which probably OK, because it is difficult to overestimate level of incompetence of a typical commercial programmer, especially outsource programmer.

From the computer science point of view, as a programming language Java is even worse than 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) and just repeats old mistakes. It has a couple of minor innovations on runtime level (jars, multithreaded garbage collection, etc). In most areas of language design Java represents one step forward and two steps back. It can be viewed as essentially scripting language run time 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. True it parasites on very fashionable OO paradigm and nothing can hurt the programming language more then being out of fashion. Actually in the past pretty innovative language -- PL/1 -- had fallen as a victim of structured programming fundamentalism (and subsequent rise of Pascal proved that being fashionable does matter).

In a way PL/1 even now might be competitive with Java in development costs (IBM compilers were real masterpieces of compiler writing and simplified development dramatically). It was a solid, small by today standards and expressive language with its incredible quality of optimizing and debugging compilers on IBM mainframes: both remain to this day real masterpieces of software engineering, reminder that once upon the time IBM was a great software development company...

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 became much lower. Architectural flaws in run time implementation also surfaced. Due to them Microsoft's CLI technology can run Java faster than any JVM. With Microsoft CLI available on Suse (mono) part of Java developers switched to C# but their share is still not enough to make a dent in the language adoption.

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

As I already mentioned several times, my main frustration with Java is connected with the fact that it is half-way from C++ to real scripting language like Python. This feeling was aptly formulated in this critique on Java:

The creators of Java tried to make a better C++. But they ended up with a language that is ugly, hard to read and that requires an inordinate amount of typing because of a variety of pedagogical restrictions imposed by Java's creators.

This "inordinate amount of typing" means that on real programs the language might actually be lower level then C++ (measured in the ration of lines of code) and not much faster then Perl/PHP/Python (C++ runtime is definitely faster, but program in Perl/PHP/Python are more high level and that means that compilers/interpreters can deploy more sophisticated algorithms).

We can ignore Simson Garfinkel's claims that Java is unsuitable for "major desktop applications":

Simson Garfinkel: Just because Java has created an industry, just because some people are being paid more than $250,000 a year for writing Java programs, that doesn't mean that Java is a good thing.

With the current 3.6 Ghz CPUs you probably can write a really usable major desktop apps in Java (Eclipse and Tivoli Advance Monitoring 6.1 demonstrates that it is possible). But on such desktops similar GUI can be developed in, say, Python twice faster and have a codebase which might be three times smaller. This is an important advanatage.

Portability between similar architectures (for example Solaris, AIX, HP-UX, Linux) that matters most in the current economic environment is actually slightly limited in Java: the more complex the product is the less chances are that it will work. But tremendous industry momentum behind Java and money that IBM and Sun are putting into it lead to quick imporments in this area to the expent that now it is safe to develop on windows and deploy, say on Solaris major financial applications. The quality of the "on the fly" compiler also was gradually improved.

But it is "inordinate amount of typing" that really hurts: the language is verbose to the level that you cannot but hate it despite the fact that in some areas it does represents a modest advance over C++. I mean things like slightly better strings implementation. It is pretty funny that it took designers of C-style languages almost 40 years to relearn that fact that PL/1 designers made right from the first time: strings should be an internal datatype (or several datatypes as Unicode string is different from a 8-bit string) as well as automatic memory allocation. As we know one of the simplifications of C as PL/1 derivative was to get rid of PL/1 strings type. That Thompson decision was probably OK (and even, in a deceptive way, elegant) solution if you use the language just for writing an OS for a computer with 128K or 256K of memory (but even here he might missed an opportunity to implement at least XPL-style string type, which are useful for error messages). But it proved to be a huge mistake if you are using the same language for writing a complier or other applications ;-).

Moreover Java OO libraries looks like new Babylon tower that buries the naive developer in complexity and redundancy before he realize the magnitude of the threat ;-). Loading of several dozens of libraries even of a very fast computer makes start of any Java application really painful operation (a good example is IBM client for Tivoli Enterpise Console). Like in Turing Machine everything is possible in Java and writing of any non-trivial program takes just too long.

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.

With all those money spend Java definitely is an OK environment. But 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: Considering proprietary languages such as Java and C#, was the decision to make C free deliberate? C users sometime complain that standardization bodies have no teeth and cannot force vendors to provide standard-compliant implementations. What is your preferred model of language development and standardization?

Dennis Ritchie: I can't recall any difficulty in making the C language definition completely open -- any discussion on the matter tended to mention languages whose inventors tried to keep tight control, and consequent ill fate.

I'm just an observer of Java, and where Microsoft wants to go with C# is too early to tell. Although Sun doubtless has spent more on Java as a strategic tool than would be justified simply by garnering some publicity for neat research work by Gosling and company, they've been quite open about the language specification as such. But of course they have been regarding the whole Java package (with libraries) as strategic versus Microsoft and other competitors.

True enough that standards bodies themselves have weak teeth, but they do have influence and importance when a language begins to be widely used. Partly this is simply because it does allow public comment, partly because it adds a certain gravitas to the project. If there is an ISO or ANSI standard, and you distribute a product that claims to conform, your customer has at least a hook for arguing to you when it doesn't.

On the other hand, the "open evolution" idea has its own drawbacks, whether in official standards bodies or more informally, say over the Web or mailing lists. When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn't developed under the advice of a worldwide crowd. C is peculiar in a lot of ways, but it, like many other successful things, has a certain unity of approach that stems from development in a small group. To tell the truth, I don't know how Linus and his merry band manage so well -- I couldn't have stood it with C.

This whole area is complicated and there is no single lesson to be drawn from its history, except that early and extreme attempts at close control are likely to be detrimental. When will we have a C99-compliant edition of The C Programming Language? (See Resources for a link.)

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 []:

"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:

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:

There are also several implementation issues:

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:

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


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

Top Visited
Past week
Past month


Old News ;-)

2005 2004 2003 2002 2001 2000 1999

"It has come to our attention that some people want to program in things other than Java"

Gilad Bracha, Sun

[Nov 08, 2015] The Anti-Java Professor and the Jobless Programmers

Nick Geoghegan

James Maguire's article raises some interesting questions as to why teaching Java to first year CS / IT students is a bad idea. The article mentions both Ada and Pascal – neither of which really "took off" outside of the States, with the former being used mainly by contractors of the US Dept. of Defense.

This is my own, personal, extension to the article – which I agree with – and why first year students should be taught C in first year. I'm biased though, I learned C as my first language and extensively use C or C++ in projects.

Java is a very high level language that has interesting features that make it easier for programmers. The two main points, that I like about Java, are libraries (although libraries exist for C / C++ ) and memory management.


Libraries are fantastic. They offer an API and abstract a metric fuck tonne of work that a programmer doesn't care about. I don't care how the library works inside, just that I have a way of putting in input and getting expected output (see my post on abstraction). I've extensively used libraries, even this week, for audio codec decoding. Libraries mean not reinventing the wheel and reusing code (something students are discouraged from doing, as it's plagiarism, yet in the real world you are rewarded). Again, starting with C means that you appreciate the libraries more.

Memory Management

Managing your programs memory manually is a pain in the hole. We all know this after spending countless hours finding memory leaks in our programs. Java's inbuilt memory management tool is great – it saves me from having to do it. However, if I had have learned Java first, I would assume (for a short amount of time) that all languages managed memory for you or that all languages were shite compared to Java because they don't manage memory for you. Going from a "lesser" language like C to Java makes you appreciate the memory manager

What's so great about C?

In the context of a first language to teach students, C is perfect. C is

  • Relatively simple
  • Procedural
  • Lacks OOP features, which confuse freshers
  • Low level
  • Fast
  • Imperative
  • Weakly typed
  • Easy to get bugs

Java is a complex language that will spoil a first year student. However, as noted, CS / IT courses need to keep student retention rates high. As an example, my first year class was about 60 people, final year was 8. There are ways to keep students, possibly with other, easier, languages in the second semester of first year – so that students don't hate the subject when choosing the next years subject post exams.

Conversely, I could say that you should teach Java in first year and expand on more difficult languages like C or assembler (which should be taught side by side, in my mind) later down the line – keeping retention high in the initial years, and drilling down with each successive semester to more systems level programming.

There's a time and place for Java, which I believe is third year or final year. This will keep Java fresh in the students mind while they are going job hunting after leaving the bosom of academia. This will give them a good head start, as most companies are Java houses in Ireland.

[Nov 08, 2015] Abstraction

Filed in Programming No Comments

A few things can confuse programming students, or new people to programming. One of these is abstraction.

Wikipedia says:

In computer science, abstraction is the process by which data and programs are defined with a representation similar to its meaning (semantics), while hiding away the implementation details. Abstraction tries to reduce and factor out details so that the programmer can focus on a few concepts at a time. A system can have several abstraction layers whereby different meanings and amounts of detail are exposed to the programmer. For example, low-level abstraction layers expose details of the hardware where the program is run, while high-level layers deal with the business logic of the program.

That might be a bit too wordy for some people, and not at all clear. Here's my analogy of abstraction.

Abstraction is like a car

A car has a few features that makes it unique.

  • A steering wheel
  • Accelerator
  • Brake
  • Clutch
  • Transmission (Automatic or Manual)

If someone can drive a Manual transmission car, they can drive any Manual transmission car. Automatic drivers, sadly, cannot drive a Manual transmission drivers without "relearing" the car. That is an aside, we'll assume that all cars are Manual transmission cars – as is the case in Ireland for most cars.

Since I can drive my car, which is a Mitsubishi Pajero, that means that I can drive your car – a Honda Civic, Toyota Yaris, Volkswagen Passat.

All I need to know, in order to drive a car – any car – is how to use the breaks, accelerator, steering wheel, clutch and transmission. Since I already know this in my car, I can abstract away your car and it's controls.

I do not need to know the inner workings of your car in order to drive it, just the controls. I don't need to know how exactly the breaks work in your car, only that they work. I don't need to know, that your car has a turbo charger, only that when I push the accelerator, the car moves. I also don't need to know the exact revs that I should gear up or gear down (although that would be better on the engine!)

Virtually all controls are the same. Standardization means that the clutch, break and accelerator are all in the same place, regardless of the car. This means that I do not need to relearn how a car works. To me, a car is just a car, and is interchangeable with any other car.

Abstraction means not caring

As a programmer, or someone using a third party API (for example), abstraction means not caring how the inner workings of some function works – Linked list data structure, variable names inside the function, the sorting algorithm used, etc – just that I have a standard (preferable unchanging) interface to do whatever I need to do.

Abstraction can be taught of as a black box. For input, you get output. That shouldn't be the case, but often is. We need abstraction so that, as a programmer, we can concentrate on other aspects of the program – this is the corner-stone for large scale, multi developer, software projects.

[Jun 15, 2009] JRuby to live on after Sun-Oracle merger, engineer says ITworld

May 6, 2009 |

JRuby, a Sun Microsystems-driven implementation of the Ruby language for the Java Virtual Machine, is being used in a range of applications including one to battle infectious diseases. But like other Sun technologies, it remains to be seen how Oracle, which plans to buy Sun, will deal with it.

Still, a key developer of JRuby, Sun Senior Staff Engineer Charles Nutter, expects open source JRuby to do just fine. "I think JRuby, since it's an entirely open source, community-driven project, is going to live beyond any uncertainty that might come out of this," Nutter said during an interview Tuesday at the RailsConf 2009 conference in Las Vegas.

[ Related: "Is Java as we know it doomed?" | InfoWorld's Neil McAllister shows what Oracle's real motivation may be in buying Sun. | Sun's efforts to make Java open source have also led to decidedly mixed reviews. ]

While stressing he had no idea what would transpire between Oracle and Sun, Nutter added that he knows JRuby will survive.

Oracle announced its intentions to buy Sun for $7.4 billion last month. Although the company has shed little light on what it intends to do with the many Sun technologies, Oracle has been positive about Java.

JRuby, particularly when paired with the Ruby on Rails framework, has been finding its way into critical applications. In addition to running on the Google App Engine cloud platform, the state of Utah is using JRuby on Rails in an open source application to fight infectious diseases, Nutter said. JRuby also is being deployed in a refueling application at the Oslo airport.

"Not only is JRuby refueling planes, we're actually battling swine flu," Nutter said during a presentation at the conference.

Work continues on upgrades to JRuby. Version 1.3 is planned for release next week and features fixes for Google App Engine and performance work.

JRuby 1.4, anticipated for release this summer, will focus on Java integration to make it easier to integrate directly on Java frameworks and call Java libraries, Nutter said.

Another capability eyed for JRuby 1.4, dubbed Nailgun, will help JVM startup times by maintaining a "warm" JVM in the background, Nutter said.

"We will also have a compiler that allows you to run Ruby code into a normal Java class that you can construct and call methods on," said Nutter. "The benefit of that is you can integrate Ruby code into any part of a Java stack and you'll never know that it's actually Ruby code running."

[Dec 22, 2008] CodeExplorer 1.2 by Alexei Orishchenko

About: CodeExplorer is Idea Plugin for Java code analysis. It finds all method call chains to a method, what methods are called from a method, and more. Analysis results (call graph - methods and calls between them) are shown on a handy diagram in the CodeExplorer tool window.

Changes: This release adds an interface method node (with edges to methods that implement it) and method filters, opens analysis results in a new tab, calls long operations with a progress dialog, adds more commands to the node context menu, and fixes the inner class method name and unit analysis.

[Jul 10, 2008] Detangler 0.4 by DeNova

About: Detangler is a Java Swing thread debugger. No changes to your code are needed to find the exact line where a bug is. Detangler solves problems such as incomplete and incorrect displays, events happening in the wrong order, gray windows, lockups, and slow response that gets slower with more use. These symptoms are usually caused by incorrect Swing threading, and thread bugs are the hardest to find. Detangler finds those tough bugs for you so that your application runs smoothly and quickly.

Changes: Automatically detects the program name, classpath, and working directory after user selects the main class or jar file. The license has been fixed so that commercial software can be used with Detangler. This release is started from the installer and requests feedback if uninstalled.

[May 24, 2008] Jython Reborn By Chris McAvoy

Here's a fun game to play at your next developer cocktail party. If someone asks you what you're interested in, tell them "Jython." Inevitably, their response will be, "Jython is dead." Six months ago, I would have agreed, but with recent investment by Sun Microsystems, it appears that Jython is very much alive and ready to be used. I'll spend a little bit of time talking about some recent Jython history, and then compile the latest revision of Jython from source and play around with it a bit.

Jython is one of the many dynamic languages built on top of the Java Virtual Machine. The Jython project began in 1997. The original release was written by Jim Hugunin, who worked on it until 1999. Jim currently develops IronPython, the .NET implementation of Python.

Between 1999 and 2005, Jython passed among several lead developers, finally ending up with Frank Wierzbicki. In March of this year, Frank was hired by Sun Microsystems to work on Jython full time. Sun's recent hiring of two lead JRuby developers, plus the hiring of Ted Leung as "Principal Engineer, Dynamic Languages and Tools," shows just how serious Sun appears to be in its future support of dynamic languages on the JVM. Jython and JRuby aren't alone; the JVM language space is getting crowded, Scala, Rhino (a Javascript implementation written by the Mozilla Foundation), Clojure (a Lisp dialect), and Groovy all have their proponents.

The current release of Jython is 2.2, which conforms to the CPython 2.2 release. However, after 2.2, the Jython developers started to move in a new direction for the implementation, choosing ASM and ANTLR to speed development time. Although it's still in development, I'll focus on the 2.3 trunk version of Jython. A 2.5 implementation (again, that conforms to the 2.5 release of CPython) is slated to be the next official release). To get started on the latest version of Jython, you'll have to check it out of the Sourceforge repository.

[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, 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(){

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.


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


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

The initial version of OpenGrok was a perl script named that extracted the above 5 streams and piped them to a lucene search engine. had become more intelligent. It was now running each file through ctags and extracting definitions. It also parsed out program identifiers. It would run dis(1) on ELF files and extract labels and call statement symbols.

I called it the Universal Program Search Engine. I was using this on my machine for quite some time. This system was used to confirm or deny existence of several vulnerabilities. For example I used it to confirm that no code in Solaris 7 was calling gzprintf() which was the cause of CVE-2003-0107 Now I could pinpoint affected areas in Solaris for each newly discovered security hole.

Perl to Java

I choose Perl because it was very easy and quick to code. I could use its efficient data structures. It was really quick to prototype a design and make sure it actually worked. I realized choosing perl for a long term solution was a mistake. Perl is great for onetime use and throw type of applications. When I profiled the processes, java process was mostly waiting for perl to parse the text. Processing the entire program tree source and binaries took a almost half a day. After some profiling the perl code and some optimizations, I could reduce the time to about 8-9 hours. Perl was consuming too many compute cycles, despite my script being only couple of hundred lines.

[Jul 10, 2007] OpenGrok at

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.



[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


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 ( ) 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 label Groovy purely in those terms, though. It can be precompiled into Java bytecode, be integrated into Java applications, power Web applications, add an extra degree of control within build files, and be the basis of whole applications on its own-Groovy is too flexible to be pigeon-holed.

What we can say about Groovy is that it is closely tied to the Java platform. This is true in terms of both implementation (many parts of Groovy are written in Java, with the rest being written in Groovy itself) and interaction. When you program in Groovy, in many ways, you're writing a special kind of Java. All the power of the Java platform-including the massive set of available libraries-is there to be harnessed.

Does this make Groovy just a layer of syntactic sugar? Not at all. Although everything you do in Groovy could be done in Java, it would be madness to write the Java code required to work Groovy's magic. Groovy performs a lot of work behind the scenes to achieve its agility and dynamic nature. As you read this book, try to think every so often about what would be required to mimic the effects of Groovy using Java. Many of the Groovy features that seem extraordinary at first-encapsulating logic in objects in a natural way, building hierarchies with barely any code other than what is absolutely required to compute the data, expressing database queries in the normal application language before they are translated into SQL, manipulating the runtime behavior of individual objects after they have been created-all of these are tasks that Java cannot perform. You might like to think of Groovy as being a "full color" language compared with the monochrome nature of Java-the miracle being that the color pictures are created out of lots of carefully engineered black and white dots.

Let's take a closer look at what makes Groovy so appealing, starting with how Groovy and Java work hand-in-hand.

[Apr 3, 2007] Jeffs Mostly Java Web Log Groovy And Others Continue To Expand The JVM Horizon

January 20, 2007 (

Here are some of the things stirring in that community right now:

- Groovy has just released version 1.0. The Groovy community has known that this was coming and having 1.0 out there on the shelves now is a big win for Groovy.

- Manning has recently published Groovy In Action, known as GINA. GINA is being referred to as "Groovy's Pick Axe Book" (a reference to Dave Thomas' definitive guide to Ruby, Programming Ruby). That is not because GINA was the first major book published on Groovy. This has more to do with GINA's clear, direct and thorough coverage of the language.

- Apress has recently published The Definitive Guide To Grails. In The Definitive Guide, Graeme Rocher presents Grails with a real nuts-and-bolts feel that takes developers through comprehensive coverage of the Grails framework.

- Morgan Kaufmann has recently published Groovy Programmers: An Introduction for Java Developers. I have not had time to read Kaufmann's book yet but I think having another general coverage book out there is probably a good thing.

- Jay Zimmerman and Scott Davis have gone live with, a great one stop shopping portal for all things Groovy and Grails.

- InfoQ recently published Jason Rudolph's minibook Getting Started with Grails, providing another source of Grails coverage and bringing Grails to the attention of more folks.

- The 2007 No Fluff Just Stuff Symposium Tour is dedicating significant track time to both Groovy and Grails. NFJS has always responded to the community by presenting what developers know is going to be important and the timing is just right this year for the tour to bring Groovy and Grails to the forefront.

- Skills Matter has announced the first 3 day Grails eXchange 2007 event. Grails eXchange focuses on Groovy and Grails in addition to providing tracks dedicated to Java Entperise Edition (JEE) and Ajax/Web 2.0.

- Sven Haiges has announced that his series of Grails podcasts is going to expand to include general Groovy coverage. Sven's podcasts have been a great asset to the Grails community and opening that up to include more Groovy coverage is going to be great for the community.

- Some recent podcasts of interest include Scott Davis' interview with Guillaume Laforge, an interview with Jay Zimmerman and an interview I did with Sven Haiges for the Grails Podcast series.

[Apr 2, 2007] Enterprise Java Community TSS Featured Entry

Looking at Python, there's an amateurish feel about it. I'm sure this will piss off Python people immensely, and the fact that I can't give concrete examples will piss them off even more, but that's the first impression I got after looking at it for a few hours. Put in the simplest terms, it feels like a very annoying language to me. Writing 'lambda' all of the place seems the height of silliness. They can keep their 'self'. Double underscores get real old real fast - even in just a few hours. "def"? "DEF"? WTF? I don't think I can use a language that defines methods with a keyword "DEF" (aside: And I'm pissed that Groovy requires DEF, but at least its only in one specific case).

Ruby and Python both also seem to have issues with runtime speed, which just goes further to reduce my warm fuzzies. I want my warm fuzzies, damn it, and these guys aren't giving them to me!

That leaves Groovy. Based on extensive past experience in encountering and learning new things, I was fully prepared to be wildly disappointed. In the real world the stars of the show seem to never live up to their billing. The handsome lead looks fabulous in his stage makeup, but after the show you find that the makeup was covering 37 zits; he's really 5'2"; his last bath was probably in the Nixon era; he was wearing a girdle to hold in his 48-inch belly; and he's got bits of chunky bacon stuck in his teeth. There's alot of people out there making alot of fancy talk, painting a pretty picture to give the illusion of their hero being a a virile leading man. But almost always it's all smoke and mirrors, it's a coverup aimed at making a smelly short fat man with bad complexion look good.

In Groovy's case, I was pleasantly surprised. Maybe there is a smelly short fat man buried in there somewhere with chunky bacon rotting in his teeth, but I haven't found him yet.

The following are my first impressions of learning Groovy, and my experiences in trying to use it for the past week. To give you a bit of context, I'm using Groovy to script the configuration of my XALogging implementation, and to also script the performance and stress tests.

Please keep in mind that this is the result of only a week's worth of experimentation, reading, and trying to use the language in real world work. I am in no way a Groovy expert, or even an intermediate Groovy user - I should be considered a bare novice who's still has a stupid look on his face most of the time. As such it's a certainty that I've gotten some things wrong here. In those cases, I hope the true experts will stand up and show me the error of my ways.

[Mar 20, 2007] Java 7 aka Groovy 1.0 by Jeff Cunningham

January 10, 2007 ( The 2 points i have read about the most..the property operator and null handling..both of these are already in Groovy. I know Groovy got some of these ideas from other languages, and java is trying to adopt some dynamic features to keep developers interested in java.

I'll admit i've been reading Groovy in Action (so my groovy knowledge is still theoretical), and i'm pretty excited about trying to learn Groovy well enough to begin using in my projects. I would think any java fan would find lots to like in Groovy, if they can forget about the early hype and examine groovy with an open mind. seems funny that jdk is trying to adopt some ideas that are already done better in Groovy. I like that Groovy overloads the . (dot) operator for property access, instead of creating a new -> operator. I believe both can generate the accessor methods for you, if you desire.

I also like Groovy's safe null check, using the ?

In Groovy to prevent null pointers, you would so something like obj1?.obj2?.someMethod

In java 7 proposal it look like this in java:


At 6:32 PM, Stephen Colebourne said...

On JavaLobby I suggested adding new syntax to Java to allow embedded Groovy code within a Java method:

public void doStuff() {
Person person = ...;
FormBean input = ...;
groovy {
// write any valid Groovy code here
person.surname = input.surname;

[Mar 15, 2007] JSR-241- Groovy A New Standard Programmingisoliver/entry/f3">Chris Oliver's blog

[Feb 20, 2007] Groovy is great for unit testing as Java unit test code can be quite verbose.

March 2005 (DDJ) Language features like closures and native syntax for list and maps mean less typing and code that's easier to read

David Black, Unit testing is a Groovy Thing DDJ March 2005 p 12

[Dec 31, 2006] Java Quotes in 2005 by Elliotte Rusty Harold

[Dec 15, 2006] Computerworld - The mythical open source miracle by Neil McAllister

Actually Spolsky does not understand the role of scripting languages. But hi is right of target with his critique of OO. Object oriented programming is no silver bullet.
Dec 14, 2006 (InfoWorld) Joel Spolsky is one of our most celebrated pundits on the practice of software development, and he's full of terrific insight. In a recent blog post, he decries the fallacy of "Lego programming" -- the all-too-common assumption that sophisticated new tools will make writing applications as easy as snapping together children's toys. It simply isn't so, he says -- despite the fact that people have been claiming it for decades -- because the most important work in software development happens before a single line of code is written.

By way of support, Spolsky reminds us of a quote from the most celebrated pundit of an earlier generation of developers. In his 1987 essay "No Silver Bullet," Frederick P. Brooks wrote, "The essence of a software entity is a construct of interlocking concepts ... I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation ... If this is true, building software will always be hard. There is inherently no silver bullet."

As Spolsky points out, in the 20 years since Brooks wrote "No Silver Bullet," countless products have reached the market heralded as the silver bullet for effortless software development. Similarly, in the 30 years since Brooks published " The Mythical Man-Month" -- in which, among other things, he debunks the fallacy that if one programmer can do a job in ten months, ten programmers can do the same job in one month -- product managers have continued to buy into various methodologies and tricks that claim to make running software projects as easy as stacking Lego bricks.

Don't you believe it. If, as Brooks wrote, the hard part of software development is the initial design, then no amount of radical workflows or agile development methods will get a struggling project out the door, any more than the latest GUI rapid-development toolkit will.

And neither will open source. Too often, commercial software companies decide to turn over their orphaned software to "the community" -- if such a thing exists -- in the naive belief that open source will be a miracle cure to get a flagging project back on track. This is just another fallacy, as history demonstrates.

In 1998, Netscape released the source code to its Mozilla browser to the public to much fanfare, but only lukewarm response from developers. As it turned out, the Mozilla source was much too complex and of too poor quality for developers outside Netscape to understand it. As Jamie Zawinski recounts, the resulting decision to rewrite the browser's rendering engine from scratch derailed the project anywhere from six to ten months.

This is a classic example of the fallacy of the mythical man-month. The problem with the Mozilla code was poor design, not lack of an able workforce. Throwing more bodies at the project didn't necessarily help; it may have even hindered it. And while implementing a community development process may have allowed Netscape to sidestep its own internal management problems, it was certainly no silver bullet for success.

The key to developing good software the first time around is doing the hard work at the beginning: good design, and rigorous testing of that design. Fail that, and you've got no choice but to take the hard road. As Brooks observed all those years ago, successful software will never be easy. No amount of open source process will change that, and to think otherwise is just more Lego-programming nonsense.

[Dec 9, 2006] Did Sun's GPL Move Cost it a Major Talent

Usually small companies adopt GPL as a protection against big sharks similar to the fact that anarchism always has its major support base in small merchants and producers. Sun in not a small vendor but with dual licensing it might kill two birds with one stone: prevent Microsoft encroaching into Java turf with .Net and get a free PR boost for its old technology that lost with age some shine.

Reporter's Notebook: Did Sun Microsystems' decision to adopt the GNU General Public License (GPL) cost the company one of its top talents? That's what a lot of people have been wondering in recent weeks.

As most every Java programmer might know by now, Sun decided to adopt the GNU General Public License v2 as its license of choice for the open sourcing of its Java language.

The move met with considerable approval across the developer blogosphere and even from the GPL's creator (and frequent Sun critic) Richard Stallman. But it seems not everyone was happy with it, or so the rumors go.

Very quietly in early November, Graham Hamilton, a Sun vice president and fellow in the Java platform team, left the company prior to the announcement of the GPL direction. Very little was made of this, and few noticed until the news appeared in the blog of Geir Magnusson, chair of the Apache Jakarta project, a few weeks later.

James Gosling may be the rock star of the Java world but Hamilton was a heavyweight in his own right. Graham joined the Java team in 1995 and has been involved in a number of projects, including CORBA support, the JDBC database connectivity APIs, JavaBeans, the Java Plug-in, RMI-IIOP, JAX-RPC, and others.

He was also the lead architect for Java Platform Standard Edition (Java SE) releases 1.3, 1.4, and 5.0, as well as one of the designers of the Java Community Process, which handled the development of projects before Sun adopted the open source model. The JCP still plays a big role in Java development.

Other news sites were quick to jump to the assumption that Hamilton departed in protest to the GPL decision. He had been known as an opponent of opening up the source code and wanting Sun to retain as much control over Java as possible. However, it's not clear if there is a definite causal relationship between his departure and Sun's decision to go open source.

Sun would say nothing on the subject beyond the following statement: "Sun thanks Graham for his many contributions to the company and to Java technology. Graham is widely respected by Sun employees and developers around the world. While it is always sad to see an employee of his caliber depart, we wish him well in all his future endeavors."

As if he doesn't have enough to do, Gosling will be taking over Hamilton's responsibilities when he returns to work after recuperating from jaw surgery.

Raven Zachary, analyst with The 451 Group, said there was considerable debate within Sun over which license to use, with some traditionalists wanting to keep things under as much Sun control as possible. But he thinks more departures from Sun by those who oppose the GPL could be healthy for the company.

"This is an opportunity for Sun to solidify its support for an open source software model, and if there has to be a little bit of shedding of the skin from the old guard, that's not necessarily a bad thing," said Zachary.

The GPL move threw more than a few people for a loop, because it came out of nowhere. Till now, Sun had been using its own license, the Common Development and Distribution License (CDDL), a derivative of the Mozilla Public License, to release the Java code.

The assumption was that Sun would go with CDDL again, but Sun CEO Jonathan Schwartz had said as far back as May of this year that GPL was very much "on the table."

Schwartz only added to the confusion with a blog entry, which seems to say the decision to adopt a GPL license was in response to the Novell/Microsoft deal of November 2.

A Sun rep denied this, attributing the somewhat loopy blog entry to being done "probably at four in the morning." The rep argued that it would be practically impossible to marshal all of the company's legal and technical teams to shift the Java code base from CDDL to GPL in under 11 days.

Magnusson takes Sun's side in this case. "While I believe that the CDDL was on the table in the beginning, as late as October I'm fairly convinced that the GPL had been decided upon. It prohibits proprietary forks, and preserves the current technology licensing revenue from those that incorporate Java SE technology into proprietary products. I can't fault them for that," he told

Prohibiting forking, or splintering of the code base, is probably the top concern for Sun. GPL also throws a huge monkey wrench into the plans of the Apache Harmony project, an open source Java SE project by The Apache Foundation (and by extension, IBM, which has all but subsumed Apache these days).

"Had Sun actually gone ahead and used a CDDL license, it would have been much more compatible with the Harmony project and allowed for code sharing and reuse," said Zachary. "With the GPL, the challenge is you have a somewhat incompatible license with what Apache has been using with Harmony."

It also explains IBM's recent behavior. Right before Sun announced its GPL plans, IBM issued a statement attributed to Rod Smith, vice president of emerging Internet technologies. In 2004, Smith wrote an open letter to Sun requesting the company make Java open source.

This time, Smith encouraged Sun to join an existing open source Java project rather than start its own, and make it "Apache-friendly." That takes a fair amount of brass, telling Sun to join someone else's Java project than continue with its own. Naturally, Sun dismissed this out of hand.

For now, Hamilton is maintaining a low profile. He has not signed on with a new company nor has he made a public statement. Gosling is healing well, according to Sun officials, and life goes on at Sun. It all looks like another peculiar round of corporate chess, with the pieces all being shuffled and a significant piece, for now, being taken off the board.

[Dec 1, 2006] Red Hat From 'Cuddly Penguin' to Public Enemy No. 1

We have suffered from that image in the past. And some of our competitors have played up the fact that the JBoss guys are behaving like a sect. When, in fact, if you look at the composition of our community, we have an order of magnitude more committers than our direct open-source competitors.

But the perception is still there. Bull even said something about that perception. And we'd been thinking about opening up the governance. So when Bull provided us with a great study case, we decided to put the pedal to the metal. But make no mistake this is not going to be a free-for-all. We care a lot about the quality of what gets committed. We invest very heavily in all our projects. We're serious about this so we expect the same level of seriousness from our collaborators.

There is going to be a hybrid model where there is an opening up of the governance. In terms of code contributions it's always been there. But now it's been made explicit instead of implicit and open to attacks of "closedness." JBoss has always been an open community, but we've hired most of our primary committers.

Well, you seem more willing to compromise and evolve your stance on things. Like SCA [Service Component Architecture]-initially you were against it, but it seems like you've changed your mind.

Well, yeah, the specific SCA stance today is there is no reason for us to be for or against it. If it plays out in the market, we'll support it. And I think Mark Little [a JBoss core developer] said it very well that the ESB implementations usually outlive standards.

So what you're seeing from us is mostly due to Mark Little's influence. Mark has been around in the standards arena and has seen all these standards come and go. So it's not about the standards, it's about our implementation in support of all these standards. And it's not our place to be waging a standards war. It's our place to implement and let the market decide and we'll follow the market.

So where I'll agree with you is that it's less of a dogmatic position in terms of perceived competition and more focus on what we do well, which is implementations.

Another thing is JBoss four years ago was very much Marc Fleury and the competitive stance against Sun and things like that. Today I don't do anything. In fact, I actively stay out in terms of not getting in the way of my guys.

So it's both a sign of maturity and of a more diverse organization. I'm representing more than leading the technical direction these days. And that's a very good thing.

You said you approached David Heinemeier Hansson, the creator of Ruby on Rails, to work at JBoss. What other types of developers are you interested in hiring?

Yeah, we did approach him. There is a lot of talent around the Web framework. One of the problems is it's a very fragmented community at a personal level. You have one guy and his framework. Though, this is not the case with Ruby on Rails. But there's a lot of innovation that's going on that would benefit from unification under a bigger distribution umbrella and bigger R&D umbrella. And I think JBoss/Red Hat is in a position to offer that. So we're always talking about new guys.

One of the things I like to do is talk to the core developers and say, "Where are you in terms of recruitment?" And we're talking to scripting guys. I think scripting is the next frontier as [Ruby on Rails] has showed. We have a unique opportunity of bringing under one big branded umbrella a diverse group of folks that today are doing excellent work, be it the scripting crowd, REST, Web framework, or the Faces, or the guys integrating with Seam. All of the work we're doing is going to take more people and we're always on the lookout for the right talent and the right fit.

[Nov 17, 2006] Sun's Gosling Already Plenty of Java 'Harmony' Under the Sun

"The major vendors have kind of said tools and development environments tend to be loss leaders for the rest of their platforms," he added. "That's made it very difficult for individual companies whose businesses are built on tools to survive."
"We've got several thousand man-years of engineering in [Java], and we hear very strongly that if this thing turned into an open source project - where just any old person could check in stuff - they'd all freak. They'd all go screaming into the hills."

he Apache Software Foundation's proposal of an open source version of Java 2 Standard Edition (J2SE) has the "Father of Java" James Gosling puzzled. "It's often difficult to get a good picture from the open source community of what they actually object to in what we're doing," said the fellow and Chief Technology Officer of Sun's Developer Products group, who created the Java language, in an interview with DevX. "In what way could we be more open?

"Since day zero, 10 years ago, all of our sources have been open and available," he explained, adding that Sun has worked to establish a governance model (the Java Community Process or JCP), which is "very similar to how many projects in open source work."

The Apache proposal, called Project Harmony, got officially underway May 6, when Geir Magnusson, an Apache project chair, posted an overview of Harmony's need, objectives, and key participants to an "incubator" mailing list for Apache members. In it, Magnusson writes, "there is a clear need for an open-source version of J2SE runtime platform and there are many ongoing efforts to produce solutions (Kaffe, Classpath, etc.) [and] provide alternative approaches to execution of Java bytecode (GCJ and IKVM), but barriers exist which prevent these efforts from reaching a greater potential."

If Java turned into an open source project, the enterprise development community would go screaming into the hills.

The "clear need" that Magnusson cites is anything but clear to Gosling, who says Sun has received a negative response from the enterprise development community regarding the idea of open-source Java. "We've got several thousand man-years of engineering in [Java], and we hear very strongly that if this thing turned into an open source project-where just any old person could check in stuff-they'd all freak. They'd all go screaming into the hills."

Testing Is Hard. Not Testing Is Harder
Project Harmony would be available under the Apache License v2 rather than one of Sun's licenses, but Gosling doesn't buy into the theory that Harmony's need lies in alternate licensing, opening up what can be done with applications and code. He said, "For most users, we're actually pretty close to the Apache license. You can do an awful lot of stuff with our system before you run into license restrictions."

While he characterized the Sun licenses as "pretty liberal" Gosling conceded that the compatibility testing requirement in Sun's license is "where [it] gets sticky." Sun's J2SE licensee partners are required to satisfy all the tests in the Java technology Compatibility Kit (JCK) before they can release their implementations. This, he says, has proved a daunting requirement for many. "One of the things that has come out over and over again as an issue is that testing is hard. Our test suites have literally hundreds of thousands of test programs in them. It's not like there's one file you run through your compiler."

In the open source community, if you actually care about being legally clean, it's a nightmare.

Although testing may make adherence to Sun licenses difficult, thanks to the current licensing morass, using open source is no walk in the park either. Gosling said, "In the open source community, if you actually care about being legally clean, it's a nightmare. Most people don't actually read the licenses. Every day or two there's something about someone getting hammered for GPL violations, and most of the people who are doing it don't even know it."

For Sun, the stakes are too high to be loose with licensing, according to Gosling. The JCP employs the JSPA (Java Standards Participation Agreement) as a means of verifying that contributed ideas and concepts are "legally clean." Said Gosling, "We don't want something to get accepted as a standard and then afterwards [have a third party say] the standard that is now deployed all over the place is actually covered under my patent and you owe me a lot of money. And that happens in other standards venues all the time.

"We get hammered by some folks because we're not willing to be as cavalier as they would like us to be. But on the other hand, the majority of customers who really matter to us actually care very deeply about the fact that we are excruciatingly careful," he added.

[Nov 16, 2006] No sparks flying in Sun-Microsoft affair

"Two billion dollars buys a lot of love." -- Jonathan Schwartz

February 8, 2005 (Silicon Valley Sleuth) Thanks to the European Union, the Sun-Microsoft settlement is getting less and less relevant, Java godfather James Gossling said at an event in Sydney, Australia.

"Our agreement with them is becoming less and less relevant because of a lot of the fallout of some of the antitrust action in Europe. Europe (has) been forcing Microsoft to open up those interfaces to everyone anyway. So the agreement we have with them looks a lot like the ones that the EU are getting them to do," Cnet quoted Gossling saying.

But the arrangement getting less relevant doesn't mean it's completely useless. As part of the deal, Microsoft paid Sun $ 1.95 bn in "and now shut up" money.

And as Sun COO Jonathan Schwartz recently said at a Churchill Club event in Silicon Valley: "Two billion dollars buys a lot of love."

[Nov 15, 2006] Gosling Java source code already available By Paul Krill

He was right. But in view of recent actions of Sun brass should Gosling now eat his words printed on IBM printer and shredded in borsch ?
May 10, 2006 (InfoWorld) "There's a bunch of people out there getting all hyper, and I don't believe there's anything there for them to get hyper about," Gosling said when asked about the possibility of a full open source route for Java.

Source code for Java already is available and has been for 10 years, he said. The current model for Java is close to an open source model, Gosling said.

Java developers, meanwhile, want to preserve interoperability and reliability, which is maintained by the current rules governing Java, Gosling said. To be certified as Java-compliant, software most undergo a test suite.

"They really like the fact that we're very compulsive about the whole testing thing," Gosling said.

So if Gosling has anything to do with it, Java won't be open sourced any time soon; but what does Gosling's boss think?

Despite some assertions to the contrary, Sun is doing fine with making money from Java, he said. The company earns money with its Java Enterprise System network services software and also in selling services and support, Gosling said.

Glad to hear it. But playing devil's advocate here, is 'making money' the same as 'making a profit'?

[Nov 14, 2006] Sun eyeing GPL for Java

GPL was always fueled by fear of Microsoft, but usually it is a small fish that tend to embrace it as a misguided defense against big sharks. Sun is no small fish but still there are bigger sharks and the danger from .NET is all to real to ignore. Actually this is Sun's second attempt to use GPL for a large software product (the first was Open Office). In retrospect, Sun's lawsuit against Microsoft now looks questionable and bizarre move: they probably should cooperate in Novell style, not to sue and get .NET in return. I think there are several reasons behind this rather bold move:
  1. It might get a boost to scripting languages implementations which use JVM like Jython and Ryno.
  2. Java is probably the loss leader for Sun and it is time to cut expenses on the product that does not bring much to the bottom line (it is true that GPL is actually a pretty decent license for abandonware or any mature and stagnant software).
  3. Sun brass slightly overreacted to the Microsoft-Novell deal announcement (with implicit threat of .NET undermining Java franchise as Mono is covered by the agreement, as is, paradoxically, OpenOffice ;-). But who knows, technical politics is as complex as "big" politics and this might be a shrewd counterattack: dual licensing ensures Sun leadership and at the same that main problem with GPL -- the danger of forking is minimal as Java is too big and too mature. At the same time it makes Java different from .NET and all those open source crazies with red-eyes can now serve as Java evangelists :-)

    Moreover, while GPL is a bad license (in comparison with BSD license, Mozilla or Sun's own CDDL license ;-) is not totally bad for compliers and compiler-like products as gcc demonstrated long ago. As long as you have the ability to write your own code without paying arm and leg to some benevolent not quite so vendor, you do cannot care less about the license for the compiler. Still Java is more of an interpreted then compiled language and here the jury is still out -- none of the major scripting languages uses pure GPL and that's for a reason (but many including Perl use GPL as the second license) It is actually the licensing for libraries that really matters.

    Availability of Java under GPL might neutralize the boost for .Net as after Novell deal Mono is protected from lawsuits and that means the .NET instantly got some legitimacy in Linux world. Also C# is a slightly better language from a more powerful competitor and is supported by Visual Studio -- (for some strange reasons) the leading enterprise IDE. If you can develop on Windows using Visual Studio but run software on Unix there are reasons for Sun brass to lose sleep: Novell turns into Microsoft Trojan horse perfectly positioned to weaken or even undermine Java in enterprise environment, the area that matters for Sun most.

  4. In the past commercial software development companies which embraced GPL did not last long. So a shadow of Corel is now all over Sun. But Sun is not a pure software development company and it has many products in the its software stack. Java is just one of them.

November 13, 2006 (IDG News Service) -- It's not every day your boss puts you on the spot. But that's exactly what the head of Sun Microsystems Inc. did to his chief software executive today as they both celebrated the vendor's move to make its core Java platform freely available.

Sun confirmed that it's open-sourcing both its Java Platform Standard Edition (Java SE) and its Java Platform Micro Edition (Java ME) under the GNU General Public License Version 2 (GPLv2). GPLv2 is a popular license already used by free and open-source software (FOSS) projects and products including the Linux operating system. It's the first time Sun, which has committed to open-source all its software, has adopted a license other than its own Common Development and Distribution License.

So will Sun look to use the GPL for other offerings it has already open-sourced, such as the OpenSolaris version of its operating system? That was the topic of discussion in this exchange between Jonathan Schwartz, Sun's president and CEO, and Rich Green, the company's senior vice president of software at an event to formally open-source Java in Santa Clara, Calif. The event was webcast.

"Are you adverse to changing the license, Rich Green?" Schwartz asked.

"Certainly not," Green responded, prompting the Sun CEO to fire back in a half-joking manner: "Will you GPL Solaris, Mr. Green?"

"We will take a close look at it," Green said, adding that it was possible that the familiarity and comfort level many developers have with the GPL may result in Sun adopting it for OpenSolaris.

Both men positioned Sun's embracing of GPL for Java as an important change in the software landscape, which the company hopes will result in much greater adoption of all flavors of Java across mobile devices and computers.

Over the decade that Java has been in existence, 4 billion devices have used the technology, according to Schwartz, with Java shipping on eight of every 10 phones today. "How do we get to the next 4 billion?" he asked. "How do we continue to create opportunity in the marketplace?"

Today's announcement makes Sun the single largest contributor to the open-source community, with Java SE alone consisting of more than 6 million lines of code, Green said.

He showed video clips of leading FOSS luminaries welcoming Sun's move, including Richard Stallman, the creator of the GPL. Stallman said that Sun has now contributed more software than any other company to the free software community. "It shows leadership," he added. "It's an example I hope others will follow."

The real challenge for Sun as it continues on its open-source path is a cultural one, Green said. "How do we operate in full transparent view, managing the source code in full public view?" he asked. The membrane between Sun and developers outside the company has to be porous, Schwartz added, so that there can be a continual flow of feedback on the Java open-source work.

As an aside, Sun also announced it will open-source the long-time Java mascot Duke, a black-and-white triangle with a red nose and black arms, so any developer can freely use the image.

[Nov 14, 2006] Computerworld - Father of Java chides open source developer community

Feb 07, 2005 ( Java creator, IT industry heavyweight and CTO of Sun Microsystem's developer products group James Gosling has launched a blistering attack on the open source developer community saying companies that give away software lack financial viability.

In Sydney at the start of a national lecture tour, including an address to Directors of Information Technology at the Council of Australian Universities, Gosling described the economic sustainability of open source as "in a pickle".

"There are all these open source groups that have to figure out what their economic model is," Gosling told Computerworld.

"Everyone that works on these open source projects [must] pay rent and buy where does that money come from?

Open source vendors also came under fire, with Gosling sideswiping MySQL, JBoss, and Red Hat: "They say that they are running their businesses based on services.

"These businesses are more hype than reality. If they don't have a [longer term] economic model...they are going to have a really hard time."

Gosling took aim at MySQL, describing its open source database as "still basically commercial, but you can use it for free".

"I actually find it amazing that people consider MySQL to be an open source project given that there is no one allowed to do check-ins. When you look at the licence for MySQL you really do need to feed them money in order to be clean with their licence."

When asked about Sun's stance on open sourcing Java, Gosling described the whole debate as "very weird".

"We have been distributing the source to Java freely since the very first day [and] you can go to our Web site and download the sources, no problem," he said. "In that sense, Java has been open source for a decade."

Gosling said people in the open source world quibble about one clause in the Java licence that disqualifies it from being open source, but is important for maintaining compatibility.

"So we have this licence that says you can only distribute this commercially and call it Java if you have passed the set of tests," he said.

[Nov 7, 2006] Employing Rexx as a Scripting Language for Java Java, Scripting Languages, and the Bean Scripting Framework (BSF)

In the past, the need for scripting languages for Java applications has been neglected by many companies, most notably by Sun itself. Although Sun started a JCP process-Java specification request 223 (JSR-223)-in the summer of 2003 to define and create a standard Java interface to scripting languages, it still will be some time until it will be made widely available with the next major release of the Java language.

One major company that has embraced Java is IBM. For business application development in Java, IBM wanted to include the capability of invoking scripting languages from Java in the context of Java Server Pages (JSP) in their Java application server WebSphere. Drawing from an IBM-funded open source development project, Bean Scripting Framework (BSF), IBM incorporated that into their application server. Because BSF has been handed over to the Apache organization, everyone can use that open sourced infrastructure for free. Jakarta BSF allows deploying scripts from Java in many languages, among them JavaScript (by virtue of using Rhino, the Java implementation of JavaScript) and Netrexx, a Rexx-like language implemented in Java.

The BSF framework is aimed at making it easy for Java programmers to employ scripting languages that execute in the context of their Java applications. The package BSF4Rexx adds the scripting language ooRexx to BSF, so that Rexx and ooRexx scripts can be invoked by Java.

[Nov 7, 2006] Programming Tools Java Scripting Languages Linux Journal

Jul 12, 2005 What's new with Jython and a look at the latest Java scripting language, Groovy.

[Nov 7, 2006] Choosing a Java scripting language Round two - Java World

Three years ago, I wrote an article for JavaWorld called "Java Scripting Languages: Which Is Right for You?" When I collected the interpreters to compare, I tried to choose ones that seemed a good fit for a demanding commercial application. Ideally, I wanted an interpreter that would ease the extension of the application's user interface, have readable scripting code, be reliable, fast, well-supported, well-documented, and complete. At that time, I narrowed the list down to Jacl, Jython, Rhino, and BeanShell.

A lot has changed over the last three years. Instead of a handful of choices, there are now more than a dozen scripting languages either under active development or already available for use. The list of solid choices is bigger than it was three years ago and now includes Groovy, JudoScript, Pnuts, and JRuby, in addition to Jacl, Jython, Rhino, and BeanShell. We could consider other scripting interpreters beyond this group, but this list is large enough for developers to find what they're looking for.

[Oct 29, 2006] Project details for doxygen

doxygen 1.5.1
by Dimitri van Heesch - Sun, Oct 29th 2006 11:00 PDT

About: Doxygen is a cross-platform, JavaDoc-like documentation system for C++, C, Objective-C, C#, Java, IDL, Python, and PHP. Doxygen can be used to generate an on-line class browser (in HTML) and/or an off-line reference manual (in LaTeX or RTF) from a set of source files. Doxygen can also be configured to extract the code-structure from undocumented source files. This includes dependency graphs, class diagrams and hyperlinked source code. This type of information can be very useful to quickly find your way in large source distributions.

Changes: This release fixes a number of bugs that could cause it to crash under certain conditions or produce invalid output.

[Oct 25, 2006] DDJ Portal Blog/Sun Gets Rubyfied by Jon Erickson

On the heels of last weekend's Ruby Conference in Denver (for a report, see Jack Woehr's blog), Sun Microsystems made a Ruby-related announcement of its own. Led by Charles Nutter and Thomas Enebo, the chief maintainers of JRuby, a 100% pure Java implementation of the Ruby language, Sun has released JRuby 0.9.1. Among the features of this release are:

In related news, Ola Bini has been inducted into JRuby as a core developer during this development cycle.
Details are available at Thomas Enebo's blog and Ola Bini's blog.

[Oct 06, 2006] Scripting for the Java Platform

Version 6 of the Java Platform, Standard Edition (Java SE), does not mandate any particular script engine, but it does include the Mozilla Rhino engine for the JavaScript programming language. The Java SE 6 platform implements the java.script APIs, which allow you to use script engines that comply with JSR 223. The web site hosts an open project to maintain several script engines that conform to JSR 223. The site also links to engines maintained elsewhere. You can learn more about the the embedded JavaScript technology engine by visiting the Mozilla Rhino web site.

[Oct 04, 2006] What's New in Java SE 6 Beta 2 Rhino was added as Sun supported scripting engine. It is possible to use Jython too.

You can now mix in JavaScript technology with your Java technology source code, useful for prototyping. Also useful when you have teams with a variety of skill sets. More advanced developers can plug in their own scripting engines and mix their favorite scripting language in with Java code as they see fit.

Perhaps You ThougHt yOu couldN't program with a scripting language and Java togetheR. Which will yoU Be trYing ?

Rhino JavaScript engine

[Oct 04, 2006] Scripting Languages for Java An article comparing and contrasting Rhino and Jython.

[Oct 04, 2006] BeanShell, Rhino and Java -- Performance Comparison

For those who don't like looking at raw numbers, here are my conclusions:
  1. Rhino is significantly faster than BeanShell and the difference become more pronounced as the data size increases.
  2. There doesn't seem to be much difference in speed between interpreted and compiled execution of JavaScript programs. This matches with the observation in the above-mentioned article regarding speed of compiled JavaScript programs. So, there is not much benefit of a compiler, after all.
  3. Java classes are a second class citizen in a JavaScript program (compared to native types). Given a choice, choose a native type.
  4. Even pure JavaScript is no match for a compiled Java program, which is almost 10 times faster.

The performance advantage of Rhino alone may not sufficient for me to switch, for most of my programs spend less than 10 percent of the total execution time running BeanShell scripts (rest is spent running Java byte code from existing class libraries), but it certainly is going to be a factor.

[Oct 04, 2006] Java scripting languages: Which is right for you?

April 2002 (JavaWorld) ... Let's go through the library support issues for each interpreter in our survey.

Jacl has an active support group. Although the download link at the development site points you at a release that is several years old, newer versions can be found using the CVS version control system. Jacl consists of about 37,000 lines of Java code.

Jython seems to feature active support, maintenance, and updates. Jython consists of about 55,000 lines of Java code.

Rhino receives updates and new releases on a frequent basis, and comprises about 44,000 lines of Java code.

BeanShell features regular updates and releases; it consists of about 25,000 lines of Java code plus a substantial number of BeanShell scripts.

What the support information means
All four interpreters are big, complex beasts. You'll be ahead in the game if you can rely on a support team to make improvements and fix bugs. Before you choose an interpreter, check to see how often it is updated and released. You might contact one of the developers to see what the long term plans for the interpreter are and to see what their process is for fixing bugs.

Even though you can download these interpreters for free, what are the licensing rules about embedding the scripting interpreter in a commercial application?

Fortunately, licensing does not present a problem for any of these libraries. The way I read the license agreements for Jacl, Jython, JavaScript, and BeanShell, the user must abide by the GNU Lesser General Public license or an equivalent. That means you can ship the libraries with your application even if your application is not free. However, you cannot strip the copyright headers out of their source files or script files, and you may need to clarify to users that the rights to the scripting interpreter bundled with your application belong to someone else. Naturally, don't take my word for it. When you get interpreter distribution you care about, read and interpret the licensing information for yourself, and have your legal department affirm you can use it with your application without creating any problems for you.

Final thoughts
If you need to integrate scripting support code into your Java application, I advise you to standardize on a single scripting interpreter. Each additional scripting language you support in your product has associated costs, so avoid hooking more than one scripting interpreter into your application. When adding scripting support, you can simplify things further by using a Java-based interpreter instead of a native interpreter such as Perl. That will make your solution more portable and simplify the integration task between your Java program and the interpreter.

If your customers expect a particular language to customize your products, look seriously at integrating with a scripting interpreter that supports that language, in the way that Jacl supports Tcl syntax. If you are not locked to a particular language, compare the interpreters from a variety of standpoints to see which are better suited to particular tasks than others.

For instance, Jacl moves extremely slowly compared to the other interpreters, but proves useful if you need your scripts written in Tcl. If you're porting an application from Tcl/Tk to Java, the ability to run your old Tcl scripts in the new Java application might be so valuable that it would outweigh other concerns. Also, Tcl is a popular programming language, so many developers are already familiar with it, and Tcl books are easy to find.

If you want Java-like scripting code and prefer painless integration, BeanShell looks good. On the downside, the user guide for BeanShell syntax and programming is limited to what ships with the release, and it runs slower than some of the other interpreters. On the other hand, I found BeanShell easy to work with and liked it quite a bit. Its well organized libraries make integration simple. If performance is not the most important criteria for your scripting interpreter, consider BeanShell.

Rhino runs significantly faster than BeanShell and likewise supports Java-like syntax in its scripting. Moreover, it appears well written and well supported, and you'll find numerous JavaScript syntax books at the bookstore. I had no problems and recommend it if you have equally balanced needs for performance, Java-like syntax, and strong support for the libraries.

Jython is the fastest scripting interpreters I looked at and has some powerful programming features. My only real concern was about Jython's control-flow syntax, which might or might not be important to you. As with Jacl, writing scripts for Jython may have more of a learning curve to it than JavaScript or BeanShell do, since there is more new ground to cover. If you want to write nontrivial scripts in Python, I recommend buying a book. Python is a popular programming language, so you'll have plenty to choose from at the bookstore.

[Sep 30, 2006] Weblogs Forum - The departure of the hyper-enthusiasts -- another look at Bruce post

Re: The departure of the hyper-enthusiasts by Jakub Pawlowicz
Posted: Dec 18, 2005 5:01 PM
I think you are mainly right about reasons for people moving to Ruby, and its influence on Python and Java languages.
But by saying that "Java-on-rails might actually tempt me into creating a web app using Java again." and by comparing development in Ruby to the one in EJB 1/2 (or even EJB 3), you are missing the fact, that part of the server-side Java community has already moved to the lightweight approaches such as Spring Framework.
From a one and a half year experience of working as a Spring web developer I must admit that the server-side Java development could be much simpler with lightweight approaches than it was in the EJB 1/2 times.
Re: The departure of the hyper-enthusiasts by Adam Connor
Posted: Dec 19, 2005 9:14 AM
> One fact that generally seems to be overlooked in these
> discussions is that all these languages (Smalltalk,
> Python, Java, Ruby, C#, etc.) are all, more or less,
> functionally identical.

In the Turing sense, sure. In the "equivalent productivity" sense, I doubt it. Java is a fairly tedious and verbose language, and refactoring is made expensive by all the static type annotations. Early on, when you are still experimenting with the design, Java is an expensive language to work with. Dynamic languages have an advantage here precisely because they don't require as many decisions about type, and the code is easier to refactor.

There are also differences in features that are shared. I've written a fair amount of metaprogramming code in Java. It is tedious in the extreme. Ruby looks a LOT easier to me, as does Lisp (in a different way).

I'm mostly interested in finding tools that improve my productivity at this point. I can easily see why folks are interested in defecting from Java.

The departure of the hyper-enthusiasts by Sergio Fanchiotti Posted: Dec 19, 2005 12:12 PM
Interesting article and discussion.

The most important aspect of a programming language adoption (for me) its usefulness to solve a common problem in a domain area. All the rest is watercooler bragging.

C solved the problem of being a portable assembler. Still is today.

C++ tried to solve the problem of building large and more maintainable applications riding on the portablilty of C. Somehow it still works for that task, warts and all.

Perl solved the problem of implementing a portable glue language for data processing. Then it was adapted to the initial web data processing mechanism using CGI. Its lack of scalability to build consistent and maintainable apps opened the field to newcomers like PHP.

Java was first billed as a portable solution for client apps. Then marketiing hype took over. Java suffered when it tried to cover too many domains while being awful at delivering in most. Only on the server side and rarely in the client side you see some Java apps work well enough. Too much work for little payoff.

The problem with Python and Ruby is the same one I have when trying to getting good at speaking Portugese, French or Italian from knowing Spanish. The difference is not that large so I slip back to the previous knowledge to get real communication (read work) done. In my case it is Perl vs Python or Ruby, but every one probably has the same experience with their favorite dialect. That is the most important aspect to rescue from what that Bruce and others point out.

In most cases the deciding factor is the emergence of the 'killer app' or for developers the 'killer framework pattern' to make the jump worth the split brain pain. The Python community has been in search of that killer framework for a while without a big hit like Ruby has had with rails. But trying to replicate previously successful stuff is not going to work in principle.

In a sense the answer is to look beyond the current common application domains and try to see what is coming next. What is the next paradigm that will make development easier.

Personally I am perceiving more and more the need to have a clear and simple way to build scalable distributed apps in a simple way. There will be plenty of CPUs and even plenty of hosts where apps will need to run in parallel or worse, asynchonoulsy. Trying to fight about whose web framework is the best is kind of childish because it seems to me that it is just the front end of a much larger problem that will need to faced sooner rather than later. Most of the web smarts is what happens behid the web server. All that SQL encapsulation is nice but it is a very restrictive model when thinking about distributed processing, a kind of premature optimization or lack of clear component separation when building an app.

So, in conclusion, the quality of a newcomer language will be probably measured on how well it will support a framework were developers can build large scalable distributed apps over many hosts (or mutiple core cpus). Also its capability to adapt to legacy infrastructure (e.g. C and C++ stuff mostly) while doing that is key.

Today most attempts I've seen are pityful in solving the future problem mentioned above with the exception two very obscure cases that never got to be popular. The first was a very interesting agent framework caller Voyager, written in Java; the second was Erlang, a pure functional language. Both cases looked like a great way to build a future of small pieces of code running in a collaborative way.

Why didn't Sun buy Voyager and ran with that is the biggest case of missed opportunity I've ever seen. And why erlang hasn't made more impact in the scripting world than all the web services stuff amazes me even more.

Or to put in a different way, does Python or Ruby give us an better tool for the future, not the stuff of Yesterday?

[Sep 11, 2006] Java Community News - Sun's JRuby Move by Frank Sommers

Sep 11, 2006 (

Sun announced last week the hiring of Thomas Enebo and Charles Nutter, the two key developers behind JRuby. Artima asked Enebo and Nutter, as well as Tim Bray, Sun's director for Web technologies, what this move will mean for the Java and Ruby communities.

Sun's hiring of the two key figures behind the JRuby project, Thomas Enebo and Charles Nutter, promises a truly robust Ruby implementation on the JVM. Enebo noted that working for Sun full time will allow the duo to focus on achieving the JRuby project's ambitious goals:

[The goal of JRuby is to] make the best Ruby implementation we can on the JVM. Part of this is making the runtime perform well, and part of it is helping to bridge the Java and Ruby worlds in a way that is easy for a programmer to use...

Sun's hiring us will give us much more time to work on JRuby, which will obviously speed things up; but it will also increase the quality of how we work, since we won't be taxed from an additional day job.

Nutter pointed out that JRuby will be entirely compatible with the C-based Ruby implementation:

We...aim to provide a drop-in replacement for the C Ruby interpreter... We are working to keep JRuby as compatible with C Ruby as possible... Compatibility with C Ruby is of paramount importance; if we can't run what Ruby can run, what's the point?

At the same, JRuby may provide capabilities to Ruby code not available in the C-based Ruby interpreter. Here, again, is Charles Nutter:

There are many cases where the Java platforms and libraries are required for a given project, owing sometimes to the fact that there's just so many Java libraries out there. Other projects may have threading requirements that go beyond what C Ruby can provide, or database connectivity issues that JDBC can solve.

Nutter noted that by keeping JRuby compatible with the C-based Ruby interpreter, projects can easily migrate back and forth between the C-based and JVM-based Ruby interpreters.

The move to support a high quality Ruby implementation that runs on the Java virtual machine highlights the JVM's gradually evolution into a general-purpose execution environment, not unlike the role Microsoft's CLR environment plays. Sun's Tim Bray noted that,

Looking back ten years, it might have been really smart, at the birth of Java, to brand the platform and the language separately. But during Java's early years, the technology was hitting such a big sweet spot that it was easy to see the whole thing-VM, libraries, and language-as a single engineering triumph. Microsoft was smart to get out there and evangelize that a virtual machine and API repertoire aren't necessarily tied to a language. On the engineering front, we've been pretty serious about going multi-language for some time now, [for example,] with the work on Rhino and the proposed new dynamic-method-dispatch bytecode.

Bray also noted that the JVM can become one of the most capable Ruby execution environments:

Currently, native Ruby runs mostly in interpreted mode. If we arrange for JRuby to be compiled into Java bytecodes, it'll be running on the JVM, which is one of the world's most heavily-optimized pieces of software. So JRuby might end up having a general performance advantage.

More specifically, Sun is leading the charge toward highly-parallel multicore computing with the T1000 and T2000 "Coolthreads" chips, which are really well-suited to server-side Web apps. The native Ruby implementation of threads is fairly limited and may not take good advantage of this kind of CPU. JRuby uses native Java threads, which are very highly tuned; so in the particular case of highly-threaded parallel code, there's a pretty good [chance] that JRuby will be a performance winner on modern silicon.

In addition to the performance advantage, the JVM may offer a political safety to developers wanting to code in Ruby in an otherwise Java shop, as Nutter pointed out:

JRuby may ... be able to offer some "platform confidence" to existing Java shops wary of accepting Ruby as a business-critical application language. We all know the suits love anything that says Java, and as far as they're concerned JRuby is just Java in a different form. Of course we've always had to pick and choose languages and libraries from many places, but now there's a much easier path to introducing Ruby into a Java-based organization. That should make a lot of Ruby folks happy, since it means more work, more exposure, and more opportunities to grow the language and the platform.

In addition to runtime and political benefits, a robust JRuby implementation will bring Ruby developers the biggest benefit by allowing Ruby code to make use of thousands of Java class libraries. Enebo noted that,

Java has a huge corpus of libraries... In some semblance most libraries you can think of have already been implemented in Java, usually as an open source package. JRuby allows Ruby to access any Java class and interact with it as if it was written in Ruby. This means a Ruby programmer has a much larger toolbox at their disposal.

Nutter also remarked that JRuby may be a natural way to bridge Java's suitability for writing library code, on the one hand, and Ruby's productivity, on the other:

JRuby is the right tool for anyone who wants to leverage the decade-old decade-tested Java platform and libraries without the sometimes cumbersome overhead of writing everything in Java. Java the language is great... but it's great in the way that C is great, as a language for bare-metal, system-critical libraries and algorithms. Developing more squishy, dynamic, touchy-feely "application" code in Java is a joyless proposition. That's where Ruby comes in...

I like to think that JRuby is to Java what Ruby is to C. UNIX guys have known for years that while the heavy lifting is best done with a fast, static, compiled language like C, most of the real work gets done with scripting languages like Perl, Python, and Ruby. For some reason, it's taken much longer for Java folks to realize the same thing.

Indeed, Sun's Bray noted that accesses to Ruby's productivity is the biggest pay-off of JRuby for Java developers:

The most obvious short-term benefit will come to Java developers who want to write part of their app in Ruby. There are certain classes of problem where dynamically-typed languages give a better fit and you get your solution [finished] sooner. This kind of developer will be able to go on using their existing Java classes and packages and interfaces, while still enjoying Ruby's advantages.

In addition, Enebo pointed out that JRuby is also available as a JSR 223 scripting language:

A Java project can also make use of JRuby by embedding via JSR223 or BSF. This allows a Java application to delegate some subset of its code to a language that may be better suited for filling a particular need. One example I have been playing with recently is interacting with JMX MBeans.

While Ruby and Java seem a natural pair, working full-time for Sun will allow Enebo and Nutter to focus on some of the thornier issues of marrying Ruby's dynamism with the JVM. Nutter pointed out that,

Java has always been designed as a multi-lingual platform, but its support for dynamic languages like Ruby isn't quite where it needs to be yet. That means that for much of Ruby we've had to implement a "VM on top of a VM" that bridges that gap. We do not have control over the Java we maintain our own. We do not have a dynamic invocation bytecode in the we use our own method. We don't have support for we simulate them with movable scopes and command implementations. However our recent efforts have aimed toward componentizing these pieces; as the JVM evolves to support them, we'll be able to toss them out one by one.

Enebo added that,

We have to emulate a set of language semantics which do not map well with the JVM's underlying design. Those language semantics are sometimes quirky and reflected some evolutionary set of changes which need to be properly reflected in our implementation. We are getting pretty close to matching parity with the C implementation, but some of the last cases will be a challenge. Also as we understand the internals better we have ideas, but it is tough to visualize the change thoroughly because of the amount of moving parts we need to understand.

Still, Enebo, Nutter, and Bray all agreed that Ruby is a more natural match between a dynamic scripting language and Java than previous such attempts, such as a Tcl/Java combination. Here is Enebo:

Ruby has significant differences from Java, but those differences are generally flexibility at runtime. You can dynamically create classes and define methods at the drop of a hat. This flexibility takes Java's stricter statically-typed environment and allows you to do things not possible in Java to Java objects [and] classes. That gives the programmer a sense of freedom and empowerment. The differences in these cases will play off as positive features to a programmer. This is one thing I like about the combination of Java and Ruby. Java provides [a] strict well-delineated [environment] ... and Ruby provides a less restrictive environment because of its dynamic properties and dynamic typing.

Nutter added that,:

The disconnect between Java and Ruby is much easier to bridge. Ruby is a pure OO language where Java is a "mostly" pure OO language... Ruby has classes, methods, objects, just like Java. Ruby has basically the same flow control and exception-handling semantics. Ruby makes threading deceptively easy, as does Java. When you ignore Ruby's fluid typing system and simpler syntax, the leap from one language to the other isn't really that far.

What do you think of using a scripting language, such as JRuby, with Java? To what extent did that improve your productivity? And what are some of the downsides of using a dynamic language in Java's static environment?


Re: Sun's JRuby Move by Todd Blanchard

Well, there's a lot of Java code. Some of it is useful. So being able to call it is nice (once upon atime before C++ - we had binary compatibility among the different languages).

OTOH, Sun is looking desperate. They have hired a lot of dynamic language luminaries including Gilad Bracha, Dan Ingalls, and now the JRuby guys, to build dynamic languages on their VM.

It seems like they are hedging their bets. Java the language is a drag - and people are bored with it. It lacks power, it requires pointless verbosity, it sucks creativity, it is dull dull dull to program in. Java the language's days are numbered for sure.

The influencers have moved on to more dynamic pastures.

It might be good - or it might be irrelevant. It depends on whether JRuby can match Ruby in performance, portability, and still provide access to the Java legacy code base in a way that is easy to use.

[Sep 5, 2006] Scripting for the Java Platform By John O'Conner, July 2006

Articles Index

The Java platform provides rich resources for both desktop and web application development. However, using those resources from outside the platform has been impractical unless you resort to proprietary software solutions. No industry standard has defined or clarified how developers can use Java class files from other programming languages. Scripting languages haven't had a standard, industry-supported way to integrate with Java technologies. However, as Bob Dylan once said, "the times, they are a changin'." One change is Java Specification Request (JSR) 223, which helps developers integrate Java technology and scripting languages by defining a standard framework and application programming interface (API) to do the following:

  1. Access and control Java technology-based objects from a scripting environment
  2. Create web content with scripting languages
  3. Embed scripting environments within Java technology-based applications

This article focuses on the specification's third goal and will show you how to use an embedded scripting environment from a Java platform application. A demo application called ScriptCalc will provide a working example of how to extend your applications with user-defined scripts in the JavaScript programming language.

Note: Any API additions or other enhancements to the Java SE platform specification are subject to review and approval by the JSR 270 Expert Group.

[Aug 10, 2006] .NET and Java to get better dynamic language support

By Ryan Paul | Published: August 10, 2006 - 08:07AM CT

With highly expressive syntax that is easy to read, write, and maintain, dynamic programming languages like Python and Ruby are extremely conducive to rapid development. Microsoft and Sun Microsystems have observed growing interest in dynamic programming, and plan to integrate more extensive support for dynamic language features in their respective managed language platforms.

Microsoft developer Jim Hugunin reveals that the Redmond, WA software company is in the process of augmenting its popular .NET platform to simplify development of dynamic programming languages. Hugunin, the developer of a Python implementation for .NET called IronPython, says that the .NET Common Language Runtime will be extended in order to add additional support for dynamic language features. New libraries will be added as well to provide framework components that can be used by language creators. Microsoft hopes that the new features and the availability of the IronPython source code (which will act as a reference implementation) will encourage developers to bring other popular dynamic languages to the .NET platform. Several useful dynamic language features have already been added to .NET 2.0, most notably Lightweight Code Generation and DynamicMethod.

Hugunin is also very enthusiastic about the opportunities created by PowerShell, Microsoft's next-generation command line architecture. Built on .NET technology, PowerShell provides a highly sophisticated dynamic language that includes impressive support for first-class functions and other desirable features. PowerShell also comes with a broad selection of useful libraries and utilities that simplify common computing tasks. Hugunin hopes to expose much of that functionality to Visual Basic and IronPython in order to provide users with a broader selection of options for scripting.

In my overview of PowerShell (then called the Microsoft Command Shell), I pointed out that lack of support for defining classes in scripts represents one of the most significant limitations of the language. By enabling users to leverage the power and functionality of the PowerShell libraries and classes in an elegant and sophisticated dynamic language like Python, Microsoft can provide developers with the best of both worlds.

Python isn't the only dynamic language making its way to .NET. Canadian developer John Lam is currently developing RubyCLR, a bridge that will make it possible for developers to create .NET applications with Ruby. Other dynamic languages ported to .NET include Lisp (Rob Blackwell's L#), and Smalltalk (SmallScript Corp's S#).

Sun Microsystems plans to expand its own Java platform to provide stronger support for dynamic languages. In an uncharacteristically perceptive statement from Sun, Sun Computational Theologist Gilad Bracha admits, "It has come to our attention that some people want to program in things other than Java."

Sun has been steadily laboring to improve dynamic language support, and plans to include a JavaScript implementation in version six of Java Standard Edition. In order to simplify development of dynamic languages for the Java Virtual Machine, Sun has issued a Java Specification Request describing a new bytecode operation called invokedynamic, which Bracha describes as "a loosely-typed invokevirtual." Sun also plans to add support for dynamic metaprogramming facilities (runtime code generation mechanisms analogous to macros in Lisp and metaclasses in Python). Although several dynamic languages are already available for the Java Virtual Machine, including JRuby and Jython, the new features are important because they will simplify the language development process and expand the scope of functionality accessible to those dynamic languages. Dynamic metaprogramming is a particularly exciting feature that has a lot to offer in the field of domain-specific language design.

Many dynamic language enthusiasts are also interested in Parrot, an open source virtual machine designed specifically for dynamic languages. Initially conceived as the foundation for Perl 6, Parrot provides some extremely impressive features including a built-in grammar engine that vastly simplifies the process of language development. Although Parrot is far from complete, a number of languages built on top of it are at various stages of completion, including ports of Python, Ruby, Tcl, Lisp, and basic. Perl 6 developers claim that Parrot will eventually provide better performance than the JVM or .NET for dynamic scripting languages, but performance claims are currently debatable since Parrot is still in early stages of development. There are several significant architectural differences between Parrot and other prominent virtual machines, particularly the fact that Parrot is register-based, whereas Java's bytecode and .NET's Common Intermediate Language are stack-based.

Released yesterday, Parrot 0.4.6 includes new partial Ruby and Javascript implementations, improvements for the grammar engine and abstract syntax tree generator, and new opcodes for accessing globals, as well as numerous bug fixes and improvements.

Managed language platforms have a lot to offer modern dynamic languages, particularly performance (IronPython is one and a half times faster than the standard Python implementation in some contexts), interoperability, and broader library support. As dynamic languages continue to grow in popularity, widely used development platforms like .NET and Java will expand to meet that demand, and Microsoft and Sun will continue to strengthen their commitments to the dynamic language community. Parrot will also eventually catch up and provide a robust, open source alternative.

[Aug 1, 2006] Sun Digging Deep for Dynamic Language Support

REDMOND, Wash.-Sun Microsystems is planning to increase support for dynamic languages and is looking at various ways to better allow dynamically typed languages to run on the Java Virtual Machine.

Gilad Bracha, a computational theologist at Sun delivered a presentation called "Dynamically Typed Languages on the Java Platform" at the Lang.NET 2006 Symposium here on August 1, and said Sun plans to broaden its support for dynamic or scripting languages.

"It has come to our attention that some people want to program in things other than Java," Bracha quipped.

Sun is broadening its support for dynamic languages to satisfy user demand, but also to help broaden the overall community of developers who use the Java platform, Bracha said.

Moreover, Bracha, who joked that "it is good to be behind former enemy lines," noted that among the benefits of enhancing Sun's support for dynamic languages is simplifying implementers' lives.

He also said better support for dynamic languages also would likely yield more good implementations for programmers to use, and provide potential for "awesome performance over time."

Meanwhile, Bracha noted that Sun currently offers support for some dynamic languages on the Java platform, such as Jython, Kawa, Groovy and ECMAScript.

And Java Standard Edition 6 (Java SE 6), also known by the codename Mustang, "will come with a JavaScript implementation packaged in" when it becomes available later this year, he said.

"We're solidly committed" to providing enhanced support for dynamic languages by adding a bytecode called Invokedynamic and adding hot swapping support, Bracha said.

Both of these efforts are part of JSR 292 (Java Specification Request 292), the goal of which is to allow scripting languages to be implemented natively on the JVM, he said.

As a start, Sun is focusing on method invocation, Bracha said. The JVM has four bytecodes for method invocation. One is invokevirtual, which is very close to the Java language semantics, but it is not enough, Bracha said.

"So we introduced invokedynamic; it is a loosely typed invokevirtual," he said.

Invokedynamic is a possible solution to better enabling dynamic languages on the JVM because it "is a natural general purpose primitive. It is not tied to the semantics of a specific programming language, and it is a flexible building block for a variety of method invocation semantics," Bracha said.

But this, too, is only a partial solution, he noted.

Meanwhile, "hot swapping," which is the ability to modify code on the fly, is "one of the coolest things in programming," according to Bracha.

[Jun 24, 2006] Computerworld Nothing to fear from native code – it's been put in its place

I have prepared an account of the history of .Net and Java that's intended to balance more fanciful post-mortem accounts. It reads thus: Sun created Java to cash in on the success of Visual Basic and to convince development managers that C++ coders are all slobbering toddlers playing with nail guns. Sun did grant C++ dispensation for "performance-sensitive applications", a category that covered most of Sun's software catalogue. Microsoft created .Net to keep Java from gaining traction and to put that cross-platform nonsense to rest once and for all. One OS, one run-time, many languages was the best way to go. C#, the Microsoft alternative to Java with the honesty to use "C" in its name, still kept the pencils and paper clips away from the inmates except, of course, for those developers working on performance-sensitive applications, a category that covered most of Microsoft's software catalogue.

Java and .Net turned all existing native software into ticking time bombs, infinitely exploitable by shadowy figures, impossible to hand from the fired to the hired and rife with blue screens, kernel panics and divisions by zero. Developers scurried off for re-training, new languages, new tools, new books, new friends and new -employers.

To the dismay of Sun, and the temporary frustration of Microsoft, C++ survived efforts to render it extinct. Microsoft's frustration gave way to its self-preservation instinct when its own developers demanded that C++ be restored as a first-class language for in-house commercial projects. Bless the lot of them.

Where do things stand now? Fearless C, C++, and Objective-C developers have tools of their dreams that let them dig deeper than ever before into system, OS, and CPU internals. Optimization, at which .Net and Java can only play, is hot as compilers - including the free GNU Compiler Collection - evolve from heuristic to automated empirical optimization. Development tools watch your application run and then re-tune it based on observed behavior.

As for the reputed dangers of using unmanaged and unsafe code, the responsibility for safety has been returned to its rightful place: put in the CPU, the OS and application frameworks. Users deserve protection from errant code, regardless of its origin.

Here's a native code prediction that's way under most people's radar: we'll see more use of assembly language. When developers dare to handcraft architecture-dependent code the performance of an application, or a tweaked open-source OS, can take off. Mac users know how far a simple change can take you; a lot of applications you wouldn't think of as maths-intensive go stratospheric when they're enhanced for PowerPC's AltiVec vector maths accelerator. Developers coding for new, controlled deployments can afford to set high requirements that include a 64-bit CPU, OS and drivers. And if you know you're coding for Opteron and you're ready to write to that architecture, baby, life is a highway.

I'm not preaching a wholesale move away from entrenched Java and .Net, nor do I attribute their success to skullduggery or ignorance. But, it's time for developers and IT buyers of software and development services to drop the presumption that Java's and .Net's training wheels are essential equipment. Java is no longer the only path to writing once and running everywhere, and .Net is no longer the only path to stable and secure Windows applications.

[June 15, 2006] -- 5.5 is new impressive version of Netbeans... Good co-operation features with lines attributed to the developer who last changed them. Completion feature can save some typing...

[Apr 10, 2006] Digg PHP's Scalability and Performance - O'Reilly ONLamp Blog There is simply no truth to the idea that Java is better than scripting languages at writing scalable web applications.

Several weeks ago there was a notable bit of controversy over some comments made by James Gosling, father of the Java programming language. He has since addressed the flame war that erupted, but the whole ordeal got me thinking seriously about PHP and its scalability and performance abilities compared to Java. I knew that several hugely popular Web 2.0 applications were written in scripting languages like PHP, so I contacted Owen Byrne - Senior Software Engineer at to learn how he addressed any problems they encountered during their meteoric growth. This article addresses the all-to-common false assumptions about the cost of scalability and performance in PHP applications.

At the time Gosling's comments were made, I was working on tuning and optimizing the source code and server configuration for the launch of Jobby, a Web 2.0 resume tracking application written using the WASP PHP framework. I really hadn't done any substantial research on how to best optimize PHP applications at the time. My background is heavy in the architecture and development of highly scalable applications in Java, but I realized there were enough substantial differences between Java and PHP to cause me concern. In my experience, it was certainly faster to develop web applications in languages like PHP; but I was curious as to how much of that time savings might be lost to performance tuning and scaling costs. What I found was both encouraging and surprising.

What are Performance and Scalability?
Before I go on, I want to make sure the ideas of performance and scalability are understood. Performance is measured by the output behavior of the application. In other words, performance is whether or not the app is fast. A good performing web application is expected to render a page in around or under 1 second (depending on the complexity of the page, of course). Scalability is the ability of the application to maintain good performance under heavy load with the addition of resources. For example, as the popularity of a web application grows, it can be called scalable if you can maintain good performance metrics by simply making small hardware additions. With that in mind, I wondered how PHP would perform under heavy load, and whether it would scale well compared with Java.

Hardware Cost
My first concern was raw horsepower. Executing scripting language code is more hardware intensive because to the code isn't compiled. The hardware we had available for the launch of Jobby was a single hosted Linux server with a 2GHz processor and 1GB of RAM. On this single modest server I was going to have to run both Apache 2 and MySQL. Previous applications I had worked on in Java had been deployed on 10-20 application servers with at least 2 dedicated, massively parallel, ultra expensive database servers. Of course, these applications handled traffic in the millions of hits per month.

To get a better idea of what was in store for a heavily loaded PHP application, I set up an interview with Owen Byrne, cofounder and Senior Software Engineer at From talking with Owen I learned gets on the order of 200 million page views per month, and they're able to handle it with only 3 web servers and 8 small database servers (I'll discuss the reason for so many database servers in the next section). Even better news was that they were able to handle their first year's worth of growth on a single hosted server like the one I was using. My hardware worries were relieved. The hardware requirements to run high-traffic PHP applications didn't seem to be more costly than for Java.

Database Cost
Next I was worried about database costs. The enterprise Java applications I had worked on were powered by expensive database software like Oracle, Informix, and DB2. I had decided early on to use MySQL for my database, which is of course free. I wondered whether the simplicity of MySQL would be a liability when it came to trying to squeeze the last bit of performance out of the database. MySQL has had a reputation for being slow in the past, but most of that seems to have come from sub-optimal configuration and the overuse of MyISAM tables. Owen confirmed that the use of InnoDB for tables for read/write data makes a massive performance difference.

There are some scalability issues with MySQL, one being the need for large amounts of slave databases. However, these issues are decidedly not PHP related, and are being addressed in future versions of MySQL. It could be argued that even with the large amount of slave databases that are needed, the hardware required to support them is less expensive than the 8+ CPU boxes that typically power large Oracle or DB2 databases. The database requirements to run massive PHP applications still weren't more costly than for Java.

PHP Coding Cost
Lastly, and most importantly, I was worried about scalability and performance costs directly attributed to the PHP language itself. During my conversation with Owen I asked him if there were any performance or scalability problems he encountered that were related to having chosen to write the application in PHP. A bit to my surprise, he responded by saying, "none of the scaling challenges we faced had anything to do with PHP," and that "the biggest issues faced were database related." He even added, "in fact, we found that the lightweight nature of PHP allowed us to easily move processing tasks from the database to PHP in order to deal with that problem." Owen mentioned they use the APC PHP accelerator platform as well as MCache to lighten their database load. Still, I was skeptical. I had written Jobby entirely in PHP 5 using a framework which uses a highly object oriented MVC architecture to provide application development scalability. How would this hold up to large amounts of traffic?

My worries were largely related to the PHP engine having to effectively parse and interpret every included class on each page load. I discovered this was just my misunderstanding of the best way to configure a PHP server. After doing some research, I found that by using a combination of Apache 2's worker threads, FastCGI, and a PHP accelerator, this was no longer a problem. Any class or script loading overhead was only encountered on the first page load. Subsequent page loads were of comparative performance to a typical Java application. Making these configuration changes were trivial and generated massive performance gains. With regard to scalability and performance, PHP itself, even PHP 5 with heavy OO, was not more costly than Java.

Jobby was launched successfully on its single modest server and, thanks to links from Ajaxian and TechCrunch, went on to happily survive hundreds of thousands of hits in a single week. Assuming I applied all of my new found PHP tuning knowledge correctly, the application should be able to handle much more load on its current hardware.

Digg is in the process of preparing to scale to 10 times current load. I asked Owen Byrne if that meant an increase in headcount and he said that wasn't necessary. The only real change they identified was a switch to a different database platform. There doesn't seem to be any additional manpower cost to PHP scalability either.

It turns out that it really is fast and cheap to develop applications in PHP. Most scaling and performance challenges are almost always related to the data layer, and are common across all language platforms. Even as a self-proclaimed PHP evangelist, I was very startled to find out that all of the theories I was subscribing to were true. There is simply no truth to the idea that Java is better than scripting languages at writing scalable web applications. I won't go as far as to say that PHP is better than Java, because it is never that simple. However it just isn't true to say that PHP doesn't scale, and with the rise of Web 2.0, sites like Digg, Flickr, and even Jobby are proving that large scale applications can be rapidly built and maintained on-the-cheap, by one or two developers.

Further Reading



Is Java over the hill - O'Reilly Mac DevCenter Blog

Seems like there is a buzz in the air these days about the demise of Java. Two recent examples include Marc Andreessen's comments on how Java has acquired all the issues that its predecessors have and how PHP will take the lead away from Java in the not so distant future and Bruce Tate's recent OnJava article on specific places where Java is losing ground to other languages.

So is Java on the way out ? I hope not, because I believe that fundamentally Java is a great language, but Java does have some real problems. I think the root cause of most of the problems is Java's enormous scope and complexity.

A couple of months ago, after reading all sorts of articles on Ruby and Ruby on Rails, I decided that I would try them out. My goal was not to create some epic program, just to get something working that gave me an idea of what Ruby was all about. I started by downloading and installing Ruby (not realizing that it was included in OS X) and some libraries, then I downloaded and installed Ruby on Rails, then I found an article at and used it to create my first Ruby on Rails application. Total time from the first download to the program working, including setting up the database, was somewhere between an hour and an hour and a half. Not too bad, from my point of view that is just about the right amount of time a developer should be willing to dedicate to going from no knowledge to having a simple working demo. The same thing in PHP might not have been as easy to code, but the setup would have only 10-15 minutes, giving me more than an hour to code up an example

How long would that whole process take in Java? Just think of all the steps involved: downloading and installing the JDK, figuring out to use Tomcat (or some other servlet engine), installing Tomcat, getting the JDBC driver, setting up the JDBC driver, deciding how to do the database queries (either through your own code or with Hibernate or some other package) - then assuming I didn't go off shaving yacks, I would finally be ready to sit down and write code.

Think about this: Java is so complex that new OS X versions come out months after the Windows and Solaris versions and needs to be compiled and optimized by Apple, not Sun.

What's worse for all this complexity, we don't even get :

  • a basic scripting language
  • a built in, simple web server
  • a built in, simple servlet container
  • a built in build tool

Sure all of these things exist in the greater Java community (Groovy, Jigsaw, Tomcat and Ant respectively, for example) but since a large amount of Java's installed base is developing web apps, why does Sun keep adding marginally useful Swing widgets instead of trying to include things that developers might actually use ?

What does Java need to do to get it's act together ?

Software DevelopmentTiger by the Tail Software Development, SDWest 2004 By Rick Wayne

Bad Java Mood

In his tutorial "JDK 1.5-What's New," Paul Tyma, the president of New York City-based consulting company Outscheme, was willing not only to teach it, but to critique its new features. (In a June 2003 Web rant titled "I'm in a Bad Java Mood Today," Tyma made some telling points about Java's "ivory-tower" features-why does every single program have to extract the Object class from a JAR file and load it, anyway? He went on to say that "It's like Java has been designed according to the Big-Honking-Feels-Good-Runs-like-Crap pattern.

[Apr 3, 2006] Slashdot Interview With the Father of Java

Embedded and Java shouldn't be seen together!

(Score:3, Informative)

by Bad Mamba Jamba (941082) on Friday March 31, @09:57PM (#15039329)

There's been all kinds of growth lately in cellphones and more and more embedded systems.

As an unfortunate software developer on one of Sun's high profile embedded Java projects, OCAP, it irks me to see Java and Embedded listed in the same sentence. I could rant for days on the shortcomings of Java and it's unsuitability for an embedded environment but to name some of my biggest peeves...

1. Any language without unsigned primitive types doesn't belong in embedded land. Embedded systems frequently use unsigned data types. Making me cast up to a bigger primitive size and doing all kinds of bit manipulation gyrations to make unsigned byte data come out right is just wrong.

2. Most embedded implementations don't have room for a JIT compiler. So you end up interpreting everything or precompiling on the way down to the embedded device. Most embedded devices these days still have pretty lame CPUs in them so everything Java is extra extra slow even relative to a desktop counterpart. Especially if you're doing an app with any kind of graphics. As for pre-compiling...this simply isn't an option in some deployments...say OCAP for instance!

3. Many embedded environments use multithreading to process various IO tasks etc. Having what amounts to a critical section for your only means of synchronization (and yea Java 5 tries to solve this but most embedded devices are still back on 1.x implementations of Java) leads to one heck of a deadlock nightmare if you aren't very careful with your design. I need not cite the performance hit here either if you're lazy with your syncs. I also need not mention that the thread scheduling is left unspecified so your app may run OK on one JVM but when you port ot another there's no telling...

4. Java requires a lot of memory if you really want to do something useful. Especially anything graphics related. Most embedded devices don't abound with a ton of memory. As such you end up garbage collecting more and running into problems. Garbage collection can be a costly operation per #2 above. And finding a memory leak in a Java program ain't no picnic either. Especially on an embedded device where you may or matynot be able to get tools in there to see what's going on.

Yeah you can circumvent some issues if you're smart about your design and don't do stupid things but so far most embedded Java developers I've met are imports from desktop/server land and don't think about this stuff so you can imagine the mess you end up with.

Just my two cents...

Java bloat

(Score:1, Informative)

by Anonymous Coward on Friday March 31, @10:32PM (#15039515)

Now I know I am going to get mod down, tossed to the wolves, raked over the coals with an inbox full of your nuts -- but here goes because after spending 4 years in Java I now have an opinion.

Java is bloatware and sells hardware. It is great on a desktop as an applet or even as a program running locally where you have 2GB or ram and dual procs to itself. But it has no freaking business on a server. In fact, those writing server apps in Java are plain utterly stupid.

Um, what?

(Score:5, Informative)

by Anonymous Coward on Saturday April 01, @04:33AM (#15040818)

Where does this 256mb per user figure come from? Any app that requires that much mem per user, and isn't doing something like ray tracing the next King Kong movie, is broken. Yeah I can write utterly broken C++ that also sucks up 256mb per user to log in to a website, but that has nothing to do with the language.

I think you probably don't understand how Java server stuff works. Your reference to Apache being part of a Java server deployment shows that. It used to be, back in the old days a few years ago, that people often installed Tomcat and Apache together using a connector. I don't know anyone who still does this. Tomcat 5 servers static content about as fast as Apache.

As for threading: If you're writing a web application, you don't need to write any threads. You need to give a little bit of thought to threads, because your Servlets are objects and they can be used by multiple threads at the same time. Handling this is quite trivial: you just don't touch any instance variables from methods in your servlet. If you don't want to try to figure out threading, that's all you need to know. Tomcat will do all the rest.

Again, I have no clue where you got that 256mb per user, but I'll clarify a few points. In a typical Java Servlet application, which would use Tomcat (or similar) to serve an application where users log in, do stuff, and data are stored in a DB, this is how resource use will work:

I really don't think you understand how these things work, and if you have real-world experience with Java webapps, then the ones you are thinking of were written by clowns.

Contact management, calendar management, sales automation []

Re:Um, what?


by Anonymous Coward on Sunday April 02, @10:20AM (#15045434)

The garbage collection is still a problem it has to be said though a couple of things can really help depending on your application. With J2EE apps something I've found (specifically running under WebSphere on AIX though the technique should work well enough on anything) is to use smaller JVM's (say about 512MB each) and let WAS distribute load around them as it sees fit. The upshot of this is that although the pause still occurs it is much shorter (there's less to deal with) and doesn't occur for every transaction at the same time.

This doesn't help with desktop apps of course, although the pauses are a great deal shorter in JSE 5 because of better use of parallelism during collection periods during which application threads are stopped. The pauses are also more uniform due to deliberately spacing them such that there is less impact on collection latency as seen by application threads. And the heap is better utilized due to improved promotion failure handling which postpones the need to start collections. JSE 5 ergonomics also includes better handling of thread local allocation buffers (TLABs). Adaptive resizing of TLABs reduces young generation fragmentation and wasted space thus reducing the number of collections.

The other thing with Swing apps is to spend some time looking at the number of different events that occur over the GUI. Often when a Swing app appears slow it is because a single click is firing off hundreds of different events in the model and you get a sort of event storm with the JVM thrashing about to keep up. A really well written swing app (see Netbeans or IDEA for example) doesn't really seem to suffer nearly as much. Again a valid criticism of Java is that building good GUI in it is harder than it should be and a lot of work is going in to improving this at the moment with Mustang (JSE 6) showing good early promise.

Re:Java bloat


by MemoryDragon (544441) on Monday April 03, @08:05AM (#15049019)

Interesting numbers, I have 2000 users serviced by a single 128MB Tomcat running Jetspeed/Turbine, and has been running that for years now (Uptime can be measured in years)

Re:Java bloat


by pebs (654334) on Monday April 03, @03:04PM (#15052491)

if you have to restart the VM for some reason you kick all users off. Messy.

With Tomcat, if I have to restart, it doesn't kick all the users off. Their sessions are serialized to disk and they can continue where they left off once the app starts again.

Re:why is java soo dead ?

(Score:1, Redundant)

by d3ik (798966) on Friday March 31, @08:20PM (#15038509)

The preview is there for a reason...

why aren't any of the cool and useful websites being created with java on the back-end ?

Honestly, I believe the problem here is more with Java developers than Java itself. Java developers are constantly trying to overwrite their code (as in writing more than necessary, not saving over an existing file:). Instead of using the KISS mentality, everything has to have an XML configuration file and object factory. Java devs are typically very black and white, code to the requirements, check off the features on their checklists, etc.

On the other hand, Google has said they use Java for a number of applications. It's a great tool in the right hands.

why has java been relegated to the enterprise space only ?

A number of reasons... PHBs feel more comfortable with a "proven" solution with "corporate backing" versus all that pony tail and birkenstock hippie open source stuff (kidding!). Also, the creative types that typically make the 'innovative' web applications usually shy away from the corporate stigma that Java has. See the above comment. Java developers are typically viewed as corporate shills.

why is java almost dead on the desktop ?

I'll concede that this is due to Java itself. AWT sucked, Swing is marginally better... SWT seems to be the way to go but since Sun didn't invent it they're not going to back it.

what are you smoking Gosling...when you say that java is still evolving ?

Do you own a newer cell phone? Does it have cool features like text messaging and possibly web browsing? If so, your phone more than likely runs J2ME.

Re:why is java soo dead ?


by MemoryDragon (544441) on Monday April 03, @08:06AM (#15049026)

Useful websites like,, or They all run on java.

Re:Not compatible with itself


by MECC (8478) * on Monday April 03, @09:09AM (#15049314)

I'll try that and see if I can get ciscoworks' and fluke's and mci's java to play together, which they don't right now. Of course, it still doesn't change the fact the all those products, to name just a few, because they need java to run, don't work, and the workaround/kludge required to get them to work is needed for one reason only - java. Other languages don't have this problem. Why java?

Not compatible with itself

(Score:0, Troll)

by MECC (8478) * on Friday March 31, @09:25PM (#15039114)

Does this guy have any excuse why Java isn't compatible with itself? Why won't something written to run in 1.4.1 run in 1.4.2, or 1.5? All this ends up meaning is that no matter how interesting java the language is, when you get something written in java, it comes out of the box broken. Seriously, if I install two java products on my computer, each written in a different version of java, they break one another, unless I come up with a work-around.

For a language to be so incompatible with itself, no matter how you cut it, or what last-minute workaround you manage to cough up, that is so wrong there is no final verdict to pass on java other than "FAILURE".
I've had to tell people walking in the door with 30k$ products to get lost because it written in java. Why? Because it was found to break the 100k$ product written in another version on java. That makes it range anywhere from 100% dysfunctional to just a run of the mill nightmare to deal with.

Other bendors trot out their java-powered web sites, and it ends up either not working because of another currently deployed java product or it breaks the currently deployed java product. Unfortunately for that bendor, they get the distinction of being labeled 'unable to support services' - for no reason other than that they just had to do it in java.

As a matter of practice, anyone suggesting using java to implement something should just have their tounge cut out and stapled to their foreheads. Before they're fired.

[Mar 25, 2006] Headway Software - Products - Structure101 An interesting static byte code analyzer for Java

Structure101 for Java parses your byte code and creates an implementation model of all the dependencies mapped up through the compositional hierarchy. It does this at a rate of mega-SLOCs per minute. You can browse the model and view dependency diagrams at any level - method, class, package or jar. (More...)

We consider structure to be important through the life of an application - not just something that gets fixed in an expensive 'Big Bang'. At the same time, we realize that many of our customers only begin looking at structure when they get the feeling it is out of control.

...Structure101TM, currently available for Java only, is designed for live, evolving, imperfect, real projects, where ongoing development must continue. We have focused on making sense of large, difficult code-bases. Structure101 lets you keep a lid on the structural complexity so that it doesn't get any worse, and enables you to gradually streamline the structure while still working to hard delivery schedules.

We have been doing structure since 1999. The core engine of Structure101, the Higraph, is on its 3rd incarnation, lightning fast and massively scalable. It is our passion to continually find new ways to understand and control structure - to make structure simple.

It is very common for packages and classes to outgrow themselves. Big fat packages or classes tend to be difficult to work with because they lack the structure that helps to guide human understanding. Structure101 helps by letting you view even very large dependency graphs of the package or class contents. To help further, Structure101 can perform an Auto-partition on the graph, to reveal the hidden, inherent structure. As well has helping you understand what you've got, seeing the inherent structure may help you to decide how to add structure by creating sub-packages or classes. -- What Is Java

The JVM Without Java

Indeed, one of Tate's key criteria in finding potential successors to Java's success is the idea that "the next commercially successful language should have a version that runs in the JVM. That would help a language overcome many obstacles, both political and technical." He points out that a VM approach gives you security ("if you can secure the virtual machine, it's much easier to secure the language"), portability, interoperability, and extensibility. With the JVM having effectively solved these problems, a new language wouldn't need its own VM if it can simply run in the JVM that is already on millions of computers.

In many ways, this is already happening. Writing interpreters for scripting languages in Java effectively brings these languages to the JVM, like Rhino for JavaScript, Jython for Python, or JRuby for Ruby.

But it's also possible to bypass the Java language altogether and go straight to the JVM level. There are already C-to-JVM bytecode compilers, such as the commercial Axiomatic Multi-Platform C, which provides a subset of ANSI C. Furthermore, the growth of Java bytecode manipulation with tools such as ASM and Apache BCEL allow Java applications to create executable classes at runtime. This is no longer Java, but effectively a form of assembly language programming for the JVM.

Perhaps appreciating the desire to run non-Java code on the JVM, a new JSR, "Supporting Dynamically Typed Languages on the JavaTM Platform" (JSR 292), has recently been introduced, specifying a new bytecode that would make the JVM better suited to running languages without static type information.

[Mar 12, 2006] James Gosling Java Is Under No Serious Threat From PHP, Ruby or C# @ JAVA DEVELOPER'S JOURNAL

"There have been a number of language coming up lately," noted James Gosling today at Sun's World Wide Education & Research Conference in New York City when asked if Java was in any kind of danger from the newcomers. "PHP and Ruby are perfectly fine systems," he continued, "but they are scripting languages and get their power through specialization: they just generate web pages. But none of them attempt any serious breadth in the application domain and they both have really serious scaling and performance problems."

The Father of Java then dismissed Microsoft's C# as having had potential, but no longer: "We were afraid they were going to do something really creative - but they're hopelessly focused on one platform."

PHP (for example) is able to make things simpler because it's 100% aimed at web pages, Gosling explained. Whereas with Java, he said, "We have a balancing act: we need the simplicity but we also need power."

He called Simplicity and Power "evil twin brothers" - "Building systems that have a lot of power just attracts complexity. Because of the way that the world has become so interconnected it helps to have systems where it carries over from one domain to another. You can do web presentation stuff really well in PHP but you couldn't write a library that does, say, interplanetary navigation."

On the other hand, any discussion about Java "versus" PHP or Ruby or any other language is in many ways moot, Gosling also stressed:

"We also tried to work with all these languages ,so that Java works with PHP and works with Python, so you can do the web presentation layer in PHP and the analytics in Java. Lots of people do that."

i-Technology Viewpoint Java's Not Evolving Fast Enough @ SYS-CON AUSTRALIA

A programming API represents a documented contract between a function that provides some kind of computing service and those who wish to use it. In Java, once an API is used there is a physical contract between the two that the compiler and JVM enforce. If at some point in the future the author of the API wishes to make changes, they are limited in scope; if the author renames methods or removes arguments, programs that are bound to the previous signature will no longer run. The change can be published with the new version of the class library or framework so that users can upgrade their code; however, in many cases this isn't a viable option. It may be that the system that used the old API is no longer being worked on by a development team and is considered stable, or that the release cycle of the now broken system is dependent on other circumstances that prevent it from being upgraded.

No API can be got right the first time, irrespective of how many specifications, architecture meetings, and examples take place prior to its release. The whole idea of launching a set of class libraries and Javadocs onto the world as being the eternal way of doing something goes against the whole philosophy of agile programming. One of the principles of extreme programming is that a good program is built flexibly and in a fluid state; at each stage the feedback loop of usage and reconstruction means that the right solution is arrived at by accident rather than by design. This is akin to evolution, whereby variations in a species arise by random mutation and are mixed in offspring to create new individuals. The fittest varieties survive whatever the environment provides and the cycle continues, allowing the species to adapt and evolve.

The Java language has maintained its API over many releases so a program that is compiled on 1.2 will run unchanged on a Java 5 runtime environment The benefit of this is that older Java programs remain functional on modern JREs; however, it comes at a price. The language now contains a plethora of deprecated classes and methods, new features are sometimes sacrificed to ensure backward compatibility, and the evolution of Java is hindered and held back. The class java.util.Date, for example, has more public deprecated methods than non-deprecated ones. Not a lot has changed in the domain model of Dates since the Gregorian calendar was introduced in 1582, and this ratio of legacy to current API is a sign that code change is a natural flux that occurs during its usage.

In nature the extinction of a species is not a gradual thing but comes in waves. Punctuated Equilibrium describes an effect whereby the environment remains fairly static for a while and then a huge amount of change occurs in a small amount of time. These boundaries are mass extinctions that not only cause many species to die out, but are also the event that allows others to flourish and fill the void left by the departing ones. To a certain extent Java benefited from this back in 1995, when it was born out of a combination of the best ideas of C++ and Smalltalk; the catastrophic meteorite striking at the time being the Internet and demand for heterogeneous networked computing.

What worries me 10 years later is that I don't believe Java is evolving fast enough, and that strong typing to antiquated APIs are holding it back. XML won over a slew of competing technologies for program-to-program communication transport because it is text based, allowing it to be read by heterogeneous end points (as opposed to alternatives like CORBA IDL or other binary RPCs). XML is also flexible in its typing, because tags can be declared as optional and new tags can be introduced in a message without breaking callers using the older format. While Java has done well as an enterprise language in the application server space, this is largely due to the fact that the big names of IT backed it rather than any inherent feature of the language. Languages such as Ruby and Perl have grown tremendously in the past few years and now command a sizeable portion of application development.

If Java is to remain at the forefront of technology for the next 10 years, it must find a better way to evolve. It needs to find a way of decoupling API calls between internal code and external blocks, perhaps even introducing soft typing calls across program boundaries or having flexible message transport across modules. While XML parsing functionality is now included in a Java runtime by default, it feels very shoehorned into place when compared with how .NET has done the same integration. Older languages like COBOL or RPG, as well as Visual Basic, include the concept of structures into a program definition that can be externalized, and having Java include a slew of JARs and runtime bolt ons to do simple XML parsing seems a missed opportunity to embrace the technology.

Becoming strong enough to do battle with Microsoft, the T-Rex of computing, may have fared well for Java in the past, but at the expense of what it has now become and how quickly it can keep up with change and the legacy it has created. I fear that unless a fundamental change to the language is made that allows more flexibility in binding between functional units, between and across JVM boundaries, Java will be a victim of the same fate as the behemoths it fights in the IT tar pit. Survival against change - whether in nature, technology, or business - is determined by ones ability to adapt. Java needs to move forward by being more agile. As the language grows with more and more APIs and divisions, it runs the risk of losing sight of the finish line, while smaller and nimbler technologies become more ubiquitous. When the next IT meteor strikes, Java must be the fastest to adapt if it is to survive and grow over the next 10 years.

[Feb 5, 2006] Groovy - Home (see also Gosling interview wee he praises Groovy)

Groovy is an agile dynamic language for the Java 2 Platform that has many of the features that people like so much in languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax.

Groovy is designed to help you get things done on the Java 2 Platform in a quick, concise and fun way - Groovy brings the power of a scripting language directly into the Java 2 Platform. For example:

As well as being a powerful language for scripting Java objects, Groovy can be used as an alternative compiler to javac to generate standard Java bytecode to be used by any Java project.

[Feb 2, 2006] Rhino a JavaScript implementation in Java.

Created primarily by Norris Boyd (at Netscape). Used by IBM in Tivoli. Rhino is ECMA-262 Edition 3 compliant.

Rhino is an open source JavaScript engine. It is developed entirely in Java and managed by the Mozilla Foundation. There is also an implementation in C known as SpiderMonkey.

The Rhino project was started at Netscape in 1997 and released to in 1998. It was made open source thereafter. The project gets its name from the animal on the cover of the JavaScript book [1] from O'Reilly (preview online).

Rhino converts JavaScript scripts into Java classes. Rhino works in both compiled as well as interpreted mode. It is intended to be used in applications, hence there is no support for the browser objects that are commonly associated with JavaScript.

Rhino can be used as a debugger by making use of the Rhino shell. It can be used in applications by embedding Rhino.

[Jan 28, 2006] trails Home

Trails is a domain driven development framework in the spirit of Ruby on Rails or Naked Objects.

The trails project aims to make java enterprise application development radically simpler by allowing developers to focus on the domain model and having other portions dynamically generated. We will leverage existing technologies such as Spring, Tapestry, and Hibernate rather than reinventing.

[Jan 28, 2006] Java Makes Scripting Languages Irrelevant by Diomidis Spinellis. That author claim that "The gap between system programming languages and scripting languages is slowly closing. Problems with high cost of development, slow debugging, java class libraries hell, etc are swiped under the carpet. For example, some scripting languages are capitalizing on Java's infrastructure by having their code compile into JVM bytecode. However, there is still a lot of ground in the middle that is up for the grabs. New system programming language designs can offer more of the advantages now available only through scripting, while scripting languages are constantly benefiting from hardware performance advances that make their (real or perceived) efficiency drawbacks less relevant every day. The issue of the result's quality remains an open question on both fronts." In reality the level of the language (which can be measured approximately by the number of token that is required to express a given program) is of paramount importance and here Java cannot compete with languages like Python and Ruby.

Rumors of the death of scripting languages ...

Notice, how most of the nice features applications obtain through the use of scripting languages are now offered by Java:

In addition, in applications written in Java what can be considered as an API already comes for free as part of their object-oriented design. One only needs to allow an application to dynamically load user-specified classes, expose its API by providing access to some of the application's objects, limit the application's exposure through the security manager and exception handlers, and the need for a separate scripting language vanishes.

In fact, many modern Java applications that support beans, plugins, and other extension mechanisms, follow exactly this strategy. Eclipse, Maven, Ant, Javadoc, ArgoUML, and Tomcat are some notable examples. Even on resource-constrained embedded devices, such as mobile phones, which are still programmed in a system programming language, configuration and customization is currently moving toward the Java direction.

... are greatly exaggerated

Does the trend of customizing applications through a Java interface make scripting languages irrelevant? Yes and no. As an application configuration and extension mechanism, Java is probably the way to go. The cost of marshalling and unmarshaling data objects and types between the application's code written in Java and the conventions expected by a different scripting language is too high for the limited incremental benefits that the scripting language would offer. On the other hand, scripting languages still have an edge in a number of areas, offering us a number of distinct advantages.

A more flexible or imaginative syntax. Think of Perl's numerous quoting mechanisms and its regular expression extension syntax, or Python's use of indentation for grouping statements. These make some program elements a lot easier to read. As an example, variable substitution within Perl's or the Unix shell's double quoted strings is by far the most readable way to represent a program's output.

Less fuss about types. Most scripting languages are typeless and therefore easier to write programs in. For example, Perl makes writing a client or server for an XML-based web service a breeze, whereas in Java we have to go through a number of contortions to implement the same functionality. Of course, the robustness and maintainability of code written in a typeless language is a different question, as many of us who maintain production code written in a scripting language later discover.

A more aggressive use of reflection. Consider here Perl's eval construct and Python's object emulation features. These allow the programmer to construct and execute code on the fly, or dynamically change a class's fields. In many cases these features simplify the construction of flexible and adaptable software systems.

Tighter integration with command-line tools. Although Java 1.5 comes with an API containing over 3000 classes-with thousands more being available through both open source and proprietary packages-many operations can still be performed in a more reliable and efficient manner by interfacing with venerable command-line tools. The Unix scripting languages provide many facilities for combining these tools, such as the creation of pipelines, and the processing of data through sophisticated control constructs.

Viability as a command language. Many scripting languages, such as the ones of the operating system shells, can also double as a command language. Command-line interfaces often offer a considerably more expressive working medium than GUI environments (we'll expand on that in another column). Coupling a command-line interface with a scripting language means that commonly executed command sequences can easily be promoted into automated scripts; a boon to developers. This coupling also encourages an exploratory programming style, which many of us find very productive. I often code complex pipelines step by step, examining the output of each step, before tacking another processing element at the pipeline's end.

A shorter build cycle. Although for many systems a build cycle that provided time for an elaborate lunch is now sadly history, the tight feedback loop offered by the lack of a compilation step in scripting languages allows for rapid prototyping and exploratory changes, often hand-in-hand with the end-user. This is a feature that those using agile development methodologies can surely appreciate.

So, where do we stand now? The gap between system programming languages and scripting languages is slowly closing. For example, some scripting languages are capitalizing on Java's infrastructure by having their code compile into JVM bytecode. However, there is still a lot of ground in the middle that is up for the grabs. New system programming language designs can offer more of the advantages now available only through scripting, while scripting languages are constantly benefiting from hardware performance advances that make their (real or perceived) efficiency drawbacks less relevant every day. The issue of the result's quality remains an open question on both fronts.

We developers, as avid tool users, enjoy viewing the battle from atop, reaping the benefits.

[Mar 14, 2005] Choosing a Java scripting language Round two By David Kearns

Scripting languages have proven their value to Java developers. They let users extend and customize the application's functionality and appearance, which adds value to the program. In addition, they can dramatically simplify certain design tasks for a programmer by making it possible to define, load, and evaluate functions on the fly. For a developer, the task of integrating one or more of these scripting languages is easy. Picking one from the growing list is hard. This article describes some of the issues that come with supporting a scripting language in your Java application and compares Groovy, JudoScript, Pnuts, JRuby, Jacl, Jython, Rhino, and BeanShell in a variety of ways to help you make the right choice. (4,300 words; March 14, 2005)

Is a Java macro language enough

SUN is going to add a new byte-code to support scripting languages. A new JSR, "Supporting Dynamically Typed Languages on the JavaTM Platform" (JSR 292), has recently been introduced, specifying a new bytecode that would make the JVM better suited to running languages without static type information.

What do you get if you add a MOP?

Today we have some level of meta capabilities thru the reflection abilities in Java and the several Aspect-Oriented tools out there. (AspectJ, JBoss AOP, Spring AOP and others) But those clearly aren't a MOP. A MOP is about fully exposing the languages core concepts and implementation thus allowing the language to be extended at well defined places and allowing us to provide new capabilities and extensions previously not thought of. All of that while still maintaining the same basic syntax of the language. Meta-objects and Meta-object Protocols. Aspect-Oriented programming tools give us some capabilities to reposition our behavior and to cause it to be called in the correct situations, but fall short of a true MOP. Java itself has class objects (they don't do much, but we have them), we have Dynamic Proxies and we have XDoclet and byte-code modifiers. All this to give us the ability to work with the code and meta-system.

What will allowing Lisp Style Macros allow?

Ted mentions OpenJava as a tool that allowed macros of similar power to Lisp macros to be added to Java. This is very interesting work and you should read the papers on that site for a good understanding of what they were working towards. There is a point in the paper OpenJava: A Class-Based Macro System for Java, that I disagree with concerning the power of the Lisp macros to be customized for specific types, but lets just say that you can get that same effect using a combination of macro system with and on the Lisp MOP. As for other macro systems for Java, I don't think we'll see one worth working with without a MOP of some kind. If you read this paper, they basically describes a simple MOP that is able to manipulate a program at compile time and then save that meta-data in a separate set of byte-code as the JVM doesn't need that extra info to run. But notice, that they have to separate that description and also that they save some of that data in little strings in the classes. Ted doesn't mention whether he wants the MOP data around at run-time. But for us suffice to say macros are about allowing us to have code that manipulates code that we have and either modifies it or creates new code.

Is there a better language to generate byte-code?

On the better language for generating byte-code he doesn't really reference anything besides the work Microsoft is doing on the CLR and CLI stuff for .NET. He does mention them as more language friendly but does mention that it mostly has the same drawbacks as the Java platform. I conjecture that the byte-codes lack of full power is part of the issue. This is why SUN is going to add a new byte-code to support scripting languages.
There was a push both internally and externally early on in Java's history before 1.0 was even out, to extend the byte-code in concert with Parc-Place Systems (an old Smalltalk vendor - some of who's employees went to SUN to work on Java) to support more of this dynamic capability including MOPs, but choose not too.

[Sep 19. 2006] A Brief Hello to Andy O.

Saturday December 06, 2003

Sun's Gotten It Right

In the past couple of years, I've seen an endless number of rants about how Sun is screwing up Java. Endless complaints about the JCP being an awful mechanism for bringing forth new standards. Bitter open source purists bitching about Java not being true open source, and proclaiming the imminent downfall of the language because of it. A mountain of attacks on J2EE being too complex. AOP zealots frustrated that AOP hasn't been incorporated in the core J2SE system. A thousand and one framework developers hawking their alpha 0.0003 software they developed last weekend and stuck on sourceforge as clearly superior to anything ever produced by Sun. Poor souls inflicted with terminal cases of Featuritis begging that Java incorporate every possible language feature ever contemplated in the software world. Haughty wannabe stock analysts pointing out Sun's flagging financial performance. Wanna be developers who have difficulty compiling a "Hello World!" example laughing at the ever-morphing state of Sun's own app server offerings.

I believe all of these people miss a fundamental point. Above all else, what every language system needs to be successful is a stable base that the world can count on being there. They need a unified language that's available on a wide variety of platforms. They need a high level of backwards compatibility, and not have huge swaths of code broken by the next upgrade. And they need a language that has proven usefulness in the marketplace.

This is exactly what Sun has given us. They've given us a language with astonishing backwards compatibility. The VM improves in speed and stability with every release. You can count on Java X.X being very much the same on any modern platform you care to mention. The mix of features in the language and their interplay with each other is unique, compelling, and proven to be extremely useful in day-to-day software development. The rate of change has been slow enough that the marketplace isn't thrown into complete chaos every 3 months. They've given the world a healthy, solid, stable base to build on. It's this stability which enables people to pitch their AOP frameworks, and web frameworks, and experimental languages and VMs based on Java. It's this stability that gives corporations a chance to plan meaningfully for the future. It's an approach that has engendered a huge "after-market" of companies and tools and open source products, and allowed them to flourish.

I'm sure people out there will nickel and dime the above observations to death. They'll point out some feature that broke for them on some JVM upgrade. Cite some JVM bug which caused a core dump for them. Ridicule some feature added at some point as over kill, or argue that the rate of change is too slow for their needs. They'll still bitch about JCP and J2EE. But these people are missing the big picture - shit happens, bugs occur, companies make missteps, individuals make bad judgement calls. In the small, mistakes have been made. But in the big picture viewpoint, the view from 10,000 feet, Sun has done a remarkable job at shepherding Java along. Cameron Purdy has a saying he's repeated a few times, and repeated recently, that has some bearing here: getting old sucks, but it's better than all the alternatives. Likewise - you can say Java sucks, but taken as a whole it's better than the alternatives. You can eviscerate Sun for its mistakes - but they've made fewer mistakes in this realm then anyone else I can think of.

The next time you get your dander up and want to curse Sun out for how its managed Java over the years, stop and think for a moment. Think of any other company and how Java would have turned out if they had been managing Java all these years. In my mind, if any one else had created Java, there wouldn't be a Java today - their'd just be some niche language that quickly peaked and was already fading away. If you want to curse Sun's treatment of JBoss, consider that JBoss would not exist w/out Sun's largess and contributions to the industry. If you curse the JCP, look at how other standardization attempts are working out in the real world. If you lust after some feature, just look at those poor C++ and perl programmers out there who are almost literally drowning in features.

Sexy and flashy and cutting-edge and provactive are "in", and likely they always will be. But it's rock-solid stability that makes the real, long-lasting successes in this world.

December 06, 2003 12:47 PM EST Permalink Politics Java fans fight back By Simson Garfinkel

Just because Java has created an industry, just because some people are being paid more than $250,000 a year for writing Java programs, that doesn't mean that Java is a good thing.
Java fans fight back

OK, Sun's programming language does have some good points, but it's still a long way from perfect.

My article last week on Java touched a nerve with readers. After reading the column, more than 100 people clicked the "mailto" link on my byline and let me know precisely how they felt -- and hundreds more wrote angry letters to the editor. I tried to respond to the first 50 or so e-mails. But when the mail kept pouring in after a week, I asked my editor if I could write a response for all to read.

Reactions to the article were mixed, with roughly 40 percent agreeing with my conclusion and 55 percent calling me names, cursing at me with their keyboards and saying that I don't know beans about programming. The remaining 5 percent were the most curious of all -- they said that I pulled my punches, that I wasn't harsh enough on the Java blight.

It's easy to understand how the article could engender such varied responses. Java is a huge industry. There are tens of thousands of companies using Java and hundreds providing tools for the language. And since there is so much disparity between the programmers that are bad at Java and those who are good at it, an attack on Java as a whole can be very threatening to those at the top of the profession. Or as one programmer with a Hotmail account told me, "Here's this for a kicker: I make more than YOU and I'm cutting code in Java! :) Suck on my $200,000/yr as a Java Developer, dumb ass."

Considering the more literate responses, the biggest criticism was that my analysis of Java was dated. "Your article is clear, concise, accurate and two years out of date," wrote Richard Katz from Mpath Interactive. Like several other readers, Katz told me that the mainstream Java world has given up on Java-based applications -- the real action is with Java application servers.

"You also ignore that the biggest growth market for Java isn't embedded devices and the J2ME," wrote Stu Charlton, a senior consultant at Infusion Development Corp. "It's the enterprise, and the J2EE. (Enterprise consulting is, in fact, my profession.) The number of financial systems that push billions of dollars in transactions through Java is astounding, based on my experience of working at investment banks in Canada, the U.S. and Japan over the last three years."

Others wrote that Java had made their lives easier by allowing them to develop Java plug-ins for Web servers on low-cost Windows NT systems, and then move the same code to $250,000 Sun Solaris servers.

In my defense, I chose to focus on desktop applications and applets because that is where most readers will encounter Java. Sun promised that Java would be the language of choice for developing desktop applications, and Sun has never repudiated this claim. It's also instructive to look at the desktop Java experience because that is where we have the most data, and that is where it is easiest to draw conclusions.

The fact is, it's somewhat easier to understand Java's contribution -- and its costs -- when you consider server-based systems. On these systems, Java's automatic memory management makes it a lot easier to write a reliable application server. And the plug-in nature of the Java class files makes it easier to write with systems like BEA WebLogic. But this ease comes at a price. I've heard of many Java installations where the server steadily uses up more memory as the day goes on, and as a result the servers need to be rebooted every night. There are other ways that performance can suffer. Some readers wrote to me that they have Java running just as fast as C; others wrote that they saw 10-fold increases in server performance when they swapped out an application written in Java for one written in C.

Jan 18, 2001 | Readers also took me to task for my criticisms of Java portability. In the world of servers, you really can take a Java class file that was developed on a Windows NT server and move it to a Solaris box. "We develop on NT boxes or Unix boxes, and deploy on both," wrote Geraint Preston from Lehman Brothers. "We've never had any problem with platform-independence, which means we can move our applications, with no recompilation, from $30,000 NT application servers to $2 million Sun E10000 servers, as and when we need."

But think about the logic behind this argument for a moment. This argument says that it is more cost-efficient for an organization to spend $2 million on an application server and use Java than to spend $1 million on a lower-priced server and use C++ instead. It's true, many organizations find it easier to throw hardware at a problem than to go out and hire another programmer. But it's also easy to understand why Sun has worked so hard at instilling this attitude in the marketplace: Sun makes money selling big iron.

Indeed, take a closer look at the Java application server market, and you'll see that there's a contradiction of sorts. At first it seems that BEA Systems' Tuxedo 6.x allows you to run Java plug-ins on a huge number of platforms: The company's chart of supported operating systems includes Apple's MacOS, Data General's DG/UX, IBM's AIX, and of course Microsoft Windows and Linux. But look deeper. Although the client runs on many of these servers, the server runs on considerably fewer. Java's famed portability is there for some developers, but not for others.

Many readers took me to task for saying that Java is always interpreted -- there are many just-in-time (JIT) compilers out there now. But even ignoring the fact that the bytecode still needs to be compiled every single time that it is run, and ignoring the problem that there are fundamental difficulties in getting a JIT to compile as efficiently as a traditional compiler, there are still major problems with the Java language definition that condemn it to running slower than C++ forever.

Leo Kuznetsov of Alameda, Calif., sent me an interesting example of the inherent inefficiencies of Java. Consider the case, he wrote, of appending the letters "abc" to the end of a string. In C++ concatenation is pretty simple -- a buffer gets reallocated and three characters get appended to the end of the string. But in Java, three StringBuffer objects and one new String object need to be created.

David Griffiths wrote to me, "Speed is not always the issue. Time to market frequently has a bigger payoff." This is absolutely true, and it explains the popularity of Perl, for those who want platform independence, and Microsoft's ASP and VB Script, for those who don't care about portability.

In that vein, several readers accused me of carrying water for Microsoft -- one even insulted me by asking how much money Microsoft had paid me to place the article. These comments all demonstrate that one of the significant forces behind Java is anti-Microsoft obsession. These people hate Microsoft, and Java is the best weapon against Microsoft, so Java must be good, right? It's a twisted logic, especially when you consider that Microsoft's Java implementations have traditionally been better than Sun's.

The fact is, I do plenty of cross-platform development with C++ and Qt, an application framework that's quite efficient and easy to use. I use Qt because I don't want the code I write to be trapped on Windows or on Unix. Likewise, I use C++ because I don't want my code being trapped in a slow, inefficient and difficult-to-read language.

"Sir, you have hit the nail on the head with your article regarding Java performance in Salon," wrote Brad Clawsie. "Unfortunately, the Java backers are legion. I suspect that you will get an unbearable number of flames. Java supporters are in the denial stage and they are getting a bit prickly with high-profile criticism of the language."

It's sad, but true. Just because Java has created an industry, just because some people are being paid more than $250,000 a year for writing Java programs, that doesn't mean that Java is a good thing. Politics Java Slow, ugly and irrelevant By Simson Garfinkel

Old but good

The programming language once hailed as a revolutionary breakthrough is no substitute for simply training good programmers.

I hate Java. As a programmer, I hate Java, the language, for what it has done to the field of programming. As a journalist, I hate the relentless hyping of Java by its supporters, as well as their unending excuses as to why Java has failed to deliver. And as a technologist who has been involved with three major projects that have used Java, I hate the complications that Java has caused.

I will concede that it is possible to use Java to create small applications that are downloaded over the Web and run within Web browsers. Over the past month, I've actually run into two such Java-based applications that worked pretty well. The first was a Java-based mortgage calculator that dramatically shows the financial advantage to pre-paying your home mortgage -- paying just $50 extra on a $733 monthly mortgage payment can save you $40,196 over the course of an 8 percent, 30-year loan. I was also particularly impressed by the Yahoo Finance Java-based portfolio manager, which lets you rapidly compare a large set of stocks using dozens of different variables.

But such examples are exceptions rather than the rule. The vast majority of the high-profile attempts to use Java to create major desktop applications have failed. The reasons are straightforward. Java hype is built on the promulgation of two Big Lies. No. 1: Java is as fast, or faster, than other programming languages. And No. 2: Java is "portable" -- it is "write-once, run-everywhere" -- in other words, a Java program can be written once and then run on any kind of computer or operating system. But five years after Java's introduction, it is still slow and cumbersome, and not only has the "write-once, run-everywhere" promise not been delivered on, it's also turned out to not even be necessary.

Java is far from even being the first attempt at portability. Let's not forget that the original motivation behind the C* language, way back in the early 1970s, was to create a portable computer language. The theory was that a programmer would be able to take a program written in C and be able to run it on different computers simply by recompiling* the source code. And to this end, C has been tremendously successful. I have many programs that can compile and run on Windows, on Intel-based Unix workstations, and even on Sun Ultra-SPARC servers. One of the advantages of Java over C was supposed to be that programs would be able to migrate from computer to computer without having to be recompiled. But while the portability works most of the time, Java is not, and never will be, a replacement for C or its successor C++.

The creators of Java tried to make a better C++. But they ended up with a language that is ugly, hard to read and that requires an inordinate amount of typing because of a variety of pedagogical restrictions imposed by Java's creators. They ended up with a slow mess.

Jan 8, 2001 | Look behind Java's first Big Lie, and it's clear that a well-written program in Java could never run as fast as a well-written program in C or C++. That's because the Java bytecode is interpreted, not compiled. Programs written in C are compiled into binaries which can be executed by a specific computer processor. Programs written in Java require one more step -- they must be interpreted by the Java "virtual machine" before running on a particular computer architecture. As a result, a computer running a Java program has to execute more machine-language instructions to do the same amount of work than a computer running an equivalent program written in C.

Remember back in October 1996 when Corel announced that it was creating Corel Office for Java? Corel promised us a complete rewrite of WordPerfect and other office applications, which would have supposedly allowed these new Java-based applications to run on any Java-compliant machine.

Office for Java was a failure. While the product is still in the Sun Java Solutions catalog and you can download the beta from a few archive sites on the Internet, the project was abandoned in August 1997. Download it for yourself and you'll find out why: It's buggy and sluggish. On my 700 MHz Pentium III, Office for Java brought memories of my old Macintosh Duo's ill-fated attempts to run the heavily bloated Microsoft Word 6. The program's speed, alas, was dreadful.

Netscape had similar problems when it attempted to rewrite large parts of Netscape Navigator into Java. Indeed, the damning article What Netscape Learned from Cross-Platform Software Development," explains how Netscape's engineers were sold on the language and started writing large chunks of Navigator into Java. Netscape was committed to delivering Navigator on nearly a dozen different platforms, so Java seemed like the perfect solution. But Netscape's engineers couldn't make the language perform as Sun had advertised: Java was simply too slow. Netscape's engineers tried writing their own Java implementation, thinking that they could build a version that was faster than Sun's, but even that didn't work. "By mid-1998, Netscape was not only deemphasizing Java, it was even planning to replace existing implementations with C and C++." In other words, Netscape was taking the new code that had been written in Java and was rewriting it in C and C++.

Not the best advertisement for a state-of-the-art programming language, one might argue. Still, Java's supporters insist that many programs written in Java can be made to run as fast as programs in C. David Pollak, a San Francisco programmer who wrote an entire spreadsheet in Java and now does technology turn-arounds for companies that have Java disasters on their hands, is a huge fan of running Java applets inside Web servers: the performance difference between well-written Java and native C code is negligible, says Pollak. What really slows down Java programs, says Pollak, is when the Java applications try to display user interfaces on the screen of a computer. One way that Pollak has found to speed up Java programs is to rewrite their user interfaces in Microsoft's Visual Basic.

Pollak is a realist. But Sun Microsystems, which originally created Java, goes further, claiming on numerous occasions ( here and here, for example) that Sun's HotSpot technology would allow programs written in Java to actually run faster than programs in C++.

It's true that some programs written in Java do seem to run nearly as fast as similar programs written in C. It's also true that this experience isn't universal. So what gives?

A 1999 study of programming efficiency goes a long way toward explaining the conflicting experiences with Java's performance. For the study, Lutz Prechelt, a senior research associate at the school of Informatics at the University of Karlsruhe, Germany, had 38 graduate students write 40 different versions of a simple text manipulation program. The programmers, who had an average experience of eight years, created 24 versions in Java, 11 in C++, and five in C. The results, published in Communications of the ACM, were revealing. The majority of programs written in C or C++ could complete the given task in between one and five minutes. Most of the Java programs, on the other hand, required between two and 30 minutes, with some taking more than an hour. In other words, the fastest Java programs, written by the most experienced Java programmers, could significantly outperform the poorly-written C programs. But the typical Java program was much slower than the typical C program.

The upshot: It's better to train programmers to write efficient code than to depend on new programming languages to do it for them.

"The bottom line is that if you are a skilled-enough programmer and a dedicated-enough person to wade through the docs and learn to use Java effectively, you are going to be just as effective in any of the other computer languages that people have been using in the last 30 years," says Philip Greenspun, who teaches software engineering for Web applications at MIT. "If you weren't good enough to program in C or LISP or PL/1 or Pascal, then you aren't good enough to program in Java."

Java's second Big Lie was "write-once, run-everywhere." As long as every Java implementation was certified, Sun told us, they would all run the same Java bytecode equally well. But as programmers became experienced with the language, they soon realized that Java was really "write-once, test-everywhere." Every Java implementation is a little different, and sometimes those differences matter.

Write-once, run-everywhere isn't even that useful an attribute for a programming language today. Sure, it would have been a godsend in the 1980s or the early 1990s, when a dozen different companies sold different microprocessors and different versions of Unix and other operating systems. But by 1995, when Java was introduced, the business world had pretty much settled down to use Intel-powered PCs running Windows on the desktop. The truth is that most businesses didn't need Java's promise of "write-once, run-everywhere." The only people who needed it were companies like Sun and Apple: If these companies could just convince Windows programmers to code in Java, then their resulting programs would run equally well (or poorly) on Windows, Sun's Solaris and Apple's MacOS.

Java does have one good idea: automatic memory management, also called "garbage collection," which actually eliminates one of the most common causes of program crashes in the world of C and C++. Of course, SmallTalk had garbage collection in 1970, and LISP had it in the 1960s --- or was it the 1950s? But at least garbage collection is part of the language. (As an interesting side note, it's fairly trivial to add garbage collection to C and C++ as well, but for some reason the practice is not popular.)

I must also admit that, despite my animosity, it looks like Java will have a bright future. But that future probably won't be on desktop computers at all. Rather, it will be on smart cards, handheld devices and embedded computers, using the Java 2 Platform, Micro Edition. The Micro Edition actually comes with several slightly different -- and mutually incompatible -- versions of the Java language, but all of these Javas have essentially the same syntax and use essentially the same compilers. And since there are hundreds of thousands, if not millions, of people who have painstakingly learned Java over the past five years, companies adopting this so-called J2ME technology will have thousands of developers capable of writing programs for their products.

I've long argued that companies like Sony and Sharp should create developer kits for their microprocessor-containing consumer devices. With the J2ME platform, they don't have to create the developer kit: Sun has already done the work. Security professionals have warned that this will open the door wide for hostile code and malicious programmers, but who cares? It will be cool for people to be able to download programs to run on their cell phones.

But what will be the ultimate legacy of Java? The anti-Microsoft crowd said that Java would allow Sun to finally make inroads against Microsoft's dominance of the desktop. But in the final analysis, Java was nothing more than a ploy to capture the public's interest and, in so doing, boost Sun's stock price. And it worked marvelously. Java's introduction in 1995 marked the beginning of what was essentially a five-year climb in the price of Sun's stock: $1,000 invested in Sun on July 1995 would have been worth $18,535 at the close of trading on December 30th, 2000. Now that's the power of Java.


Recommended Links

Google matched content

Softpanorama Recommended

Top articles


InfoQ Dynamically Typed Languages for the JVM

Gilad Bracha is a Distinguished Engineer at Cadence Design Systems. At the time of this recording, he was a Computational Theologist and Distinguished Engineer at Sun Microsystems. He is co-author of the Java Language Specification, and a researcher in the area of object-oriented programming languages.

The Java Community Process(SM) Program - JSRs Java Specification Requests - detail JSR# 241

Book excerpt Your way to Groovy - Java World

scripting Project Home Page

List of Java scripting languages - Wikipedia, the free encyclopedia

List of Java scripting languages Information from

Scripting for the Java Platform By John O'Conner, July 2006

Java Scripting: Half the Size, Half the Time - O'Reilly ONJava Blog

F3 Sun's new declarative Java scripting language

I found this via Ajaxian at

They didn't have a link back to the original blog, but the images were being pulled from Chris Oliver's site. Seemed a little odd, so I linked to the original blog.

Java problems

Top dozen Pro Java sites

See also Java/java_lab.shtml




Sleep - Java Scripting Language Perl-style scripting language for Java

Sleep is an embeddable scripting solution for Java applications. Sleep is heavily inspired by Perl with bits of Objective-C thrown in. The Sleep Java API allows the language to be extended with new constructs, operators, functions, and variable containers.

Sleep source and binaries are released under the GNU Lesser General Public License


Sleep came from an inspired weekend of coding in April 2002. Since then Sleep has been developed in parallel with the Java IRC Client, jIRCii. Nearly three years later Sleep is a stable and ready to use solution for scripting Java applications.


Sleep - Java Scripting Language This document covers the fundamentals of the sleep language in an application neutral way. The format of this documentation is a mix between a tutorial and a reference. You should be able to read straight through this documentation to gain an initial understanding of sleep and later use it as a reference.

Pipes for NetRexx and Java

Pipes for NetRexx and Java implements VM pipes a piping methodology developed by John P. Hartmann

see also:


Jawk - Java-like, Awk-like Reporting Language

Jawk is a combination of Awk and Java such that Awk scripts can be written to utilize Java services.

Even though it has been extensively testing under practical circumstances (i.e., it is used to maintain this web site), it is not yet in beta because formal unit and system testing has not been done.

Documentation is also limited. However, more will be added shortly. In the mean time, please review the Overview section.


[Jul 31, 2006] A. Sundararajan's Weblog

JSR-223 script engine for AWK

Just added JSR-223 script engine for AWK. This is based on Jawk implementation. If you are interested, you can checkout the sources from! Jawk has nice Java support - like calling Java constructors, methods etc.

Security Model Problems



Coding Style

Literate programming movement

It's interesting to note than like famous Moliere's character Bruce Eckel practiced kind of literary programming in writing TIJ without knowing how it is called :-).

Java under the microscope

Java Hype

Java and other languages

General language design issues






Comparing Python to Other Languages

Python vs. Object REXX?








Visual Age for Java (free download available from the IBM site)

VADD - Programming with VisualAge for Java Version 2 (SG24-5264-00)


Internationalization and XML

Text Boundary Analysis in Java

Bluestone moves to marry Java and XML - JavaWorld - February 1999

Educational Issues

Academic Institutions Teaching Java -- out-of-date list maintained by Sun

Some Questions and Answers about using Java in Computer Science Curricula

How widely is Java taught in 1st year Computer Science Should Java be taught in first year Computer Science? A very interesting site for teachers. It contains several links to other sites of similar value. Java Campus. Hotbed of Java resources for both teachers and students.

Java in the Computing Curriculum Conference (JICC3). South Bank University: London on Monday the 25th January 1999. Java -- An Object First Approach

Protest letter about changing AP CS to C++


Lynn Andrea Stein course



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: April 23, 2019