Java the platform is also evolving by way of having a JVM common ground and introducing multiple languages that compile down to it. Replacing a language with another is slightly less nuts if both languages compile to the same intermediary and are easily interoperable. But, going back to java-the-language for a moment:
What java really needs is a magic backwards compatibility. I know of no language that even tried, and java in general tries to avoid new territory, but clearly, that seems to be where java needs to go if everyone thinks the complexity budget is used up. A way to be backwards compatible while being able to change just about everything in the language. This doesn't even seem completely ridiculous to create, either. I haven't thought it all the way through, but, here's an overview: 1. You split the problem into 'language' and 'library' backwards compatibility. 2. You solve language compatibility by introducing a mandatory 'source' keyword (only legal before the first package/import statement). Anything lacking a source parameter is assumed to be targetted first at the supplied -source parameter to the compiler, and if that isn't there, the most recent version of java that didn't have the source keyword (let's say java7). Want to make '==' be syntax sugar for .equals, and relegate actual object reference identity to some library call, because, lets be honest here, you hardly ever use that - go right ahead. We have this, very lightly, in the form of the - source parameter today, but it could do with some more improvement, and with a 'source' keyword you could make a few breaking changes. 3. Then you worry about solving this problem in library space. Currently java doesn't try to solve this problem at all; you can compile against an older standard (-source) and produce older-format class files (-target), but you'll be using the libraries of the java version you start the program with, regardless of the -source or - target parameter. If something works differently now, or has been removed, all java classes, past and present, compiled against whatever you specified, won't work if they depended on that. Hence the golden rule in java core libraries today: You can't mess things up. You can only add. We can't 'fix' naming mistakes like renaming 'plus' to 'add' in BigInteger and BigDecimal. We can't spin corba out to a separate library (you can solve removal by detecting usage and live-downloading the dependencies, but that still doesn't allow us fine grained control of fixing things). We can't even remove Vector and Hashtable, and we can't even make the simple change of rewiring java.util.Property's getMap() method to return a Map of <String, String>, which properties clearly are, just in case some idiot decided to take that map and stuff non-strings in it in some misguided attempt at brevity. Sun takes this backwards compatibility -that- seriously. I can envision a library system that can make it work, though: Any library ships as the 'canonical' representation, which is usually the latest and greatest version, along with wrappers. A wrapper wraps FROM a version TO a version. The system is smart enough to wrap wrappers to make longer jumps - if your canonical API version is v3, you've got your v3 to v2 wrapper, and you still have your old v2 to v1 wrapper, the system will wrap v3 through v2 to v1 if some code expects v1. The wrapper must handle every possible manipulation - if one particular class file is expecting v1 of the library and creates a new instance, it will call the wrapper's special 'constructor' factory method, which will eventually construct a canonical (v3), and return it. Anything the class tries to do with this canonical is always run through the wrapper - the wrapper dictates what API it has, not the canonical, and is even able to tack on an extra shadow object for extra attribute storage if need be. You can't just ship a different version of the library the way OSGi does - because if you do that, you can't interoperate old code with new code. The beauty of wrappers is that the v1-expecting code can create an object using the v1 API, then pass this object off to a library which is far more recent and expects the v3 API, and it would just work, because the moment the object is manipulated by the newer class, a different wrapper is used. The only burden is specifying which API you want. IDEs can lock it down for you as you type. Library updates can even ship with jackpot-like refactor rules which attempt to automatically update vX expecting code to vX+1 expecting code, with all IDEs being able to run these rules because they are standard. Wrappers can even have different @Deprecated markings. If you deprecated something because its fundamentally dumb (security leak, could cause deadlocks like Thread.stop, etc), you can stick the @Deprecated in the wrapper to the old API, so people recompiling old code still get the warning, but if you deprecated it because you're evolving the API, but a certain way of working is still so popular you don't want to immediately force everyone that can't change this easily to use a wrapper, you leave it out, because, obviously, if someone wants to change the code, they'd set up their code to expect a newer version. Libraries aren't required to provide wrappers, but it gives an out for libraries which have become so entrenched that making breaking changes pisses off more people than its worth. First and foremost are of course the java core libraries. I would introduce the source keyword, this library system, and a bunch of not-very-breaking language-level changes, without changing the library much except for very obvious edge cases, first. Let's say this is java 8. Let the kinks be worked out, and then the only thing you do for java 9 is a massive retooling of some of the most offending libraries. If the community accepts that, you've got carte blanche to take the language to where-ever you think it needs to go, and adding things to the language that are made difficult primarily because of library code (non-nullness, reifiable generics) becomes a breeze as well. Even worrying about developer mindset (the third concern in breaking APIs and languages is that people need to learn the new ways) is now mostly moot, because those that don't want to change will simply be told to stick with the old version - no harm, no foul, they can interop with newer code perfectly, they can upgrade their library usage on a case-by-case basis. You don't even need to spend much time on maintaining old versions: After all, they are really using the newer version (or can, anyway) - as long as your wrapper works, their code never notices. It would also posit java as having a unique position - it would be the only language that offers tools to transparently evolve code while staying 100% compatible with whatever is out there, where old and new code is 100% interoperable. On Nov 23, 1:47 am, "Peter Becker" <[EMAIL PROTECTED]> wrote: > Hear hear. > > > > On Sun, Nov 23, 2008 at 4:47 AM, gafter <[EMAIL PROTECTED]> wrote: > > > On Nov 4, 3:40 pm, Patrick Wright <[EMAIL PROTECTED]> wrote: > >> I think that, in principle, Java could be extended in interesting ways > >> and could take cues from other languages (including, sure, C#), but > >> lately I'm tending to agree with Josh Bloch that Java's complexity > >> budget is used up. Every change at this point seems to imply a great > >> risk to instability (or unexpected side-effects) somewhere else in the > >> language or the library ecosystem. > > >> Another issue--and I'm not sure how MS addresses this--is that it's > >> becoming very hard for any new proposal for changes to the language to > >> gain much traction at this point; there's too much disagreement on > >> each proposal (including, in the last year+, both properties and > >> closures) and that makes it hard to build any real consensus. A lot of > >> anger comes up in these discussions, and there are certainly those who > >> would like to roll the releases back to 1.4, as well as those who > >> would like Java the language to move forward aggressively. These > >> people simply aren't finding common ground. So my guess is, Sun would > >> have to try and "pull a JCP" and just dictate what the changes would > >> be. But then, look at how much controversy Java 5 caused, for example; > >> I think they just don't want to go through that again. > > > I'm a Java programmer, and I'm learning C#. I was also a designer and > > implementer of language features for Java, and now I'm doing that for > > C# as a member of MS's language design team. C# is not more suited to > > further evolution than Java, but it continues to evolve quite > > successfully. So I can tell you exactly how MS addresses this. > > > The perception that Java's complexity budget is used up, and that the > > language is too brittle to undergo further evolution, arises commonly > > among people who think themselves capable of language design but who > > don't really have the background, training, or skills to do it. If > > they attempt to draft or implement language proposals, when the > > feedback arrives they realize there were many interactions that they > > didn't consider, and that the task is far more difficult than they > > thought. From this they come to the incorrect conclusion that the > > language has become too complex and further evolution is impossible. > > A related effect is that nonprofessionals sometimes mistake a formal > > specification for a user guide, concluding that properly proposed > > changes would be too difficult to use. Language design is not easy, > > and like many other fields requires a great deal of work by > > professionals. The ideal end product seems intuitive and easy to use, > > but that hides the effort that went into creating it, resulting in the > > false impression that language design is easy. > > > The Java language is well suited to further evolution, provided that > > the language design is done by professionals with the appropriate > > skills. Most important is to have a single individual or a small like- > > minded team responsible for the decisions to ensure consistency of the > > whole. Language design is not a community exercise suitable for a > > large-scale democratic process. Unfortunately, Sun doesn't seem > > willing to invest in the resources to make it happen. That, more than > > anything else, is the obstacle to the language's evolution. > > > Regards, > > Neal > > -- > What happened to Schroedinger's cat? My invisible saddled white dragon ate it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
