It's awesome to see this posted - I was (one of) the original creators of code.nasa.gov when we first launched it in early 2012. I've since moved on from NASA, but the agency has kept on posting things to the site as well as on GitHub (https://github.com/nasa). So glad to see the torch continue to burn.
There's a big effort within the federal government to do more around engaging citizens in using (and contributing to) free/open source software, as well as starting to develop more user-centered products and services. If you're interested in that sort of thing, check out 18F (https://18f.gsa.gov and https://github.com/18F). We'd love to hear from you.
This is really cool. Never understood the seemingly traditional java practice of making super-deep source directories (gov.nasa.arc.spife.core.plan/src/gov/nasa/arc/spife/core/plan/timeline/ with nothing else in the intermediate folders)
It is supposed to provide a unique identifier for all packages in all applications, allowing you to mix code from multiple packages without namespace collisions.
> The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.
(Apologies in advance if I am misunderstanding the complaint -- I'm assuming 0 prior knowledge on your end, so my write-up below may sound obvious! Sidenote: I've written a JVM, so I've gained an appreciation for some aspects of the JVM, including class resolution [0].)
In Java/the JVM, file names unambiguously correspond to your package/module/class names. Given a full class name (e.g. java.lang.String) and the class path (a list of folders/JAR files), the JVM is able to locate the specific file with the implementation of that class. This feature is crucial to how the JVM performs dynamic classloading, as classes can reference other packages/classes with a simple string, and the JVM will fetch the relevant class dynamically at runtime.
For example, in the parent comment, gov.nasa.arc.spife.core.plan is the package name, which translates to the folder /src/gov/nasa/arc/spife/core/plan/. This package name, while verbose, makes sense for NASA, as it corresponds to that organization's hierarchy. gov.nasa corresponds to NASA, arc = NASA's Ames Research Center, spife is probably the project name, and then the rest correspond to packages in that project. This hierarchy makes it clear who has the right to modify particular hierarchies of the namespace, allowing employees to make new packages within their levels of the hierarchy without worrying about name collisions.
As a concrete example, it would be troublesome if every research lab decided to use the gov.nasa.util package name. Or worse -- just 'util'. If both of these are libraries, it's feasible that a client application might use both of them... but then the application will discover that it is unable to use both due to a simple naming conflict in library code!
I agree that it appears cumbersome and wasteful to those used to editing on the command line (as the files are scattered all over the file system), but it's less visible when using an IDE that coalesces empty folders together.
Yup! It seems we're not disagreeing entirely. My complaint is that it's fine if you want to use "gov.nasa.arc.spife" as a unique disambiguator for your package / modules, but you shouldn't have to encode that in the path, just some metadata in a file somewhere would have done the same job. The nestedness is superfluous. The logical hierarchy here need not also be a physical one, that's basically what I'm getting at. Fair point about java-specific IDEs hacking around that.
All this code is ALREADY in a folder named gov.nasa.arc.spife.core.plan.editor.timeline so why even bother creating the src/gov/nasa/arc/spife/core/plan/editor/timeline structure within that?
1) The containing folder you're referring to is not part of the compiled artifact.
2) If you're feeling particularly adventurous, you could probably write a ClassLoader which knows how to resolve the full class identifier (including package) to its actual class, which needn't be in that directory structure, but at that point you're fighting 19 years of Java history.
3) Scala mitigates the crazy folder hierarchies by letting you structure the source more naturally (needn't be a 1:1 between package and folder structure, and even have multiple classes per file), and ensures the resulting class files are structured the way the JVM's default ClassLoader wants them. That said, many folks end up adopting the Java source style for consistency, especially in teams where they have to maintain legacy Java code anyhow.
> you shouldn't have to encode that in the path, just some metadata in a file somewhere would have done the same job
There are two problems with this approach, from how I see it.
1) Now there is an extra build step: Produce the metadata that associates class names with files.
2) This mechanism also adds an extra level of indirection when the ClassLoader needs to resolve a class.
By using a file system, you can edit a single Java file in a project with many classes, and recompile only that single file to test your changes.
> All this code is ALREADY in a folder named gov.nasa.arc.spife.core.plan.editor.timeline
That's NASA's choice for organizing code into modules. Each of these look like individual libraries, and that's the full name of the package that the library supplies. Sounds practical, especially since they have the source code of other non-NASA libraries checked in (e.g. rhino).
They could have merged the source trees of the individual components, but that becomes cumbersome as some of the third party components are under different licenses, and it's likely that each of these packages are built and packaged into separate JAR files.
That folder name won't be in the final JAR file, which will only have the hierarchy past the src folder.
Note that the JVM has a robust mechanism for custom classloaders, so you could actually implement your metadata idea if you wanted to. What will happen at runtime is that the JVM will invoke your custom classloader with the full class name (e.g. java.lang.String), and then you have to give it the Class object associated with it (which you can construct dynamically, produce from a byte array loaded from somewhere, or request from the JVM's file-based classloader).
Hey this is cool, thanks! I'm going to dig in to their surface crack tool and see what they consider for it. It could be very useful in my line of work.
I'd love to see them put up more code for simulation and analysis of mechanical systems.
edit: Holy crap, I'm flicking through the Tech Transfer Software Catalogue and there's a heap of cool mechanical engineer stuff in here. I wish more of it were available in the academic and/or commercial realm (particularly outside the US)!
Second project should be a Library for rigorous verification of non-linear arithmetic, but was empty, save for a readme and license: https://github.com/nasa/Kodiak
Or, is that a punny statement about non-linear arithmetic?
There's a big effort within the federal government to do more around engaging citizens in using (and contributing to) free/open source software, as well as starting to develop more user-centered products and services. If you're interested in that sort of thing, check out 18F (https://18f.gsa.gov and https://github.com/18F). We'd love to hear from you.