Scripting Languages for Java vs. Pure Java

Exception Handling

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

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

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

begin

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

end

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

The initial version of OpenGrok was a perl script named rob.pl that extracted the above 5 streams and piped them to a lucene search engine. rob.pl 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 OpenSolaris.org

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

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

Downloads

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

Requirements

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

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

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

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

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

On this latter point, Peter writes:

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

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

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

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

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

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

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

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

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

---

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

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

---

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

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

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

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

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

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

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

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

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

JavaOne 2007 Prodigal Sun returns to the client by Elliotte Harold

Many language proposals

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

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

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

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

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

JavaOne 2007 Prodigal Sun returns to the client by Elliotte Harold

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

Redesign the Installer

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

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

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

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

Warm up cold starts

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

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

Shrink the JRE

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

From JARs to JAM

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

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

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

Summary

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Groovy is often referred to as a scripting language-and it works very well for scripting. It's a mistake to 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 (javajeff.blogspot.com)

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 http://www.aboutgrooy.com/, 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 (javajmc.blogspot.com) 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.

Anyway..it 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:
obj1#getObj2()#getSomething()

Comments:

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

• 2004 Quotes
• 2003 Quotes
• 2002 Quotes
• 2001 Quotes
• 2000 Quotes
• 1999 Quotes
• 1998 Quotes

[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 internetnews.com.

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

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 (Computerworld.com.au) 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 lunch...so 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] freshmeat.net 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:

• Overall performance is 50-60% faster than JRuby 0.9.0
• New interpreter design
• Refactoring of Method dispatch, code evaluation, and block dispatch code
• Parser performance enhancement
• Rewriting of Enumerable and StringScanner in Java
• New syntax for including Java classes into Ruby

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 scripting.dev.java.net 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.

Scripting
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
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
Jython seems to feature active support, maintenance, and updates. Jython consists of about 55,000 lines of Java code.

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

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

Licensing
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 (www.artima.com)

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 stack...so we maintain our own. We do not have a dynamic invocation bytecode in the JVM...so we use our own method. We don't have support for closures...so 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

[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] netbeans.org -- 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...

• Comprehensive support for building IDE plug-in modules and rich client applications on the NetBeans platform
• Simplified and intuitive GUI building using Project Matisse
• Support for Sun Application Server 8.2, Weblogic9 and JBoss 4
• Web services support for Java Enterprise Edition applications
• Enhanced support for JavaServer Faces and Struts
• An expanded number of available refactoring actions
• Various editor enhancements including an error stripe and Java hints
• Faster code completion
• Completely reworked and improved CVS support
• Enhanced debugging which is integrated in the Source Editor
• Streamlined, user-friendly IDE configuration
• The ability to discuss and edit code with other developers with the NetBeans Developer Collaboration feature
• Full-featured profiling functionality
• The award winning NetBeans Mobility Pack which can be used to write, test, and debug applications for the Java Micro Edition platform

• Feature Highlights The NetBeans 5.5 Beta release contains many features that maximize your productivity and flexibility with building robust, standards-compliant Java™ applications:

  • General Java Enterprise Edition™ 5 platform support:
    • Deploys to the Sun Java System Application Server PE 9 (Glassfish).
    • Provides code completion and Javadoc for Java EE 5 APIs and deployment descriptors.
    • Web tier technologies updated for Java EE 5 platform: Servlet 2.5, JavaServer™ Pages 2.1, JavaServer™ Faces 1.2
  • Java Persistence support:
    • Generates Java entity classes from existing DB schemas.
    • Creates entity classes in the IDE and lets the server generate the DB relying on the DB-from-Java feature in Glassfish
    • The persistence runtime can be used in web apps and plain Java apps without the need of a full-blown Java EE application server.
    • Wizards for creating complete web application for manipulating data in the database using Java Persistence.
    • Enhanced Java source editor for code completion and hints.
    • High level user actions that generate common code patterns (e.g. using an Entity Manager).
  • Java API for XML Web Services (JAX-WS) Support (aka Web Service 2.0)
    • Generates JAX-WS 2.0 artifacts for SE 6 and EE 5 projects
    • Configuration is done through bindings customization (like asynchronous calls, package info)
    • Simplified and updated template wizards.
    • High-level user actions that generate common code patterns (e.g. calling a web service).
  • Support for Enterprise Java Beans 3 session beans
    • Simplified development of session beans and message driven beans.
    • Enhanced Java source editor with code completion, error checking, and hints specifically targeting EJB 3.
  • Other improvements:
    • Code completion for the JavaServer™ Pages Expression Language.
    • Support for Java EE Application Clients.
    • Support for configuring security in Java EE applications.
    • Support for running SQL scripts directly from the IDE

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

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

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:

• Threads: Tomcat can be configured to create however many threads you want. A few dozen to a few hundred is typical. It certainly does NOT create a new thread per request. Just like Apache 2 in threaded mode (which is not its default mode btw) it creates these threads and has them hanging around until they are needed. Just like Apache 2 in threaded mode, these are plain old operating system threads
• Threads again: Your reference to threads, and developers not knowing that Java is threaded, and again this 256mb per user makes me think that you are assuming that every user needs a separate JVM. This is not the case on any server-based app that is correctly written. Yes I can imagine some bozo creating a web app where Apache forks off a ne JVM for each user session... but wow, that is an inconceivably bad way to design a web app, ie, using a JVM for doing CGI. That's fighting hard against the design and the right way to do it, so of course it won't work. You do not Java for doing CGI servers! One web application = one JVM per machine = one JVM overhead per machine. If you are looking at any deployment where that is NOT the case, it was done by someone who is incompetent.
• Memory: Sessions are created with a simple session map. A session itself takes up about 1k of memory. If you're smart, you store a user ID in the session and then the servlets can use that to interact with the database. So you're still storing less than 2k per user in memory in the session. It's no different from how PHP is often used. If you're really clever you use Hibernate and store a lightweight user object in the session, and have Hibernate do all its magic caching and proxying. You still have only a few K per user session to store.
• CPU: Any real-world benchmarks Java just isn't slower. I would expect that a Java web app would use less CPU than a PHP app, because PHP has to parse and compile some large subset of the application with every single request. In Java, the whole thing is compiled to bytecode, which has probably been compiled to native assembly, and it's all loaded in the thread, in memory, ready to go when a request hits it.
• Garbage collection: This is a problem that Java has. The GC does have to use a global lock and stop every thread (I believe) at certain times to do GC. In practice, this isn't so bad on web server apps. It's worse on desktop apps, which do in fact freeze up for a few seconds at a time occasionally.

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 [contempo.biz]

Re:Um, what?

(Score:1)

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

(Score:2)

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

(Score:1)

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

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 ?

(Score:2)

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

Useful websites like weather.com, ebay.com, or wallmart.com? They all run on java.

Re:Not compatible with itself

(Score:2)

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.

...Structure101^TM, 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.

ONJava.com -- 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:

• Shell scripting using Groovy allows the full power of the Java Platform to be brought to bear to the task at hand.
• Groovy can be used (and indeed is already being used) as a replacement for Java for small and medium sized applications to execute on the Java 2 Platform.
• Groovy can be used as an embedded language for dynamic business rules or extension points utilizing the agility of Groovy and saving the cost of redeploying applications for each change of rule (especially when the rules are stored in a database).
• Groovy makes writing test cases for unit tests very easy.

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 mozilla.org 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:

• automatic memory management through garbage collection,
• a standard string data type,
• collection interfaces implementing most useful data structures, and

• a very rich language library.

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

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

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

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

Continued

Recommended Links

Softpanorama Recommended

Top articles

Sites

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

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

F3 Sun's new declarative Java scripting language

I found this via Ajaxian at http://ajaxian.com/archives/f3-suns-new-declarative-java-scripting-language

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

• Chapter 27 -- Alternatives to Java
• Useful and interesting links for new Java programmers
• Java is taking us in the wrong direction
• Why Some People Hate Java
• Java-AWT: Is it really cross-platform? (Not really, at least for 1.0.2.)
• The Unofficial Java Bug Report
• The Java Hall of Shame: in which Java violates the "Principle of Least Astonishment."
• AWT: Java's Achilles Heel (and the sequel.)

• Der Java Hype in german

• Java Hate Page

• Java Quotes in 1999 by Elliotte Rusty Harold

• Lecture 1A Shortcomings

• Slashdot Internet C++ Competition For Java And C Sharp

• So I'm a "clueless academic", am I? (Score:1) by Kevin S. Van Horn on Friday October 20, @11:12AM EST (#314) (User #29825 Info)

  There's a good possibility that I'm the instructor being referred to. Before you call me a clueless academic, let me give you some of my creds: - I've been programming for twenty years. - Almost all of my work experience (including all of the last five years) has been in industry, doing hands-on programming. - I built the NewsTracker service for Excite. - I wrote about half of the microcode for the MasPar MP-1 series of massively-parallel computers. - I'm willing to use my real name when posting my opinions, and not hide behind a pseudonym :-). In my opinion, Java may be fine for applets, but it is utterly unsuitable for large software projects. I'm going to write up a comprehensive critique of Java sometime within the next few months, but for the moment, let me toss off a few problems that immediately come to mind: No real analog to const. The "final" keyword only prevents assignment. It does not prevent modification of the object referenced. I consider "const" correctness an important part of good program design, as it helps you catch many errors at compile time, and also acts as documentation for your code. In a similar vein, no notion of a "const" method. In fact, you can have a "final" method, but its meaning bears absolutely no relation to the use of "final" when applied to variables. No reliable destructors, so you cannot use the "resource acquisition is a constructor and resource release is a destructor" idiom that is so useful in C++. This idiom is useful because it allows you to remove opportunities for error from your program (you can't forget to release a resource). 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. For example, all functions must be class members, all exceptions that may be thrown (except for RuntimeException and Error) have to be declared with a throws clause, etc. There are good arguments against many of these decisions, in at least some circumstances. The designers of C++, on the other hand, were a bit more humble. They left the language amenable to a variety of programming styles. This has allowed people to experiment to find out what really works, rather than being forced to accept some doctrine handed down from on high. The reference semantics combined with "by-value" syntax for objects cause a lot of confusion for beginners. The fact that you *only* have reference semantics for objects causes design problems. For example, there is a real conceptual and design difference between a container of objects and a container of references to objects, but Java mixes the two ideas together. This results in situations where code outside of an associative container class (like a set) can screw up the associative container by modifying the state of objects contained in that container. The lack of templates means that one loses some of the power of typechecking, and one has to resort to some pretty clumsy and awkward means of dealing with container classes. For example, in C++, I can have an associative array mapping keys of type K to values of type V, for any types K and V, through the use of templates. The analog in Java is a container that maps Object to Object. The problem here is that I have to do widening conversions that weaken typing. Strong typing is important because it is an extremely useful tool for catching errors very early -- at compile time instead of at run time, when they are harder to deal with. With Java I can no longer guarantee that all my keys have one type, and all my values have one type. When I retrieve values, I have to do narrowing conversions, which may result in a run-time type error that I should have been able to catch at compile time. And what if I want to put values of a primitive type in a generic container? Then I have to resort to the truly hideous kludge of using these wrapper classes to turn them into objects. The vast gulf in behavior and syntax between primitive types and object types is a nasty misfeature of the language that throws up barriers to writing generic code.

• James Gosling Talks About the Java Platform Here and Now - JavaOne Today

• In retrospect...
  Bret Sommers: One of the tenets of engineering states that if we could do it again, we'd always do a better job the second time around. If you could go back several years and rearchitect Java from scratch, what would you change? What language features would you omit? What would you include?

  James Gosling: One that I've been personally focusing on lately is high-performance numerical computing, because when I first did Java, I wasn't targeting it for people who wanted to write routines that did weather simulations. And yet there are lots of people who are writing stuff like that. There are a variety of things in Java's specification that slow that down a little bit, and some relatively minor tweaks actually make it a whole lot better for people doing high-performance numeric computing.

  If you go to my personal home page on the Java Web site, (http://java.sun.com/people/jag), I've got this really crusty, old copy of the Java Spec -- the last one that I wrote the entirety of. And it's got a collection of things in there that are about some testing -- to be able to do assertions and preconditions and post-conditions. I had been doing some work on that, but because of schedules, I had to rip that out, and I regret doing that today. There was also some stuff on multivalued returns that I felt pretty strongly about.

  One of the issues about the list of things that are left out is that, by and large, I left things out when the answer wasn't clear -- when it wasn't clear what was the correct thing to do. I generally have this philosophical view that it's easier to stick the right thing in when there's a hole, rather than when there's an old broken thing that was just wrong. So I've tended to resist the urge to just put something in. So with the multivalued return thing, there are sort of two styles that people have used. I was dithering on style and doing some little experiments.

  It's the same sort of thing with enumerations. Enumerations are one thing that we get asked about an awful lot. Yet once you probe the technical details of what enumerations are, how they're used, and all of the rest of that, it turns into a real hairball. I've been through that hairball several times and haven't revisited it lately.

• Chris Laffra. JAVA Soft Spots. In: ADT August 1997 - InterIntranet Development

  Many I/S organizations are embracing Java, but they should be aware of the shortcomings of the still immature language

• Making Sense of Java by Hank Shiffman (Silicon Graphics, Inc.)
• Java Hype <-> Java Reality
• Debating Java's rightful place
• Java hype aside C++ still rules
• Java - Myth or Magic by Jan Newmarch. Distributed Information Laboratory. University of Canberra
• T.C.Doyle.Overpromised and underperforming, Java collides with reality. VARBusiness
• Introducing Object-Oriented Programming by James M. Coggins. Department of Computer Science University of North Carolina At Chapel Hill
• Critique of the Object Oriented Paradigm: Beyond Object-Orientation. By Shajan Miah Date: 14th May, 1997 www.westga.edu
• JavaX White Paper: JAVAX AN APPROACHABLE EXAMINATION OF JAVA, JAVABEANS, JAVASCRIPT AND ALL THE RELATED JAVA TECHNOLOGIES Jothy Rosenberg, Chief Technology Officer, NovaSoft Systems, Inc.
• Digital Espresso for Tues May 28 1996 Java's Shortcomings and Inferno
• Internet Special - Java Soft Spots
• Java Bright Promise Uncertain Future by George Grayson Capan

Top dozen Pro Java sites

See also Java/java_lab.shtml

• **** http://developer.netscape.com/docs/manuals/java.html -- a definitive resource for the client side Java

• **** java-resource.com -- an excellent site with on-line support for beginning programmers

• [must] Java Platform Documentation

• **** Inside Java

• **** Cafe Au Lait Cafe Au Lait has many resources for learning to program in Java including a tutorial, examples, exercises, FAQ lists, book reviews, user groups and more.
• Java Technology Home Page -- Sun Java page -- the place to download the latest JDK and other things.
• Java Developer Connection
  • A Look at Text
  • Memory Management
  • Collections
  • Online Training Servlets: Fundamentals of Java Servlets 2D Text: A Tutorial on Styled Text Security: Fundamentals of Java Security
• Javaworld -- free IDG e-zine
• Gamelan -- the official directory for Java
• [August 3, 1999] Java-Linux Java(tm) Tools for Linux -- good
• Javalobby
• Focus on Java
• Cafe Del Sol
• Java Developer's Journal
• Developer's Daily Educational resources for software developers

Etc.

• Roasted Java News

• Netscape DevEdge Online
• Netscape Java Developer Central
• Yahoo! - Computers and Internet Programming Languages Java - This is one of the best starting points for digging information about Java.
• Linux Java Tips and Hints Page
• Java-Linux
• Simplicity for Java Homepage -- free IDE for Linux developers
• Download the JDK for Linux
• Rapuid Systems Solution - Java Resource List -- A list of online information sources about Java.
• The Java Centre -- The Java Centre is the fastest growing UK based Java resource. It includes a comprehensive list of UK Java developers, as well as a showcase of many different applets. In addition there is a section where technical questions can be addressed.
• Java Optimization -- How to optimize your Java programs so that they're smaller, faster, and more maintainable.
• Markus Reith's Java Developer's Page

Tutorials

• See Java Course for more info. See ../Bookshelf/java.shtml
• Yahoo!Java tutotial list
• Getting Started -- Sun Java tutorial -- how to compile and execute HelloWorld program...
• Javasoft Tutorial
• Elliotte Rusty Harold Java notes
• Cafe au Lait Java FAQs News and Resources
• Introduction to Java Programming Week 1
• Java Education - Introduction to Java Online Course
• jCentral
• John Zukowski's resource list
• Marty Hall's list of resources, Markus Reith's Java Developer's Page
• Jonathan Knudsen's columns contain good examples
• Examples from Java in a Nutshell book
• JDC Online Training page
• Magelang's Beans tutorial
• Richard Baldwin's online Java tutorials
• Lyn Andrea Stein's Interactive Programming in Java
• Bert Wachsmuth's Virtual Java and Network Programming, Seton Hall University
• Computer Science 124: Introduction to Programming Using Java
• E.J. Friedman-Hill's Java Course
• Concurrent programming using Java course
• Tutorials: N-ary's; Steven Koch's; Shlurrrpp......Java by Vijay Mukhi, Sonal Kotecha, and Shashank Tripathi; Thingtone's; JavaSoft's;
• Lea's on concurrent programming;
• E. R. Harold's; on threads; on optimization;
• Tientien Li's on inter-applet communication;
• David Eck's Introductory Programming course using Java
• Bill Hibbard's Java course notes
• Gamelan's Learning Java resources
• FAQs: Java FAQ Archives, Peter van der Linden's Java Programmers FAQ Sun's, Digital Focus', D'Arcy Smith's, Java FAQ Archives, Java networking FAQ, JWS FAQ

Sleep

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

History

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.

Features

• Perl/Objective-C inspired language syntax
• Fast execution / small runtime size (~200 KB)
• Parsed scripts can be serialized
• Easy API for making application data structures / functionality available to scripters
• Access, create, and query Java objects from Sleep scripts
• Function Closures as first class types
• Full documentation for application developers and end-user scripters

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

see also:

• The NetRexx Language
• NetRexx.org, Home of the NetRexx Foundation
• REXX - Wikipedia, the free encyclopedia REXX is considered a precursor to Tcl and Python.

JAWK

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.

Notes:

• The following files are available for download in the sourceforge download section:
  • jawk.{release_number}.jar - The executable jar file.
  • jawk_src.{release_number}.jar - Sources to Jawk.
  • jawk_ex.{release_number}.jar - Some example Jawk scripts.
• JRE 1.5 is required to run Jawk. JDK 1.5 is required to build Jawk.
• The software is tested on Windows systems, only, since I do not readily have access to a Linux or Solaris machine running Java 1.5.

[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 https://scripting.dev.java.net! Jawk has nice Java support - like calling Java constructors, methods etc.

Security Model Problems

• Deviant Byte Code A Fundamental Threat to Java Security
• Java Security
• SIP Java Security FAQ
• Java Security Hotlist

Reference

• Java IAQ Infrequently Answered Questions

• Java Platform 1.2 API Specification -- standard and free from Sun

• Java FAQ

• Java 1.1 Class Hierarchy Diagrams

• The Java Language Specification
• Java 1.2 Documentation, Java 1.2 API Specifications: java.io, java.awt, java.awt.geom, java.lang, java.math, java.util, java.text, java.sql, java.security, java.rmi, java.net, java.beans, java.applet, javax.swing, javax.accessibility
• API search
• Roedy Green's Java glossary
• java.sun.com documentation
• O'Reilly Java Reference Library and CDROM version (restricted access)
• Tools: Javadoc home page, javadoc-related tools, Tools Reference Pages
• Products and APIs, including release dates for planned APIs
• 3D API
• Advanced Java Mailing list archives

Magazines

• The Java Report

• Javaworld -- free IDG e-zine

Coding Style

• Java Coding Standards

• Programming in Java Style Guide -- this is short and nononcence guide that should be read and following. the content partially reproducred above

• Gary's bookmarksJavastyle

• Java Style Guide (Nasa)

• Draft Java Coding Standard -- written by Doug Lea and released to the public domain.

• Draft Java Coding Standard - Doug Lee/NASA
• Java Coding Standards - AmbySoft Inc.
• Java Style Guide - U.S. Navy
• Java Style Guidelines
• Mark Fussell's Java Development Standards

• AmbySoft Inc. Java Coding Standards

• The Coding Standards Repository

• AmbySoft Inc. Java Coding Standards

• Kent Sandvik's Java Coding Style Guidelines

• Taligent's Java Cookbook

• Naval Postgraduate School Java Style Guide

• Solo Software Engineering home page

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

• Yahoo!Literate Programming -- do not expect much. The idea is almost forgotten.

• LitProg Philosophy

• FAQ - comp.programming.literate -- old, never updated since 1995

• Literate Programming Library -- very old, a lot links are broken

• Knuth Donald personal WEB page -- some references to CWEB

• Donald Knuth CLB Interview 12/07/93

Etc

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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

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