Dick, It really irks me to see you bully Joe from your pulpit like this. Comparing your job to his is comparing apples to oranges. I'm quite certain you wouldn't get paid to work on your *closed source* product if it didn't make a profit. The fact is, Sun doesn't profit from adding features to the Java programming language. You are not a paying customer. Sun is not a charity. Luckily for us, Sun open sourced Java so other companies can contribute, and other companies do. Google is actually behind 4 out of 7 of the proposals in project Coin.
It's also worth noting that Project Coin doesn't have a monopoly on language changes. It's just one JSR with the stated purpose of combining a small # of small language changes. If you don't like the way Project Coin is run, submit a separate JSR for your language change. I personally wrote the Simplified Varargs Method Invocation proposal. What at first seemed like the simplest proposal (just moving some warnings around) turned out to be anything but. Compare: Initial proposal: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000217.html Followup: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000316.html The first proposal failed to account for edge cases like overriding a varargs method where the varargs have a non-reifiable component type with a method that takes an array with a reified component type. If unaddressed, these kinds of holes can easily result in a change doing more harm than good, a change that ultimately hurts Java instead of helping it. It's not enough just to consider the benefits of a change. You also have to consider the negative consequences. If we can't come up with a design where the benefits outweigh the drawbacks greatly enough, we just have to live without that feature until we come up with a better design. Finally, I'm tired of hearing BGGA described as a perfect language change with no negative consequences. Sun did anything but ignore BGGA. In fact, three of the four letters in BGGA correspond to Sun employees. The main problem with BGGA, in my humble opinion, was that the final remaining author refused to consider a simpler proposal that didn't mandate custom control constructs. If he had, chances are good we'd have closures already. I'm personally not fond of custom control constructs. To support them, you need non-local returns; I think non-local returns are a recipe for puzzlers. It also appeared as though BGGA had two separate custom control construct syntaxes that focused on two specific use cases (one of which is already addressed by a purpose-built construct). I didn't think BGGA did as good of a job as the purpose-built constructs, and it did even worse for a third construct I tried it against. While I'm generally supportive of closures, it's my personal opinion that Java has too much cruft already and we shouldn't complicate it further with custom control constructs. Simpler closures get us far enough. Of course, others vehemently disagree, but it doesn't matter what either of us think individually. The point is, we all share one language, and I don't think it's fair to add features to the language when there is so much disagreement. Thanks, Bob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
