I looked at BigDate46.java. Here's the first place I found, and there
may be others, where lexical order would affect initialization results.

   static {
     ...
     int last = daysInMonth( mmi, false );
     ...
   }

daysInMonth() returns a value from usual_DaysPerMonthTable[], which,
depending on lexical order, may or may not have been initialized by the
the the above static initializer runs. Had the code from daysInMonth()
been copied inline into the static initializer, then the compiler would
have caught out-of-order initialization.

See "The Java Programming Language" for the conditions when javac, going
back at least to 1.0.3, would consider using a variable before its
declaration to be an error.

8.3.2.3 Restrictions on the use of Fields during Initialization

The declaration of a member needs to appear before it is used only if
the member is an instance (respectively static) field of a class or
interface C and all of the following conditions hold:

    1. The usage occurs in an instance (respectively static) variable
initializer of C or in an instance (respectively static) initializer of C.
    2. The usage is not on the left hand side of an assignment.
    3. C is the innermost class or interface enclosing the usage.

A compile-time error occurs if any of the three requirements above are
not met.
<<

From 8.3.2.1:

One subtlety here is that, at run time, static variables that are final
and that are initialized with compile-time constant values are
initialized first. This also applies to such fields in interfaces
(§9.3.1). These variables are "constants" that will never be observed to
have their default initial values (§4.5.5), even by devious programs.
<<
  A program that calls daysInMonth() from a static initializer that
lexically precedes the declaration of usual_DaysPerMonthTable[] would
count as a "devious program".

  It's not really uninitialized variables that cause the compiler to
complain about static int a=b+4, b=3. The static variables in question
do get their default initial values (binary zeros or null); it's just
that their "initializer" (the expression to the right of the = sign in
their declaration, or the value assigned by a static{} initializer)
hasn't run yet.
  Local variables don't have default initial values, so the compiler
(and the verifier, since the .class may not have been produced by a
conforming compiler) has to complain where it would allow a static (or
instance) variable to be used before its =3 is executed.

--Mike Amling