The Artima Developer Community
Sponsored Link

Weblogs Forum
JavaOne 2005: Wrap Up

3 replies on 1 page. Most recent reply: Jul 16, 2005 6:13 PM by Ben Atkin

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 3 replies on 1 page
Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

JavaOne 2005: Wrap Up (View in Weblogs)
Posted: Jul 8, 2005 2:37 AM
Reply to this message Reply
Summary
This article is my end-of-show wrap up, with notes on a variety of announcements and things. It compares Groovy to BeanShell, describes great new announcements like AJAX and Hibernate, and takes a look at a radically new concept that was a major theme of the show--EASE OF USE enhancements coming up in J2EE, NetBeans, and Java Studio Creator.
Advertisement

It was a great show, with some exciting new technologies to cover including Groovy, JackPot, and the NetBeans Colloboration APIs. The final day had some good stuff, but at the end of the day I still had my socks on (translation: no earth-shattering revelations occurred), so I decided it was time to write my traditional "wrap up" article.

A funny thing happened on the way to writing that article, though. So many ideas were spinning around in my head that it took a week to capture them all. Those thoughts will appear in an upcoming series of articles. But now, at last, here is my wrap-up article for JavaOne 2005. It covers:

BeanShell vs. Groovy--Which Script Engine is Right for You? #

As I wrote in It's a Groovy Day!, Groovy is one sexy scripting engine. But BeanShell has been around for quite awhile. In fact, it pioneered the whold concept of scripting engines for the JVM. Here then, are some reasons why you might want to choose BeanShell:

  • "Pure" Java syntax. Groovy has added it's own syntax, using square brackets to create lists for example, and adding ==~ as a pattern-matching operator for Strings. Since BeanShell restricts itself to existing Java syntax, it never has to worry about a future incompatibility with the Java language

  • Smaller footprint. Beanshell is tiny--a minute fraction of Groovy's size. If you need a scripting engine in a cellphone, this is the one to use.

  • Faster. In addition to beeing smaller, BeanShell doesn't build classes. Groovy has a runtime dependency on ASM, a tool that builds byte codes for classes dynamically. After building a class, Groovy runs it. BeanShell skips all that and interprets your scripts directly.

  • Dynamic. BeanShell creates a small stub that the JVM thinks is a class it's executing. That creates the interesting capability to hack a BeanShell script while it's running as part of a servlet, so you don't have recycle the servlet to test your changes.

  • Available today. It's there now. It runs. No waiting.

Here, on the other hand, is the short list of reasons why you might prefer to use Groovy as your scripting engine:

  • It's sexy. Things like pattern-matching operators really float my boat. I find that stuff a great selling point. I want my language to make it easy to do the things I do frequently.

  • It's powerful. The ability to apply closures (unnamed blocks of code) to whole collections using commnads like Collection.each, Table.eachRow, and File.eachLine let you get a lot done in a few lines of code.

  • It's cool. It's sexy. And it's powerful. What's not to like?.

  • It's compilable. It's already building classes, so all it has to do is save the classes so you can run them directly or use them in your application.

  • It solves "point of pain" use cases for developers. The ability to add functionality to ANT scripts and replace XSLT for XML processing are just two of the many areas in which the language has been explicitly designed to solve problems for developers.

Ajax--Web Pages that Work like Desktop Apps #

I never got to see this, but from the sound of things, it's going to make web applications virtually indistinguishable from their desktop cousins. The Asynchronous Javascript and XML (AJAX) engine enables client buffering of data and manipulations that let you smoothly pan across a map, for example, instead of jumping from screen to screen. Apparently, the image buffering goes on in the background, so it's transparent to the user (depending on network traffic, I'm guessing).

Fromt the sound of things, Ajax is going to usher in an era of truly distributed computing, where the application you're running over the web is indistinguishable from one running on the desktop, without requiring a monstrous connection speed. It could also let a web-based email client load messages in the background and let the user scroll through them, instead of paging through 25 at a time..

Don't Persist--Hibernate #

Hibernate was getting a lot of buzz at the show. I never got a chance to look at it, but I'm told it's a lot easier to use than JDBC. Apparently, it uses reflection to persist your objects to a relational database in an intelligent, query-able way (rather than saving them as Binary Large Objects (BLOBs), for example.

NetBeans--An IDE Who's Time Has Come #

I saw this tagline on a slide at the convention: "NetBeans 4.1 is not your father's NetBeans". From where I'm sitting, that looks like the truth. There are plenty of new features on the way in NetBeans, including:

  • A better layout manager
  • An interactive GUI designer
  • ANT-based builds
  • Support for remote collaboration, as described in Share the News!
  • Restart your application "on the fly", to speed up the test-run-debug cycle.
  • Refactoring that includes EJBs as well as server code.
  • "Logical" project view, to hide files that provide the "plumbing"
  • Code folding, to hide event-listeners and other such wiring, so you can focus on application logic
  • Drag and drop external resources, like an EJB, database, or JMS messenger. Wrappers are automatically constructed so you don't have to.

And all of that is in additon to a great suite of tools for testing, refactoring, and debugging server-side apps and client apps.

Java Studio Creator--To Simplify Web Development #

Due out later this year, Java Studio Creator is an IDE based on NetBeans that makes it really easy to build a web application. Here are some of its features:

  • The GUI design tool operates graphically. You can drag components from the default library, and you can drag a line between a label and a field, for example.When you set the "required" property on the field, the label automatically gets an asterisk, and the system ensures that a value is filled in before the form is accepted--so you write less code to check for errors and spend your time processing data.

  • You can define "virtual forms" for master/detail relationships, so you process those parts of the form that have actually changed.

  • The look and feel of JSF components can be changed all at one time by dropping in a jar file that defines the "Theme"--or create your own.

  • You can import component libraries provided by other vendors, and target the application for a variety of web servers.

  • New application models simplify the process of building an application and keep the wiring hidden away, out of sight.

  • One of the new application types, portlets, lets you export a WAR that can be deployed on a portal server.

J2EE Ease of Use--A Phrase You Never Thought You'd Hear #

The next version of the J2EE specification is explicity target at--get this--ease of use. A lot of effort is going into tools to take the pain out of J2EE development, as well. The combined result of these efforts may well be something like a reasonable development environment.

This is coming from a J2SE guy, you understand. I've looked at J2EE before, but the wiring was pretty darn complex. XML descriptor files had to describe things in other XML descriptor files that matched the source code. It was difficult to get everything to work properly for a simple web application--much less a full-blown business application with EJBs and all the rest. So I pretty well stayed on the J2SE side of things, where I could make a bit more sense of things. But that could change. Rapidly.

Some of things that are coming include:

  • Annotations. Use of annotations in your source code to describe components, instead of external XML descriptor files. That's easier to maintain, and the number of descriptor files drops from 9 to 2--so innstead of writing 792 lines of XML, you're writing 26.

  • EJBs as POJOs. EJBs become Plain Old Java Objects (POJOs) so you can extend them

  • NetBeans improvements. As mentioned earlier, NetBeans is making it a lot easier to develop web applications.

  • Java Studio Creator. A way to take the pain out of web development.

  • GlassFish. Sun's Application Server 9 for J2EE and basic web apps, which will be open sourced. (App Server 8 made humungous strides in the ease-of-use department, compared to App Server 7. It will be interesting to see what things are like in App Server 9.)

As part of Sun's commitment to making life easier for developers, they recruited Paul Anderson of the Anderson Software Group (http://www.asgteach.com) to teach people how to use Java Studio Creator. The presentation and lab exercises were smooth and well-paced. They displayed the polish of a professional educator. Of course, all the polish in the world wouldn't have made much difference if Creator were difficult to use. So it was the right combination of product and presentation. In other words, J2EE is growing up. It's becoming less about technology, and more about getting things done.

The guiding principle in all this appears to be "things just work". Things are getting simpler, and the tools are taking over the complicated wiring and keeping the plumbing hidden behind the walls. You do less, and the container does more--so you can focus your attention on the problem you're trying to solve instead of spending your time on implementation details.

Resources

Previous articles in this series:

Resources mentioned in this article:


Brendan Johnston

Posts: 10
Nickname: bjsyd70
Registered: Jun, 2003

Re: JavaOne 2005: Wrap Up Posted: Jul 8, 2005 1:47 PM
Reply to this message Reply
Hibernate is a Java/SQL ORM (Object Relational Mapping) tool. I use Hibernate. In my opinion, Hibernate is not hopelessly broken proprietary junk. It has the same goals as TopLink and many other tools. These have been out for over 10 years. It is at best, a better mouse trap, not a revolution. So far it seems that ORM is, in general, a costly problem to solve, and all the ORM tools I have used reflect that.

http://www.hibernate.org

Scott Fingerhut

Posts: 3
Nickname: fingerhut
Registered: Jul, 2005

Re: JavaOne 2005: Wrap Up (invitation to be part of AJAX preview) Posted: Jul 14, 2005 12:15 AM
Reply to this message Reply
Sorry to hear you couldn't come by to see the AJAX stuff.

We had a booth and were showing General Interface along with an announcement that anyone can get their hands on a free eval preview version before it gets to the general public.


Also InfoWorld's Jon Udell has a video of it in action. See this, more and sign up for the Accelerator Program at:

http://developer.tibco.com

Ben Atkin

Posts: 4
Nickname: benatkin
Registered: Jul, 2005

AJAX and map images Posted: Jul 16, 2005 6:13 PM
Reply to this message Reply
HttpXMLRequest() (the single built-in function that makes AJAX possible) can only send/receive XML. It can't upload or download binary data (such as images). However, it can, just by modifying the page, get the browser to download and show the images.

So, for the maps to work, it must add an <IMG> or equivalent element pointing to a (possibly dynamically generated) image on the server. The browser caches the image and displays it.

I imagine some combination of a small browser cache and moving a long enough distance on the map could cause the browser to replace old cached image data with new data. This would mean when you moved back it would redownload. I imagine the browser makers fixed any bugs with traveling back to images that were forced out of the cache back in the 90's.

I imagine designers may have to dodge a couple weak points of browsers to get this to work well. But the majority of the heavy lifting (threading, caching, displaying, scrolling) is done by the browser, which can load multiple images at once and cleverly caches images. The server has some of the work too, but it can work pretty statelessly, I imagine.

Flat View: This topic has 3 replies on 1 page
Topic: See the World Previous Topic   Next Topic Topic: Any Idiot.

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use