by Matthieu Riou 12/05/2007
Rational
There's a first step that every single Java project has to go through: setting up a build system. And often before that, choosing a build system. There hasn't been much improvement in the Java world in this area for quite a while; Ant 1.1 was released in July 2000 and Maven was created in 2004.
');
//-->
This lack of innovation could seem strange: for non trivial projects (which most end up being after some time), writing build scripts can take a lot of time. Given that builds usually aren't shipped to users, the time spent on their maintenance can seem like time lost... but a sub-optimal build system will actually make you lose time. So down the road, the best build is the one that saves you the most time when writing, debugging, and maintaining your scripts.
I started working on Raven because I was deeply dissatisfied with the solutions available in the Java world. And from what I've heard from other developers, I'm not the only one.
Now I'm going to say something controversial: both Ant and Maven have their strengths and weaknesses, but these tools are just toys compared to a full scripting environment. Think conditions, loops, exceptions, complex data structures. Most of all, think of all the details that you forgot to think about, all the little quirks and peculiarities that appear on most projects. What is going to be most powerful to solve these problems, a simple XML grammar or a full and powerful scripting language (not to mention Turing complete)? Would you rather write copy source, target or 3 lines of XML? And what fallback do you have when you're not within the boundaries imposed by the tool?
Getting Practical
Raven is based on the Ruby dynamic language and its most prominent build tool, Rake. Don't worry, you don't have to know either to read this article or start using Raven, you can learn little by little, starting simple. Rake itself is a little bit like Ant, it lets you define tasks and the dependencies between them. Only its syntax is much sweeter. For example:task "hello" do
puts "Hello"
end
task "world" => "hello" do
puts "World"
end
If you have Rake installed, put this in a file named Rakefile and execute rake world in a command in the same directory as the file. It will do what you would expect. Note that the syntax could be even more terse by using { ... } blocks on one line instead of do ... end but this demonstrates the most common case, where you'll have more than one line of code in your task body. And you can put pretty much any Ruby code within the task block (and even Java code as we'll be using JRuby), even rely on external libraries, instantiate objects, and call methods. Your build can be as simple or as complex as you need.
The limitation is that Rake only provides very generic tasks that just wrap some classic Ruby code but don't do anything much by themselves. You have to tell them what to do in the nested code. That's where Raven shines. To make the life of Java developers easier, Raven adds a set of predefined tasks that implement the most common needs for a Java build system, like compiling or resolving jar dependencies. Just like a library, but instead of being a set of classes and methods, it's a set of reusable tasks that are well-suited for Java builds. So, all the tasks you're going to see in the rest of this article are implemented by Raven.
But wait, I haven't told you how to install anything. The quickest way to get started is to use Raven packaged with JRuby (a Ruby interpreter written in Java), everything necessary is bundled in it.
Download the Raven distribution prepackaged with JRuby.
Unzip it on your disk and set the environment variable JRUBY_HOME to this location.
Add %JRUBY_HOME%\bin to your PATH environment variable.
Check your installation by typing jruby -v in a command window.
For a more complete installation using the native Ruby interpreter (it's much faster to start up), see the Raven web site.
A Simple Project
To show you how to use Raven, I'm going to start with a simple but still a real world example: building Apache Commons Net. The Apache Commons Net library implements the client side of many network protocols like FTP or SMTP. Right now, their build is based on Ant and is mildly complex, so it's a pretty good candidate for me to present Raven.
Raven being just a set of specific tasks (plus a bit more, but we'll see that later), the whole build is still directed by Rake. So, all of the code I'm going to show is part of a file named Rakefile that should be placed at the root of the Commons Net unpacked source distribution. When you start Rake, it always looks for that script.
This first snippet demonstrates initialization and dependency handling:require "raven"
require "rake/clean"
CLEAN.include ["target", "dist"]
dependency "compile_deps" do task
task.deps << "oro-oro" end The two first lines load Raven and a Rake subtask for cleaning. The require command in Ruby is a bit like import, only it can load either a whole library (like Raven) or a single file. The third line tells Rake which directories should be removed by the clean task. Lines 5 to 7 demonstrate the usage of the Raven dependency task. Commons Net depends on the Jakarta ORO library, so we're adding a dependency on it. It's just about listing which set of libraries will be needed. Calling the task (by executing rake compile_deps) will actually trigger the library download from a default Raven repository and depending on it will propagate a proper classpath as we'll see later. Also note that you can specify more than one library at a time and also give version numbers (Raven uses the latest by default). All of these library declarations are valid within a dependency task: task.deps << ["springframework-spring-core", { "taglibs-standard" => "1.1.2" }]
task.deps << ["axis2-kernel", "axis2-codegen"] The provided name should follow the Maven naming of groupId and artifactId separated by a dash. Browse the Raven repository to see which libraries are available. Partial names can also be provided when there's no ambiguity. Now that we're done with dependencies, let's see what compilation would look like:javac "compile" => "compile_deps" do task
task.build_path << "src/java" end jar "commons-net.jar" => "compile"
The javac task is another of the tasks that Raven provides. What it does is pretty simple to understand. The => notation declares the pre-requisite on the dependencies. From this Raven can automatically compute the classpath for you. Notice that we are also setting the build path. It needs to be explicit as Commons Net has its sources under src/java. If it were under src/main/java, no additional configuration would be needed, making this the sweet one-liner:javac "compile" => "compile_deps"
Finally, once compilation is done, the previous snippet also packages everything in a jar. That's the role of the jar task. The produced jar file is directly named like the task, minimizing the number of parameters.
With everything I've explained so far, you should end up with a 10 line Rakefile located at the root of the Commons Net source distribution. To run the build, just execute rake commons-net.jar and everything should get built in a target directory. You could also add a default task so that just running rake would build your jar:task "default" => "commons-net.jar"
Some More
Compiling and packaging is nice, but it's usually only the first step in a build. For example, the Commons Net Ant script also handles tests and Javadoc. How would you do this with Raven? Once again, it's pretty simple, really.junit "test"=>["compile", "compile_deps", "test_deps"] do task
task.build_path << "src/test" task.test_classes << "**/*Test.java" end javadoc "jdoc" do task task.build_path << "src/java" end You probably don't need much of an explanation to understand what this does. Just note that the settings inside the tasks are here because Commons Net directory structure doesn't follow the Raven defaults. If the tests were located under src/test/java and the test classes followed the Test* pattern, the tasks would just be empty. There are a few other tasks that I won't detail much more here, but that you should know of, in case you would need one of them. jar_source Builds a jar file containing your project sources war Builds a WAR file from your compiled classes and the additional web application resources located under src/main/webapp lib_dir Creates a library directory and places all your project dependencies in it, makes it very easy to construct a classpath for your command scripts (bat or sh) On the Shoulders of Giants To be complete, our real life example should include a way to build a distribution. The Commons Net original build has a dist task and, even if it didn't, distribution is a pretty common use case, perhaps even the most common. So, how would you go about doing it with Raven? Well, errr, you don't. There's nothing in Raven to help you build distributions. You see, there's no real standard way to make a distribution, it really depends on what you want to include. But don't worry, you're not left alone here. As I mentioned at the beginning of this article, Raven is built on top of Rake, which itself runs in a full Ruby interpreter. So our dist task is just going to be a simple Rake task:lib_dir("dist:libs" => "compile_deps") do task
task.target = "dist/lib"
end
task "dist" => ["commons-net.jar", "dist:libs"] do
cp ["LICENSE.txt", "NOTICE.txt", "target/commons-net.jar"], "dist"
File.open("dist/README.txt", "w") { f f << "Built on #{Time.now}" } end The first line of code demonstrates the usage of the lib_dir task that I explained previously. Then comes the interesting bit. The dist task is a standard Rake task, it only checks for the prerequisites and executes the code body afterward. Here I'm just making sure that the jar has been built and the libraries are included in a lib sub-directory. The rest is pure and simple Ruby. Rake pre-includes a Ruby module that handles all basic file operations. Things like cp (copy), mv (move), mkdir (make directory), or rm (remove). That's pretty handy in a build where you typically do a lot of file manipulations. So, the first line in my task block copies the license, the notice file, and the produced jar in the distro directory. The cp method, just like most of the others, accept arrays. The second line demonstrates how you would go about tweaking some file content. I'm creating a new README file (the "w" flag means new file) and adding a simple timestamp in it. Don't be put off by the #{..} syntax inside the string, it's just a way to place the result of a computation of a variable value inside of a string (the equivalent of "Built on" + new Date().toString()). Typically you would append that type of information in your README using the w+ flag, but Commons Net doesn't have a README, so I'm just creating an empty one here. With the dist task, our build is complete, I've shown you everything that was needed to replace the original Ant script. We've reduced a 170 lines build to a 20 lines one. That's almost 10 times less code to maintain. But to drive my point a little further, just let me give you one last example that would demonstrate the usage of a control structure:MODULES = ["web", "business", "persistence"] MODULES.each do mod javac "#{mod}:compile" => ["#{mod}_deps", "common_deps"]
end
This would create a compilation task for a given list of modules. No need to repeat, just iterate. You can even create a method and call it from a task with specific parameters. Very basic things when you're programming, but something we've lost with most current build tools.
I hope you're now starting to see how much power being based on a scripting language like Ruby gives to Raven. You have a pretty strong and terse basis with a set of Java-specific tasks provided by Raven, simple cases are very simple to write. For everything that doesn't fit in the framework, you have an elegant safety net (in place of a plugin framework).
Other Choices
Raven isn't the only one of its kind, it's my answer to the build problem and to the dissatisfaction I had with the currently available tools. Others came with other solutions coming from the same frustrations, and I don't pretend that my solution will be the best for everybody. So, there are a couple of alternatives, built on the same foundations as Raven, namely Rake, but with a different philosophy.
The first alternative would be Antwrap. I wouldn't actually consider it a replacement for Raven, so much as a very good complement. It lets you reuse all existing Ant tasks that have already been created, but with a much nicer syntax than XML. So, you could use Raven for everything that's already included and Antwrap when an existing Ant task does what you're looking for, all within the same script.
The second tool is Buildr. It's an Apache Incubator project and completely overlaps with Raven, so it could be a total replacement. The difference is in the philosophy: Raven is imperative, asking you to write how to build your project; Buildr is more declarative, you specify what your build looks like. So, said differently, those of you who prefer the style of Ant over Maven will prefer Raven, those who are more seduced by the Maven model will probably find Buildr more seducing. And I don't see this as a problem, software is also a matter of preferences and taste, you should just use the tool that makes you most comfortable.
Conclusion
In this article, you've learned how to write a build script for an existing Java project using Raven. You've seen how to handle dependencies, compile, package, and do all the tasks necessary to most Java software builds. However, there's much more to Raven than what I've explained in those lines, especially in the dependency management area. I encourage you to continue exploring, using the Raven web site and book (see references) to discover more. And hopefully you'll find interest in Rake and the Ruby language as well.
Beyond Raven, I hope you'll start being more demanding from your build system, a rich scripting environment should be a minimum. Too much time has been wasted writing XML.
Resources
The source for the Rakefile detailed in this article.
Raven distribution, download the pre-packaged JRuby one for easy installation.
Apache Commons Net to download the source distribution built in the article.
Raven's web site, with more information and examples.
The Raven Book, a definitive reference.
Rake documentation.
Antwrap
Buildr
Matthieu Riou has been a consultant, freelancer, developer, and engineer for a wide variety of companies. He's also a Vice President at the Apache Software Foundation and has founded several open source projects.
2009年3月10日星期二
Introducing [fleXive] - A Complementary Approach to Java EE 5 Web Development
by Markus Plesser and Daniel Lichtenberger 05/01/2008
The daily bread and butter of an architect or developer dealing with web applications usually consists of a great many repetitive tasks. These start with setting up a development environment, choosing and downloading libraries (or let tools like Maven download them), creating basic build scripts, and wiring up all necessary components. After some time a naked skeleton for a web application is ready and waiting for further coding. While these steps are easy and can be efficiently handled by automation tools, other tasks like managing users, choosing a viable form of persistence (file based, JDBC, Hibernate, JPA, etc.), and implementing security for your sensitive data will still require a lot more time and effort.
');
//-->
There are many solutions out there that deal with some of these issues, but in most cases with some drawbacks: e.g., Ruby on Rails -- it is great and works well, but may not have corporate penetration, especially if a Java or .Net platform is already a company standard. We won't delve into the .Net world -- since this is a quite different situation than your typical Java environment -- but having a look at Java and especially Java EE, a web application will in most cases use JSF as its web framework, and the choice for a viable persistence framework will usually be Hibernate or JPA (in some Application Servers implemented using Hibernate). Depending on the use of some scaffolding tools you'll soon have some very basic versions of forms to create, read, edit, and delete data instances.
So far it has been pretty straightforward -- now imagine you also need authorization and authentication -- not only to be able to use (and hence see) data from your application, but even more to restrict access in a finer grained way than the usual "all or nothing" approach. You'll soon end up coding your own custom tailored mini-security framework - maybe based on established open source libraries like OSUser or Acegi coupled with some JAAS code.
Over the years, the authors did the same tasks over and over again. We learned a lot -- in particular about the capabilities and effort to integrate various libraries, as well as their major advantages and drawbacks -- and came up with a list of requirements for a framework:
Built in security, from authentication to fine grained authorization
Datatypes with inherent support for multiple languages
Versioning
Hierarchical data structures
Support for workflows
Every little bit of the framework should be scriptable
No vendor or technology lock-in
Interoperability with other applications
Figure 1. [fleXive] core components
At its heart [fleXive] is a pure Java EE 5 application, the core is made up of EJB3 beans, sharing common states and configuration using a clustered cache (including out-of-the-box support for JBoss Cache 2.x with pluggable interfaces that could be used for other providers like GigaSpaces or Coherence), while the web layer is based on JSF using Facelets, Richfaces/Ajax4JSF, and the Dojo toolkit. As a persistence alternative to JPA/Hibernate (which can be used as well of course) [fleXive] comes with its own persistence implementation offering some advantages like integrated ACL based security, versioning, support for multilingual data types, inheritance, and reuse. The persistence framework is not intended as an object-to-relational mapper, but rather as generic objects with all instance data accessible using XPath-like statements or traversing object graphs.
All these so called engines (implemented as Enterprise JavaBeans) can be used in your project. [fleXive] supports you by creating application skeletons where you just have to implement your business logic, use some of the pre-made JSF user interface components while giving you the freedom to use which ever Java EE 5 compatible library you wish.
Figure 2. [fleXive] support for writing applications
A big advantage of using [fleXive] is the powerful, and extendable, backend application where you can model your data structures, manage users and security, visually create queries, store search results in so called briefcases, or edit your data instances.
While being designed and written from scratch, [fleXive] uses very mature and approved concepts dating back to 1999. Originally intended as a framework for content management systems it grew to a feature reach multi purpose framework incorporating state of the art open source projects and tools.
Not everything is perfect yet and some features (like import/export and webservice support) are still in the works, but the majority of the framework is very stable and solid and soon ready for production use. Since we at UCS (unique computing solutions gmbh), the company sponsoring [fleXive] and being responsible for development, believe in OpenSource and "give and take," we decided to release the whole framework licensed under the LGPL v2.1 or higher.
A backend application showcasing most of [fleXive]'s features which is built on top of the framework is licensed under the GPL v2 or higher. It helps you to visually manage most aspects of [fleXive] - like defining data structures, building queries, manage users and security, etc.
And while we are currently the only ones maintaining and extending [fleXive] we certainly do hope for some positive feedback, feature requests, and helping hands when it comes to development and documentation from you, the community, to make [fleXive] a valuable choice for upcoming web applications.
We tried not to reinvent the wheel, but to make it easier and faster to develop web applications using up-to-date technology, provide means to extend the framework using plugins, and provide a backend administration application that is ready to use and can easily be adopted to your needs.
Current development snapshots and the "Release Candidate 1" are available for download at http://www.flexive.org/download - the final release following hopefully soon after [fleXive] is feature complete and more or less bug free. For further information please have a look at the roadmap.
The daily bread and butter of an architect or developer dealing with web applications usually consists of a great many repetitive tasks. These start with setting up a development environment, choosing and downloading libraries (or let tools like Maven download them), creating basic build scripts, and wiring up all necessary components. After some time a naked skeleton for a web application is ready and waiting for further coding. While these steps are easy and can be efficiently handled by automation tools, other tasks like managing users, choosing a viable form of persistence (file based, JDBC, Hibernate, JPA, etc.), and implementing security for your sensitive data will still require a lot more time and effort.
');
//-->
There are many solutions out there that deal with some of these issues, but in most cases with some drawbacks: e.g., Ruby on Rails -- it is great and works well, but may not have corporate penetration, especially if a Java or .Net platform is already a company standard. We won't delve into the .Net world -- since this is a quite different situation than your typical Java environment -- but having a look at Java and especially Java EE, a web application will in most cases use JSF as its web framework, and the choice for a viable persistence framework will usually be Hibernate or JPA (in some Application Servers implemented using Hibernate). Depending on the use of some scaffolding tools you'll soon have some very basic versions of forms to create, read, edit, and delete data instances.
So far it has been pretty straightforward -- now imagine you also need authorization and authentication -- not only to be able to use (and hence see) data from your application, but even more to restrict access in a finer grained way than the usual "all or nothing" approach. You'll soon end up coding your own custom tailored mini-security framework - maybe based on established open source libraries like OSUser or Acegi coupled with some JAAS code.
Over the years, the authors did the same tasks over and over again. We learned a lot -- in particular about the capabilities and effort to integrate various libraries, as well as their major advantages and drawbacks -- and came up with a list of requirements for a framework:
Built in security, from authentication to fine grained authorization
Datatypes with inherent support for multiple languages
Versioning
Hierarchical data structures
Support for workflows
Every little bit of the framework should be scriptable
No vendor or technology lock-in
Interoperability with other applications
Figure 1. [fleXive] core components
At its heart [fleXive] is a pure Java EE 5 application, the core is made up of EJB3 beans, sharing common states and configuration using a clustered cache (including out-of-the-box support for JBoss Cache 2.x with pluggable interfaces that could be used for other providers like GigaSpaces or Coherence), while the web layer is based on JSF using Facelets, Richfaces/Ajax4JSF, and the Dojo toolkit. As a persistence alternative to JPA/Hibernate (which can be used as well of course) [fleXive] comes with its own persistence implementation offering some advantages like integrated ACL based security, versioning, support for multilingual data types, inheritance, and reuse. The persistence framework is not intended as an object-to-relational mapper, but rather as generic objects with all instance data accessible using XPath-like statements or traversing object graphs.
All these so called engines (implemented as Enterprise JavaBeans) can be used in your project. [fleXive] supports you by creating application skeletons where you just have to implement your business logic, use some of the pre-made JSF user interface components while giving you the freedom to use which ever Java EE 5 compatible library you wish.
Figure 2. [fleXive] support for writing applications
A big advantage of using [fleXive] is the powerful, and extendable, backend application where you can model your data structures, manage users and security, visually create queries, store search results in so called briefcases, or edit your data instances.
While being designed and written from scratch, [fleXive] uses very mature and approved concepts dating back to 1999. Originally intended as a framework for content management systems it grew to a feature reach multi purpose framework incorporating state of the art open source projects and tools.
Not everything is perfect yet and some features (like import/export and webservice support) are still in the works, but the majority of the framework is very stable and solid and soon ready for production use. Since we at UCS (unique computing solutions gmbh), the company sponsoring [fleXive] and being responsible for development, believe in OpenSource and "give and take," we decided to release the whole framework licensed under the LGPL v2.1 or higher.
A backend application showcasing most of [fleXive]'s features which is built on top of the framework is licensed under the GPL v2 or higher. It helps you to visually manage most aspects of [fleXive] - like defining data structures, building queries, manage users and security, etc.
And while we are currently the only ones maintaining and extending [fleXive] we certainly do hope for some positive feedback, feature requests, and helping hands when it comes to development and documentation from you, the community, to make [fleXive] a valuable choice for upcoming web applications.
We tried not to reinvent the wheel, but to make it easier and faster to develop web applications using up-to-date technology, provide means to extend the framework using plugins, and provide a backend administration application that is ready to use and can easily be adopted to your needs.
Current development snapshots and the "Release Candidate 1" are available for download at http://www.flexive.org/download - the final release following hopefully soon after [fleXive] is feature complete and more or less bug free. For further information please have a look at the roadmap.
Does Enterprise Development Have to Be Painful?
by chromatic 02/28/2008
Despite the buzz about social networking, mashups, collaborative filtering, machine learning, and everything else grouped under the convenient label of Web 2.0, writing business software seems to be business as usual: push messages around, present data entry screens, produce reports, and occasionally make people's work easier by automating repetitive tasks. I fled corporate IT in 2000, believing that business software—especially "enterprise software"—is bulky, complex, and uninteresting.
It can be. Enterprise-wide software must be reliable and fault-tolerant. That's not simple or easy or even fun to build. Unless you have the time and resources and talent to write and maintain and deploy your own completely custom software (who does?), you use generalized software packages and adapt them to your business. Only the generality of such a framework offers the potential for customization... at the cost of complexity.
Recently, Tim O'Reilly spoke at SAP's Tech Ed Conference. He found inspiration in subsequent conversations, and wrote SAP as a Web 2.0 Company?. SAP Labs invited other O'Reilly folks to see what they're working on and to ask for advice on how to engage the large community of SAP users, developers, and consultants more effectively.
I went there, and met Will Gardella (see SAP's Composition on Grails). His work convinced me that my perception of SAP and its software was incomplete. While there's still necessary complexity in producing robust, reliable, business-wide and business-critical software, writing that software does not have to be an exercise in tedium. Will, Moya Watson, and the other people I met actually live that idea.
The team at SAP made me an offer. If I would give their software a fair try and write about my experience installing it, learning it, and building a couple of modest sample applications, they'd give me all of the support I wanted. We decided that the right approach was to explore the software behind Will's Groovy on Grails, so I agreed to install and explore the SAP development environment called SAP NetWeaver Composition Environment, or SAP NetWeaver CE.
Why does this matter?
Business software isn't going away. If you're a consultant or a small ISV, you probably make money writing, customizing, and maintaining software of this sort. Maybe your platform isn't J2EE or ABAP, but learning an extra tool and platform gives you and your customers more options.
Most of the components in this stack are at least open standards. Some are free and open source software. You can interact with a SAP installation through SOAP/WSDL, with Groovy, and as a J2EE provider. SAP NetWeaver CE itself is an Eclipse-based IDE. These are well-established and well-understood technologies, not a proprietary concrete jungle.
It's good to learn something new. I haven't done serious Java development in several years. Most of my recent programming is low-level, cross-platform C code. Stretching my brain and switching habits away from my Vim, GCC, Valgrind, and GDB habits helps me grow as a developer.
Good development habits and good ideas come from all over. SAP NetWeaver CE and some of its tools encourage a nice separation of concerns that, applied well, appears to allow a rapid yet robust approach to developing and deploying applications. I've built MVC applications in several languages, but it's nice to see it encouraged as well as it is here.
First Approach
My initial impression was, "This software sounds great, if you're an expert already." Will and Moya have built impressive systems, but they're experienced SAP insiders. I'd have to start from zero, relying only on a decade of experience building software, mostly in different realms.
I'd long heard that installing and configuring SAP was complex. Thus, downloading and installing the SAP NetWeaver Composition Environment was my first milestone. Once I'd accomplished that, I could survey the landscape and review my initial impressions. Even discovering what I needed to download took some time, so I gave myself a week. I relied heavily on help from Armand Wilson, a consultant within SAP for advice over email (and once, via telephone and a shared desktop) to resolve at least one troublesome problem.
None of the machines in my office were suitable installation candidates. I convinced O'Reilly IT to loan me a spare ThinkPad with a 1.5 GHz Centrino CPU and 2 GB of RAM—and, most important, a fresh Windows XP installation. A virtual machine image will, apparently, not do the trick, even on a monster multi-core 64-bit Ubuntu development box.
Installing the SAP Server
Armand told me to download the SAP NetWeaver CE Trial Version from SAP NetWeaver Composition Environment Downloads on the SAP Developer Network (SDN). This file is really big; it's an RAR file more than a gigabyte in size. I never successfuly completed a download on the ThinkPad due to a combination of wireless networking and server cancellations.
After several abortive attempts, I downloaded the file on a Linux machine thanks to curl and resuming downloads, extracted the archive there, and used rsync to copy all of the files from the Linux machine to the Windows machine.
This gave me a directory that included an HTML file called Start. I launched the HTML file and skimmed the instructions. An installation link in the sidebar prompted me to download or save an executable file named sapinst.exe. I launched it myself from JavaEE\CE71_03_IM_WIN_I386_ADA\sapinst.exe.
Unfortunately, the whole directory path had spaces in it, so the installer refused to run. I moved the top folder to C:\ and this time the installer launched successfully. It offered only a few prompts: accept the license, specify a SAP system ID (I kept the default of CE1).
The next step asked for my JCE unlimited strength jurisdiction policy archive. I didn't have one, so the installer refused to proceed. I found the JCE on Sun's Java downloads site. I extracted the JAR file from the ZIP, and gave the installer its path. That didn't work either. When I gave the installer the full path to the ZIP file, it proceeded.
Next, it asked for a master password for the server. This step gave me some trouble. The installer rejected my first, a strong password with non-alphanumeric characters. I wondered if it only allowed alphanumerics, then finally read the password directions and realized that it was one character too short. I've spent too much time working around bad password systems to trust that any password system could actually work well.
I wrote down the password. I had a feeling I'd use it later.
The installer then scanned my system and helpfully reported that I had 2047 megabytes of memory and the minimum recommendation is 2048. I risked it, as I couldn't find a spare 1 MB stick and an empty slot in the ThinkPad. The installer purred through all 33 installation phases.
I told Armand that I thought I'd completed things on my own. He asked the innocent question, "Is the SAP server running?" He told me to launch the management console to verify that both little icons in the left tree under the SAP Root and CE1 were green. They looked green to me, but when we looked in the Process List entry under both icons, neither service was actually running.
After more scrambling, I noticed that I had two SAP management consoles running. I closed both consoles and waited for a moment, then launched only one console and attempted to start both services. Twenty minutes later, they had both started. Step one was complete. With a better download system than I have—and existing hardware—you should be able to install an SAP server in two hours. Read the installation requirements better than I did, and you should have no trouble.
Installing the SAP NetWeaver Composition Environment with IDE
Step two was to install the developer components, including the Eclipse-based IDE. I went to the same SAP download page as before and downloaded only the Developer Studio, which seemed slim at 680 megabytes. This was a mistake. I needed the 1.2 gigabyte Composition Environment download. The smaller download lacks the Composition Environment plugins for Eclipse. Unfortunately, I only discovered this when I started to build applications, and I found no good way to install the plugins separately. I had to uninstall and reinstall, but that only took a few clicks and some time.
The downloading process was again painful, but the Linux/rsync approach worked fine. Installation proceeded until the installer tried to find JDK 1.5.0_06 or better on my machine.
I knew I had one installed, but I couldn't find it either. After another trip to Sun's download page, I had installed the entire JDK. I even included the optional parts I knew I didn't need, as my instincts had already led me astray enough.
The installer ran for an hour and then wanted to connect to the Internet to perform more updates. I let it update everything.
With the proper package downloaded and installed, I was ready to write applications—starting by working through the example code Armand provided.
Conclusions
The two most difficult parts of the installation process, for me, were almost entirely external. One was getting the right hardware, and that's because of a little scramble in our IT department right before the Christmas holidays. The other problem was getting a reliable download onto the ThinkPad. If I had a much faster Internet connection, or if I were more familiar with the Windows tools for managing long, potentially-interrupted downloads, that process might have been easier too. I spent most of a work-week downloading the software.
Both installations were time-consuming, but not troublesome. Paying more attention to the installation instructions, particularly the dependencies, would have saved me time. I did search SDN for some error messages and workarounds to see if I could find solutions for any problems I encountered, but I seem to have avoided any serious troubles not of my own making. Even the one problem I had with SDN (an invalid download link from a Wiki page) saw a very quick fix from Moya Watson.
I have a lot to learn to write applications with SAP NetWeaver CE, but I'm past the first hurdles, and that gives me a lot of confidence that things will make a lot of sense in context from here. While the download-and-go score is much less than the simple aptitude install build-essential I normally use on a new machine, the immediate out-of-the-box capabilities are greater. Writing software this way may be much easier than I thought.
chromatic promotes free and open source software for O'Reilly's Open Technology Exchange.
Despite the buzz about social networking, mashups, collaborative filtering, machine learning, and everything else grouped under the convenient label of Web 2.0, writing business software seems to be business as usual: push messages around, present data entry screens, produce reports, and occasionally make people's work easier by automating repetitive tasks. I fled corporate IT in 2000, believing that business software—especially "enterprise software"—is bulky, complex, and uninteresting.
It can be. Enterprise-wide software must be reliable and fault-tolerant. That's not simple or easy or even fun to build. Unless you have the time and resources and talent to write and maintain and deploy your own completely custom software (who does?), you use generalized software packages and adapt them to your business. Only the generality of such a framework offers the potential for customization... at the cost of complexity.
Recently, Tim O'Reilly spoke at SAP's Tech Ed Conference. He found inspiration in subsequent conversations, and wrote SAP as a Web 2.0 Company?. SAP Labs invited other O'Reilly folks to see what they're working on and to ask for advice on how to engage the large community of SAP users, developers, and consultants more effectively.
I went there, and met Will Gardella (see SAP's Composition on Grails). His work convinced me that my perception of SAP and its software was incomplete. While there's still necessary complexity in producing robust, reliable, business-wide and business-critical software, writing that software does not have to be an exercise in tedium. Will, Moya Watson, and the other people I met actually live that idea.
The team at SAP made me an offer. If I would give their software a fair try and write about my experience installing it, learning it, and building a couple of modest sample applications, they'd give me all of the support I wanted. We decided that the right approach was to explore the software behind Will's Groovy on Grails, so I agreed to install and explore the SAP development environment called SAP NetWeaver Composition Environment, or SAP NetWeaver CE.
Why does this matter?
Business software isn't going away. If you're a consultant or a small ISV, you probably make money writing, customizing, and maintaining software of this sort. Maybe your platform isn't J2EE or ABAP, but learning an extra tool and platform gives you and your customers more options.
Most of the components in this stack are at least open standards. Some are free and open source software. You can interact with a SAP installation through SOAP/WSDL, with Groovy, and as a J2EE provider. SAP NetWeaver CE itself is an Eclipse-based IDE. These are well-established and well-understood technologies, not a proprietary concrete jungle.
It's good to learn something new. I haven't done serious Java development in several years. Most of my recent programming is low-level, cross-platform C code. Stretching my brain and switching habits away from my Vim, GCC, Valgrind, and GDB habits helps me grow as a developer.
Good development habits and good ideas come from all over. SAP NetWeaver CE and some of its tools encourage a nice separation of concerns that, applied well, appears to allow a rapid yet robust approach to developing and deploying applications. I've built MVC applications in several languages, but it's nice to see it encouraged as well as it is here.
First Approach
My initial impression was, "This software sounds great, if you're an expert already." Will and Moya have built impressive systems, but they're experienced SAP insiders. I'd have to start from zero, relying only on a decade of experience building software, mostly in different realms.
I'd long heard that installing and configuring SAP was complex. Thus, downloading and installing the SAP NetWeaver Composition Environment was my first milestone. Once I'd accomplished that, I could survey the landscape and review my initial impressions. Even discovering what I needed to download took some time, so I gave myself a week. I relied heavily on help from Armand Wilson, a consultant within SAP for advice over email (and once, via telephone and a shared desktop) to resolve at least one troublesome problem.
None of the machines in my office were suitable installation candidates. I convinced O'Reilly IT to loan me a spare ThinkPad with a 1.5 GHz Centrino CPU and 2 GB of RAM—and, most important, a fresh Windows XP installation. A virtual machine image will, apparently, not do the trick, even on a monster multi-core 64-bit Ubuntu development box.
Installing the SAP Server
Armand told me to download the SAP NetWeaver CE Trial Version from SAP NetWeaver Composition Environment Downloads on the SAP Developer Network (SDN). This file is really big; it's an RAR file more than a gigabyte in size. I never successfuly completed a download on the ThinkPad due to a combination of wireless networking and server cancellations.
After several abortive attempts, I downloaded the file on a Linux machine thanks to curl and resuming downloads, extracted the archive there, and used rsync to copy all of the files from the Linux machine to the Windows machine.
This gave me a directory that included an HTML file called Start. I launched the HTML file and skimmed the instructions. An installation link in the sidebar prompted me to download or save an executable file named sapinst.exe. I launched it myself from JavaEE\CE71_03_IM_WIN_I386_ADA\sapinst.exe.
Unfortunately, the whole directory path had spaces in it, so the installer refused to run. I moved the top folder to C:\ and this time the installer launched successfully. It offered only a few prompts: accept the license, specify a SAP system ID (I kept the default of CE1).
The next step asked for my JCE unlimited strength jurisdiction policy archive. I didn't have one, so the installer refused to proceed. I found the JCE on Sun's Java downloads site. I extracted the JAR file from the ZIP, and gave the installer its path. That didn't work either. When I gave the installer the full path to the ZIP file, it proceeded.
Next, it asked for a master password for the server. This step gave me some trouble. The installer rejected my first, a strong password with non-alphanumeric characters. I wondered if it only allowed alphanumerics, then finally read the password directions and realized that it was one character too short. I've spent too much time working around bad password systems to trust that any password system could actually work well.
I wrote down the password. I had a feeling I'd use it later.
The installer then scanned my system and helpfully reported that I had 2047 megabytes of memory and the minimum recommendation is 2048. I risked it, as I couldn't find a spare 1 MB stick and an empty slot in the ThinkPad. The installer purred through all 33 installation phases.
I told Armand that I thought I'd completed things on my own. He asked the innocent question, "Is the SAP server running?" He told me to launch the management console to verify that both little icons in the left tree under the SAP Root and CE1 were green. They looked green to me, but when we looked in the Process List entry under both icons, neither service was actually running.
After more scrambling, I noticed that I had two SAP management consoles running. I closed both consoles and waited for a moment, then launched only one console and attempted to start both services. Twenty minutes later, they had both started. Step one was complete. With a better download system than I have—and existing hardware—you should be able to install an SAP server in two hours. Read the installation requirements better than I did, and you should have no trouble.
Installing the SAP NetWeaver Composition Environment with IDE
Step two was to install the developer components, including the Eclipse-based IDE. I went to the same SAP download page as before and downloaded only the Developer Studio, which seemed slim at 680 megabytes. This was a mistake. I needed the 1.2 gigabyte Composition Environment download. The smaller download lacks the Composition Environment plugins for Eclipse. Unfortunately, I only discovered this when I started to build applications, and I found no good way to install the plugins separately. I had to uninstall and reinstall, but that only took a few clicks and some time.
The downloading process was again painful, but the Linux/rsync approach worked fine. Installation proceeded until the installer tried to find JDK 1.5.0_06 or better on my machine.
I knew I had one installed, but I couldn't find it either. After another trip to Sun's download page, I had installed the entire JDK. I even included the optional parts I knew I didn't need, as my instincts had already led me astray enough.
The installer ran for an hour and then wanted to connect to the Internet to perform more updates. I let it update everything.
With the proper package downloaded and installed, I was ready to write applications—starting by working through the example code Armand provided.
Conclusions
The two most difficult parts of the installation process, for me, were almost entirely external. One was getting the right hardware, and that's because of a little scramble in our IT department right before the Christmas holidays. The other problem was getting a reliable download onto the ThinkPad. If I had a much faster Internet connection, or if I were more familiar with the Windows tools for managing long, potentially-interrupted downloads, that process might have been easier too. I spent most of a work-week downloading the software.
Both installations were time-consuming, but not troublesome. Paying more attention to the installation instructions, particularly the dependencies, would have saved me time. I did search SDN for some error messages and workarounds to see if I could find solutions for any problems I encountered, but I seem to have avoided any serious troubles not of my own making. Even the one problem I had with SDN (an invalid download link from a Wiki page) saw a very quick fix from Moya Watson.
I have a lot to learn to write applications with SAP NetWeaver CE, but I'm past the first hurdles, and that gives me a lot of confidence that things will make a lot of sense in context from here. While the download-and-go score is much less than the simple aptitude install build-essential I normally use on a new machine, the immediate out-of-the-box capabilities are greater. Writing software this way may be much easier than I thought.
chromatic promotes free and open source software for O'Reilly's Open Technology Exchange.
Does Enterprise Development Have to Be Painful? (Part Two)
by chromatic 05/07/2008
As I mentioned in Does Enterprise Development Have to be Painful, Part One, I've been exploring the world of enterprise software development with SAP NetWeaver Composition Environment (after this, SAP NetWeaver CE), as part of a challenge from SAP Labs to see how much I could accomplish with minimal training and direction (though with the offer of assistance from one or two of their consultants if I managed to get myself completely stuck).
I decided that my best approach would be to build a simple, self-contained application with their system, writing as little code as possible and using as many of their tools as I could. I settled for a tiny task tracking application, in which a task has a due date, a description, and an associated category. The entire application consists of two models, their business logic, and a user interface. SAP NetWeaver CE provides plenty of tools to build, manage, and deploy these types of business objects and their relationships, so I thought this would be a good basic experiment. This is a standard CRUD-style application, where the code needs to Create, Read, Update, and possibly Delete data.
Is it too basic? Perhaps; if this were the only type of application I ever built, SAP's tools are definitely overkill. I don't need clustering or monitoring or failsafe deployment and rollback to keep track of what I need to do in a day. However, it was the minimal application I could imagine that exercised most of the parts of the system that a real application would actually use. In building and deploying the task tracker, I performed the work that a real team would perform when building and deploying a much larger application. I just didn't have to invest several months to design and build such an application. My design took me a day, and I figured that building the application myself should take a couple of ideal calendar days.
What's in SAP NetWeaver CE
SAP NetWeaver CE has two main parts. The first is a server component that represents the large database, cluster, services registry, user management, and central configuration of an enterprise-wide installation. For the most part, I ignored it except to make sure it was running and to perform a few configurations. The second part of the system is an IDE built on Eclipse. If you're at home in Eclipse or another IDE and don't mind performing some visual modeling instead of writing heaps of code yourself, you will find the IDE very comfortable.
This modeling was simple. Although I like opening a text editor and writing some declarative code to tell an object-relational mapper the structure of my database (or to make that tool generate my schema for me), the model design tool in the IDE was easy to use. I didn't have to think about creating tables or choosing column types or optimizing data for JOIN operations. If the abstraction holds through my application's lifecycle, I won't have to worry about versioning or migrating data between schema changes.
Declaring my Task and Category models was as easy as creating new business objects and selecting from menus of available attribute types. Although mousing around was probably slower than typing the corresponding short declarations in a text editor, there's enough metadata slinging happening behind the scenes that I didn't perceive any mild inefficiencies in the UI; it was doing enough of the other work for me.
This was the easy part of the process, and with the help of one of the built-in tutorials, I had two models built and associated very quickly.
Modeling Business Objects
The word model should make you think that these models contain business logic. They do. However, this is where I first ran into trouble. Models have operations -- business logic -- and the IDE gives you an easy way to declare them. For example, I wanted an operation which returned a list of all open tasks and another operation that returned a list of all tasks for a given date. You can create an operation which filters the entire collection of model items on a particular attribute, but apart from creating some metadata (I assume hidden somewhere) and adding a method stub to the generated Java Bean for your model, nothing else happens. You have to write code that uses the appropriate SAP Java APIs to perform this filtering. The help system has some information on how to write query filters, though it is unclear. (Likewise, the tutorial example provided is missing code and writes to a deprecated API.)
As with the basic model structure, you model operations in the IDE, selecting the input and output types (both provided by the Composite Application Framework and modeled explicitly on your own) as well as any exceptions that the operation might throw. The IDE generates methods on your model beans for you, but only signatures and empty implementations that return null. It's up to you to implement the rest of the code. One of my initial experiments was to create an operation that returned a collection of all of the open tasks by filtering out all tasks with an open status. I originally modeled it believing that taking the status type as an input parameter was the right approach, but it appears that creating a non-parameterized filter in the body of the method is correct.
Producing a UI
I set aside the notion of finding the most correct and purest design in favor of getting the back-end model to communicate with a front-end UI, specifically through the use of Visual Composer. Visual Composer is a UI-builder with intelligent widgets configurable almost entirely through a drag-and-drop interface built with SVG and other web technologies. There's no code required. Visual Composer can consume web services if you have them deployed properly, which means you need to produce a valid WSDL file and publish it somewhere that Visual Composer can access it.
I had trouble with this step. There are several different ways to expose business models as web services. Their context menus available from the project navigator give you the option of exposing them directly. You can also model services with their own operations apart from your business models. I assumed that providing an application service would be the proper approach; however, all of the tutorials and documentation I saw described the very configuration of application services and again gave very little information about what the body of the generated methods should contain. I'm comfortable writing business logic, but I didn't find a good reference to the types of operations most often found within these methods, nor the preferred and current APIs provided for performing this logic.
Although the generated business models all have CRUD methods provided to create, read, update, and delete business model instances, the generated application service has no operations by default. I didn't see an easy way to link in the operations of the business models. Presumably it is possible to expose those operations directly, or to wrap them in the application service. I can understand the organizational principle of modeling business objects and providing different API bundles for different types of applications, but the enforced striation seemed excessive for my very simple purposes. (In larger projects, it's likely very important.)
I decided to expose the Task models operations directly as a web service. Configuring and registering this web service with my SAP server for Visual Composer's consumption was the most complex part of this process. My contact, Armand, walked me through testing the web service from the IDE (which launches a web service browser), configuring the web service both inside the IDE and deploying the service to the SAP NetWeaver server, and creating a destination for the web service in the SAP NetWeaver Administrator. At that point, we restarted Visual Composer, and I was able to see my web service as a data component within Visual Composer. Since that point, I've learned that you can right-click on the services search widget within Visual Composer to refresh the services cache without restarting the system.
After all of that, building a UI with Visual Composer was simple. Visual Composer presents a few menus of widgets, including buttons, table lists, and input boxes. Because WSDL includes remote calls and argument types, you can easily connect a UI widget with the proper parameters such that input and output displays properly. You can consume several web services in a single form; one view of the UI shows logical relationships and data flow between widgets and services and the other is a layout view, which allows you to rearrange the actual view of the UI.
Yet More Than One Afternoon
With everything working together, I had finally achieved my write-test-debug cycle. Even though my actual code is minimal, my web services are small, and my operations are few, the cycle is not fast. My under-powered laptop running the SAP server, the IDE, and Visual Composer takes several minutes to generate, build, and deploy a new version of my web service to the J2EE server, and Visual Composer takes a few minutes to start. The effective cycle of experimentation is by no means instantaneous or cheap. If you're interested in performing similar experiments, I cannot recommend more highly browsing through an existing non-trivial application to get a feel for how components connect. The better your understanding of the pieces and their relationships, the less time you'll have to spend backtracking and redeploying to correct your mistakes. Experimenting on your own from scratch is very time-consuming. I also recommend a high-powered development machine -- or better yet, a separate machine for the server and another for the development station.
Having built a trivial application, I see the power of this system. It took me much more than an afternoon to put things together correctly the first time, but reproducing my results even on a new project will be easier. Except for the initial system configuration and deploying the web service, the only difficult or time-consuming steps of the process were those for which the available documentation is skimpy or absent.
My next task is to bundle the application for deployment and distribution. That's the subject of my next article.
chromatic promotes free and open source software for O'Reilly's Open Technology Exchange.
As I mentioned in Does Enterprise Development Have to be Painful, Part One, I've been exploring the world of enterprise software development with SAP NetWeaver Composition Environment (after this, SAP NetWeaver CE), as part of a challenge from SAP Labs to see how much I could accomplish with minimal training and direction (though with the offer of assistance from one or two of their consultants if I managed to get myself completely stuck).
I decided that my best approach would be to build a simple, self-contained application with their system, writing as little code as possible and using as many of their tools as I could. I settled for a tiny task tracking application, in which a task has a due date, a description, and an associated category. The entire application consists of two models, their business logic, and a user interface. SAP NetWeaver CE provides plenty of tools to build, manage, and deploy these types of business objects and their relationships, so I thought this would be a good basic experiment. This is a standard CRUD-style application, where the code needs to Create, Read, Update, and possibly Delete data.
Is it too basic? Perhaps; if this were the only type of application I ever built, SAP's tools are definitely overkill. I don't need clustering or monitoring or failsafe deployment and rollback to keep track of what I need to do in a day. However, it was the minimal application I could imagine that exercised most of the parts of the system that a real application would actually use. In building and deploying the task tracker, I performed the work that a real team would perform when building and deploying a much larger application. I just didn't have to invest several months to design and build such an application. My design took me a day, and I figured that building the application myself should take a couple of ideal calendar days.
What's in SAP NetWeaver CE
SAP NetWeaver CE has two main parts. The first is a server component that represents the large database, cluster, services registry, user management, and central configuration of an enterprise-wide installation. For the most part, I ignored it except to make sure it was running and to perform a few configurations. The second part of the system is an IDE built on Eclipse. If you're at home in Eclipse or another IDE and don't mind performing some visual modeling instead of writing heaps of code yourself, you will find the IDE very comfortable.
This modeling was simple. Although I like opening a text editor and writing some declarative code to tell an object-relational mapper the structure of my database (or to make that tool generate my schema for me), the model design tool in the IDE was easy to use. I didn't have to think about creating tables or choosing column types or optimizing data for JOIN operations. If the abstraction holds through my application's lifecycle, I won't have to worry about versioning or migrating data between schema changes.
Declaring my Task and Category models was as easy as creating new business objects and selecting from menus of available attribute types. Although mousing around was probably slower than typing the corresponding short declarations in a text editor, there's enough metadata slinging happening behind the scenes that I didn't perceive any mild inefficiencies in the UI; it was doing enough of the other work for me.
This was the easy part of the process, and with the help of one of the built-in tutorials, I had two models built and associated very quickly.
Modeling Business Objects
The word model should make you think that these models contain business logic. They do. However, this is where I first ran into trouble. Models have operations -- business logic -- and the IDE gives you an easy way to declare them. For example, I wanted an operation which returned a list of all open tasks and another operation that returned a list of all tasks for a given date. You can create an operation which filters the entire collection of model items on a particular attribute, but apart from creating some metadata (I assume hidden somewhere) and adding a method stub to the generated Java Bean for your model, nothing else happens. You have to write code that uses the appropriate SAP Java APIs to perform this filtering. The help system has some information on how to write query filters, though it is unclear. (Likewise, the tutorial example provided is missing code and writes to a deprecated API.)
As with the basic model structure, you model operations in the IDE, selecting the input and output types (both provided by the Composite Application Framework and modeled explicitly on your own) as well as any exceptions that the operation might throw. The IDE generates methods on your model beans for you, but only signatures and empty implementations that return null. It's up to you to implement the rest of the code. One of my initial experiments was to create an operation that returned a collection of all of the open tasks by filtering out all tasks with an open status. I originally modeled it believing that taking the status type as an input parameter was the right approach, but it appears that creating a non-parameterized filter in the body of the method is correct.
Producing a UI
I set aside the notion of finding the most correct and purest design in favor of getting the back-end model to communicate with a front-end UI, specifically through the use of Visual Composer. Visual Composer is a UI-builder with intelligent widgets configurable almost entirely through a drag-and-drop interface built with SVG and other web technologies. There's no code required. Visual Composer can consume web services if you have them deployed properly, which means you need to produce a valid WSDL file and publish it somewhere that Visual Composer can access it.
I had trouble with this step. There are several different ways to expose business models as web services. Their context menus available from the project navigator give you the option of exposing them directly. You can also model services with their own operations apart from your business models. I assumed that providing an application service would be the proper approach; however, all of the tutorials and documentation I saw described the very configuration of application services and again gave very little information about what the body of the generated methods should contain. I'm comfortable writing business logic, but I didn't find a good reference to the types of operations most often found within these methods, nor the preferred and current APIs provided for performing this logic.
Although the generated business models all have CRUD methods provided to create, read, update, and delete business model instances, the generated application service has no operations by default. I didn't see an easy way to link in the operations of the business models. Presumably it is possible to expose those operations directly, or to wrap them in the application service. I can understand the organizational principle of modeling business objects and providing different API bundles for different types of applications, but the enforced striation seemed excessive for my very simple purposes. (In larger projects, it's likely very important.)
I decided to expose the Task models operations directly as a web service. Configuring and registering this web service with my SAP server for Visual Composer's consumption was the most complex part of this process. My contact, Armand, walked me through testing the web service from the IDE (which launches a web service browser), configuring the web service both inside the IDE and deploying the service to the SAP NetWeaver server, and creating a destination for the web service in the SAP NetWeaver Administrator. At that point, we restarted Visual Composer, and I was able to see my web service as a data component within Visual Composer. Since that point, I've learned that you can right-click on the services search widget within Visual Composer to refresh the services cache without restarting the system.
After all of that, building a UI with Visual Composer was simple. Visual Composer presents a few menus of widgets, including buttons, table lists, and input boxes. Because WSDL includes remote calls and argument types, you can easily connect a UI widget with the proper parameters such that input and output displays properly. You can consume several web services in a single form; one view of the UI shows logical relationships and data flow between widgets and services and the other is a layout view, which allows you to rearrange the actual view of the UI.
Yet More Than One Afternoon
With everything working together, I had finally achieved my write-test-debug cycle. Even though my actual code is minimal, my web services are small, and my operations are few, the cycle is not fast. My under-powered laptop running the SAP server, the IDE, and Visual Composer takes several minutes to generate, build, and deploy a new version of my web service to the J2EE server, and Visual Composer takes a few minutes to start. The effective cycle of experimentation is by no means instantaneous or cheap. If you're interested in performing similar experiments, I cannot recommend more highly browsing through an existing non-trivial application to get a feel for how components connect. The better your understanding of the pieces and their relationships, the less time you'll have to spend backtracking and redeploying to correct your mistakes. Experimenting on your own from scratch is very time-consuming. I also recommend a high-powered development machine -- or better yet, a separate machine for the server and another for the development station.
Having built a trivial application, I see the power of this system. It took me much more than an afternoon to put things together correctly the first time, but reproducing my results even on a new project will be easier. Except for the initial system configuration and deploying the web service, the only difficult or time-consuming steps of the process were those for which the available documentation is skimpy or absent.
My next task is to bundle the application for deployment and distribution. That's the subject of my next article.
chromatic promotes free and open source software for O'Reilly's Open Technology Exchange.
Does Java Run Faster On .NET VM and Windows Azure?
There's an interesting thread taking place over on the IKVM.NET mailing list. It starts with a post from Alberto Diez:
Dear all,
I have tried the IKVM tool with the Java library weka.jar; I have generatedthe corresponding weka.dll and I have tried out some algorithms under .NETframework (C#, Visual Studio 2005) with really surprising results: it worksbetter (it builds models faster and with less-consuming memory) than underJava (Eclipse framework and directly under command prompt, with the jdk-jre1.6.03 installed)!
I wonder if this is normal or I am doing something wrong...
Thanks in advance.
Kind regards,Alberto.
Dr. Michael Kay then follows-up with:
Sounds good to me!
For Saxon I generally reckon the .NET code is slower than the native Javaequivalent by a factor of 1.2 to 1.5 - but that's on a fairly limitedsample. The .NET code has much faster warm-up time, so it's faster overallfor small jobs.
Michael Kayhttp://www.saxonica.com/
Interesting, though not really all that surprising. Given the fact that:
Java is now open source
The IKVM.NET library is built on top of that source
The Java libraries are compiled to CIL just like any other .NET library
You've got a world class developer in Jeroen Frijters finding every possible way to tweak as much performance into the IKVM.NET VM and compiler
The .NET platform performs better under various circumstances and scenarios
... why wouldn't Java code run faster on the .NET platform, at least under these same circumstances and scenarios?
Oh, and BTW: Interested in running your Java code on Windows Azure? That's now possible too. :-)
Dear all,
I have tried the IKVM tool with the Java library weka.jar; I have generatedthe corresponding weka.dll and I have tried out some algorithms under .NETframework (C#, Visual Studio 2005) with really surprising results: it worksbetter (it builds models faster and with less-consuming memory) than underJava (Eclipse framework and directly under command prompt, with the jdk-jre1.6.03 installed)!
I wonder if this is normal or I am doing something wrong...
Thanks in advance.
Kind regards,Alberto.
Dr. Michael Kay then follows-up with:
Sounds good to me!
For Saxon I generally reckon the .NET code is slower than the native Javaequivalent by a factor of 1.2 to 1.5 - but that's on a fairly limitedsample. The .NET code has much faster warm-up time, so it's faster overallfor small jobs.
Michael Kayhttp://www.saxonica.com/
Interesting, though not really all that surprising. Given the fact that:
Java is now open source
The IKVM.NET library is built on top of that source
The Java libraries are compiled to CIL just like any other .NET library
You've got a world class developer in Jeroen Frijters finding every possible way to tweak as much performance into the IKVM.NET VM and compiler
The .NET platform performs better under various circumstances and scenarios
... why wouldn't Java code run faster on the .NET platform, at least under these same circumstances and scenarios?
Oh, and BTW: Interested in running your Java code on Windows Azure? That's now possible too. :-)
A Conversation with the Authors of JRuby Cookbook
Henry Liu and Justin Edelson wrote the just released JRuby Cookbook which is available from O'Reilly in both Print and Electronic formats. I spoke with both Henry and Justin about the book, JRuby, and the current state of the Java platform. Here's the transcript of our interview.
Interview Transcript
Tim O'Brien: Let's just dive in. You wrote the JRuby Cookbook - the two of you wrote this book. Could you talk to me a little bit about what's in the book and who you think should buy it?
Justin Edelson: So I'll start. The book really covers a variety of facets of using JRuby. I think it was important to us that this not just be a "JRuby on Rails" book. Ola's book is really good and covers that subject in a fair bit of depth, so we wanted to cover - we certainly talk about rails, but we wanted to look at the whole JRuby ecosystem and the various things that you can do with it. So those range from just using JRuby as a scripting language inside a Java application - there's a whole chapter about GUI applications.
We talk about build/deployment/testing, that sort of stuff, as well as obviously covering Rails, which you couldn't write a Ruby book and not touch on Rails. So we really try to cover a wide gamut of different application types.
Henry Liu: Yeah, and just to add something, I think that the general philosophy or the idea behind the book is sort of taking the practices that happen in the Ruby community, like continuous integration and sort of exploring that intersection with a lot of the common Java practices and a lot of the common Java software. I think that's where you're trying - I think that was the sort of voice they we trying to project out of the book. At least that was what I was trying to project.
Tim O'Brien: So it's more than just JRuby on Rails book. It talks about how to use JRuby inside of a Java application that already exists?
Justin Edelson: Yeah. I think we touch on a few different ways of doing that from using just the JRuby interpreter directly. We talk a little bit about the enscripting framework as well as the newer Javax scripting package to really do language-level integration. And then we have a number of recipes that are focused around using JRuby to define beans in a Spring container, which is a really nice way of making other parts of your application use JRuby, but they don't necessarily need to know they're interacting with JRuby. So using Spring is sort of a mediator there.
Tim O'Brien: I was talking to the Spring Source CEO, Rod Johnson, although I'm not sure if it was the CEO or not. He's definitely one of the primary forces behind the company, and we were talking about Groovy and Gr ails and Spring, and he said that there was less of an impedance mismatch between Groovy and Java, and that there was something of an impedance mismatch between JRuby and Java. Could you talk about that?
Justin Edelson: Well, I'm not sure exactly what he means. I'll say that I think Henry and I both found that the lack of annotation support in JRuby led to a few problems, and so I could definitely see that if - because so much of what Spring has been doing in the 2.0, especially in the 2.5 release, has been annotation-driven, I could see that being an area of mismatch, whereas Groovy as of 1.5 has support for annotations. But on the whole I'm not quite sure what he's referring to.
Justin Edelson: So there's nothing preventing you - from JRuby you have access to the whole of any API in Java, and so there's no real conceptual reason why you can't just "new" up a Spring application context that actually you could have it be a JRuby initializing a Spring application context in which all of the beans are defined in Groovy. That's certainly possible, although we don't go into detail on that in the book.
Henry Liu: I think it actually gets more interesting though when you look at some of the sort of flip side is when you have a Spring container, you're in Spring, and then you can use Ruby to define your controllers. I think that's sort of the angle that we really explore in the book, and that's really where we see the benefit because you get that benefit of not having the benefit of descriptive language, where you don't have to compile things. You can just deploy the scripts up into your production environment and it'll just pick them up right on the fly.
So that's sort of - we sort of look at that aspect of the problem more and not really the given a Ruby application using like an inversion of control container like Spring in your applications.
Tim O'Brien:So if I were working on a Spring-MVC front end for a (Audio Glitch) application I could write one of my controllers in Ruby, and I could (Audio Glitch) right. What is involved there? One of the things that I have always thought is the reason why people don't get into JRuby is what has to be on a class path? Is it just a Jar file for JRuby? Okay, how do I gain access to say something like a gem? Could you talk about that, just the basic process of integrating JRuby and all of the things that come with Ruby into a JVM.
Justin Edelson: Yeah, so from a base standpoint you really just need the JRuby JAR, and this is an area where I think Maven becomes very helpful as a build tool in that you can just add a dependency to JRuby and it's on your class path bundled in your WAR or whatever the deployable unit is. From a gem perspective the primary way of integrating that is you basically set some system properties that let the JRuby runtime know where the gem path is, and we talk a lot in the book about different gem manipulation or management techniques, I should say. There's one use case where if you're using both CRuby and JRuby you might wanna point them to the same gem path.
In another context maybe you want those to be totally separate, and through just manipulation of the command line you can say install these gems to a shared location or to a sort of private location. And then when you run your Spring application in this case you would just make sure that you're setting the JRuby home environment variable correctly to point to your gem install location. And for pure Ruby gems that don't have any need of code, the same gem works in either environment. Obviously native code is a different story.
Tim O'Brien: What is the general sense in terms of gems? So if you look at something like Ferret - is Ferret all Ruby or does Ferret have some C components to it?
Henry Liu: Ferret? That's the search engine, the Ruby search engine.
Tim O'Brien: Yeah.
Henry Liu: I think it actually does have C bindings to it, last time I - at least when you - yes, go ahead.
Tim O'Brien: So how do you find a way around that? I mean, is it just the case that there are certain gems that you just aren't gonna be using from JRuby, and if so, what's the percentage?
Henry Liu: So basically, yeah. If you have gems that have native parts to it that'll compile in C then you have a couple options. The most common gems, like for example RMagick or Hpricot or even Mongrel, they all have JRuby implementations of it, so the parts that are done in native code have been implemented in Java. So you can install this alternative version of the gem when you're in a JRuby environment. The other option obviously is to just do your own porting. You can dig down in and sort of go through the same task. But yeah, those are probably the few main approaches that you'd take if you had a gem that - and in terms of percentage, I can't quantify that.
I have no idea. But the most popular gems at least have been moved across and/or are in the process of being moved across.
Justin Edelson: And there are also a couple of examples where - you know, Henry mentioned some of the image manipulation stuff where I think it's primarily the JRuby team or other volunteers have created API-compatible versions of those gems that instead of using a native layer use a Java layer. And especially I think we found that to be the case around image manipulation, but there's a lot of stuff now in the JRE to handle image manipulation. So all the team has done is really write a wrapper around that that emulates the image science Ruby gem API for example.
Tim O'Brien: For the record, I'd just like to say that installing RMagick in CRuby is something of a pain in the neck, so would you say that it's more or less easy to use the JRuby version?
Justin Edelson: I think there are some font issues that sort of get in the way of doing a -
Henry Liu: Yeah, I think in general it's easier because obviously you don't have to install the RMagick, which depending on your platform can be difficult. But I think the one problem right now is that they have a lot of the library, and every time they release it they have more compatibility with the C version of RMagick, but it's still lacking a little bit in terms of complete compatibility. So I'm sure that there are a lot of fringe cases out there where there may not be 100 percent compatibility. But it's definitely improving, and with every version it gets closer and closer. And it's something I think they're obviously working on.
Tim O'Brien: One of the old JRuby blog posts I think was by Ola Bini, and he talked about how you could use JRuby to sort of launch up the JConsole, and you had more transparency as to what was going on in your application. Could you talk to me about some of the things that are possible in a JRuby app that are not possible in a plain old Ruby app?
Justin Edelson: I think the stuff that Ola's talking about there in monitoring and manageability is really key. JMX in the Java space is pretty well established and there's a solid maturity of the ecosystem; things like Hyperic or even just JConsole and Visual VM, which are now included in the JRE, and the ability to expose arbitrary parts of your application for management is a really nice thing that the Java platform just provides now. I know in the work that Henry and I do there's historically we've done a lot of monitoring at the system level - free memory, thread use, things like that. And being able to bring monitoring up the application stack and say how's this cache doing, how many times are people ordering something?
And then using off-the-shelf tools that know how to speak JMX to graph that is a big win, and something that I think the CRuby community is a little lagging behind the Java community, just because Java has been sort of enterprise focused.
Henry Liu: I just wanted to add one more point about the differences. I'm not an expert in this field, and I haven't really tracked the newest developments, but a lot of people sort of look to the threading support, and that's one main difference. Right now with Java you have the VM has evolved so far in ten plus years or even more in its life, and you have support for running on multiple cores, and you have the threading model is just a little bit better implemented and a little bit more robust. You have real preemptive multithreading as opposed to a lot of the earlier Ruby implementations. I think, I'm not sure, with 1.9 there may be better support, but I don't know for sure.
Tim O'Brien: Question about the Ruby community - the Ruby community - oh, I should be more specific. The Rails community was sort of founded with this ethos of anti-Java bigotry. Now, that might be an unfair word to use. Let's just say they had strong feelings against the Java language specifically. How has that changed? Has it changed? Can you talk about some of the places where the communities don't see eye-to-eye and some of the places where they do?
Henry Liu: I guess when I used to go to the early NYC Ruby meetings, yeah, it was definitely a really interesting crowd, because you had this one side of people in the room who were hard-core Ruby people and never wanted to know Java or learn it ever. And then you had people like myself who had years and years of Java experience, dying to learn some new technology. And I think it's always been kind of an awkward match to not necessarily a perfect kind of marriage in any way, but I don't know. I think JRuby is sort of that attempt to bridge that gap a little bit and try to have these kind of groups see eye-to-eye a little bit, but I can't honestly say that I see that much.
There isn't like this Kum Ba Yah moment where people are just holding hands and coming together. I think that the Ruby people still tend to look for their solutions using the Ruby technology and writing their technologies in the Ruby code; using Java when absolutely necessary, but generally still looking toward Ruby-oriented solutions. I don't know exactly how many Java developers are crossing over to Ruby, but probably more and more hopefully with the book.
Tim O'Brien: Do you want to comment on this, Justin?
Justin Edelson: I think what JRuby does is it actually broadens the playing field a little bit for Ruby in that as Henry said, especially around Rails. The audience for that has been people who frankly in a lot of cases were just burnt out on Java, and what JRuby has allowed is to bring more Java people into Ruby and create more deployment opportunities. To me that's really the biggest area which JRuby brings to the Ruby language is more deployment opportunities, especially within the enterprise where things like JBoss or BA are well-established technologies.
And we really aren't - systems people aren't particularly interested in running Mongrel or other Rails-oriented containers - or Ruby-oriented containers, I should say. And JRuby really allows the broadening of that playing field for them.
Tim O'Brien: So one thing I just have to ask you is both of you are Java programmers. You would call yourselves Java programmers, I guess, if I forced you to choose a language?
Henry Liu: Yeah, I would have to say that. I mean, I do a lot of Ruby development but I think in terms of the mindset, yeah, I'm definitely more of a Java developer.
Tim O'Brien: And Justin?
Justin Edelson: I disagree with the question a little bit. I think we're not - well, in all seriousness, I don't think that we're language - I don't think of myself and I frankly don't think of Henry as a particularly language-oriented developer. I think we're software developers, systems architects, at the core, and we're really interested in finding the right tools for the job. There are certainly people who are Java developers, and when all you have is a hammer everything looks like a nail. But I think especially in this environment you need to be really picky about which tools you use for which job, and find solutions to problems.
And I think that's what I've tried to do, and in working with Henry that's what I can see that he's tried to do. So I would disagree a little bit with the characterization that we have to be one or the other. I spend I feel most of my time in the build and deployment world now, but that's not how I would define myself.
Tim O'Brien: Well, if that were a trick question I think Justin just got an A+. But the reason I ask is because it seems like Java has been having an identity crisis for years and years and years, the platform. Some could argue that it's healthier than ever; some could argue that it's on its last legs. But it's clear that Sun has had a problem devoting resources to it, or at least if you look at something like JavaFX, there have been a series of failed efforts to sort of inject more energy into the platform. Could you talk to me a little bit about whether or not your interest in Ruby is something that is a reaction to that, or is it something that you think would've arose naturally despite what's happened to the platform?
Justin Edelson: It's a little hard to say. I think especially what's happened with Rails has been a recognition that the way that we have been doing development - divorce it from any particular language. But the way that we've been doing development needs to be shooken up a little bit, and that to me is what Rails ultimately did because at the core of Rails all of the MVC stuff is nothing particularly new. The big thing at least that I took away from working with Rails is the fast turnaround development, and that's what - looking at that you said, "Wow, I really understand how this changes the game." The controllers and all that sort of stuff, that's nothing new - it's the process changes. So I think Sun is in a position where they need to try to make the language and the platform more agile and more easily adaptable to change.
Tim O'Brien: Do you think that they're succeeding in doing that?
Justin Edelson: Well, they employ Nutter. I know Henry - and maybe Henry can speak more to this - was really impressed with NetBeans. Not a thing - I have not used NetBeans a lot; historically I'm an Eclipse person, and that I will characterize myself as an Eclipse person there. But I think they are making some strides in that direction. I don't really understand JavaFX - I'm not sure where it fits in. I understand the language; I'm not clear what the strategy is behind that, but they're trying.
Henry Liu: Yeah, and like Justin mentioned, I think that they're doing - I think it's sort of they got a couple hits, but they also have some misses or some half-assed work, I guess. The NetBeans I think is one of the definite better areas. The idea is really good. The feature set is comparable in a lot of ways to Eclipse and to the other popular IDEs. Actually in some things they do better in terms of completion of Ruby code, especially for JRuby developers. JavaFX - I don't know. I worked on a lot of the GUI chapter so I looked at JavaFX a lot and thought about it in comparison to a lot of the technologies that we talk about in the book.
My take-away was that what I thought was interesting was the scripting language itself, ultimately; the JavaFX language that you use to sort of create all the logic and define all the actual components. I just thought compared to Ruby or to JRuby at the end of the day it was just second-rate, and if that's really all that the technology is bringing to the table, this sort of scripting language, I think a lot of the ideal alternative techniques that we talk about in the book are much better. I mean, the only issue is a lot of it is tied into Swing, or a lot of the examples we talk about Swing, but there are also newer GUI technologies that are emerging that are using their own drawing toolkits.
And accessing them through JRuby can be as good as any JavaFX stack, in my opinion - not that I have done that much development, but just what I've looked at and a lot of the examples that I've looked at, it seemed to me that you could do as much or more over in the JRuby plus a toolkit world.
Justin Edelson: The other big win I should mention is GlassFish, which I think especially in the v3, Sun and the GlassFish team have really taken the bloated nature of the J2EE container, the Java EE container and taken that into account and tried to redefine it, which is why you see things like the GlassFish gem, which will allow you to run a Rails application in GlassFish using basically an identical mechanism to the way you would run it with WEBrick or Mongrel. And I know that the Grails team has actually done something similar recently where they're starting to use GlassFish in lieu of Jetty as a low-impact servlet container.
Tim O'Brien: I saw an exchange on Twitter between Tim Bray and someone who works for G21 yesterday. I think Tim Bray was asking, "Why did you switch to GlassFish from Jetty?" I didn't hear what the answer is. It seems to be bucking a trend, though. It seems like a lot of people have embraced Jetty over something like Tomcat. Is it just that they need more of the J2EE features?
Justin Edelson: I can't speak for everyone, but I can say that my perception is that Jetty is used much more in development than in production. And so that may be part of it is that you desire a development environment that's as close as possible to your production environment. So using something like JBoss or even Tomcat, which is obviously lower impact than say JBoss or BEA in development, if you're going for a rapid turnaround, quick reload of the container, doesn't quite work as well. Whereas I think the Maven Jetty plug-in has done a great job of really speeding up Java development.
So I would assume that that's part of it, is that more Grails applications or more JRuby applications are going to be deployed on GlassFish than they would on Jetty.
Tim O'Brien: How did the two of you meet - how did you start working on the book?
Justin Edelson: I've known Henry for I think five years now?
Henry Liu: Something like that, yeah; time goes by fast.
Justin Edelson: Exactly. We worked together at MTV Networks, where we both still work, and I'd come in as a software developer and met Henry pretty quickly, and we just worked on and off together over that span of time.
Henry Liu: Yeah, and I don't think that we've - sorry, go ahead.
Justin Edelson: Well, I was just gonna say that I was thinking about an anecdote, and I'll say that the first thing I can really remember talking to Henry about was telling him that the author of the Lemony Snicket books was a member of the Magnetic Fields, and Henry was unaware of that.
Tim O'Brien: I didn't know that either.
Justin Edelson: That's the first thing that I - I think he isn't actually a full member, but sort of a mostly member. I'm not -
Tim O'Brien: And that was sort of a key pivotal moment that was sort of like a -
Henry Liu: Eureka!
Henry Liu: No, I don't know. I think that we've just always worked closely, but not ever directly on the same project, I guess. But I don't know. Our technology department's pretty small and we work pretty closely together, so I've always been aware of Justin and I've always respected everything that he's ever - you know, if I've heard him speak about something he always sounded very intelligent, so I didn't think twice about working with him. And I did over the years I've kind of peeked through some of his code, and I saw that his philosophy of design and architecture was very consistent with things that I would work on.
I kind of knew based on what I'd seen in the past that we'd be a good fit for trying something like this.
Tim O'Brien: How did you write the book? Was it in DocBook? Was it in the Wiki?
Justin Edelson: We did it in Word, which I'm not sure I will do again.
Tim O'Brien: And who was the editor - was it Mike Loukides?
Justin Edelson: Yeah.
Tim O'Brien: And how is he to work with?
Justin Edelson: I like Mike a lot; it worked really well. Mike is a great guy to work with from my perspective on a technology book because he actually knows the technology. So he was always willing to push us to say what about this, what about that? I can see from a developer's perspective why this is important or why this isn't. So he had some really valuable feedback.
Tim O'Brien: Is this a Java book or is this a Ruby book?
Justin Edelson: That's the million-dollar question.
Henry Liu: I think it goes back to what I was saying - I think it's a little - I don't know. I think we're trying to be a little bit of both but trying to be its own thing. I think it's useful for both. It's the obvious answer, but I think that Ruby developers who want to learn how to leverage some Java technology to make their jobs easier, I think they can take a lot away from it. And I think that obviously Java developers who want to look at what's going on in the Ruby world and learn some of the agile practices that are happening there and learn some new ways of using their old technology, I think that they'll find that really valuable too.
Justin Edelson: Yeah, I think - and this may not be a popular statement - but I actually think at the end of the day the two languages as languages - they're not that different. And so my perspective is that somebody who's a Ruby developer is gonna get the Java parts. Somebody who's a Java developer is gonna get the Ruby parts pretty easily.
Interview Transcript
Tim O'Brien: Let's just dive in. You wrote the JRuby Cookbook - the two of you wrote this book. Could you talk to me a little bit about what's in the book and who you think should buy it?
Justin Edelson: So I'll start. The book really covers a variety of facets of using JRuby. I think it was important to us that this not just be a "JRuby on Rails" book. Ola's book is really good and covers that subject in a fair bit of depth, so we wanted to cover - we certainly talk about rails, but we wanted to look at the whole JRuby ecosystem and the various things that you can do with it. So those range from just using JRuby as a scripting language inside a Java application - there's a whole chapter about GUI applications.
We talk about build/deployment/testing, that sort of stuff, as well as obviously covering Rails, which you couldn't write a Ruby book and not touch on Rails. So we really try to cover a wide gamut of different application types.
Henry Liu: Yeah, and just to add something, I think that the general philosophy or the idea behind the book is sort of taking the practices that happen in the Ruby community, like continuous integration and sort of exploring that intersection with a lot of the common Java practices and a lot of the common Java software. I think that's where you're trying - I think that was the sort of voice they we trying to project out of the book. At least that was what I was trying to project.
Tim O'Brien: So it's more than just JRuby on Rails book. It talks about how to use JRuby inside of a Java application that already exists?
Justin Edelson: Yeah. I think we touch on a few different ways of doing that from using just the JRuby interpreter directly. We talk a little bit about the enscripting framework as well as the newer Javax scripting package to really do language-level integration. And then we have a number of recipes that are focused around using JRuby to define beans in a Spring container, which is a really nice way of making other parts of your application use JRuby, but they don't necessarily need to know they're interacting with JRuby. So using Spring is sort of a mediator there.
Tim O'Brien: I was talking to the Spring Source CEO, Rod Johnson, although I'm not sure if it was the CEO or not. He's definitely one of the primary forces behind the company, and we were talking about Groovy and Gr ails and Spring, and he said that there was less of an impedance mismatch between Groovy and Java, and that there was something of an impedance mismatch between JRuby and Java. Could you talk about that?
Justin Edelson: Well, I'm not sure exactly what he means. I'll say that I think Henry and I both found that the lack of annotation support in JRuby led to a few problems, and so I could definitely see that if - because so much of what Spring has been doing in the 2.0, especially in the 2.5 release, has been annotation-driven, I could see that being an area of mismatch, whereas Groovy as of 1.5 has support for annotations. But on the whole I'm not quite sure what he's referring to.
Justin Edelson: So there's nothing preventing you - from JRuby you have access to the whole of any API in Java, and so there's no real conceptual reason why you can't just "new" up a Spring application context that actually you could have it be a JRuby initializing a Spring application context in which all of the beans are defined in Groovy. That's certainly possible, although we don't go into detail on that in the book.
Henry Liu: I think it actually gets more interesting though when you look at some of the sort of flip side is when you have a Spring container, you're in Spring, and then you can use Ruby to define your controllers. I think that's sort of the angle that we really explore in the book, and that's really where we see the benefit because you get that benefit of not having the benefit of descriptive language, where you don't have to compile things. You can just deploy the scripts up into your production environment and it'll just pick them up right on the fly.
So that's sort of - we sort of look at that aspect of the problem more and not really the given a Ruby application using like an inversion of control container like Spring in your applications.
Tim O'Brien:So if I were working on a Spring-MVC front end for a (Audio Glitch) application I could write one of my controllers in Ruby, and I could (Audio Glitch) right. What is involved there? One of the things that I have always thought is the reason why people don't get into JRuby is what has to be on a class path? Is it just a Jar file for JRuby? Okay, how do I gain access to say something like a gem? Could you talk about that, just the basic process of integrating JRuby and all of the things that come with Ruby into a JVM.
Justin Edelson: Yeah, so from a base standpoint you really just need the JRuby JAR, and this is an area where I think Maven becomes very helpful as a build tool in that you can just add a dependency to JRuby and it's on your class path bundled in your WAR or whatever the deployable unit is. From a gem perspective the primary way of integrating that is you basically set some system properties that let the JRuby runtime know where the gem path is, and we talk a lot in the book about different gem manipulation or management techniques, I should say. There's one use case where if you're using both CRuby and JRuby you might wanna point them to the same gem path.
In another context maybe you want those to be totally separate, and through just manipulation of the command line you can say install these gems to a shared location or to a sort of private location. And then when you run your Spring application in this case you would just make sure that you're setting the JRuby home environment variable correctly to point to your gem install location. And for pure Ruby gems that don't have any need of code, the same gem works in either environment. Obviously native code is a different story.
Tim O'Brien: What is the general sense in terms of gems? So if you look at something like Ferret - is Ferret all Ruby or does Ferret have some C components to it?
Henry Liu: Ferret? That's the search engine, the Ruby search engine.
Tim O'Brien: Yeah.
Henry Liu: I think it actually does have C bindings to it, last time I - at least when you - yes, go ahead.
Tim O'Brien: So how do you find a way around that? I mean, is it just the case that there are certain gems that you just aren't gonna be using from JRuby, and if so, what's the percentage?
Henry Liu: So basically, yeah. If you have gems that have native parts to it that'll compile in C then you have a couple options. The most common gems, like for example RMagick or Hpricot or even Mongrel, they all have JRuby implementations of it, so the parts that are done in native code have been implemented in Java. So you can install this alternative version of the gem when you're in a JRuby environment. The other option obviously is to just do your own porting. You can dig down in and sort of go through the same task. But yeah, those are probably the few main approaches that you'd take if you had a gem that - and in terms of percentage, I can't quantify that.
I have no idea. But the most popular gems at least have been moved across and/or are in the process of being moved across.
Justin Edelson: And there are also a couple of examples where - you know, Henry mentioned some of the image manipulation stuff where I think it's primarily the JRuby team or other volunteers have created API-compatible versions of those gems that instead of using a native layer use a Java layer. And especially I think we found that to be the case around image manipulation, but there's a lot of stuff now in the JRE to handle image manipulation. So all the team has done is really write a wrapper around that that emulates the image science Ruby gem API for example.
Tim O'Brien: For the record, I'd just like to say that installing RMagick in CRuby is something of a pain in the neck, so would you say that it's more or less easy to use the JRuby version?
Justin Edelson: I think there are some font issues that sort of get in the way of doing a -
Henry Liu: Yeah, I think in general it's easier because obviously you don't have to install the RMagick, which depending on your platform can be difficult. But I think the one problem right now is that they have a lot of the library, and every time they release it they have more compatibility with the C version of RMagick, but it's still lacking a little bit in terms of complete compatibility. So I'm sure that there are a lot of fringe cases out there where there may not be 100 percent compatibility. But it's definitely improving, and with every version it gets closer and closer. And it's something I think they're obviously working on.
Tim O'Brien: One of the old JRuby blog posts I think was by Ola Bini, and he talked about how you could use JRuby to sort of launch up the JConsole, and you had more transparency as to what was going on in your application. Could you talk to me about some of the things that are possible in a JRuby app that are not possible in a plain old Ruby app?
Justin Edelson: I think the stuff that Ola's talking about there in monitoring and manageability is really key. JMX in the Java space is pretty well established and there's a solid maturity of the ecosystem; things like Hyperic or even just JConsole and Visual VM, which are now included in the JRE, and the ability to expose arbitrary parts of your application for management is a really nice thing that the Java platform just provides now. I know in the work that Henry and I do there's historically we've done a lot of monitoring at the system level - free memory, thread use, things like that. And being able to bring monitoring up the application stack and say how's this cache doing, how many times are people ordering something?
And then using off-the-shelf tools that know how to speak JMX to graph that is a big win, and something that I think the CRuby community is a little lagging behind the Java community, just because Java has been sort of enterprise focused.
Henry Liu: I just wanted to add one more point about the differences. I'm not an expert in this field, and I haven't really tracked the newest developments, but a lot of people sort of look to the threading support, and that's one main difference. Right now with Java you have the VM has evolved so far in ten plus years or even more in its life, and you have support for running on multiple cores, and you have the threading model is just a little bit better implemented and a little bit more robust. You have real preemptive multithreading as opposed to a lot of the earlier Ruby implementations. I think, I'm not sure, with 1.9 there may be better support, but I don't know for sure.
Tim O'Brien: Question about the Ruby community - the Ruby community - oh, I should be more specific. The Rails community was sort of founded with this ethos of anti-Java bigotry. Now, that might be an unfair word to use. Let's just say they had strong feelings against the Java language specifically. How has that changed? Has it changed? Can you talk about some of the places where the communities don't see eye-to-eye and some of the places where they do?
Henry Liu: I guess when I used to go to the early NYC Ruby meetings, yeah, it was definitely a really interesting crowd, because you had this one side of people in the room who were hard-core Ruby people and never wanted to know Java or learn it ever. And then you had people like myself who had years and years of Java experience, dying to learn some new technology. And I think it's always been kind of an awkward match to not necessarily a perfect kind of marriage in any way, but I don't know. I think JRuby is sort of that attempt to bridge that gap a little bit and try to have these kind of groups see eye-to-eye a little bit, but I can't honestly say that I see that much.
There isn't like this Kum Ba Yah moment where people are just holding hands and coming together. I think that the Ruby people still tend to look for their solutions using the Ruby technology and writing their technologies in the Ruby code; using Java when absolutely necessary, but generally still looking toward Ruby-oriented solutions. I don't know exactly how many Java developers are crossing over to Ruby, but probably more and more hopefully with the book.
Tim O'Brien: Do you want to comment on this, Justin?
Justin Edelson: I think what JRuby does is it actually broadens the playing field a little bit for Ruby in that as Henry said, especially around Rails. The audience for that has been people who frankly in a lot of cases were just burnt out on Java, and what JRuby has allowed is to bring more Java people into Ruby and create more deployment opportunities. To me that's really the biggest area which JRuby brings to the Ruby language is more deployment opportunities, especially within the enterprise where things like JBoss or BA are well-established technologies.
And we really aren't - systems people aren't particularly interested in running Mongrel or other Rails-oriented containers - or Ruby-oriented containers, I should say. And JRuby really allows the broadening of that playing field for them.
Tim O'Brien: So one thing I just have to ask you is both of you are Java programmers. You would call yourselves Java programmers, I guess, if I forced you to choose a language?
Henry Liu: Yeah, I would have to say that. I mean, I do a lot of Ruby development but I think in terms of the mindset, yeah, I'm definitely more of a Java developer.
Tim O'Brien: And Justin?
Justin Edelson: I disagree with the question a little bit. I think we're not - well, in all seriousness, I don't think that we're language - I don't think of myself and I frankly don't think of Henry as a particularly language-oriented developer. I think we're software developers, systems architects, at the core, and we're really interested in finding the right tools for the job. There are certainly people who are Java developers, and when all you have is a hammer everything looks like a nail. But I think especially in this environment you need to be really picky about which tools you use for which job, and find solutions to problems.
And I think that's what I've tried to do, and in working with Henry that's what I can see that he's tried to do. So I would disagree a little bit with the characterization that we have to be one or the other. I spend I feel most of my time in the build and deployment world now, but that's not how I would define myself.
Tim O'Brien: Well, if that were a trick question I think Justin just got an A+. But the reason I ask is because it seems like Java has been having an identity crisis for years and years and years, the platform. Some could argue that it's healthier than ever; some could argue that it's on its last legs. But it's clear that Sun has had a problem devoting resources to it, or at least if you look at something like JavaFX, there have been a series of failed efforts to sort of inject more energy into the platform. Could you talk to me a little bit about whether or not your interest in Ruby is something that is a reaction to that, or is it something that you think would've arose naturally despite what's happened to the platform?
Justin Edelson: It's a little hard to say. I think especially what's happened with Rails has been a recognition that the way that we have been doing development - divorce it from any particular language. But the way that we've been doing development needs to be shooken up a little bit, and that to me is what Rails ultimately did because at the core of Rails all of the MVC stuff is nothing particularly new. The big thing at least that I took away from working with Rails is the fast turnaround development, and that's what - looking at that you said, "Wow, I really understand how this changes the game." The controllers and all that sort of stuff, that's nothing new - it's the process changes. So I think Sun is in a position where they need to try to make the language and the platform more agile and more easily adaptable to change.
Tim O'Brien: Do you think that they're succeeding in doing that?
Justin Edelson: Well, they employ Nutter. I know Henry - and maybe Henry can speak more to this - was really impressed with NetBeans. Not a thing - I have not used NetBeans a lot; historically I'm an Eclipse person, and that I will characterize myself as an Eclipse person there. But I think they are making some strides in that direction. I don't really understand JavaFX - I'm not sure where it fits in. I understand the language; I'm not clear what the strategy is behind that, but they're trying.
Henry Liu: Yeah, and like Justin mentioned, I think that they're doing - I think it's sort of they got a couple hits, but they also have some misses or some half-assed work, I guess. The NetBeans I think is one of the definite better areas. The idea is really good. The feature set is comparable in a lot of ways to Eclipse and to the other popular IDEs. Actually in some things they do better in terms of completion of Ruby code, especially for JRuby developers. JavaFX - I don't know. I worked on a lot of the GUI chapter so I looked at JavaFX a lot and thought about it in comparison to a lot of the technologies that we talk about in the book.
My take-away was that what I thought was interesting was the scripting language itself, ultimately; the JavaFX language that you use to sort of create all the logic and define all the actual components. I just thought compared to Ruby or to JRuby at the end of the day it was just second-rate, and if that's really all that the technology is bringing to the table, this sort of scripting language, I think a lot of the ideal alternative techniques that we talk about in the book are much better. I mean, the only issue is a lot of it is tied into Swing, or a lot of the examples we talk about Swing, but there are also newer GUI technologies that are emerging that are using their own drawing toolkits.
And accessing them through JRuby can be as good as any JavaFX stack, in my opinion - not that I have done that much development, but just what I've looked at and a lot of the examples that I've looked at, it seemed to me that you could do as much or more over in the JRuby plus a toolkit world.
Justin Edelson: The other big win I should mention is GlassFish, which I think especially in the v3, Sun and the GlassFish team have really taken the bloated nature of the J2EE container, the Java EE container and taken that into account and tried to redefine it, which is why you see things like the GlassFish gem, which will allow you to run a Rails application in GlassFish using basically an identical mechanism to the way you would run it with WEBrick or Mongrel. And I know that the Grails team has actually done something similar recently where they're starting to use GlassFish in lieu of Jetty as a low-impact servlet container.
Tim O'Brien: I saw an exchange on Twitter between Tim Bray and someone who works for G21 yesterday. I think Tim Bray was asking, "Why did you switch to GlassFish from Jetty?" I didn't hear what the answer is. It seems to be bucking a trend, though. It seems like a lot of people have embraced Jetty over something like Tomcat. Is it just that they need more of the J2EE features?
Justin Edelson: I can't speak for everyone, but I can say that my perception is that Jetty is used much more in development than in production. And so that may be part of it is that you desire a development environment that's as close as possible to your production environment. So using something like JBoss or even Tomcat, which is obviously lower impact than say JBoss or BEA in development, if you're going for a rapid turnaround, quick reload of the container, doesn't quite work as well. Whereas I think the Maven Jetty plug-in has done a great job of really speeding up Java development.
So I would assume that that's part of it, is that more Grails applications or more JRuby applications are going to be deployed on GlassFish than they would on Jetty.
Tim O'Brien: How did the two of you meet - how did you start working on the book?
Justin Edelson: I've known Henry for I think five years now?
Henry Liu: Something like that, yeah; time goes by fast.
Justin Edelson: Exactly. We worked together at MTV Networks, where we both still work, and I'd come in as a software developer and met Henry pretty quickly, and we just worked on and off together over that span of time.
Henry Liu: Yeah, and I don't think that we've - sorry, go ahead.
Justin Edelson: Well, I was just gonna say that I was thinking about an anecdote, and I'll say that the first thing I can really remember talking to Henry about was telling him that the author of the Lemony Snicket books was a member of the Magnetic Fields, and Henry was unaware of that.
Tim O'Brien: I didn't know that either.
Justin Edelson: That's the first thing that I - I think he isn't actually a full member, but sort of a mostly member. I'm not -
Tim O'Brien: And that was sort of a key pivotal moment that was sort of like a -
Henry Liu: Eureka!
Henry Liu: No, I don't know. I think that we've just always worked closely, but not ever directly on the same project, I guess. But I don't know. Our technology department's pretty small and we work pretty closely together, so I've always been aware of Justin and I've always respected everything that he's ever - you know, if I've heard him speak about something he always sounded very intelligent, so I didn't think twice about working with him. And I did over the years I've kind of peeked through some of his code, and I saw that his philosophy of design and architecture was very consistent with things that I would work on.
I kind of knew based on what I'd seen in the past that we'd be a good fit for trying something like this.
Tim O'Brien: How did you write the book? Was it in DocBook? Was it in the Wiki?
Justin Edelson: We did it in Word, which I'm not sure I will do again.
Tim O'Brien: And who was the editor - was it Mike Loukides?
Justin Edelson: Yeah.
Tim O'Brien: And how is he to work with?
Justin Edelson: I like Mike a lot; it worked really well. Mike is a great guy to work with from my perspective on a technology book because he actually knows the technology. So he was always willing to push us to say what about this, what about that? I can see from a developer's perspective why this is important or why this isn't. So he had some really valuable feedback.
Tim O'Brien: Is this a Java book or is this a Ruby book?
Justin Edelson: That's the million-dollar question.
Henry Liu: I think it goes back to what I was saying - I think it's a little - I don't know. I think we're trying to be a little bit of both but trying to be its own thing. I think it's useful for both. It's the obvious answer, but I think that Ruby developers who want to learn how to leverage some Java technology to make their jobs easier, I think they can take a lot away from it. And I think that obviously Java developers who want to look at what's going on in the Ruby world and learn some of the agile practices that are happening there and learn some new ways of using their old technology, I think that they'll find that really valuable too.
Justin Edelson: Yeah, I think - and this may not be a popular statement - but I actually think at the end of the day the two languages as languages - they're not that different. And so my perspective is that somebody who's a Ruby developer is gonna get the Java parts. Somebody who's a Java developer is gonna get the Ruby parts pretty easily.
Sun's Layoffs, Anil Gadre, and What happens to Java now?
Sun is all about JAVA. While they might try to tell you that they have a diversified portfolio of strong products in the server market, you should also know that the server market evaporated along with the economy. Sun realizes this and has expanded the software division into three components. I'm most interested in the Application Platform Software division, which will oversee Java, MySQL, and Glassfish.
Sun announced massive layoffs today, and shuffled some executives around to new positions. Most relevant to the Java platform is the selection Anil Gadre to head the Application Platform Software division. Before serving as Chief Marketing Officer, Anil Gadre was general manager of the Solaris effort. Anil Gadre is also named as co-inventor on a Sun patent for the per-employee pricing model Sun uses for Java Enterprise support. Gadre is also largely responsible for repositioning Solaris to compete with Linux, most notably managing Solaris' transition from proprietary to open source.
Time to Refocus the Java Platform?
Sun has also announced that Rich Green is leaving the organization. This year's JavaOne was noticeably downbeat and Schwartz's mood at the blogger press conference was noticably glum as the conference happened to coincide with the announcement of layoffs. It is certainly no surprise that Green is leaving the organization, but one has the question why it didn't happen much sooner. Sun has hemorrhaged GUI experts to Adobe ever since it decided to start pushing JavaFX as the answer to everything interactive; I wonder if it is time for Sun Microsystems to disengage from the JavaFX effort. The PR team continues to trumpet the technology as the next big thing, but the demonstrations are underwhelming at best. With Green's departure, Gadre has an opportunity to refocus on the core platform and reconnect with the developer audience. The center of this community is still server-side development, not mobile GUI or Bluray.
While Java retains a large developer base, the Java brand has been in a free fall for a few years, and I'm constantly surprised to keep on seeing the same marketing executives in the briefing rooms year after year. To the Sun employees who find themselves jobless, good luck. Know that the magnitude of this layoff would have been smaller if your management team had been making more rational decisions about direction over the past few years. To the employees who remain, you should take no solace that you remain in the employment of a company that has so badly mismanaged the Java platform. Gadre might be just what the doctor ordered, but it will take bold strokes to resuscitate this platform.
Opportunity to Break a Log Jam
The transition to open source Java was prolonged and rocky, and the JCP is currently paralyzed over the continuing disagreement over the TCK. Sun has preached openness while using TCK licensing as a lever to protect its revenue from licensing Java on mobile platforms. Open source communities see the restructuring as an opportunity to reengage Sun to see if they are ready to break this log jam. It will be interesting to see if there is any shift in TCK licensing strategy with the management change. If Sun wants to protect the Mobile revenue by precluding a JVM implementation under a BSD-style license, they will not budge. If Sun realizes that the viability of the platform is more important than the Mobile revenue, they will capitulate and remove conditions from the TCK license. (I predict no progress.)
What Happens to Java When...
Although the press release positions this as an "opportunity" for Sun to align itself with the market. This isn't a restructuring to take advantage of favorable market conditions, this is a round of layoffs precipitated by the worst economic conditions in decades and serious talk of a multi-year recession. This could very well be the last gasp of a company trying to rearrange business units for a sale. The coming multi-year recession will claim a few large companies, and Sun's operating costs were already very high before the current global crisis. Maybe they will survive the coming storm, maybe they won't...
...but if they don't, what happens to Java?
PHOTO CREDITS: Tim O'Brien
Sun announced massive layoffs today, and shuffled some executives around to new positions. Most relevant to the Java platform is the selection Anil Gadre to head the Application Platform Software division. Before serving as Chief Marketing Officer, Anil Gadre was general manager of the Solaris effort. Anil Gadre is also named as co-inventor on a Sun patent for the per-employee pricing model Sun uses for Java Enterprise support. Gadre is also largely responsible for repositioning Solaris to compete with Linux, most notably managing Solaris' transition from proprietary to open source.
Time to Refocus the Java Platform?
Sun has also announced that Rich Green is leaving the organization. This year's JavaOne was noticeably downbeat and Schwartz's mood at the blogger press conference was noticably glum as the conference happened to coincide with the announcement of layoffs. It is certainly no surprise that Green is leaving the organization, but one has the question why it didn't happen much sooner. Sun has hemorrhaged GUI experts to Adobe ever since it decided to start pushing JavaFX as the answer to everything interactive; I wonder if it is time for Sun Microsystems to disengage from the JavaFX effort. The PR team continues to trumpet the technology as the next big thing, but the demonstrations are underwhelming at best. With Green's departure, Gadre has an opportunity to refocus on the core platform and reconnect with the developer audience. The center of this community is still server-side development, not mobile GUI or Bluray.
While Java retains a large developer base, the Java brand has been in a free fall for a few years, and I'm constantly surprised to keep on seeing the same marketing executives in the briefing rooms year after year. To the Sun employees who find themselves jobless, good luck. Know that the magnitude of this layoff would have been smaller if your management team had been making more rational decisions about direction over the past few years. To the employees who remain, you should take no solace that you remain in the employment of a company that has so badly mismanaged the Java platform. Gadre might be just what the doctor ordered, but it will take bold strokes to resuscitate this platform.
Opportunity to Break a Log Jam
The transition to open source Java was prolonged and rocky, and the JCP is currently paralyzed over the continuing disagreement over the TCK. Sun has preached openness while using TCK licensing as a lever to protect its revenue from licensing Java on mobile platforms. Open source communities see the restructuring as an opportunity to reengage Sun to see if they are ready to break this log jam. It will be interesting to see if there is any shift in TCK licensing strategy with the management change. If Sun wants to protect the Mobile revenue by precluding a JVM implementation under a BSD-style license, they will not budge. If Sun realizes that the viability of the platform is more important than the Mobile revenue, they will capitulate and remove conditions from the TCK license. (I predict no progress.)
What Happens to Java When...
Although the press release positions this as an "opportunity" for Sun to align itself with the market. This isn't a restructuring to take advantage of favorable market conditions, this is a round of layoffs precipitated by the worst economic conditions in decades and serious talk of a multi-year recession. This could very well be the last gasp of a company trying to rearrange business units for a sale. The coming multi-year recession will claim a few large companies, and Sun's operating costs were already very high before the current global crisis. Maybe they will survive the coming storm, maybe they won't...
...but if they don't, what happens to Java?
PHOTO CREDITS: Tim O'Brien
订阅：
博文 (Atom)