Welcome to the first article in a series of migration topics for ArcGIS Runtime Java developers and for those folks who are planning to migrate away from the ArcGIS Engine Java development platform.
The goal of these publications, like all of our postings on blogs and the Resource Centers, is to help you become successful as you evolve your GIS work for today and the future.
Let’s start by taking a quick look at the main visual component of the new ArcGIS Runtime SDK for Java and contrasting it with the visual MapBean component in the ArcObjects SDK for Java. But first, let me set the context with a bit of background.
The ArcGIS Runtime SDK for Java1.0 was first released in June 2012 as a pure Java developer’s toolkit for building rich, fast, standalone or embedded ArcGIS client applications for laptops and desktop devices. With this SDK, Java developers can build apps that allow users to visualize, analyze and collect geographic information in both connected and disconnected environments, making use of geographic resources that are both online as well as “local” to the device the app is running on.
This product was designed to continue meeting the needs of developers using the current ArcObjects SDK for Java as well as address many of the issues and headaches that developers have encountered over the years while developing Engine Java applications. While the ArcObjects software library provides a much richer and broader scope of ArcGIS capabilities for building custom GIS apps than the Runtime SDKs, ArcObjects is very much non-modular, has a much larger memory footprint, is complex in it’s deployment model, and is not Linux-friendly. Speaking of Linux, apps built with the ArcObjects SDK for Java that are designed to run on Linux do not perform well at all, compared to those that run on Windows. The ArcGIS Runtime SDK for Java addresses these shortcomings, as well as a number of other issues.
The ArcGIS Runtime SDK for Java is the future direction for ArcGIS Java developers looking to provide Java SE based ArcGIS solutions for Linux and Windows, and even the Mac OS X platform. However, there are many existing ArcGIS Engine Java applications out there that have been very successful over the years. As users begin to compare the 2 SDKs and plan their own migrations and road maps, it is critical that they are able to find good migration strategies for evolving these Engine applications to ArcGIS Runtime apps.
So! Here we are. Today’s topic will focus on one of the key visual components of the new Runtime SDK for Java, the JMap, and how programming with the JMap component differs from programming with the traditional visual controls found in the ArcObjects SDK for Java. Take note of where your existing code is today, and how it can be refactored and reused when building Runtime apps with Java.
A JMap component running in a JFrame
JMap is comparable to the MapBean component in the ArcObjects Java SDK. While comparable in some respects, these two components are quite different in architecture and how they work.
Architectural differences
The Engine’s MapBean, as you may recall, is an AWT wrapper around an ActiveX control. This allows for map documents (MXDs) to be visualized in a Java AWT or Swing-based app, on Linux or Windows, in the same way as in ArcMap, with basically the same or similar ArcObjects implementation underneath, so to speak. Through a Java-to-COM interoperability library (Esri’s), Java’s AWT events are marshaled to the ArcObjects COM components which are registered on the machine that the application’s MapBean is running on.
JMap is quite different. The Runtime SDK for Java provides a library that extends the pure Java SE and Swing platform. There are no ArcObjects involved in the new Java API. Therefore, the JMap is a pure extension of Swing’s JComponent. This makes the JMap much lighter-weight yet extremely powerful compared to the heavier, more complex MapBean. There is a caveat to this “pure” word I keep using, and it is this: the JMap does depend on a video/graphics accelerator, OpenGL or DirectX, native to the hardware that a JMap-based app is running on. If either OpenGL or DirectX libraries are not present on the target device of the application, the JMap cannot be used. As always, Esri highly recommends that you refer to the latest System Requirements documents for specific versions of these that are supported.
Functional differences
Remember what the first critical line of code in your ArcGIS Engine applications needed to be if your application was going to use the visual bean components? You needed to initialize Engine by calling the static method EngineInitializer.initializeVisualBeans(). If this was not present, your application was not guaranteed to run correctly because the underlying Java-COM interop needed to be able to handle threading within your application differently that it did with non-visual apps.
With the Runtime SDK for Java applications, this is no longer the case, since there is no Java-to-COM requirement, because there is no COM or ArcObjects of any kind running in your apps, nor in your developer experience. You simply begin programming your GIS apps the same way you would do for any Java-based application.
Threading
Staying with the threading topic, there are some functional differences here as well. Remember that ArcGIS Engine needed to handle coordination of 2 distinct threading models: the ArcObjects threading model and the Java AWT/Swing threading model. If you were not careful in your coding practices with the visual beans, your applications could, and often did, experience dreadful “deadlocks”.
Again, these threading complexities that come with the co-existance of ArcObjects and pure Java simply go away with the JMap. JMap is pure Java and only exhibits AWT/Swing’s own threading model, which is quite familiar to most Java programmers.
Event Handling
Some similarities here. Both the ArcObjects-based MapBean and the Runtime Java SDK’s JMap are capable of firing events. You can add listeners to them for handling and reacting to these events. However, the MapBean control utilizes listeners that are native to ArcObjects and not Java, and uses custom events that are not fired from within Java’s event dispatching thread. By contrast, the JMap listener and eventing models are pure extensions of the Java framework. See java.util.EventListener.
Again, programming with events and listeners is another case in which using the JMap and the Runtime SDK for Java provides a natural programming model and developer experience, much more than the ArcObjects SDK for Java provides.
GUI development tools
With respect to IDE’s and design-time usage, The ArcGIS Engine’s ArcObjects SDK for Java provides a complete Visual Bean palette for drag-and-drop GUI development in Eclipse. This is a strong point for developer productivity and for getting your solutions to market quickly. The ArcGIS Runtime SDK for Java version 1.0 does not have this feature out of the box. However, the JMap is in fact a pure JComponent, and not a wrapper. as such, you can add this component to palettes manually in any Java-based GUI builder solution on the market, such as WindowBuilder for Eclipse.
Well, that’s a head-start, I think. There is so much more I could write about in comparing the two visual components, but I believe these are good key starting points. We value your feedback, so please reply with comments, corrections, concerns, etc. I hope we have highlighted the main things to keep in mind here. Something to take away is that there is not going to be a straight-forward migration path for your visual map components, I’m afraid, but the changes now are going to be SO worth it. The best advice is to delve into the Javadoc and conceptual help, and lean on the rich set of example apps in the Sample Viewer application.
The Sample Viewer Application
These are excellent resources to jumpstart your migration planning. The JMap is much more streamlined for developing apps that “go with the grain” of the ArcGIS platform today and into the future.
Until next time, happy Java coding.
