autoplot / cdfj Goto Github PK

The CDAWeb group has been working to support UTF-8 characters in CDF files. Micheal Liu says that Nand had put in support for this, but we need to make sure this was done completely. Also, there's a group with production CDF files using an old ISO charset that includes European characters, so the intent is that the encoding for the file will be declared and libraries must properly form strings.

• Removed calls to printStackTrace()` and replace with proper logging calls.
• Remove throws declarations if method doesn't throw the declared exceptions
• Do not swallow exceptions without logging the stack trace and adding comment as to why the exception is being swallowed
• Chain all exceptions
• Do not explicitly throw Throwable, Exception, or RuntimeException
• For phase 1 all new Throwable calls will be replaced with the following:
  • IllegalArgumentException Thrown when parameters are invalid. Message should contain the invalid parameter and, if possible, a message about valid values. If a non-nullable parameter is null an NPE may be thrown instead.
  • IllegalStateException Thrown when a value of an instance field is not valid for successful execution of a method.

It would be really nice if I could use this library with empty CDF files created by skeletoncdf. I don't believe it can be used this way.

Clean up javadoc linting issues.

• Redundant javadoc on @Overriding methods will be removed.
• All public and protected members will have auto generated Javadoc added.

Adding minimal maven support.

NOTE: This is WIP.

I am going to use this issue to catalog and prioritize the potential modifications our analysis of the code reveals.

High Priority

• Use of primitive wrapper constructors should be replaced by calls to *.valueOf. These constructors are deprecated and the *.valueOf methods are HotSpot Intrinsic Candidates.
• Replace Vector with CopyOnWriteArrayList or ArrayList if not used in a multithreaded context.
• If target compatibility for the current version is for 1.7 or above replace as much resource handling with try-with-resources. Moving to 1.8 in the next minor version would be recommended as APIs can be much richer.
• Clean up Spotbugs and ErrorProne issues.
• Add default cases to switch statements as opposed to falling through and returning null outside of the switch body.
• Examine all cases of static mutable fields to insure they are truly required to be mutable and if so mark the truly mutable fields volatile.
• Add basic Maven support
• Add unit testing
• Migrate directory layout to the standard Maven layout Maven layout

• Medium Priority *

• Standardize member order. Currently fields and methods are intermingled making it very difficult to read the code quickly and adding additional complexity to merge operations.
• JavaDoc

• Low Priority *

• Add Modern Logging Support via Log4j2 or Slf4j.

Currently the code does not adhere to common member declaration order.
This makes debugging, analyzing, and merging code a challenge.

** Possible Order **

All member sections will be ordered by visibility (public, protected, package, private).

• static fields
• instance fields
• constructors
• static methods
• instance methods
• nested types (interfaces and classes)

• Add a static final Logger to every class that requires logging: static final Logger LOGGER = Logger.getLogger(MyClass.getCanonicalName());

• Remove all references to System.out.print*

• Add Logging to all catch blocks: LOGGER.log(Level.Error,ex, ()->String.format("My Method failed with these parameters %s, %s",param1.param2));

Add basic Junit (Jupiter) testing support.
Adding log4j2 as a test dependency

Will create tests and clean up ADR so it can be used as a template.

The code getCDFVariable(String vtype, int number) uses a lookup table to find the Variable in O(1) time, but this was implemented with just one table for both Z and R variables. I had assumed a file was either all Z variables or all R variables, and this was an incorrect assumption. (R variables are the original CDF variable type and offer no benefit over the newer Z variable type.)

Autoplot contains a copy of this library within its bowels (CDFJavaDataSource), and this was quickly hacked to have two separate tables, one for Z variables and one for R variables, but this change was never migrated back into the library.

• IsEmpty instead of size() == 0
• Reports on declarations of Collection variables made by using the collection class as the type, rather than an appropriate interface.
• 'for' loop replaceable with enhanced 'for' loop inspection 35 warnings Reports for loops which iterate over collections or arrays, and can be replaced with an enhanced for loop (i.e. the foreach iteration syntax).
• Manual array copy inspection 16 warnings Reports the manual copying of array contents which may be replaced by calls to System.arraycopy().
• 'StringBuffer' may be 'StringBuilder' inspection 5 warnings
• String concatenation as argument to 'StringBuilder.append()' call inspection 3 warnings

The test files found at https://cdaweb.gsfc.nasa.gov/pub/software/cdf/cdf_test_files/ are missing an example of long64 variable. Also
https://cdaweb.gsfc.nasa.gov/pub/software/cdf/cdf_test_files/bigcdf_compressed.cdf
does not seem to be compressed.

Fix calls to deprecated primitive wrapper constructors replace with valueOf

For years we've talked about having a way to describe virtual variable in CDF files. Suppose the function "add10" is called, and this would have metadata describing the function like "ds[i]=ds[i]+10". Presently the CDF virtual variables are all implemented in "readmycdf.pro", and for Autoplot I've had to review this code and translate to Autoplot/QDataSet codes.

Joey, Bobby and I were chatting at AGU about using the embedded language Lua to specify these. Lua has a typical set of operators and syntax controls with loops and conditionals. This might be all that's needed for these descriptions.

Here is a survey of functions which are needed:

• add10
• multiplyBy
• counts to flux, using add and multiply operations.
• flatten timetags where out[i*nj+j]= in[i,j]

Presumably some functions can be described, like fftPower where a spectrogram is made using a sliding a window and doing ffts on each window, and this function would not be required metadata.