Something like that would be much more interesting and beneficial than the JavaFX Sun is current betting on. It would also set them apart again from competition which frankly we haven't seen since the 90's. If getting it right the first time is so difficult (and obviously it is), there should be mechanisms in place to rectify this and not just a paralyzing commitment to backwards compatibility.
On a related note, let me just point out the code transformation stuff proposed by Jaroslav Tulach and Jan Lahoda (NetBeans core ppl) which I think could deserve mentioning by The Java Posse: http://netbeans.dzone.com/news/transformation-code-transforma /Casper On Nov 23, 12:29 pm, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
