James Bayer's Blog

This was originally posted on my dev2dev blog February 4th, 2008.

Have you noticed that there is a growing buzz about alternative programming languages in the blogosphere and online technical journals?  Is this simply just US-Weekly for technology selling the latest Brangelina gossip that will be forgotten next week or is there really a coming revolution to get out in front of or even catch up with?

The Old Standbys

PHP and Perl have been popular Internet languages for some time and there is a history of using these languages in conjunction with the WebLogic Server (See WLS information about PHP, ColdFusion, and CGI).   Even JavaScript  / ECMAScript is getting integrated into the JVM in Java 6.

The New Popular Kids

Lately a newer set of languages have been getting all the attention in both the Java world and the .NET world.  Of course you've heard about Ruby and Ruby on Rails unless you've been under a rock.  Java has responded with it's own scripting language, Groovy and rails like framework called Grails.  Presumably Groovy and Grails would be more applicable to enterprise developers because of Java roots and higher likelihood of being accessible to Java developers to learn quickly.  Secondly, because Groovy is interoperable with existing java code, it can run on your corporate application server standard, which is of the utmost importance for enterprise adoption.  There is also JRuby; so you can mix Java and Ruby and not have to give up WLS container provided services and all of those plentiful java API's you have lying around from existing applications, frameworks, and packaged applications.  Not to be left-out, functional programming fans have also have a reason to get excited with Scala and F#, which combine elements of OO languages with functional principles.  Even ERLang is getting some hype. 

Why all the buzz and what to do about it?

The rationale to use these alternate languages seems to vary, but the most substantive reasons seem to center around brevity, clarity (see the Fibonacci examples), and that they are better for taking advantage of concurrent programming on the growing number of multi-core architectures.  So as an enterprise Java developer and WebLogic Server user how are you to know which of these technologies is the most relevant?  In my humble opinion, it's too early to declare definitive winners.  I don't think that brevity alone can be responsible for a seismic shift.  I am personally more swayed by the multi-core / concurrent programming arguments, but I don't feel the urgency immediately.  I think these are technologies to monitor and dip your toe in, but not necessarily to dive all the way in unless you have an edge case that is in the sweet spot in one of the languages.

I am definitely bullish on the value of the application server and the rock-solid foundation provided by WebLogic Server.  I feel that the new languages that will have the best synergy with existing Java assets will have the highest likelihood of success.  I've spent a limited amount of time playing with Scala this weekend and deployed an example in WLS.  Look for my write-up on this in an upcoming entry if you want to hear about my experiences.  If you have an opinion on future programming language adoption in the enterprise, please leave a comment.

This was originally posted on my dev2dev blog February 6th, 2008.

At the end of my previous post about the hype/buzz for alternative programming languages I promised an entry on my experimenting with Scala in WebLogic.  I have only spent a few hours of weekend time playing around, so I can't say much yet, but I'll document some of my first impressions and experiences in this post.  This is not meant to be a post on learning Scala,  For that I recommend an excellent podcast from Bill Venners that goes into great detail about Scala and why you might use it.  I highly recommend it, it is well-worth the listen.  If you prefer reading, then start with The busy Java developer's guide to Scala: Functional programming for the object oriented.  This is a post that documents my experience of using Scala with tooling and an application server familiar to java developers, namely Eclipse and WebLogic Server.

Prequisites

1. Download Eclipse 3.3 / WTP 2.0.1.  I used wtp-all-in-one-sdk-R-2.0.1.  Workshop 10.0/10.1 are still based on Eclipse 3.2, so they won't work with the Scala Plugin for Eclipse, which requires 3.3.
2. In order to easily deploy code to WLS, use Eclipse Update to install WebLogic Server Tools, I used version 1.1.2 from update site https://dev2devclub.bea.com/updates/wls-tools/europa/
3. Use Eclipse Update to install the Scala Plugin for Eclipse.  I used version 2.6.5 from update site http://www.scala-lang.org/downloads/scala-plugin/

Obligatory HelloWorld

After restarting Eclipse because of the new plug-ins, I didn't have to set any paths to configure the Scala Plugin as the set of 5 scala plugins installed include the Scala SDK.  Simply follow the instructions at the bottom of the Scala Plugin for Eclipse page to create your first HelloWorld application to make sure that everything is wired up correctly.  I did not encounter a single snag with HelloWorld at all and my console printed "HelloWorld" in no time flat.

Interoperability with Java

The scalac compiler takes .scala files and builds .class files that have a dependency on the scala-library.jar.  Go check out the bin directory in the Resource perspective and see for yourself.  Therefore, the only thing you need to invoke and run them from java is to have the .class files and the scala-library.jar on your classpath.  The converse is also true; Scala objects can just as easily invoke java objects by including them on the scala classpath.

Now this is where the developer experience is not quite ideal with respect to the packaging scala artifacts to be used easily in Dynamic Web Projects for iterative development with WebLogic Server.  First of all, I could not find a non-custom way of exporting the Scala .class files into a jar file.  In order to package up my Scala Project into a jar with the IDE I had to:

Right click on the project -> Export... -> General -> Archive File -> and select appropriate values as shown in multiple places.

Is this really that big of a deal?  Well, it depends on how you use your IDE to develop.  In the normal process of doing Java web development in the IDE, I find it convenient to have a project with Java code, say a Utility project, which is automatically included in your Dynamic Web Project's classpath and packaged up in the EAR as a jar when I do an export or a deployment.  It doesn't appear that such a nice arrangement is possible using the default tooling.  Of course you can always create a custom ant builder yourself and attach this to your project's build activity, but there is some work involved.  Certainly this will be addressed as the Scala Plugin for Eclipse matures.

Trying out some various alternatives, I was able to modify the .project xml file for the Scala project and add a Java nature and a java builder so that both .java source and .scala source were compiled into the same bin directory.  This seemed a little fragile and the build order had to be just right in order for both sets of .class files to be in the bin directory after the build.  I suspect that when the build order was reversed that the bin directory was being cleaned by one of the builders.  Here is the .project file if you feel like taking this approach.

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
    <name>ScalaExamples</name>
    <comment></comment>
    <projects>
    </projects>
    <buildSpec>
        <buildCommand>
            <name>org.eclipse.jdt.core.javabuilder</name>
            <arguments>
            </arguments>
        </buildCommand>
        <buildCommand>
            <name>ch.epfl.lamp.sdt.core.scalabuilder</name>
            <arguments>
            </arguments>
        </buildCommand>
    </buildSpec>
    <natures>
        <nature>ch.epfl.lamp.sdt.core.scalanature</nature>
        <nature>org.eclipse.jdt.core.javanature</nature>
    </natures>
</projectDescription>

Mix Scala with a Dynamic Web Application

After deciding not to spend more time on the packaging issues I moved on to another basic concept, simply calling a Scala object from a JSP.  In this case there is a suitable example addressbook.scala on the Scala site that spits out an addressbook in Xhtml.  This example also showcases one of the Scala languages handy features of native XML support.  Check out the source.  In order to invoke this quickly from a JSP, I moved it to a package called examples and created a new function named toXhtml to the AddressBook class to return the Xhtml string since the example was meant to be called from a main method and needed the function to be callable from the JSP.

def toXhtml(): String = page.toString

Here is the index.jsp

<%@page import="examples.addressbook"%>
<%= addressbook.toXhtml() %>

The steps are:

1. Package the addressbook classes in a jar and place into WEB-INF/lib
2. Copy the scala-library.jar into WEB-INF/lib (get this from the Scala SDK or from your plugin, mine is here: D:\eclipse3.3\eclipse\plugins\ch.epfl.lamp.sdt.compiler_2.6.9.RC412860\lib)
3. Create the JSP
4. Deploy to a server and invoke the jsp

Here is the end result:

Summary

There is nothing really WebLogic Server specific to this, I could have just as easily deployed this to Tomcat., or WebLogic Event Server.  The point is that Scala actually is fairly easy to integrate into both tools and runtimes that most java developers will already be familiar with.  If you have thoughts on Scala, better integration with java IDE's, etc, drop a comment.