On Fri, Oct 2, 2009 at 7:01 AM, Peter Firmstone <[email protected]> wrote:
I admire your ambitions and would love to be able to work on it in a commercial setting where this were hard requirements... but in this decade (and probably next) it is utopia for the large majority of applications. I come from an industrial automation background, where the expectations are radically different, so I think I realize your points of long-running apps, code mobility, system fault-tolerance and evolution patterns. But I also think that you need to scrap the Sun JVM for this and "go deeper", since the JVM is doing far too much 'permanent caching' and other irreversible actions that needs to be addressed. Interesting no doubt... > This sounds interesting, what your saying pretty much is, cut your losses, > break backward compatibility now and you wont have to later on, while > reducing efforts for adding new functionality. Did you have something in > mind? Yes, pretty much, with "now" not necessarily being at this point in time. For River, it could make sense to stay source compatible for an extended period of time, but when that source compatibility is desired to be broken, also prepare for "next wave" and have these things in mind. Once the issue of "keep compatibility in the future" is well understood, it takes "alertness" to see/choose a solution of any given problem. Example; you want the ability to add new Exceptions to method signatures. I would suggest that the Exception from the beginning is closely tied to the 'domain' (typically a small cluster of classes working together) and allow both subclassing (for Exceptions within the domain classification) and nested ones (for instance, a subsystem becomes tied to IOException). Similar strategies can be thought of in advance to tackle the cases where binary compatibility can be kept for compile time incompatibilities introduced, hence removing the discussion of distinction between the two altogether. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
