Proposal for Java Frameworks

Question

I've come up with a neat way of extending java's packages and inner classes to create the conceptual level of a "framework".
The technology changes are small, but the conceptual shift is huge.
A framework is a collection of classes that are linked together more closely than those in a package. Most importantly, frameworks can inherit from each other, in interesting dynamic ways.
Several languages, like Objective-C (which is more Java-like than C++ in all but syntax), allow in various ways for programmers to meddle in the hierarchy of other classes, in a way that in Java just isn't possible. The libraries from Omni use "categories" to seriously meddle with Mac OS X's Cocoa frameworks, and this is often cited as a strength of Cocoa programming. But with just two small changes, Java can leapfrog them all and become the undisputed leader of object technology.
Part 1: Syntactic Sugar
The next version of Java should add the framework keyword, as a synonym for class. So, a file called X.java:
package a.b;
public framework X {
     interface A { ... }
     abstract class B implements A { ... }
     public class C extends B { ... }
     public void main (String[] args) { ... }
     private int aMember;
}You can see, however, that it allows not only inner classes, but inner interfaces and abstract classes. Also, every member of a framework is static. This is important, since it allows the inside of a framework to behave like the inside of a package.
This is reflected in the next change, which the framework keyword makes possible in other files:
package a.b.X;
public class Y { ... }Classes can be added to a framework from other files as if it were a package. This is all just syntactic sugar for inner classes, which the compiler generates as X.class, X$B.class, X$Y.class, etc. This way, people can create frameworks of classes, which feel more coherent than packages. They are accesses from the outside in the standard way.
Part 2: Dynamic Inheritance
This change, however, requires an addition to the class loader. It covers an otherwise rare case that can occur with inner classes, and isn't specific to frameworks, but is required for their advanced behaviour. Luckily, it's more an addition than a change - it shouldn't break any existing code.
Imagine a class with inner classes, and another class that inherits from it and overrides some of them.
class X {
     class A {
          public static void write () {
               System.out.println("ordinary");
     class B {
          public static void write () {
               A.write();
class Y extends X{
     class A {
          public static void write () {
               System.out.println("salt and vinegar");
     public static void write () {
          B.write ();
}So what happens when you call Y.write(); ? At the moment, it looks from Y for a class B, and finds X$B. Then it looks from B for a class A, and finds X$A. So Y.write would produce the output:
ordinaryWhat should happen is that it should generate a new class Y$B. In this case, it would be a duplicate of X$B, but which was able to find Y$A and call its write method - as you'd expect.
The other half of this is to do with inheritance - and this is where purer languages like Objective-C currently have a slight advantage. But not for long, because we're going to create dynamically inherited classes - which is exactly what they can do, but we'll do it without having to introduce any strange new syntax or ideas, slotting it neatly into existing inner classes.
You have a similar situation to above, but with inheritance in the inner classes:
class X {
     class A {
          public static void innerWrite () {
               System.out.println("ordinary");
     class B extends A {
          public static void outerWrite () {
               innerWrite();
class Y extends X {
     class A {
          public static void innerWrite() {
               System.out.println("salt and vinegar");
     public static void write () {
          B.outerWrite();
}So now we have a classes X$A, X$B and Y$A. The write(); method is calling for Y$B - where does it get it from? At present, it just gets X$B. Instead, the VM should create a new class Y$B, that extends Y$A in the same way that X$B extends X$A. Since every method call in Java is already looked up dynamically, it shouldn't be much harder than duplicating X$B and switching its parent. This is really just a correction of how inner classes should work, rather than an exotic new feature.
A lot of you will either have gotten lost by now, or be wondering what the point is. The point is that we can take an existing framework, and add in behaviours at the root of the hierarchy, and then let those behaviours flow down through all the other classes. So we could take the Window class, and add the ability for all kinds of windows to have, say, nice fuzzy shadows. And suddenly every kind of window, from a dialog box to a pallette to a tooltip, will have nice fuzzy shadows.
So, potentially huge rewards, for very little personal coding effort.
Loose ends
The incredibly astute among you will have wondered about one last little point, when you want to extend classes in a framework. The compiler will need one last little patch to handle this syntax point:
framework X {
     class A {
          public int getNumber() {
               return 5;
framework Y extends X {
     class A extends A {
          public int getNumber() {
               return 7;
}Here, the compiler sees class A extends A and needs to read it as saying "look up the existing class A (from X) and create a new class A in Y that extends it".
When Sun created inner classes, they didn't realise what they'd unleashed. Here we take them to their logical conclusion, not by adding exotic special cases, but by filling in the small logical holes in what's already there.
     - the Shrink Laureate

Answer 1

The point is conceptual. Now that most people have
moved from functions to objects (and from pointers to
references) it's time to keep going and move to the
next step onwards.The question is, "Is this really a step forward?"
As has already been pointed out, Java provides interfaces to set up this kind of layout. As also was already pointed out, tying objects closely together this way breaks the OO nature of the design, thus reducing reusability.
So my answer to this question is "No, it's really not a step forward."
> There are always people who resist change. Lots of
people didn't like object-orientation. But how many
serious programs nowadays are written in C and
Pascal?You really don't want to know the answer to that question. An awful lot of batch programs are still written in C. And an even larger number of programs are writtin in VB.
Java has to keep evolving, or it'll get left behind -
which would be a pity, because it really is rather
nice.Yes, Java does need to keep evolving. The problem is that it needs to have its core features stable and bug-free before it can really expand and evolve. The good news is that because it's now several years old, it's far ahead of C# in this regard!
It doesn't. It has references. There's a difference.
referenceVsPointerThread.join();