Java / Scala反射：按顺序获取类方法并强制对象初始化

Question

I have a class with a few objects as inner methods.

I also asked this question a while ago and got a good answer, but that leads to fatal errors in servlet containers. Scala cannot consistently generate a TypeTag when the URLClassLoader asks for a class.

The project in question is open-source, found here .

The current approach is found here , but it doesn't preserve order. object members are correctly initialised, but in a random order.

Question : How can you collect class members:

• in the order they are defined
• in a thread-safe way
• filter them by a super type
• and greedy initliase the objects(referencing module.instance ) ?

Update :

• Don't suggest answers based on the links here, they've been tested and known to fail.
• Using a val instead of object is not an option, for stylistic reasons.
• getMethods or getDeclaredFields is known not to guarantee order. If this is somehow possible, it's likely with Scala reflection.

Answer 1

From http://docs.oracle.com/javase/6/docs/api/java/lang/Class.html#getDeclaredFields() :

public Field[] getDeclaredFields() throws SecurityException

Returns an array of Field objects reflecting all the fields declared by the class or interface represented by this Class object. This includes public, protected, default (package) access, and private fields, but excludes inherited fields. The elements in the array returned are not sorted and are not in any particular order. This method returns an array of length 0 if the class or interface declares no fields, or if this Class object represents a primitive type, an array class, or void. See The Java Language Specification, sections 8.2 and 8.3.

(my emphasis). Similar language is explicitly in the documentation for getDeclaredMethods(), but not in that for getDeclaredClasses() (but can IMO be considered implicit there).

So no, you cannot rely on ordering from Java reflection on the JVM; in practice, I have seen the order vary based on the architecture of the running JVM (32- vs. 64-bit).

If you really must initialize the objects in a particular order (why?), you could use a naming convention and sort manually; however, it would probably be better to change the code to be order-independent.

Update

It appears that you may be able to get something from the Scala reflection API:

trait EarlyInit {
  val mirror = runtimeMirror(this.getClass.getClassLoader)
  val reflection  = mirror.reflect(this)

  mirror
    .classSymbol(this.getClass)
    .toType
    .members
    .sorted    /// This method is documented to return members "in declaration order"
    .filter(_.isModule)
    .foreach(m => reflection.reflectModule(m.asModule).instance)
  }
}

See the API docs :

Sorts the symbols included in this scope so that: 1) Symbols appear in the linearization order of their owners. 2) Symbols with the same owner appear in same order of their declarations. 3) Synthetic members (eg getters/setters for vals/vars) might appear in arbitrary order.

However, this will not be guaranteed to work in general, particularly for mixed Java/Scala projects (since there really is no way to get members of a Java class in declaration order). Also, be aware that Scala runtime reflection is not thread-safe and generally not considered production ready.

I still feel that you would be better served by modifying your design to be order independent, possibly by encoding the dependencies differently.

Answer 2

AFAIK, this is impossible. The order class members are defined in simply isn't preserved in the .class files (at least using Java reflection).

Answer 3

You have a class with a few inner object s. As you indicate, inner objects are lazily-initialised when some other code references/calls them (similar to lazy val ).

Problem: (a) aforementioned lazy-initialisation PLUS (b) implicit inter-dependencies between the object definitions. This means that they need to be initialised in the order of their dependency-chain, but they do not explicitly reference each other, so correctly ordered lazy-initialisation does not occur automatically.

Attempted solution: programmatically pre-initialise these objects in the correct order, by using reflection during construction/initialisation phase. While this would work if scala or java reflection worked with you, it 'goes against the grain' - it works counter to the very definition of the inner objects. If you don't want them to be lazy-initialised, then why declare them to be inner objects in the first place?

My suggested solution: change the declarations from inner object s to val s. Order these declarations according to desired initialisation sequence. No reflection required.

(Aside: In this Q & the related ones, you've mentioned no artificial constraint or reason why object s must be used. However, if there is some strange reason why you must use object, then you still can avoid reflection. Simply have each object's constructor call a method forceInit of each object it depends upon. Each forceInit method could just return 1. This would trigger lazy-initialisation in the correct order.)

:-)

Answer 4

I ran into a similar problem and used annotations with some value to mandate the order. In particular, my object model drives an SWT table so I created:

public @interface DefaultColumnPosition {
    int value();
}

Then annotate the fields with @DefaultColumnPosition(0) or whatever the number is. Sort by the values. There is a little bit of overhead and it would be better if there was a different method, or perhaps a class level annotation that enforced order but doesn't look like it.

Have not tried the Scala solution but it looks interesting as well, I may give that a shot.