Showing messages 1 through 24 of 24.

• Generic Language Extension Mechanism
  2008-01-18 04:33:29 xylifyx [Reply | View]
  
  We should make one language extension to end all language extensions. That is a sublanguage feature, a syntactic contruction to let you embed regions of other languages into java and specify a compiler extension and an editor syntax coloring extension, debug facilities extensions, code completion extensions that seamlessly let you develop in the sublanguage.
  
  Examples of possible sublanguages: multiline strings, jsp, new loop contructs, domain specific languages, JavaFX, ... some are very simple some extremely complex.
  
  When the competing language Cx develops a new language, the java community could develop a similar extension and developer tool support within weeks, because the extension is optional and severel versions could coexist there would be no need to take it through a commttee.
  
  Think of what the simple language extension mecanism annotations have done. What would be possible with this hyper generic extension mecanism?

• any further changes aka features
  2008-01-17 16:39:27 goddard [Reply | View]
  
  should be avoided. what's the point of adding new language (not library) feature when the previous one has still its, let's say, side effects? it will just add more enthropy. but if those of you that are using java for living feel that closures are the right thing, then i would go the joshua way.

• My opinion
  2008-01-17 02:08:12 jszczepankiewicz [Reply | View]
  
  I think java should follow direction of increased productivity but without changing to scripting like language. If we have generics in java 1.0 there could be generics that behave always predictably without interfering with non generics old code. I have some doubts on closures, maybe because of my little knowledge in that but it they can increase productivity without sacrificing validation and readability of code I am on it.

• ...
  2008-01-16 11:58:44 fabriziogiudici [Reply | View]
  
  

  I agree that "frozen" is too hard for this poll. I'm not in favour of "freezing" in the sense that anyhting is changed, but I only hope in minor changes.

  For what concerns generics, I agree that they are indeed a good addition to the language, that can lead to more robust constructs and for some aspects is more readable (returning a Collection<Date> is more self-documenting than returning a Collection). It's just that they could have been designed in a simpler fashion, as Howard Lovatt recently suggested at Artima. Sun probably tried to do "too much" with them, and this is precisely what I fear from possible further additions. It's better to have minor effective changes, for most dramatic improvements go with a brand new language.

• ...
  2008-01-16 12:00:28 fabriziogiudici [Reply | View]
  
  BTW, when I read about "switch to support strings", I get chills on my back. People should learn to avoid completely switch, or at least dramatically reduce their use, yet you see that they want to use the more and more!
• ...
  2008-01-16 12:01:21 fabriziogiudici [Reply | View]
  
  ... use theM more and more.

• This poll is vague
  2008-01-15 09:41:27 behrangsa [Reply | View]
  
  Is this only about the syntax of the Java language or the APIs, etc. as well? It is not very obvious...

• Freeze...
  2008-01-15 03:38:50 linuxhippy [Reply | View]
  
  I also think that "freeze" is quite a hard word - but I would like Sun to avoid any large, invasive changes like Generics.
  Who cares about Strings in switch statements or synthatik sugar like that, but e.g. I would avoid closures completly.

• No stupid invasive changes
  2008-01-14 13:35:33 dog [Reply | View]
  
  Freeze is too strong of a word. But no invasive changes that aren't really compelling.

  Some reasons for change: better support for parallelism.

  But in general adding things just because other languages have them is dumb. Generics added little value for example. I fear closures will add little value as well.. but maybe they're but syntactic sugar to anonymous classes?

• No stupid invasive changes
  2008-01-15 10:13:11 behrangsa [Reply | View]
  
  

  
  Some reasons for change: better support for parallelism.
  

  
  
  Syntax-level change or API-level and/or VM-level changes? No to syntax-level changes...
• No stupid invasive changes
  2008-01-15 12:09:22 dog [Reply | View]
  
  I dunno.. there are people that have all sorts of experience w/Parallel languages that know the answer to this. I sure don't.

  I just say change if you need to.. but don't just change for change sake. But an example of why you may want a syntax change is the parallel for-statement Fortress has.. But maybe anonymous classes could be used as closures to support that parallelism.

• No stupid invasive changes
  2008-01-14 15:51:20 hontvari [Reply | View]
  
  For me, coming from C++, even after coding in Java for five years, generics was the most missing feature of Java... and I was reminded of that every 5 minutes when I wrote down the declaration of a collection variable.
• No stupid invasive changes
  2008-01-15 12:18:55 dog [Reply | View]
  
  I also came from C++. One big reason was I hated the stupid templates code they added and all that STL junk.

  If I wanted to continue in that path then I could just continue using C++.

• Generics are very usefull...
  2008-01-14 04:27:51 alski [Reply | View]
  
  ...anyone that's spent time chasing runtime exceptions (class casts et al) rather than use a type safe construct knows the value of generics. The beauty of them is that you pick when to use them, you're not forced to. I think that they are readable much more so than looking at some non-typed list and having to "guess" at what can go into the list without causing problems. Simplicity comes at a cost, maintainability in many cases. As for closures, why?
• Generics are very usefull...
  2008-01-15 09:52:16 behrangsa [Reply | View]
  
  I am not in favor of adding closures as well, but your argument about generics is not very solid. One could have said the same thing about closures: "anyone that's used closures knows the value of closures."
  
  I am in favor of Josh Bloch's proposal to remove wildcards from generics. Also please lets go for reified generics!

• missing option
  2008-01-14 04:00:01 pepe [Reply | View]
  
  IMO, the poll needs to split the 'no' into two versions:
  -No, but take greater care in adding new features -No, let it evolve as much as possible.
  

• not really but yes
  2008-01-14 02:33:14 pepe [Reply | View]
  
  I would like the language not to be frozen, but i think that we need to think more on the useability of the language.
  We need to keep java being a clean language, easy to read from the blink of an eye by any java-able person.
  Java learned from the mistakes of the others (and missed some, but this is an other story). Let's follow this road, looking at how those "so necessary" features go in other languages then adapt, if they are successful in ... 4 or 5 years...
  In the meantime, not only everyone will be prepared to the ideas developed (how many persons really understand closures, in all their forms? come on ) but eventually much better solutions will come out which will please everyone. Eventually those ideas will grow from discussion and/or from analyzing other languages failures and successes.
  Too rapid evolution is something .net people bitch about. Great things take time.
  
  One thing i learned from my mistakes is:
  "better is the ennemy of good"
  
  
  
  
  
  
  

• No freeze, but mainly evolve the APIs
  2008-01-11 13:29:25 aehrenr [Reply | View]
  
  The main evolution of Java should be in the APIs and the platform (e.g.. multimedia, platform integration, mathematics APIs ...) . In the language itself should be relatively few, wisely chosen changes and they should focus on simplifications (and removing idiosyncrasies from generics). And the additions to the core language should always have a good sense of proportion between the gain of power and the complexity. The BGGA closures especially the control invocation syntax is a good example how not to do it. I am for simplifying the usage of inner classes like the CICE proposal. It gives you most of the benefits of closures at reasonable complexity
• No freeze, but mainly evolve the APIs
  2008-01-13 15:36:23 wadechandler [Reply | View]
  
  I agree. I think languages changes should be thoughtful and very deliberate, and also believe the platform and APIs need to evolve more next than anything once the new plugin architecture is in place (277) in Dolphin.
• No freeze, but mainly evolve the APIs
  2008-01-15 09:41:44 behrangsa [Reply | View]
  
  Please! Just choose one of OSGI or JSR 277 and let the other one be forgotten for good! It is nonsense to have two competing specifications from the same organization!!!

• It should have been frozen at 1.4.
  2008-01-11 10:21:26 afishionado [Reply | View]
  
  

  Seriously, the only new language feature in Java 5 that is useful is enums.

  Generics are a disaster. The idea was a mess in C++, and a mess in C#. What made anyone think that Java would be different?

  The "enhanced" for loop and autoboxing serve ... what purpose, exactly? So you can save ten keystrokes when you build a loop? Hint: It doesn't hurt to type with both hands, people.

• It should have been frozen at 1.4.
  2008-01-16 07:10:41 arae [Reply | View]
  
  We use generics a lot for nested maps and sets. What is the point of a strongly typed language with untyped containers? Also the enhanced for loop makes for much more readable code.
• It should have been frozen at 1.4.
  2008-01-13 15:34:39 wadechandler [Reply | View]
  
  I think if you are using them often then you will answer your own question. They are very helpful especially for eliminating casting code and making for better type safety. The new for loop comes in very handy if you start using it. I love it now, but I use to think the same thing. Use them more, and you'll find better utility in these changes.
• It should have been frozen at 1.4.
  2008-01-15 09:26:38 behrangsa [Reply | View]
  
  For a considerable number of cases the enhanced for loop is useless:
  
  when you need the index of the element. I prefer
  
for (int i = 0; i < coll.size(); i++) {
// do somehing with i
// do something with coll.get(i);
}

  rather than
  
int index = 0;
for (Clazz elem : coll) {
// do something with index
// do something with elem
}

  In the first approach, the scope of i is just the for block, while in the second case, i is also accessible in the parent block. If we could somehow get a counter variable in the enhanced for loop maybe I would have changed my mind.