Reflection in Java: how are they getting with it?

We seem to discuss pretty specific issues lately, so I feel I can bring this one up.

For a PL in which dynamism is one of the selling points, Java has pretty bad support for reflection: reification/introspection/intercession trio.

Reification is crippled by fact that not all concepts have representation, accessible to programs - the one for bytecode (literally an array of bytes) is a joke. This can be helped by libraries, though, and indeed is.

Introspection is limited - for bytecode as well (a program cannot in general obtain a representation of bytecode for the object at hand). That's a more serious limitation, although there are ways around it if you are willing to make some assumptions.

Intercession has another twist - on a positive side, it's possible to obtain classes from bytes (though it was not possible the other way around - funny, eh?), but on a negative side, while introspection had structured representation for some concepts (like fields), intercession knows only byte arrays. Ugh.

I will skip my complaints to representation of invocations, call stacks and threads, as the post is already quite negative.

To drive this towards PL design: how did Java get there? Was it because in early years there was little use for reflection? Why wasn't it fixed? Is it a scientific problem, an engineering one, or maybe cultural? How can newly designed PLs avoid such a fate?

PS: For some users reflection and MOP may be something very esoteric and unpractical, but look at Java "enterprise" open source projects: most of them are just grown from one or other attempt to overcome these deficiencies of the language. Unfortunately, there is a limit on what libraries can do to a PL.

Dynamism is one of the sellin

Dynamism is one of the selling points of Java?

By Marcin Tustin at Sat, 2005-03-19 18:06 | login or register to post comments

Absolutely

marcin: Dynamism is one of the selling points of Java?

Emphatically, yes. If there's one thing that should be clear by now, it's that having some level of reflection is stupendously useful in the "enterprise" space, where you spend at least half of your time gluing disparate systems together. Reflection and dynamic proxies make Hibernate go, and since I'm responsible for database integration in my current C++ job, I curse, literally every day, the fact that there's no way to accomplish the same thing in C++. As I've posted before, the closest you can get, AFAIK, is the Database Template Library, which is nice, but it's no Hibernate. And if you really want to see reflection at its best, you have to check out Ruby on Rails.

What I'm still looking for is any kind of treatment of reflection and introspection in the context of type theory. I don't think it's an accident, at this point in history, that the languages with reflection and introspection are either latently typed (Smalltalk, Lisp, Ruby...) or have known type-theoretic deficiencies (Java).

By Paul Snively at Sat, 2005-03-19 18:22 | login or register to post comments

I don't dispute for a moment

I don't dispute for a moment that dynamism is so important that it should always be available, even if it is possible and desirable to write and compile programmes that have no dynamism. I do dispute that dynamism is a selling point of java, as a) Sun make almost no noise about it, AFAICT, and b) Java dynamism is just enough that you can use it if you really really have to.

By Marcin Tustin at Sun, 2005-03-20 11:58 | login or register to post comments

I would counter...

...with the observation that JavaBeans are almost entirely about reflection (the rest is about naming conventions) and that every visual Java GUI builder is using reflection. I suspect that the reason that Sun doesn't plug reflection much anymore (they did a great deal around the 1.1 release!) is that most of the obvious uses of reflection have been absorbed by tool vendors: Visual Age for Java, Hibernate...

By Paul Snively at Sun, 2005-03-20 16:02 | login or register to post comments

Dynamism that important?

I don't dispute for a moment that dynamism is so important that it should always be available

I can't resist: why is this so?

I understand why some people like "dynamism", at least in part because they perceive it as giving "something for free".

But since "there ain't no such thing as a free lunch", I'm not sure why this preference constitutes a basis for "should alway be available".

By Marc Hamann at Sun, 2005-03-20 16:41 | login or register to post comments

It's not a free lunch - hence

It's not a free lunch - hence my qualification. The best of both worlds is probably to compile statically where possible, analyse statically where possible, but have the possibility to modify or generate the programme at runtime when it is the most convenient way to do things. Or, you could just have static checking and compilation so powerful that you don't need to, but that certainly isn't what you have in java.

By Marcin Tustin at Sun, 2005-03-20 20:04 | login or register to post comments

Java reflection is junk

Just like most things in the Java world, Java's reflection is poorly thought out, and even more poorly implemented. To answer your question: "how did Java get there?" I don't know, but my guess would be bad design, and unskilled implementors.

By slava at Sun, 2005-03-20 06:46 | login or register to post comments

Too harsh

I don't see how the problems with reflection in Java are a result of unskilled implementation.

Regarding "most things in Java world", do you mean the language/VM, or the community? If the former, could you support your statement?

By Andris Birkmanis at Sun, 2005-03-20 10:58 | login or register to post comments

Unskilled implementors

I didn't mean to imply that Gosling, Steele et. al. are unskilled. They've certainly had a lot of experience in implementing and designing runtimes. However, if you look at the J2SE source code, you'll find that maybe 1% was written by people with a clue. The rest has that 'hacked together team gangbang' mentality feel that we see all too often in corporate IT. And its obvious that most things in Java were hacked together with little thought. Just browse the API documentation one day.

By slava at Sun, 2005-03-20 17:34 | login or register to post comments

Implementors broke reflection??

Just browse the API documentation one day.

I am doing that daily, and the Javadocs/sources are, indeed, of variable quality.

I just doubt it's implementors who made that impossible in this enterprise-level PL to pickle (serialize/marshall/etc.) an object together with its code (unless you controlled how it was loaded in the first place - nice workaround).

By Andris Birkmanis at Mon, 2005-03-21 10:07 | login or register to post comments

Paper on reflection

A paper that may be of interest here is Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Languages. One of the authors, Gilad Bracha, is one of the current maintainers of Java, so it probably gives a good impression of how the people behind Java think about reflection.

By Christian Plesner Hansen at Sun, 2005-03-20 11:40 | login or register to post comments

Origins

I've used the Java reflection API before, and my guess would be that designers based it on the JVM internals. I say this because everything that you can do with it (examine type signatures, construct objects, convert bytecode to a class) is something that any JVM has to do at runtime anyway, and the things it can't do (analyze bytecode, get the bytecode for a class) are things that JVMs don't necessarily need to do.

So, what this means to PL design is that designers should be thinking in terms of the PL, not in terms of the current implementation. Surprise.

By John Stracke at Mon, 2005-03-21 14:35 | login or register to post comments

Lambda the Ultimate

User login

Navigation