/me stands up an applauds.
On Sep 11, 3:12 pm, Dick Wall <[email protected]> wrote: > Well - back from a mini "vacation" and what a lot got stirred up. I > wanted to clear a few things before hopefully getting together with > Joe and anyone else interested next week to talk through the rest. I > will keep comments short here, mainly due to time, but I am sure this > will not be the end of the story. In brief: > > My comments about "being told they can't" were actually uttered with > the JCP and not Sun in mind - Joe - you added the [by Sun] modifier to > the end (and I find that willingness to claim the link interesting as > well). However, later in the same article you mention " we try to err > on the side of being conservative (saying "No." by default) first to > do no harm, but also to preserve the value of existing Java sources, > class files, and programmer skills". I don't know which "we" you are > referring too here, but this is definitely the source of the > frustration that leads to energetic and talented developers to work > outside the traditional parameters and come up with ideas like Lombok. > I completely stand by what I say - I have heard "we" just say no to > ideas like properties and closures to Java with my own ears, so it's > little wonder people find other ways. > > As listeners to the podcast will know, I am firmly behind Scala as an > alternative, and it is an alternative that suits me well personally. I > applaud efforts like Lombok and others though, that help improve > things and *should* keep everyone happy (after all, they are optional > and do not change the core platform or libraries), and yet many of the > same "we" that are against change in Java also seem to be against > Lombok or even Scala when I talk to them for any length of time. > > The last point I want to make, and the one I find hardest to swallow, > is the inherent assumption that unless someone has the skills or > willingness to work on a prototype of their own, they should not have > an opinion or at least should not be surprised if that opinion is > ignored or refused. > > Let's think about that another way. We are all developers here (well, > I would imagine most are that are reading this). If I applied that > attitude to my own job, the scientists and other subject matter > experts (who frankly know a lot more than me about the stuff that > matters) would never get what they need to do their job. I would be > insisting that they write up a prototype before I would implement a > solution for them. It is my *job* to translate those wishes into > actuality for them. That is the role of a software developer. In other > words, they are my customers, and their opinions are actually far more > important than my own, since they know what they want out of a genetic > calculator, or lab sample tracking system, or whatever else. Can I do > everything they want - well, no - I am resource limited just like > yourselves, but will you ever hear me tell them that they absolutely > can't have something unless they do it themselves, no you won't, nor > will I discourage them from working on something themselves. > > Any time I hear someone working on a compiler telling a developer that > they don't need that feature or they don't understand what they are > asking for, I cringe. The people using the Java language likely at > least have a clue what they need - maybe you can't listen to a single > voice, but when enough people ask for something, even if they are not > language experts, surely you should still listen? It is great that you > guys are language and compiler experts, for the reason that it frees > me and others like me to do what we need to do (could you write a > human genome risk calculator?). My answer for much of my recent work > has been to use Scala, as that solves my problems and meets my needs > much better than Java does now, others will find their own way, but > requiring everyone to submit prototypes before a proposal will be > considered I think is just a handy excuse to retain the status quo, > and honestly you can't stand in the way of progress - it will simply > find another path. > > I look forward to talking through these points in more detail soon. > > Cheers > > Dick > > On Sep 2, 8:44 pm, jddarcy <[email protected]> wrote: > > > > > After listening to episode 277, I'm led to conclude I'm thought of by > > some as one of the "ivory tower guys" who "just says no" to ideas > > about changing the Java programming language. > > > I have a rather different perspective. > > > In November 2006, Sun published javac and related code under the > > familiar GPLv2 with Classpath exception. [1] > > > Shortly thereafter in January 2007, no less a Java luminary than James > > Gosling endorsed the Kitchen Sink Language (KSL) project. [2] In > > James' words KSL is "A place where people could throw language > > features, no matter how absurd, just so that folks could play around" > > since he has "... never been real happy with debates about language > > features, I'd much rather implement them and try them out." > > > KSL received no significant community response. > > > Later in 2007, after the remaining core components of the platform > > were published as open source software as part of OpenJDK during > > JavaOne, in November Kijaro was created. [4] Kijaro is similar in > > spirit to KSL, but not does require contributors to sign the Sun > > Contributor Agreement (SCA). Before Project Coin, Kijaro saw a modest > > number of features developed, fewer than ten, which is also not a > > particular vigorous community response given the millions of Java > > developers in the world. > > > The earliest posts on what would become Project Coin mentioned the > > utility of prototypes, the Project Coin proposal form included a > > section to provide a link to an optional prototype, and I repeated > > stated throughout Project Coin the helpfulness of providing a > > prototype along with a proposal. > > > Despite the availability of the OpenJDK sources for javac and the > > repeated suggestions to produce prototypes, only a handful of > > prototypes were developed for the 70 proposals sent into Project Coin. > > > Dick asked rhetorically during the podcast whether alternative > > projects exploring language changes were inevitable as the "only > > approach given strict control exercised over the JVM [by Sun]." > > > IMO, such approaches are inevitable only if Sun's repeated efforts to > > collaborate continue to be ignored. > > > Classes on compilers are a core component of many undergraduate > > compiler science curricula. All the Java sources in the JDK 7 > > langtools repository adds up to about 160,000 lines of code and javac > > itself is a bit over 70,000 lines currently. These are far from > > trivial code bases and some portions of them are quite tricky, but > > implementing certain changes isn't that hard. Really. Try it out. > > > Dick says toward the end of the opening segment "If people do want to > > do this stuff, right now they are being told they can't." > > > I certainly do not have the authority to tell others what they can and > > cannot do. Indeed, I have advocated producing prototypes of language > > changes as a much more productive outlet than whining and pouting that > > other people aren't busy implementing the language changes you want to > > little avail. Others have already noted in previous messages to this > > group the irony of Lombok using the annotation processing facility I > > added to javac in JDK 6 as an alternate way to explore language > > changes (together with an agent API to rewrite javac internal > > classes!) . However, way back before JDK *5* shipped in 2005, we at > > Sun recognized that annotation processors by themselves would be a > > possible way to implement certain kinds of de facto language changes. > > The apt tool and later javac were always designed to be general meta- > > programming frameworks not directly tied to annotations; for example, > > an annotation processor can process a type containing no annotations > > to, say, enforce a chosen extra-linguistic check based on the > > structure of the program. > > > As an example of what can be done just using annotation processing, > > long-time annotation processing hacker Bruce Chapman implemented > > "multi-line strings" as part of his rapt project [5]; the value of the > > string is populated from a multi-line comment. After repeatedly > > outlining how it would be possible to do so on the annotation > > processing forum [6], I've gotten around to hacking up a little proof- > > of-concept annotation processor based implementation of Properties. > > [7] The user writes code like > > > public class TestProperty extends TestPropertyParent { > > protected TestProperty() {}; > > > �...@proofofconceptproperty > > protected int property1; > > > �...@proofofconceptproperty(readOnly = false) > > protected long property2; > > > �...@proofofconceptproperty > > protected double property3; > > > public static TestProperty newInstance(int property1, > > long property2, > > double property3) { > > return new TestPropertyChild(property1, property2, property3); > > } > > > } > > > and the annotation processor generates the superclass and subclass to > > implement the desired semantics, including the getter and setter > > methods, etc. Using annotation processors in this way is a bit clunky > > compared to native language support, but if people want to experiment, > > the capabilities have been standardized as part of the platform since > > JDK 6. > > > It is technically possible to take the OpenJDK sources and construct a > > version of javac that accepts language extensions; after all, this is > > how we generally evolve the language and also how the JSR 308 changes > > were developed before going back into the JDK 7 code base. > > Additionally, the IcedTea project and the shipping of OpenJDK 6 in > > Linux distributions has provided an existence proof that folks other > > than Sun can take the entire OpenJDK code base, add > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
