Library which provides unification of "Type Classes" in Java?

Hello LtU,

Please excuse me if I get my terms wrong, not a type system expert in any way. Since I don't really know what I'm talking about and what details are relevant I'll try to keep this short. I think it's best to discuss this and I'll come up with the details during the discussion.

I want to "map" different "type classes" into a unified system. I understand there is no such thing as a universal type system, so I'm looking for something pragmatic.

For example,

I could write a Map<String, -type- > view (or call it record, named tuple, etc) of a Java Class.

class Person {
   String name;
   int age;
}

Would become something like:

{ "name": String, "age", int }

Similarly, I could combine an XML document

<person age="23" name="Meh"/>

with a list of named & typed XPath expressions

("age", int, /person/@age)
("name", String, /person/@name)

and view that as a similar Map.

Another example would be a query on a database of similar form.

I'd then like to have operations such as:

  • trimming the Map to a new Map with a subset of it's fields
  • projecting a field of the map to the type of it's value
  • taking the union of some maps into a new Map

It's important that I can dynamically walk (incrementally) the structure of a type and build a user interface on that.

Finally I'd like to (structurally) check equality of two types.

Currently I'm trying to write this myself but there are lots of details that make this rather complex. For example, efficiently dealing with values from derived types (obtained from slice/combine operations), etc.

Is there any (Java) library that does what I'm looking for? Does this sort of thing have a name?

Thanks a lot for your input!

Jelle.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Reflection

It sounds like you want a couple of things: first, a principled interface to the JVM's reflection capabilities, and second, a consistent and convenient language for ad hoc data query/transformation. There has been a lot of work in both of these areas, but I'm not sure there's anything quite like what you want.

Regarding reflection, I recommend looking at some of the other reflection frameworks for Java, and perhaps reading up on mirror-based reflection, which I think may be relevant to your interests.

On the other hand, Java is fundamentally a poor language for ad hoc tabular data, so I guess in the end you may want to tie something like XQuery to Java reflection. I don't know of any libraries that do this, but maybe someone else can make a recommendation.

Thanks!

Thanks!

I've read this Bracha & Ungar paper on mirror-based reflection. Very relevant.

Do you know of any implementations (besides JDI) of this principle?

In retrospect, I was vaguely smelling the need for a "mirrors" based reflection system. Now with new insights gained from this paper I'll look at that design and probably clean it up. Thanks!

Regarding a transformation/query language; I've looked at Jaxen, and maybe something implementing XQuery on top of that. Although this is quite possible, type-checking those expressions seems far from trivial.

What I find hard when writing this myself is:

  • Fit it as-type-safe-as-possible into java's generics
  • Maintain a nice balance between expressiveness and not ending up with a programming language of it's own.
  • Keeping a clear and workable separation between the meta- and base levels and the classes and values.

So mostly a matter of balance. I guess this needs more tinkering... Any further hints are more then welcome.

Tell me if you find one

I have also desired a type-class transformation library . I have slowly built parts of one over the years as I required transformations, but it is hardly a clean API. I have never really enumerated the various forms type-classes could take. You mentioned a few (Map, XML, database tables, Java classes), what are there others you are explicitly interested in?

The devil is in the details. What little I have done transforming simple Java classes to database tables has shown me that the primitives do not match well, and are database specific, and really should support user defined (database) types. There must be many default behaviors defined (easy), and a way to override them (hard).

Converting to Java classes will require a Java compiler, of sorts, to generate the *.class definition. I have a *.class compiler that I built one almost a decade ago, but I do not use it for type-class transformations. Maybe you will settle for conversion to java source code instead? I wouldn’t. :)

Are you limiting your desire to member fields, or are you including method declarations too? I ask because, the SOAP libraries should provide XML Java conversion routines. But that is just one of many possible transformations.

I also like the fact you want to standardize the type operations (trim, project, union) to create new types; that has not occurred to me.

Just thinking out loud...

So some of the things I'm interested in:

  • All Java types; mainly viewing them as "terminal" or "atomic" types (int, Integer, Date, URI, MyCustomClass)
  • Composite java types: List<T>, Map<K,V> MyCustomClass
  • Constructions of "Tuple" or "Record" like types (union, projections)
  • Dynamic structures: XML, JSON (not sure if this needs to be a seperate class)
  • Enums: Man/Woman, Yes/No/Maybe
  • Dependent types, thinking mainly of n-Tuple
  • Very complex 'types', such as an entire database and a custom query language. Using a query I build new concrete types.

Clearly I'll settle for any sane subset.

I'm also very interested in getting meta-data from types, such as validation information (integer range, email address).

I'm only interested in "types" and "values"; not methods. Maybe I'm interested in method footprints; not sure.

Given the comment by Matt above, it seems a solution splits in two parts:

  • One part of the solution is a mirror-based reflection library, this gives unified insight into the structure of these "type classes". I guess there would be different API's for different classes:
    • "terminal" or "atomic" types, which expose no internal structure
    • something "tree" like, where values can be obtained directly from some path.
    • a generalization of that: something which provides a query language, where values are obtained using queries. (But this is already vague terrain; maybe needs to be in the other part)
  • The other part would be something permitting constructions on this unified reflection API to construct new types

I'm still not even sure what is possible and what kind of types to include/exclude etc.