Thanks for clarifying.

BTW, I love your opening paragraph. I expect to quote it often in the future!

Who would know the quirks in Java better than you :). So what we I’re doing in OT/J is a daring balance between playing by the rules of Java and still making conceptually sound improvements.

Why the heck did I write “Scoping”? Sure you’re right it’s about access control. I guess, however, I’m trying to better align both concepts, so that what I can see I’m also allowed to see. So private things are resolved only inside-out. With a strict inside-out scoping rule everything in scope is also accessible. Other access modifiers imply lookup strategies that may traverse also in other directions (outside-in, or sub-super). I’d hope that alignment of scoping and access control would provide for simpler intuition, but for precise argumentation the distinction is of course still needed (and of course a compiler first resolves and then checks access - but we wouldn’t necessarily want to tell programmers how the compiler works, would we?).

Inside a team we indeed apply instance based access control (by the compiler). Regarding a team from the outside it looks like a regular class, so we maintain class based access control (but even here family polymorphism helps).

Unfortunately I don’t see how access control for nested classes in Java could ever be made absolutely secure. You only have to know the name of one of those synthetic access methods in order to by-pass the compiler checks (even for class based access control). However, as I speak I realize that we could actually add a (more) secure mode pretty easily: we just need to extend those synthetic accessors: pass the caller as an additional argument and perform identity check within the accessor. This would be quite similar to how we already extend instanceof and cast (for family polymorphism). It’s still not 100% secure but I really wouldn’t want to do stack inspection for each invocation of a synthetic accessor, mh?

Anyway, my primary goal is to improve modularity for reuse, evolution and maintenance. Regarding security I’m somewhat less ambitious to improve Java - I’ll leave that field for Newspeak

Excellent coverage of nested classes. Of course, the list of quirks and misfeatures is much longer (try serializing an anonymous class; inheriting from a private class that you can access; …).

I must quibble with your use of the term “Scoping”. You are really not discussing scope at all, but rather access control and class based encapsulation. The latter is an issue in Java irrespective of nested classes (do you change that?). Furthermore, access control in Java is dynamic; fixing the compiler is easy, but the runtime remains broken (true in Scala as well). Because of this, you cannot use objects as reliable capabilities for security, which is one of our goals with Newspeak (thanks for the plug BTW).

However, the concepts mentioned in this post are the smaller part of what makes OT/J. The unique contribution of OT/J is its support for roles. Feel free to browse our documentation and write a comparison, if you see significant similarity between both languages.

Just one comment: Scala is an admirable piece of green field development. OT/J deliberately extends Java in order to support smoothest possible adoption. Those are very different goals to begin with.

As for package objects, no, I wasn’t aware of this late addition to Scala. But reading that these are singletons I’m actually disappointed: If you use these to model the above example you will end up with a world with only one City. Which reminds me that I thought of writing about the woes of singletons (which, e.g., OSGi people are very well aware of).

BTW, when searching for a succinct description of the Cake pattern all I find are references to the paper “Scalable Component Abstractions” mentioning that the paper doesn’t use the term Cake pattern. I would have to guess what within this 18pp. paper is the Cake pattern.

As for version requirements etc. this is not currently covered by OT/J (which still is a ‘traditional’ programming language agnostic to packaging and deployment). With OT/Equinox we still leave versioning to the OSGi level, but as I mentioned, I’d love to discuss how both worlds can be unified, and I think they should. Let’s mark it on our agenda.

However, in object-oriented programming classes are at the core of our business. In OT/J we have mended some of the flaws of nested classes in Java. So with OT/J we should really give nested classes a chance to live up to the idea that classes are the primary modules and not only at one level (a few hundreds of lines of code) but potentially at any level of scale.

Doing all this based on Java is a limitation, but maybe we can still bend Java to a direction that has a future. I hope so, not because I love Java, but for very pragmatic reasons.