I think it might be time for a bit of a reset of this thread, since it seems to have wandered off into the rough.
Firstly, perhaps folks out to go back and listen to the first 20 minutes of episode 277. The emphasis of that discussion was in no way bullying anyone from the pulpit, not negative in context, it was more of a "hey, isn't this Lombok a clever way around the current obstacles facing engineers that want to cut boilerplate in Java code". We at no time mentioned names, called anyone out, and the only thing that might have been considered a criticism was the frustration expressed at the speed with which specs are approved or not approved - stated very much with the JCP in mind, not Sun! Somehow this got personal, and I assure it was not us that made it so. Other threads in this group tell a larger story. Lombok does not seem to be popular with some folks and they are very negative about it. This is a harmful approach I believe. Even in the discussion on 277 we noted concerns about the implementation, and the reliance on IDEs, certainly we do not consider it a silver bullet or anything like that, just an interesting idea that also solves the concerns about all of us sharing one language and platform. If you don't want to use the features in lombok or libraries like it, then don't, and you are unaffected. If you do, then do so, and you affect no one else. Seems like a good solution that should keep everyone happy. I don't know if it is something in the water recently - maybe the economic downturn - but this constant assumption that the Java Posse are bullies, or lapdogs, or tabloid journalists, etc. seems to be coming up more and more. It's disappointing (perhaps you guys forget that we also are volunteers trying to put out content to the public, perhaps it's not open source software, but my 15-20 hours a week of effort are on a par with the kind of effort I would be able to put into open source software development). Returning to the comments about BGGA, I think the issue here is not the closures themselves, but more that Neal put in a tremendous amount of work and did everything by the book, and the result of the refusal of closures has harmed the perception that putting in that much work will make a difference. Neal has also stated here and on other blogs about this issue that he not only had a working prototype of the exception multi-catch language change but also volunteered time to complete it in isolation of closures, and that point has not been addressed by anyone, either to explain why he was not taken up on the offer, or to correct the record. If someone with the skills and energy of Neal doesn't get his chance, is it any wonder people are looking for more reliable ways to make a difference? In closing, we are always careful not to call anyone out, bully them, or abuse our position. We do talk about the issues that are of interest to the audience and there is little doubt that right now frustrations about the Java language, and interest in alternatives like Lombok, appear to be high on the list - just look at the number of comments in this thread. We are going to discuss them, we are going to upset some people when we do, but we don't call anyone out, nor do we ever prevent people from airing their side of things, even giving them air time on the podcast if desired. Personally I don't care for being compared to a bully (I hate bullies), and you will notice that you got your say in spite of the personal attack. As for the Java language changes, I feel like I don't have a tremendous amount invested in them personally, since I am using Scala more and more, but I do find it fascinating to track the ebb and flow of the community around this issue. If we can return to the source of all this, what, in particular, was wrong about the initial discussion on Lombok and other alternatives like it in Episode 277? Cheers Dick On Sep 15, 12:20 pm, Bob Lee <[email protected]> wrote: > 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 [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 -~----------~----~----~----~------~----~------~--~---
