Newbie with Java 6 to Java 7 Migration Problem

I'll start with the fact that I'm a fairly decent MS .Net developer but a complete know nothing when it comes to Java and JOGL.  I'm dabbling my way through one of the "Learn Java in 21 Days Books" to keep my head above water.  With that background, I'm a systems support person in a U.S. Air Force organization that took delivery of a custom-built Java app about a year ago.  It is an implementation of a 3D geospatial data app built on the NASA WorldWind Java SDK  (http://worldwind.arc.nasa.gov/java/).  The vendor that built the app is completely out of the picture now.  I have all the source code for both the custom app as well as the WorldWind SDK that it was built on and am expected to maintain it going forward - whether that means application enhancements or bug fixes.

Everything was going along swimmingly well on Java 6.  But the Air Force has now decided to push Java 7 and I am having a major problem with this app on the Java 7 platform.  

The display is a multi-layer, 3D display that depicts an underlying map, various 3-dimensional blocks of air space, and live air tracks derived from real-time radar data, plus some other artifacts such as lat-long grid, map scale, text annotations, etc.

For clarity, I've turned off all the layers except for the airspace layer, which is where the problem is occurring.  In normal operation on Java 6, this is what that layer looks like.

goodgraphics.jpg


However, when I update my JVM to Java 7, this layer throws all these stray line artifacts.

corrupgraphics.jpg

I've tried, with my limited understanding of Java and JOGL, to try and figure out what is going on here.  This is the exact same data displayed in the exact same application, with the only variable being the JVM running under the covers.

The corrupt artifacts are also not constant.  If I close the app and reopen it, a completely different set of corrupt lines will appear.  And if I leave the app up and running, the currently displayed set of corrupt lines will occasionally shift, increase or decrease in number, appear/reappear, etc.

This is a rather complex app with lots of different threads running to receive and process the data.

The airspace layer is updated from the server only once every 15 minutes.  Oddly, the live radar data is a constant, never ending in-feed to the app via an HTTP feed that is held in an indefinitely open state.  It's updating its layer view about every 10 seconds and it displays just fine.

As a desperate move, I downloaded the lastest WorldWind 2.0 daily build and after much head banging to figure out the differences in the organization of some of the JOGL libraries and method signatures, I was able to create a working build of my app against WorldWind 2.0 and JOGL 2.X, on the hopes that this would cure the problem.  No luck. Same graphics issues continue

Specific machine and graphics hardware are irrelevant.  I've run on 2 different desktops and a laptop.  One desktop has ATI graphics, the other NVidia.  Problem occurred with the drivers that were originally on all machines.  Updated all 3 machines to most current graphics drivers.  No luck there.  Same behavior occurs regardless of which machine/hardware the app is running on.

I have successfully established a coding/debug environment in Netbeans in which I can examine and work with all the code, including live debugging with real-time data coming in.  I just don't know where to look or what to look for.  Is there anyone out there that get me pointed anywhere in the right direction to try and figure this out?

Thanks in advance.

Which version of World Wind SDK are you using for your application?

World Wind Java SDK 1.5 uses Sun/Oracle JOGL 1( JOGL version 1.* is unmaintained with known Java 7 bugs)
World Wind Java SDK 2.0 uses JogAmp JOGL 2 ( JOGL version 2.* and later is maintained and is known to work in combination with Java 7)

http://worldwind.arc.nasa.gov/java/

+++

Can you provide a minimal test-case that reproduce the visual glitches?

The production version of the app was delivered with World Wind 1.2.  After updating the JVM to 7 and the described problem popped up, I updated the World Wind components to 1.5.1 - the latest production release. Problem continued. As noted in my original post, I have also run the app with the most recent daily build of WorldWind 2.0 and JOGL 2 but the undesirable graphics behaviors continue.

Not sure what type of test case to provide. The graphics screen shots I attached to my original post were taken from a live session of the production application as deployed, running on both Java 6 and 7.  Not sure I can strip the app down to a smaller subset of functions for isolation and testing purposes.  I'm just not that adept at Java and WorldWind.

One thing I've noticed with transitions between major Java versions, is that sometimes the iteration order over a collection will change. Collections like HashMap, which you can iterate over but which have no specific ordering, will nonetheless have a deterministic ordering depending on the implementation details of the class. Then when the Java version changes, some implementation detail changes too, and now the order is different.

In this case, perhaps the points they're drawing the lines between are stored in such a collection in Java, and now with a different iteration order in Java 7, they're getting put into the OpenGL buffers in the wrong order. The solution would be to examine the data structures for this airspace layer to see how the points are stored, and figure out if the ordering is implementation-dependent (e.g. iterating over HashMap instead of LinkedHashMap). If so, then change to an explicitly ordered collection, make sure it's loaded in the right order, and your problem would be solved :)

Thanks Wade.  The app does make extensive use of HashMaps for storing collections of stuff.  The data comes down from the server as KML and the gets washed through several transformation before going down to the lowest WorldWind application classes for rendering on screen. I'll take a closer look at that.  Sounds like it might be promising.