Joe, I seemed to have failed in the intention of my post. I was trying to be constructive and offer a way forward; but all I seem to have done is upset you, this was not my intention.
I think there is an ever increasing feeling that Java is stagnating, and as a consequence many people, including myself, are starting to use other languages, like JavaFX and Scala. These are languages written from scratch; that is a hugh effort. It seems from the outside that Java is the neglected child of the JVM. How come JavaFX and Scala can both be written from scratch in the same time scale as Java goes from 6 to 7? Is the resourcing for Java really significantly less than for Scala and FX? For myself, and I assume others, I want Java to continue to grow and go from strength to strength. Hence my proposals to break the deadlock between backward compatibility and adding new features. With regard to the community involvement, you are obviously disappointed that more people have not produced prototypes. There were some prototypes, e.g. CICE and BGGA, but these did not really advance the course of improved inner classes / closures. I can speak for myself and say that I am reluctant to invest my time in building a prototype etc. when the chances of acceptance appear to be slim; I assume from the lack of prototypes that others feel the same. You have to remember that this is not our day job, we would be doing this in our own time. People's own time is very valuable and they won't spend it unless there is going to be an outcome that is favorable (or at least likely favorable). Anyway, I hope that the impasse between backward compatibility and new features can be broken and Java has a long and glorious future. I apologize again for upsetting you and re-iterate that this was not my intention. I think you did a really good thing in opening up the decision making to more scrutiny, and I say that as someone who did not get any of his pet favorites up! -- Howard. On Sep 15, 2:01 am, jddarcy <[email protected]> wrote: > On Sep 13, 12:27 pm, hlovatt <[email protected]> wrote: > > > BIAS DISCLAIMER - features mention below are favored by me! > > > The tension between backward compatibility and introducing new > > features seems be the problem, there are ways out of this problem, > > e.g.: > > > 1. Introduce a source statement before the package statement at the > > start of the file, e.g. "source Java7;". This way a file that is > > pre-7, or lacks a source statement, can be compiled with the existing > > compiler, and a file that is 7 can use the new compiler. > > Issues with this idea were discussed in depth on the Project Coin > list; see > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000249.htmlhttp://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000512.html > > > 2. When a feature is heavily asked for, e.g. better inner classes / > > closures, then the minimum feature set, i.e. something like CISE plus > > a nifty collections library, could be implemented. > > Whom specifically do you propose to implement them? > > To get started, the source code for OpenJDK 7 is > here:http://hg.openjdk.java.net/jdk7/jdk7 > > [snip] > > > > > > > On a more negative point, project coin was announced with various > > suggested ideas: > > > Strings in switch, more concise calls to constructors with type > > parameters, exception enhancements, ability to call with methods with > > exotic names, and (possibly) bracket notation to access collections. > > > The final list is: > > > Strings in switch, *Automatic Resource Management*, more concise calls > > to constructors with type parameters, *simplified varargs method > > invocation*, *better integral literals*, *language support for > > Collection literals*, ability to call with methods with exotic names > > (*and rest of JSR 292*), and (possibly) bracket notation to access > > collections. > > > The differences between the initial and final proposal lists are > > highlighted above. Half the final list was on the original list. This > > does not seem like a hugh change given the amount of discussion on > > project coin. > > There were both additions and deletions to the initial list as well as > development of details of specific proposals. Only two of the finally > accepted proposals were written by Sun engineers, strings in switch > and JSR 292. Observing that a number of ideas on the initial list to > seed discussion were also accepted proposals in the end doesn't > necessarily imply anything untoward if the ideas and proposals were > good ones. > > -Joe > > > > > Back to the positive points. The project coin process did provide for > > open documented discussion of options, which as far as I can tell is > > well liked by the community. > > > Cheers, > > > -- Howard. > > > On Sep 6, 5:11 pm, Fabrizio Giudici <[email protected]> > > wrote: > > > > Reinier Zwitserloot wrote: > > > > Hence, I don't really care what the wider java community > > > > thinks or wants. I care about what the vocal minority wants. > > > > > NB: Casper Bang makes a pretty good case for #2 as well (meritocracy > > > > beats democracy in matters of language design). Couldn't agree more, > > > > more Casper. > > > > Good points, but I still see troubles: > > > > 1. You're assuming that the "vocal" people are the smartest guys (= > > > winners in a meritocratic context). I doubt that the two groups are the > > > same, even though it's clear that some of the vocal people are smart. > > > 2. Even pretending the previous point is a non issue, you're assuming > > > that what the smartest people decide is good for the masses. This is not > > > always true. > > > > The second point is very complex to explain, so I'm trying with an > > > example. One of the recurring criticism about why Java is too > > > conservative, or why more modern APIs haven't been developed, is the > > > constraint about binary retro-compatibility. Managing a breakage in > > > retro-compatibility is a matter of being good in software development > > > practices, basically refactoring and testing. It sounds quite obvious to > > > me that the smartest guys are pretty good in those practices, so it they > > > called for breaking retro-compatibility, it wouldn't be absurd *in their > > > perspective*. Unfortunately, 95% of the world doesn't work with best > > > practices, doesn't test (enough) and fears refactoring like hell. Break > > > retro-compatibility and you'll have tons of people lag with older Java > > > versions for years, and when they are forced to switch the up-to-date > > > Java will be so different from what they're working on that they will > > > have equal chances to move to something else (not counting those that > > > will move sooner, angry for the break). Voilà, in a few years this would > > > turn a mass-language into an elite language. > > > > -- > > > Fabrizio Giudici - Java Architect, Project Manager > > > Tidalwave s.a.s. - "We make Java work. Everywhere." > > > weblogs.java.net/blog/fabriziogiudici -www.tidalwave.it/blog > > > [email protected] - mobile: +39 348.150.6941 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
