Me too, that was a great response.
On 12 Sep., 13:36, Michael Neale <[email protected]> wrote:
> /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
-~----------~----~----~----~------~----~------~--~---
