>One of the unique requirements is that we must use accredited software. This means that we can’t just pull in third-party JAR files at will, but we can use anything already contained within the JDK.
This policy seems dubious to me. It forces the teams to roll their own immature versions of things rather than rely on heavily used (and thus heavily battle-tested) 3rd party libraries. (Any special code screening applied to internal code could also be applied to open-source 3rd party code too).
tl;dr: Java FX was convenient for data visualization. all computation software still not java, mission control and other realtime stuff definitely not java.
To be fair I worked with netbeans as well for a while and definitely like it better than eclipse. never tried Java FX because Swing is so convenient once you get the hang of the layout managers and you can drop to Graphics2D anyway for everything else.
> mission control and other realtime stuff definitely not java.
That's not true. I've used real-time Java -- as have Boeing, Raytheon and NASA, though not necessarily the projects discussed here -- for hard realtime, safety-critical defense projects. We've certainly used it for soft-realitime mission control a lot, where it has replaced pretty much all legacy C++/Ada.
God forbid someone should think something positive was said about Java.
> Java FX was convenient for data visualization
Was? They clearly gush over it and mention that they are replacing legacy systems with Java - without specifying 'data visualization' as the only use.
"At the FDF [Flight Dynamics Facility] we’ve been using Java for all of our new application development, and intend to continue doing so".
> mission control and other realtime stuff definitely not java.
"Definitely" is your interjection. "JavaFX [..] start out as ‘nice to have’s, the usefulness quickly becomes apparent in the operations environment. Before long, JavaFX becomes a first class citizen in the ground system software."
They seem to be happy with it and not precluding any particular uses.
"Ground system software" is the software that isn't part of the platform - the same verbiage is used for aerospace development. I've worked on bomber platforms that had test software written in Labview, and I'd say the same thing - "definitely not mission control or platform software".
The operator console software for the Distributed Common Ground System is written in Java. So is at least some of the operator console software aboard the P-8 Posiden. Both of those cover "mission control" for their respective systems.
>all computation software still not java, mission control and other realtime stuff definitely not java.
You should have a look at JSR-000302 Safety Critical Java Technology. No GC, realtime, direct hardware access and certified for DO-178B, Level A.
>The specification is targeted to a wide variety of very demanding certification paradigms such as the safety-critical
requirements of DO-178B, Level A. This specification presents a set of Java classes providing for safety-critical application startup, concurrency, scheduling, synchronization, input/output, memory management, timer management, interrupt processing, native interfaces, and exceptions.To enhance the certifiability of applications constructed to conform to this specification, this specification also presents a set of annotations that can be used to permit static checking for applications to guarantee that the application exhibits certain safety properties.
Warning, article is product placement for Netbeans. Author bio at the bottom: "Geertjan Wielenga is a principal product manager in Oracle for NetBeans".
This policy seems dubious to me. It forces the teams to roll their own immature versions of things rather than rely on heavily used (and thus heavily battle-tested) 3rd party libraries. (Any special code screening applied to internal code could also be applied to open-source 3rd party code too).