Framework

From APIDesign

Current revision

Designing a framework with APIs is slightly different to designing an in-house system. There are little differences which may sound like paradoxes. Mostly caused by the fact that APIs are like stars - e.g. designing a framework is like designing a universe - you never know who's watching and you need to be ready for that.

Is Java Language or a Framework?

Few years ago I got into an argument with ex-NetBeans, ex-Google developer Radim. We argued whether modularity should or should not be part of the Java language. Unsurprisingly (knowing now what Google did to Java) Radim was trying to see Java as a language only (and thus claiming modularity should not be part of it). In contrast, I (as somebody who is using modularity among NetBeans libraries every day) claimed that modularity should be essential part of the language (which is my long persisting opinion expressed at epilogue of TheAPIBook).

We have not resolved our dispute then, but at the end it boiled down to a single question: Is Java a language or a framework?

Google brought Java into completely new places. Got it into browsers (via GWT), got it to phones (via Android). When doing that, it become handy to have greater flexibility. While bringing Java into limited environments, one may not be able to implement all the existing JDK APIs. It helps to concentrate on language only, and treat libraries flexibly. Of course, having built in modularity stays in a way...

On the other hand, when you see Java as a framework, you need to count the libraries in. And one of the biggest requirement is not only have the libraries, but also have them working on all supported systems the same way. Sun as a steward of Java (well known for its write once, run anywhere vision) was obviously closer to this point of view. Porting such system to other environment may however proof to be incredibly difficult.

Forking (as done by Google) is one way to go. But the proper way is to create Modular Java SE and make sure the smallest profile can fit to any target environment. What should be the smallest profile? The current Jigsaw's java.base module has about three thousand classes. That is much better than current JDK and probably good enough to fit on a modern phone (which is basically the primary motivation for modularization of JDK as far as I understand). However it is still way to heavy to become the shared base for GWT or other in browser running Java system. Dear JDK team, can't we get something lighter?

Java Minimal Profile

It is clearly true that Java is not just a language. Certain classes are needed and required by the JavaC compiler. One needs Object, String, StringBuilder, Throwable, RuntimeException, Class, Serializable, Enum and potentially few others.

I strongly believe modularity should be part of the Java language. But also, I'd like to see the Java language to remain portable. As such it would really helped if there could be java.minimal module defined during the modularization of Java. It would contain all the classes JavaC references to in its generated bytecode. Porting Java to new systems would then require just re-implementation of VM and this java.minimal module. Everything else would be just optional libraries.

I still have to ask Radim, but I have a feeling he could agree with such java.minimal system (even including modularity as part of the language).

At the end it gives everyone a core Java language extensible by libraries. As API of libraries is easier to evolve than a language, the system would be really powerful and flexible. Having such tiny framework could end the fragmentation of various of Java forks and finally bring us closer to having (the same) Java everywhere.

Java Limited Profile

I would like to have a module compatible with CLDC as the java.base has about 3k classes, CLDC has about 216 classes and inferfaces.