This content is part of the Essential Guide: JavaOne 2014: Takeaways from Java's biggest conference
News Stay informed about the latest enterprise technology news and product updates.

JavaOne 2014 speaker previews NetBeans and JavaScript

Prior to JavaOne 2014, Rob Terpilowski discussed his NetBeans apps and other development project plans.

During a JavaOne 2014 session, Rob Terpilowski will be demoing NetBeans applications, two of which he built in his spare time.

By day, Terpilowski is a software architect for transportation company Lynden Inc., in Seattle. By night and weekend, he is partner in Zoi Capital, LLC, a commodities investment firm, and scribe for the popular Web log Rob's Blog. As a JavaOne 2014 speaker, he'll talk about integrating JavaFX into the NetBeans platform and modularity. In this interview, he talks about his recent development projects, as well as future plans for using cloud and a small gripe with JavaScript.

Apache Camel is a key ingredient of the Zoi real-time commodity price monitoring application you'll show at JavaOne 2014. How did you use Camel there?

Jan Stafford Jan Stafford

Rob Terpilowski: We've been working on two apps for Zoi, one for monitoring commodity prices and one for trading commodities through one of our brokers.

For the monitoring app, Camel definitely made it possible to create an abstraction layer over integration frameworks. You can easily take something that is communicating with email, by sending email and monitoring email boxes, switch it over to a message queue or a Web service without having to modify a whole lot of code. You're looking at the underlying mechanism, so how it's implemented is not as much of an issue as getting the data back and forth. It's become a very, very popular framework in the last five or so years.

Tell us about the Google mapping app you've been building.

Terpilowski: I'm going to demo an application I've worked on at Lynden, where we've integrated Google Maps into a NetBeans application. Rather than actually having to write our own mapping plug-in, we're able to use a JavaScript application within a Java application. It's pretty cool.

The downside is that you have to program in JavaScript.

Rob Terpilowski,
software architect, Lynden Inc.

We want to get a mapping portion in the Lynden app, because we like our warehouse managers to be able to track where any trucks are. If the [drivers] are heading out to pick up freight, the warehouse manager can actually see in real time where they are, and route them to other nearby customers to pick up freight while they're out.

Have you run into any challenges when doing any of these projects?

Terpilowski: Integrating Google Maps in the [Lynden] app is interesting to do, because it is a desktop application, and Google Maps is a JavaScript-based application that runs in the browser. So, we've been able to get a proof of concept running by writing a wrapper around Google's JavaScript API and then importing that into the desktop application.

What are some approaches you took in the mapping project?

Terpilowski: It's actually pretty cool that we've got this hybrid application now, which consists of both Swing and JavaScript running side-by-side within the same application. It's using Web services, and we're going to tie it into our messaging system. That way, we can get updates in real time about driver locations; what customer they're visiting, what loads they are picking up and information like that.

In general, I'm starting to integrate some JavaFX into the NetBeans platform, which is along the lines of the next UI framework that Oracle is providing as part of Java 8. It may not take the place of Swing, but it looks like it's going to become the next framework Oracle is supporting, as opposed to Swing. I'm sure we'll be seeing more and more desktop apps being developed using JavaFX, rather than Swing.

Why do you think that JavaScript has gotten so much traction in the cloud?

Terpilowski: All these cloud applications are being delivered with a browser. For better or worse, the only common theme across all the browsers is that they support JavaScript.

Back in the early 2000s, there was a mad rush to create all this dynamic content in JavaScript. Then there was huge blowback, and everything got pushed back to server-side apps serving up webpages. But now, if you really want dynamic content, and you really want to create something that has just as much functionality as a desktop application, JavaScript looks very good to you. Another factor is that now you can develop an application with HTML and JavaScript and not be able to tell the difference between how that functions versus if you're using a desktop application.

The downside is that you have to program in JavaScript. I can't say I'm a huge fan of it.

Why? Why are there downsides of programming in JavaScript, even when you come from a Java background?

I see more and more cloud applications in my future.

Rob Terpilowski,
software architect, Lynden Inc.

Terpilowski: Well, programming JavaScript is especially tricky from testing and debugging standpoints, I think. With Java, we have many open source tools that assist us with running unit tests and integration tests and debugging. We are just starting to see some of those tools emerge now for JavaScript.

Also, there's a cross-browser compatibility issue, say, when I'm trying to decide if I'm going to build something in Java or HTML5 in JavaScript. With JavaScript, I have to deal with the nuances between IE 9, IE 10, Chrome, Firefox and whatever other browsers users have. That's a drawback, because it's not as simple as having application running natively on the desktop.

All that said, I'll be using JavaScript. At Lynden, we're going to be upgrading our website to HTML5 and JavaScript. Previously, it was just HTML, which allows no dynamic content.

What other development projects are you planning to do?

Terpilowski: All around I see applications being run as a service within a cloud, whether it's in the [application owner's] cloud or in an Amazon or Microsoft cloud, a public cloud. That's a direction I would like to see us at Lynden take. Why are we in the business of maintaining our own hardware anymore? Why do we need to do this when we could basically delegate those to Amazon, and then we could spin-up different servers, as we need them and scale, as we need? Instead, we have to procure our servers, install them in our data center and make sure everything is properly integrated. All that work could be handed over to the cloud people who do that full-time.

For development, cloud providers make it easy to use an interface for creating applications that can scale horizontally. So, I see more and more cloud applications in my future. The cloud is where everything is going to be living someday.

I'm interested in checking out micro services [sessions and products] at JavaOne. That's the architecture we're moving toward at Lynden. We're breaking down monolithic applications into a smaller set of services and using Web services or messaging to allow them to communicate with other services that are running inside Lynden or our third-party data providers.

Here's a preview of Rob Terpilowski's Zoi Capital Google mapping app.

More by Rob Terpilowski:

Adding MBean to JMX

Working with MBean

Connecting to the app server with VisualVM

Monitoring Web apps using JMX and Spring

Dig Deeper on Web application framework and Java middleware

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.