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. This way mixed, pre & post 7, projects can be compiled and they can pick up the correct API via the module system (this is effectively how mixed language projects work at the moment). 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. At a latter date more features could be added, e.g. support for even shorter syntax, enclosing return statements, function types (structural typing), and user defined control structures if the need was still felt by the community. Some care is needed when introducing the starting proposal to ensure that it can be extended at a latter date (in the case of inner classes / closures at least this does not seem impossible). 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. 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 <fabrizio.giud...@tidalwave.it> 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 > fabrizio.giud...@tidalwave.it - 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
