#277: Not a view from an ivory tower

[jddarcy]

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 various patches
and additional components to it, and ship it as a product.

Given the OpenJDK sources Sun has published, subject to the license
and trademark terms and conditions, anyone is free to implement and
use language changes, *as long as* they assume the costs and
responsibilities for doing so. Experimentation has long been
encouraged and experiences from experiments using language changes on
real code bases would certainly better inform language evolution
decisions. Unfortunately, others have generally not done these
experiments, or if the experiments have been done, the results have
not be shared.

I also do not have the power to prevent others from using non-Java
languages on the JVM or to force others to run anything on the JVM,
nor would I want to exercise such powers even if I had them. Indeed,
for some time Sun has endorsed having additional languages for the
platform and the main beneficiary of John Rose's JSR 292 work will not
be the Java language, but all the non-Java languages hosted on top of
the JVM.

I do have the authority to speak on what Sun will and will not spend
our resources on in relation to Project Coin, certainly a right any
organization reserves to do with its resources.

If there are frustrations waiting for Java language changes, I assure
you there are also frustrations working on Java language changes. For
example, I find it frustrating (and self-inconsistent) that people
state "I don't have technical expertise in this area" while
simultaneously expecting their preferences to be selected without any
contribution on their part. [8]

Finally, going back to a white paper from 1996, the design of Java
quite intentionally said "No!" to various widely-used features from
the C/C++ world including a preprocessor and multiple inheritance.
Again since the beginning, Java admittedly borrowed features from many
other established languages. [9] Given the vast number of potential
ways to change the language that have been proposed, many language
changes will continue to be called and few will continue to be
chosen. In any endeavor there is a tension to balance stability and
progress. For the Java language, given the vast numbers of
programmers and existing code bases, 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.

There are many other fine languages which run on the JVM platform and
I expect the Java language to continue to adopt changes, big and
small, informed both by direct experiments with prototypes and by
experiences with other languages.

-Joe Darcy
Project Coin Lead

[1] http://blogs.sun.com/ahe/entry/javac_open_sourced

[2] https://ksl.dev.java.net/

[3] http://blogs.sun.com/jag/entry/compiler_fun

[4] https://kijaro.dev.java.net

[5] https://rapt.dev.java.net/; see also Bruce's https://hickory.dev.java.net/

[6] http://forums.sun.com/forum.jspa?forumID=514

[7] http://blogs.sun.com/darcy/entry/properties_via_annotation_processing

[8] http://blogs.sun.com/darcy/entry/project_coin_final_five#comments

[9] http://java.sun.com/docs/white/langenv

[Joshua Marinacci]

Thanks Joe. I appreciate this response. Any chance we can get a blog
on it to spread around?

[Vince O'Sullivan]

Thanks for your response to criticisms of the lack of significant new
features in Java 7. It is very important to know that there is a
ready line of communication between the people who control a language
and those who use it.

Having said that, could you answer this question...

Which of the new features in Java 7 do you think will do most to
address the current flow of talented programmers away from Java and to
alternative languages (such as Scala, groovy, Python, c#, etc.). Any
why?

[Casper Bang]

As I've communicated to Alex Buckley, I just think the community was
surprised by how few resources Sun would/could put on it. Seems like
this boils down to a conflict of interest between Sun, the JCP and the
people in the trenches. Sun needs to realize how this model appears
from a far and how it restricts further adoption beyond the existing
momentum. Even if the business model accounted for this already, it
will cause harm to Sun's image as entrepreneurs and innovators -
deserved or not.

So my question would be this: With JavaFX currently being marketed as
a fairly narrow RIA technology into a fairly competitive marked, what
if it fails to deliver?

/Casper

> > [5]https://rapt.dev.java.net/;see also Bruce'shttps://hickory.dev.java.net/

[Jess Holle]

All points well taken -- at least by me.

I know what it's like to work as hard as you can towards something and be shot down by criticism that you're not doing anything or not even trying.

That said, a few points:

• Not all of us are compiler experts -- and javac is fairly large and gnarly.
• Doing most things involving more than just compilation syntax or simple changes/additions to core Java classes is rather daunting in OpenJDK.  There were large portions of some presentations at JavaOne outlining just how hard this is when one has to consider native and Java code and their memory interactions with GC, etc.  Also, from everything I've heard, OpenJDK is still a rather gnarly codebase.  Being able to open a top-level project in an [ideally free] IDE on each platform, simply hit "build" and get the same result as Sun, and have full code completion / navigation data would be a really helpful starting point...  Project Maxine really struck me as compelling way out of many of these issues -- but it is in its research infancy and could have been killed for all I know (I never heard it mentioned by Sun folk at this year's JavaOne...).
• Neil Gafter certainly availed himself of javac, OpenJDK, etc, and produced a BGGA prototype.  After all of this work, it went nowhere.  Various Sun folk said they simply had no resources to properly deal with the proposal.  This has to make others gunshy of investing their time and effort.
• There is also a sense that any such effort won't bear fruit for years -- as JDK development cycles are pretty long, JDK feature freezes come pretty early, and at least some of us can't actually use any feature until it is available on all of our platforms in a normal released JDK.  In my case, this platform mix includes AIX, which automatically adds at least a year and usually more beyond Sun's development cycle.  [Yes, this is beyond Sun's control and one of my major gripes with IBM -- that and their lack of consistency with Sun's JVM implementation.]
  
• I desperately want a "controlled" form of multiple inheritance in Java ala traits or mixins.  The reduction in clumsy hand wiring to various delegate objects is clear to anyone who has used such features.  Java has always been extremely clumsy in this regard and this has been clearly evident from day one.  This needs to be fixed!  Just because Sun said no to C++'s complex, problematic, uncontrolled and chaotic multiple inheritance does not mean Java should throw out the baby with the bathwater!  In this case Sun has repeatedly told me and others "no", with no good reason other than a dogmatic "multiple inheritance is bad and will never be in Java".  This is madness.  Simply allowing something like:

public interface MyTrait
{
  public Foo getFoo();

  public void  operateOnFoo()
  {
    // default implementation calling getFoo() as needed
  }
}

would be huge -- and only requires that interfaces be allowed to provide implementation [and something like MyTrait.operateOnFoo() in cases where there is ambiguity between implementations].  One could also introduce a new contextual keyword of "trait" rather than "interface" here for clarity, but that seems unnecessary.

Finally, we did discover the ability to auto-generate base classes via annotation processors.  It's not immediately clear that this is possible from perusing the documentation, but this approach does open up a lot of doors...

--
Jess Holle

[Reinier Zwitserloot]

Joe, I think a very (_very_) large problem with The Kitchen Sink
Language, kijaro, and the open sourced JDK is that you fundamentally
can't solve your own problem with it.

There are exceptions, but the vast majority of java programmers I know
of that are interested in developing their own language features use
an IDE. The reason is fairly simple; people with the ability to reason
about which features they'd want in a programming language rightly
think java is beyond cludgy with a dumb editor. They use the smart
IDEs - generally eclipse, netbeans or IntelliJ, because those source
editors are pretty much the most advanced thing out there, for _any_
programming language. In other words, I firmly believe java would have
died a long time ago if it wasn't for the IDEs. It's no accident,
either; the way java works means that IDEs can do an extraordinary
amount of work for you, far more than in languages such as python,
where refactorings use a lot of weak raw string searches and
guesswork.


All of which is nice, but makes projects like the KSL, kijaro, and
even hacking the openJDK code base not particularly useful. Prototypes
are always nice, but I honestly cannot get a good feel of a new
language feature if I'm forced to program in notepad.

That's what makes lombok so different, and that's perhaps why the
lombok discussion group already has more posts in it inside of a month
than kijaro's in its 2 years. You can actually use it, right now, on
your day to day projects, without having to completely change your
development environment (including IDE, build scripts, etcetera).
Well, not _entirely_, you must be using only eclipse and javac, and
various source-based tools like the GWT compiler and even javadoc
cannot (yet!!) interpret lombok code. But it's close enough; the pain
of having to work around lombok's inadequacies is less than the gain,
and that's of course the key factor.


I'd also like to state my support for Jess Holle's very astute
observation that the first serious attempt to build a fully specced,
fully prototyped proposal (BGGA) got a rather lukewarm response from
sun. The BGGA proposal didn't just have an excellent spec and
prototype behind it, it has received more community support than any
proposal I've _ever_ seen in the history of java. All that, and sun
still doesn't care? That's a pretty cold shower for anybody else
wanting to try what you're suggesting: Building a prototype like you
suggest doesn't at the moment seem to make a big difference in the
likelyhood of that proposal being selected for inclusion into the JDK.

It is certainly why Roel and I built lombok into what it is today;
originally we had a plan to build an alternative closure proposal
(because, for all the praise Neal ought to receive for his work on
speccing out BGGA and building the prototype, I think there's a better
way, but that's not very relevant to this discussion), building on
neal's prototype, but after the non-result of BGGA, I didn't see how
that was going to be useful. To be useful, it had to do at least 1 of
the following 2 goals:

1. Make a lot of headway in getting the proposal into the JDK, and/or
2. be usable by myself during my day-to-day programming work.

As a prototype so far doesn't seem to accomplish goal #1, and (at
least as based on a fork of javac) isn't useful for goal #2, lombok is
an eclipse plugin and a javac annotations processor hack instead. On
that note, thanks much for the APT API - it's nice. The javac API is
also quite clean, I don't really get why Jess thinks the javac code
base is 'gnarly'. It's muuuuuch cleaner than eclipse's ecj.

But, let's not get carried away here - lombok only uses a tiny little
bit of the APT API. What lombok does is fundamentally not supported by
annotation processing. We just use annotation processing as an 'in' -
a way to get our code executed so we can break public API contracts
and dig into javac's innards. As nice as the annotation processing API
is, the cost of being forced to create subclasses is far too great to
justify some relatively small improvement as multi-line strings.

It's like the pair class: There are a few gazillion Pair
implementations out there because the slight benefit of having one is
not worth the burden of adding a dependency on a library, and yet, you
do want the feature, so people work around it. These language
improvements seem similar: For every _SINGLE_ instance where you'd
want it, it's not worth the trouble of building an annotation
processor and having to deal with generated subclasses, but add up all
the times you'd actually use such an improvement, and it's very much
worth it. Lombok solves this problem. KSL/Kijaro/OpenJDK don't.

-- Reinier Zwitserloot

On Sep 3, 4:47 pm, Jess Holle <je...@ptc.com> wrote:
> All points well taken -- at least by me.
>
> I know what it's like to work as hard as you can towards something and
> be shot down by criticism that you're not doing anything or not even trying.
>
> That said, a few points:
>

>     * Not all of us are compiler experts -- and javac is fairly large
>       and gnarly.
>     * Doing most things involving more than just compilation syntax or

>       simple changes/additions to core Java classes is rather daunting
>       in OpenJDK.  There were large portions of some presentations at
>       JavaOne outlining just how hard this is when one has to consider
>       native and Java code and their memory interactions with GC, etc.
>       Also, from everything I've heard, OpenJDK is still a rather gnarly
>       codebase.  Being able to open a top-level project in an [ideally
>       free] IDE on each platform, simply hit "build" and get the same
>       result as Sun, and have full code completion / navigation data
>       would be a really helpful starting point...  Project Maxine really
>       struck me as compelling way out of many of these issues -- but it
>       is in its research infancy and could have been killed for all I
>       know (I never heard it mentioned by Sun folk at this year's
>       JavaOne...).

>     * Neil Gafter certainly availed himself of javac, OpenJDK, etc, and

>       produced a BGGA prototype.  After all of this work, it went
>       nowhere.  Various Sun folk said they simply had no resources to
>       properly deal with the proposal.  This has to make others gunshy
>       of investing their time and effort.

>     * There is also a sense that any such effort won't bear fruit for

>       years -- as JDK development cycles are pretty long, JDK feature
>       freezes come pretty early, and at least some of us can't actually

>       /use /any feature until it is available on /all /of our platforms

>       in a normal released JDK.  In my case, this platform mix includes
>       AIX, which automatically adds at least a year and usually more
>       beyond Sun's development cycle.  [Yes, this is beyond Sun's
>       control and one of my major gripes with IBM -- that and their lack
>       of consistency with Sun's JVM implementation.]

>     * I /desperately /want a "controlled" form of multiple inheritance

> ...
>
> read more »

[Fabrizio Giudici]

Reinier Zwitserloot wrote:
> I'd also like to state my support for Jess Holle's very astute
> observation that the first serious attempt to build a fully specced,
> fully prototyped proposal (BGGA) got a rather lukewarm response from
> sun. The BGGA proposal didn't just have an excellent spec and
> prototype behind it, it has received more community support than any
> proposal I've _ever_ seen in the history of java. All that, and sun
> still doesn't care?

I know I'm going to raise a can of worms :-) but there are some points
that have to be addressed here. It all depends by what "community"
means, but the fact that there are blogs praising a certain feature, or
even a lot of messages in a mailing list doesn't prove that the majority
of the "community" wants that. To be more precise, if you have a lot of
people interested in a given project, e.g. Lombok, which is an optional
tool for Java, everybody is happy: if you get 100, 1.000, 10.000,
100.000 enthusiasts, your project will have a bright future, and the
rest of the Java users (who are millions) who don't know, don't care or
don't like it will still live happy.

Things are different if one pretend that 1.000 or 10.000 people make a
decision to change Java that will affect everybody. My personal
experience is that the vast majority of my customers (I'm talking of
several firms from small to large) don't give a bit for closures (just
to make an example), don't feel they need it, don't feel they like it
and are neutral or negative with them. My personal experience with
forums or mailing lists of various human activities (not necessarily
technological ones) is that they might have thousands of subscribers,
while the traffic is lead by tens of them. Thus, any discussion made by
those tens of persons can't be deemed of representative of the whole
community.

*** I don't think that neither blogs or mailing lists are true
representative of the reality out there (technological, political, or
what else). *** They only make more noise, but the standard rules for
democracy are still "one head, one vote", so they only count for
themselves. That's why, for instance, to elect a government blogs and
such can be thought as influential, but in the end you do count any
single vote.

As I said, this has to do with how do you define community: people who
attend blogs, mailing lists and conferences, or the whole set of users.
Of course I reckon that there is a problem with the latter, as we can't
measure it. Neither I'm pretending that Sun was right in not accepting
BGGA because they allegedly know the wishes or the whole set of users.
Neither I can, of course, pretend that I or my customers are
representative of the majority. But even if we accept the former
definition of community, I think that before declaring that the
community wants something, we need some sort of poll that, while
shouldn't necessarily be as formal and controlled like an election poll,
must be decently structured. For instance, Java.Net polls are not good,
figure out if I think that generically quoting bloggers' enthusiasm is good.

Given that, I'm not proposing to set up such a poll, because I don't
know how to set it up (and nobody says that a technical community is a
"democracy" in the strict sense - in fact, it isn't). A good half+ of my
customers don't even know or read Java.Net, DZone.com or JavaPosse or
attend a JUG, so I wouldn't be able to say how to reach and ask to
everybody. I'm only saying that in this situation, I'm all but
scandalized if Sun takes decisions such as not putting BGGA or other
stuff in the JDK. They can be technically wrong, but I don't think one
can prove they are deciding against the community will.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio...@tidalwave.it - mobile: +39 348.150.6941

[Casper Bang]

Funny enough, I just submitted such a poll to java.net since there are
certainly more average developers following it, than there are
tracking the coin mailing-list. Personally I don't think language
design should be a democratic endeavor exactly for the reasons
outlined by Joe and Alex, things goes just a little bit deeper than
most can fathom. What you *can* find out by asking the community
however, is what they struggle with daily and what would excite them.
And I should add that my definition of a community does not cover the
JCP members who are not really interested in Java per se, but much
more interested in profiting on their latest SOA vendor lock-in.

So as an engineer interested in improving my day-to-day environment I
have only a few options 1) become a cubicle robot and not care about
this stuff at all, 2) be a loudmouth and try to push what I feel is
good taste in programming, 3) find another job where I can choose a
stack that makes me feel productive and passionate again or 4) help in
undermining official Java and put my faith in the grassroots of the
community i.e. Lombok. Given the relatively mute blogosphere
surrounding JDK7, I am probably not the only one contemplating these
options.

/Casper


On 3 Sep., 22:47, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it - mobile: +39 348.150.6941

[jddarcy]

On Sep 3, 5:22 am, Joshua Marinacci <jos...@marinacci.org> wrote:
> Thanks Joe. I appreciate this response. Any chance we can get a blog  
> on it to spread around?
> On Sep 2, 2009, at 8:44 PM, jddarcy wrote:

I've posted a lightly edited copy of my post at
http://blogs.sun.com/darcy/entry/javaposse_277_ivory_tower

[Robert Casto]

1) Works really well for a while. Hard to not care though.
2) Doesn't do much more than make you look like a trouble maker.
3) The grass is always greener somewhere else. Believe me, it is because of the manure.
4) Very commendable but hard to pay the bills. Great if you can make it fit the needs of your current job. Otherwise it ends up becoming a second job.

5) Start a company and make all the decisions. Just need to find something people will give you money for. Best of both worlds but very difficult to pull off.

--
Robert Casto
www.robertcasto.com

[Fabrizio Giudici]

Casper Bang wrote:
> Funny enough, I just submitted such a poll to java.net since there are
> certainly more average developers following it, than there are
> tracking the coin mailing-list. Personally I don't think language
>

I'm not in the coin mailing-list, so I trust your numbers. Still,
looking at the latest 15 polls, the max. number of cast votes is 630.
Sounds quite low compared to the number of people using Java.

> design should be a democratic endeavor exactly for the reasons
> outlined by Joe and Alex, things goes just a little bit deeper than
> most can fathom. What you *can* find out by asking the community
>

I don't think it must be democratic either. Generically speaking, my
point on open source projects is that the best governance model is the
"benevolent dictatorship". Probably, such a widespread project like Java
should go rather with a "benevolent oligarchy", that is to be as open as
possible, without pretending to be democratic. The "democratic deficit"
is compensated with competition: let the oligarchy make its decision on
Java, if the decision is wrong the technology will decline. Amen, it's
the natural selection. While I consider almost useless statistics such
as Tiobe etc, a strong decline could be easily detected. If people start
really thinking that Java-the-language is no more effective for their
needs, they'll use something else (Scala, Groovy, Fan,
whatever-to-be-invented). Fortunately, we have competition at any level.
Eventually, the oligarchy could find the time to compensate a wrong
decision and save the technology - after all, that's what happened with
EBJ 1/2 - > Spring -> EJB 3.

> however, is what they struggle with daily and what would excite them.
> And I should add that my definition of a community does not cover the
> JCP members who are not really interested in Java per se, but much
> more interested in profiting on their latest SOA vendor lock-in.
>

I'm not interested in judging the JCP members, also because I don't know
any. Still, your point about asking what the "community" struggle with
and what would excite them can't avoid facing with the problem of
defining the community. In my partial view of the community, the part
that I can experience, I've already said that almost nobody is
interested in what are usually considered the "hot" topics. I don't
think any can "proof" his own perspective is the right one.

> So as an engineer interested in improving my day-to-day environment I
> have only a few options 1) become a cubicle robot and not care about
> this stuff at all, 2) be a loudmouth and try to push what I feel is
> good taste in programming, 3) find another job where I can choose a
> stack that makes me feel productive and passionate again or 4) help in
> undermining official Java and put my faith in the grassroots of the
> community i.e. Lombok. Given the relatively mute blogosphere
> surrounding JDK7, I am probably not the only one contemplating these
> options.
>

But I agree - I don't think we have to shut up. Shutting up is always a
bad solution. I myself I can show off a good record of "whines" and
complains ;-) especially on some topics (did anybody say "Apple"?).
Still, I don't pretend I'm representative of a majority or a minority.
Also because we tend to work with customers that share our same
sympathies - e.g. I could say that I don't see people around me working
with .NET, but certainly I don't infer that .NET is irrelevant or such.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."

[jddarcy]

On Sep 3, 6:37 am, "Vince O'Sullivan" <vjosulli...@gmail.com> wrote:
> Thanks for your response to criticisms of the lack of significant new
> features in Java 7.  

I was more so responding to the implication that Sun is not seeking
input from the broader community (Sun is part of the Java community of
course) when Project Coin offered an unprecedented invitation for
people "in the trenches" to participate in evolving the Java language.
This invitation to participate always came with the implication of
participating *in the work* of the language changes, including writing
and analyzing the proposals and developing prototypes.

The Java Language Specification has been online for over a decade,
Sun's Java compiler has been open sourced for several years, and blog
entries have been written describing the many tasks that need to be
done to add a language feature to the platform.

Sun is not preventing anyone from undertaking the work of exploring a
language change. Rather, especially with OpenJDK, we have greatly
facilitated such explorations.

> It is very important to know that there is a
> ready line of communication between the people who control a language
> and those who use it.
>
> Having said that, could you answer this question...
>
> Which of the new features in Java 7 do you think will do most to
> address the current flow of talented programmers away from Java and to
> alternative languages (such as Scala, groovy, Python, c#, etc.).  Any
> why?

I would expect programmers to choose the best language and platform
for their programming task, which may be Java alone, a mixture of Java
and some other language, or just some other language. As the Project
Coin changes are by design small, they do not fundamentally change the
scope of programs that are tractable to write in Java. In contrast,
the modularity language work *does* have the potential to meaningfully
expand the set of programs writable (and maintainable) in Java.

[Fabrizio Giudici]

jddarcy wrote:
> Sun is not preventing anyone from undertaking the work of exploring a
> language change. Rather, especially with OpenJDK, we have greatly
> facilitated such explorations.
>
>

Let me add another consideration. The fact that there are a number of
new languages around, and some - good or not - are production-ready
(e.g. Groovy or Scala) demonstrates that the "community" (still using
quotes because of my doubts about its definition) is capable to create a
new language out of the Java platform without Sun support. We also got
IDE support for many of those languages. While I don't want to make any
forecast for the future, Groovy and Scala got even their sub-communities
that are not irrelevant.

So, why doesn't somebody just pull J7 out? I mean, a language that
instead of being a totally new thing such as Groovy or Scala, is
basically "what-the-community-allegedly-wants-for-Java-7". In my point
it would be probably a bad idea, as I prefer Java to stay conservative
and new things to appear on brand new stuff, but people who are asking
to make JDK 7 in a different way clearly think different. The tech tools
are there and have been enumerated by jddarcy.

Pull it out and throw it to the wolves - and let the "community" decide
in the broader sense ("competition") of my previous post.

[Martin Wildam]

On Sep 3, 10:15 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> That's what makes lombok so different, and that's perhaps why the
> lombok discussion group already has more posts in it inside of a month
> than kijaro's in its 2 years. You can actually use it, right now, on
> your day to day projects, without having to completely change your
> development environment (including IDE, build scripts, etcetera).

Really a great idea - I took a short look at Lombok and for instance
this feature here:
http://projectlombok.org/features/Cleanup.html

One question: Whoever really developing in Java for a longer time
(longer than a month) is still coding something like the sample given
at the link above? - The very first thing I have written is a wrapper
method for such cases and I never ever need again to write such a
shitty code portion - yes, that close operations themselves can cause
errors again is shitty, but I even understand the idea behind it and I
accept it as ok! - But this does not mean that I cannot wrap this into
a one-liner!

Another sample:
http://projectlombok.org/features/Data.html
Sorry, but building hashcodes is always not necessarily built again
and again the same way. For a bunch of such annoyances I have built a
library containing a lot of such helpful static methods that solve a
lot of those according to my personal favor.

I am really annoyed of such critics of the language because with a few
minutes of work such things get a one-liner for your future use, so
why bother?

In all more than 10 programming languages used so far in my life I
found annoyances everywhere and I am quite sure that Scala have it's
own which I discover when working for about a month with it. I am sure
that programming languages have still potential to be improved but
there are also things that are just decisions between pro and contra.
Look at GWT and Wicket. Both make sense and have different approaches
with advantages and disadvantages. On framework or library level you
can easily choose that what fits your needs but when it comes to core
languages you can't make everything a matter of choice. You must
decide whether to implement it that or another way. Java somehow also
wants to keep the core simply with not too many possible variants of
how something could be written. I think it is important to keep the
core language simple so that it can be easily learned by the younger
people growing up and learning.

If you make a programming language too complex you will have in a 20
years only a very few people left who really know the language.

Please don't get me wrong I am also happy about language improvements
- as for instance using strings in switch statements - although this
also can be workarounded by using enums.

To have such enhancements as libraries that you can include then it is
awesome - because everybody who wants to use it, can use it - and for
those projects where it makes sense. Lombok offers this as far as I
have noticed which is cool!

[Casper Bang]

Poll is now running on java.net:
http://www.java.net/poll/what-your-reaction-jdk-7-feature-list

/Casper

[Paul King]

Was the poll trying to determine a response to all jdk7 features -
there are some significant ones, e.g. JSR-203 - or just the project
coin ones?

Cheers, Paul.

[Casper Bang]

Java 7, public speak for JDK7 and thus not only the Coin stuff. Things
are somewhat reversed as we don't have an umbrella JSR (yet?).

/Casper

On 5 Sep., 02:12, Paul King <paul.king.as...@gmail.com> wrote:
> Was the poll trying to determine a response to all jdk7 features -
> there are some significant ones, e.g. JSR-203 - or just the project
> coin ones?
>
> Cheers, Paul.
>

[Alex Buckley]

I have to ask: how is it different to http://java.net/poll/whats-your-view-emerging-jdk-7
?

[Casper Bang]

Well we now know the upper bound of the subset that could possibly
make it in, no? That's what I though anyway. You'd know that better
than me so correct me if I am wrong.

/Casper

On 5 Sep., 03:24, Alex Buckley <alex.buck...@sun.com> wrote:
> I have to ask: how is it different tohttp://java.net/poll/whats-your-view-emerging-jdk-7

[Casper Bang]

If I have misunderstood something, I am not alone in this, as the
editor publicaly writes "At the time of that poll, the specific
features that will be included in JDK had not been finalized. Now that
the list is out, it's a perfect time get people's reassessed view of
the JDK".

You will kindly correct us if this perception is wrong?
---
Sent from my G2, pardon any typos.

[Michael Neale]

Thats a lot of words.

Don't confuse the millions of users with the vastly smaller subset who
are able to add features to a language (or build their own language)
and the tiny subset of that set that would actually want to, with java
(when so many silly attitudes exist - law of averages and all that).

> [5]https://rapt.dev.java.net/;see also Bruce'shttps://hickory.dev.java.net/

[Michael Neale]

On Sep 3, 1:44 pm, jddarcy <jdda...@gmail.com> 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 am pretty sure they weren't referring to you or people like you at
all - more to the "paper tiger" style architects from The Enterprise
(and not the starship). (probably should make your post into a blog !
which I think someone suggested).

[Reinier Zwitserloot]

Fabrizio, I sort of agree with the gist there, but I don't think
that's particularly relevant. For these two reasons:

1. Regardless of how many people _want_ closures, the amount of effort
put in by Gafter in writing the spec and the proposal, and the sheer
amount of community involvement, is staggering. I cannot imagine any
other proposal gaining more traction. It doesn't really matter wether
closures are a good fit for java or not at this point - the
_appearance_ has been created that using a prototype + spec written
outside of sun and the JCP process, instead focussing on the (vocal)
java community, appears to be fundamentally not suited to making
change happen. Neal tried it and went all out, nobody thinks they
could match the effort and the response. Contrast this to Joe Darcy's
complaint about lukewarm response to Kijaro/JSL/coin prototypes, and
the link becomes clear: By waffling on the closure issue and now
having (apparently) dropped the idea altogher, not even giving the
BGGA community the benefit of some sort of semi-official status,
that's extremely discouraging. I speak from some experience; I haven't
bothered with prototypes for project coin because I wasn't convinced
it would make a difference. This isn't really a thing where Sun is
actively dropping the ball, but them's the breaks - that's how (some)
people (probably wrongly) see the BGGA situation. I'm mostly blaming
the java features team of pretty bad marketing if they want the
community to play around with prototypes.

2. The larger java community doesn't have a clue about what's good for
them. There's a staggering historical proof for this idea. Just look
at java's recent past: Generics in particular received a massive
amount of resistance in the runup to the java5 release, and yet few
people other than the perpetual whiners think generics were a bad idea
altogether now, with hindsight on their side. The only significant
continued resistance against generics generally holds that generics
didn't go far enough and should have broken backwards compatibility to
add reification and more. There's also the usual bitty about "design
by committee" being a pretty poor way of going about making changes.
Java is probably a bit too big and important for a single dictator,
but some sort of meritocracy works _very_ well indeed for something
like linux. "Being vocal" on the internet is sometimes just being a
loud bag of hot air, but more usually it means someone has quite a
following. They've earned their status as a loudmouth, in other words,
and you should be listening to them more closely, and not to Joe
Schmoe java user. The vocal minority DO have to prove they are
thinking of Joe Schmoe. (e.g. keep simplicity and the learning curve
in mind - and something many java feature advocates forget about). It
feels a bit evil and not very democratic, but history and practicality
suggest the meritocracy model works far better than pure democracy in
such matters. Hence, I don't really care what the wider java community
thinks or wants. I care about what the vocal minority wants.


NB: Casper Bang makes a pretty good case for #2 as well (meritocracy
beats democracy in matters of language design). Couldn't agree more,
more Casper.


On Sep 3, 9:47 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

[Reinier Zwitserloot]

So, after careful review of all the posts in this thread, I seem to
have misjudged Fabrizio's support for the democratic model. I'll leave
the previous post primarily for my point about how the failure of the
BGGA proposal is not good marketing for community experiments based
around javac-based prototyping. It also ought to go without saying
that I'm biased, as developer of projectlombok.org

[Fabrizio Giudici]

Reinier Zwitserloot wrote:
> Hence, I don't really care what the wider java community
> thinks or wants. I care about what the vocal minority wants.
>
>
> NB: Casper Bang makes a pretty good case for #2 as well (meritocracy
> beats democracy in matters of language design). Couldn't agree more,
> more Casper.
>

Good points, but I still see troubles:

1. You're assuming that the "vocal" people are the smartest guys (=
winners in a meritocratic context). I doubt that the two groups are the
same, even though it's clear that some of the vocal people are smart.
2. Even pretending the previous point is a non issue, you're assuming
that what the smartest people decide is good for the masses. This is not
always true.

The second point is very complex to explain, so I'm trying with an
example. One of the recurring criticism about why Java is too
conservative, or why more modern APIs haven't been developed, is the
constraint about binary retro-compatibility. Managing a breakage in
retro-compatibility is a matter of being good in software development
practices, basically refactoring and testing. It sounds quite obvious to
me that the smartest guys are pretty good in those practices, so it they
called for breaking retro-compatibility, it wouldn't be absurd *in their
perspective*. Unfortunately, 95% of the world doesn't work with best
practices, doesn't test (enough) and fears refactoring like hell. Break
retro-compatibility and you'll have tons of people lag with older Java
versions for years, and when they are forced to switch the up-to-date
Java will be so different from what they're working on that they will
have equal chances to move to something else (not counting those that
will move sooner, angry for the break). Voilà, in a few years this would
turn a mass-language into an elite language.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."

[Reinier Zwitserloot]

Whether or not it'll be legal in java7 isn't too relevant to lombok;
lombok can change whatever it wants, including the grammar. If there's
a compelling lombok transformation that requires the ability to
annotate a stand-alone codeblock, we can change the grammar to make
that legal. Allowing @Synchronized on a block would be kind of nice.
Not high priority, but I'll keep that in mind. For most other 'what if
we annotate the code block?' kind of features, it usually makes more
sense to create a new keyword or some other new syntax.

On Sep 6, 5:11 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

[Reinier Zwitserloot]

There's _no_ guaranteed right answer for language evolution. The
meritocracy can get it wrong, and one can make mistakes in creating
the selection criterion for what 'merit' implies (such as listening
solely to loudmouths - though in practice some of the folks
complaining have been playing around with other languages, prototypes,
and/or spinoff projects, which should all count as suitable technical
merit).

However, even if your meritocracy isn't working quite as effectively
as it could, it'll beat democracy hands down.

On Sep 6, 5:11 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

[Dick Wall]

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 <jdda...@gmail.com> 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.
>

[Viktor Klang]

Nuff said

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

[Michael Neale]

/me stands up an applauds.

> ...
>
> read more »

[Casper Bang]

Me too, that was a great response.

[Bouhamza Khalil]

Since this is my first post on the javaposse, I would like to give my
most warm thanks to the posse members, I've been listening to the
podcast for a number of years now, you made a terrific job of it,
giving a very valuable service to the community.

Here's my perspective on java language evolution and specifically
about closures.

I believe closures didn't it into JDK7 plans for two reasons:
- Lack of high qualified resources to take over the java language design
- Not enough community consensus around the BGGA proposal

The closure debate went live when Neal Gafter published the BGGA
closure proposal August 2006. It came roughly two years after the Java
Tiger release. After tiger a number of very talented individuals
involved in the Java language stewardship did leave Sun, the very
publicized ones were Joshua Block and Neal Gafter. The bleeding
didn't stop then, it continued while was google thriving, three months
after the initiation of BGGA, Gilad Bracha the 'B' in BGGA was joining
Cadence Systems, soon to be followed by Peter Von Ahe, the A in BGGA.
My impression is that within Sun, there are fewer and fewer people
that are up to the task of changing a language such as Java, one with
such a huge user base. Currently there seems to be far too few Alex
Buckleys and Joe Darceys, sure there remains others but unfortunately
not working on the Java language such as Guy Steel or Brian Goetz.

Neal Gafter did a truly magnificient job developping the specification
and the prototype for closure. He did illustrate the need for them,
why anonymous inner classes don't qualify, the use of closures with
the existing APIs, Exception transparency and much more. The prototype
was of a high quality and quite complete with a patched javac and
Javdoc. IDE support could have followed since Netbeans uses javac.
However the point of views were quite divergent, there were three
leading closures proposals but the central question was whether
closures were a good fit for Java. Neal's proposal was in contrast of
the CISE proposal which was just syntactic suger on anonymous inner
classes. In java there are many hurdles to overcome for a closure
implementation chiefly:
- the use of return
- break and continue
People exposed to Scala find closure extremely natural, one of the
resaons is that everything in Scala is an expression, there are far
fewer return statements in Scala compared to Java. Within project coin
Neal Gafter had a proposal for block expression, which could pave the
way to closures, unfortunately the proposal didn't get a lot of
traction. Tiger was a major release with a number of game-changing
features, enums annotations and Generics. Generics implementation with
erasure and wildcards, was criticized quite widely in the blogsphere,
people who didn't look favourably upon closures did feel that Java has
reached a complexity tipping point, and closure would just push the
language into the void. Critics over Generics were not completely
unfounded, in Tiger for example Doug Lea and team did not get
invokeAny and invokeAll method signature right in ExecuterService, the
signature was subsequently changed in JDK 1.6. Joshua Block was one of
the most vocal critics of the BGGA proposal. In Javapolis 2007 he
actually chnaged his presentation from "Effective java reloaded" to
"The closures controversy" see
http://parleys.com/display/PARLEYS/Home#title=The%20Closures%20Controversy;slide=1;talk=5210267.
Now that the dust has settled around generics, with frameworks such as
Wicket after much debate adopting them, with PECS mnemonic thanks to
Joshua Block, and Scala type system exposure, closures have gained in
mind share, but back then Joshua Block's message was quite effective.

I can understand Joe's Darcy pragmatic position, given the limited
resources to constrain the problem domain to one that small language
changes could address, these efforts could indeed be completed within
a reasonable JDK7 time frame, but I can also see Dick's point, that in
doing so, it is turning down innovative ideas and diverting community
contributions, what Java is actually needing most.

Finally I'd like to hail Neal Gafter efforts, his posture has been
exemplary throughout, even after closures rejection, he is still
contributing positively and eagerly to the java ecosystem, an example
to follow.

Cheers,
Khalil

On Fri, Sep 11, 2009 at 7:12 AM, Dick Wall <dick...@gmail.com> wrote:
>

[Reinier Zwitserloot]

I really don't think anybody here is seriously trying to argue the
case that the BGGA proposal was a complete no-brainer.


The problem of an entirely different nature: A proposal with the
effort and momentum of BGGA was simply not reacted on by sun. Sure, a
blog here, a blog there, but nothing official, for a very long time.
The few official words uttered were lackluster.

I'm not happy about it, but if sun wants to take it that slowly,
that's their prerogative. Where I take exception, is when Joe Darcy
complains about lack of community input. I call truth distortion: Of
course there's no community input. You killed it. Communities don't
just magically show up on your doorstep. They grow. And to grow, you
need to nurture them. For what its worth, project coin is heading the
right direction. Even replying to the java posse and to project
lombok, is heading in the right direction. Finally opening up a bit
about the module system, is sort of heading in the right direction,
but if there's one complaint the OSGi fanclub is right about (and it
would certainly be the only complaint they're right about), is that
the technical documentation is a bit scarce.

But this is not nearly good enough to rekindle the community that got
killed off when BGGA was left to go out with a whimper.

> "The closures controversy" seehttp://parleys.com/display/PARLEYS/Home#title=The%20Closures%20Contro....

> >> Contributor Agreement (SCA).  Before...
>
> read more »

[hlovatt]

BIAS DISCLAIMER - features mention below are favored by me!

The tension between backward compatibility and introducing new
features seems be the problem, there are ways out of this problem,
e.g.:

1. Introduce a source statement before the package statement at the
start of the file, e.g. "source Java7;". This way a file that is
pre-7, or lacks a source statement, can be compiled with the existing
compiler, and a file that is 7 can use the new compiler. This way
mixed, pre & post 7, projects can be compiled and they can pick up the
correct API via the module system (this is effectively how mixed
language projects work at the moment).

2. When a feature is heavily asked for, e.g. better inner classes /
closures, then the minimum feature set, i.e. something like CISE plus
a nifty collections library, could be implemented. At a latter date
more features could be added, e.g. support for even shorter syntax,
enclosing return statements, function types (structural typing), and
user defined control structures if the need was still felt by the
community. Some care is needed when introducing the starting proposal
to ensure that it can be extended at a latter date (in the case of
inner classes / closures at least this does not seem impossible).

On a more negative point, project coin was announced with various
suggested ideas:

Strings in switch, more concise calls to constructors with type
parameters, exception enhancements, ability to call with methods with
exotic names, and (possibly) bracket notation to access collections.

The final list is:

Strings in switch, *Automatic Resource Management*, more concise calls
to constructors with type parameters, *simplified varargs method
invocation*, *better integral literals*, *language support for
Collection literals*, ability to call with methods with exotic names
(*and rest of JSR 292*), and (possibly) bracket notation to access
collections.

The differences between the initial and final proposal lists are
highlighted above. Half the final list was on the original list. This
does not seem like a hugh change given the amount of discussion on
project coin.

Back to the positive points. The project coin process did provide for
open documented discussion of options, which as far as I can tell is
well liked by the community.

Cheers,

-- Howard.

On Sep 6, 5:11 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

[jddarcy]

Anyone can have an opinion. Having an informed opinion takes some
effort. Implementing the conclusions of an informed opinion can take
considerably more effort.

Project Coin != http://bugreport.sun.com/bugreport/

For many years people with ideas for language changes (and other
matters) have been welcome to submit them to bugs.sun.com; there is no
expectation that something other than a rough idea is required. These
ideas are evaluated and there are well over 100 open "requests for
enhancement" (rfes) related to language changes. I reviewed all of
these open ideas before embarking on Project Coin. Many other
submitted language rfes have been considered and subsequently closed.

Project Coin explicitly offered a different social contract than
bugs.sun.com; beyond just a vague idea, contributors were invited to
participate *in the work* of bringing a language change into the
platform. To be clear, the abundance of open language rfes means an
additional idea for language change in and of itself has essentially
no value. Instead, the coin of the realm in Project Coin was the
*analysis* of the impacts and benefits of a language change and code
for a *prototype* implementation. Those are valuable because they are
essential components of the work needed to bring a language change to
the platform. The Project Coin Proposal form [1] guided the analysis
and the OpenJDK langtools repository gave a starting point for a
compiler prototype. People could collaborate on different aspects of
a proposal and the Project Coin list explicitly made such requests for
assistance on-topic. The recommendation for prototypes was not made
for punitive purposes; rather it was made so that more accurate
information could be gathered about the language change. Quoting a
comment left by Mark Mahieu on my blog [2]:

"By the time I posted a link to a runnable prototype [of the Elvis
operator] to the list, my own understanding was much, much clearer,
and very different; after delving into the real detail I'd come to the
conclusion that it's not a good enough fit (for Java) in the form
proposed."

In contrast to this productive discourse, take the brouhaha over not
including multi-catch in the Coin final five left in comments on my
blog. [3] My message announcing the final five makes clear that this
decision was made based on resourcing concerns rather than the merits
of the idea itself. Not one of the people leaving comments full of
wailing and gnashing of teeth about the omission offered to do
anything to help implement the feature.

It is far easier to impose demands than to satisfy them. When there
is no "cost connection" between those imposing demands and those
satisfying them, ridiculous expectations can result, such as this
individual [4] whose series of requests to jdk7-dev in June I will
paraphrase:

"Hi. I'm some random Java developer with admittedly little technical
expertise [5] and no money. I read one blog entry written by Neal
Gafter several years ago [6]; despite my lack of money and admitted
lack of technical expertise, I think reading that single blog entry
written by someone else should imbue me with enough authority to
dictate [7] how *other* people should allocate *their* resources to
work on the cool Java language changes *I* personally want to see."

I have exactly zero respect for this line of thinking and see no
reason to tolerate it.

If someone says he doesn't know what he is talking about, I believe
him. I also take the next logical step of not giving much credence to
his conclusions and demands.

No one is stopping this fellow or any other interested person from
taking a compiler course, downloading the OpenJDK sources to javac,
reading the considerable programming language literature of generics,
and working on an implementation of reified generics or some other
language variant. (The careful reader will note that Microsoft's
papers describing reified generics in CLR emphasize how fast they were
able to make List<int> go and do not focus on the performance penalty
paid by List<Integer> because of the extra level of indirection
between an object and its dispatch table.)

On the subject of listening to developers ideas for changes, I posted
some related thoughts to the coin list back in July [8]:

``"Design by committee" is often derided as an inappropriate way to
manage technical projects. Simple polling about technical issues is
design by committee where the committee can be arbitrarily large and
any pretense of expertise in the area is removed. Therefore, polling
would be a poor way to drive specific technical decisions about the
Java Programming Language. One of the benefits of working in a
technical field is that technical problems often have right answers,
regardless of how many people agree or disagree with them.

This is not intended to be a slight against Java programmers who
contributed suggestions informed by their daily experiences with the
language to the Coin alias, to Sun's bug database, or elsewhere.
Rather, it is a recognition that, just as being a player and being a
coach are district roles requiring distinct skills, using the language
and evolving it and district tasks with related but separate skills
sets. Polling can provide a good indication about what pain points
people are experiencing; that is an important input, but only one kind
of input, to how the language should change.

Most Java programmers do not need to be language experts. This is
very much a feature and *not* a bug of the Java ecosystem. Not having
to be a language expert means Java programmers have time to be experts
about other things :-) ''

Moreover, the responsibilities of stewardship including preserving the
conceptual integrity of the platform, which does not necessarily
follow from point decisions.

I don't understand who is being accused of preventing or impeding use
of, say, Scala. For its part, Sun has encouraged experimentation with
the Java language changes and has funded work to improve the support
of non-Java language on top of the JVM too. Lack of corporate
sponsorship of particular other languages should certainly not be
equated to impeding their use. Conversely, Java developers are in no
way obliged to participate in Project Coin or OpenJDK activities.
However, if the extent of a developer's interaction with those working
on the language is leaving childish comments on blogs, don't expect to
have much influence over the results.

-Joe Darcy

[1] "Project Coin: Small Language Change Proposal Form Available"
http://blogs.sun.com/darcy/entry/project_coin

[2] http://blogs.sun.com/darcy/entry/project_coin_final_five#comment-1252023525000

[3] http://blogs.sun.com/darcy/entry/project_coin_final_five#comments

[4] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000666.html

[5] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000704.html

[6] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000675.html

[7] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000686.html

[8] http://mail.openjdk.java.net/pipermail/coin-dev/2009-July/002120.html

> ...
>
> read more »

[Neal Gafter]

On Sep 14, 4:30 pm, jddarcy <jdda...@gmail.com> wrote:
> ...

> In contrast to this productive discourse, take the brouhaha over not
> including multi-catch in the Coin final five left in comments on my
> blog. [3]  My message announcing the final five makes clear that this
> decision was made based on resourcing concerns rather than the merits
> of the idea itself.  Not one of the people leaving comments full of
> wailing and gnashing of teeth about the omission offered to do
> anything to help implement the feature.

I did provide a working prototype of multi-catch in the BGGA compiler
more than a year before the Coin call for proposals, and I
communicated directly to you (Joe) my willingness to complete the work
for project Coin (i.e. implement the feature in isolation) if it was a
feature you were interested in having. As I understand your comments,
it wasn't the compiler implementation you were mainly worried about.
You were worried about the specification work in the type system.
However, quoting from the proposal:

"To avoid the need to add support for general disjunctive types, but
leaving open the possibility of a future extension along these lines,
a catch parameter whose type has more than one disjunct is required to
be declared final."

In short, I don't believe the proposal has any impact on the type
system.

Cheers,
Neal Gafter

[jddarcy]

On Sep 13, 12:27 pm, hlovatt <howard.lov...@gmail.com> wrote:
> BIAS DISCLAIMER - features mention below are favored by me!
>
> The tension between backward compatibility and introducing new
> features seems be the problem, there are ways out of this problem,
> e.g.:
>
> 1. Introduce a source statement before the package statement at the
> start of the file, e.g. "source Java7;". This way a file that is
> pre-7, or lacks a source statement, can be compiled with the existing
> compiler, and a file that is 7 can use the new compiler.

Issues with this idea were discussed in depth on the Project Coin
list; see

http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000249.html
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000512.html

> 2. When a feature is heavily asked for, e.g. better inner classes /
> closures, then the minimum feature set, i.e. something like CISE plus
> a nifty collections library, could be implemented.

Whom specifically do you propose to implement them?

To get started, the source code for OpenJDK 7 is here:
http://hg.openjdk.java.net/jdk7/jdk7

[snip]

> On a more negative point, project coin was announced with various
> suggested ideas:
>
> Strings in switch, more concise calls to constructors with type
> parameters, exception enhancements, ability to call with methods with
> exotic names, and (possibly) bracket notation to access collections.
>
> The final list is:
>
> Strings in switch, *Automatic Resource Management*, more concise calls
> to constructors with type parameters, *simplified varargs method
> invocation*, *better integral literals*, *language support for
> Collection literals*, ability to call with methods with exotic names
> (*and rest of JSR 292*), and (possibly) bracket notation to access
> collections.
>
> The differences between the initial and final proposal lists are
> highlighted above. Half the final list was on the original list. This
> does not seem like a hugh change given the amount of discussion on
> project coin.

There were both additions and deletions to the initial list as well as
development of details of specific proposals. Only two of the finally
accepted proposals were written by Sun engineers, strings in switch
and JSR 292. Observing that a number of ideas on the initial list to
seed discussion were also accepted proposals in the end doesn't
necessarily imply anything untoward if the ideas and proposals were
good ones.

-Joe

[jddarcy]

On Sep 13, 7:16 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
[snip]

> Where I take exception, is when Joe Darcy
> complains about lack of community input.

Oh, there is lots of externally community input ("I want feature X
now!", for many values of X); there is much less external community
contribution toward achieving those features.

> I call truth distortion: Of
> course there's no community input. You killed it. Communities don't
> just magically show up on your doorstep. They grow. And to grow, you
> need to nurture them.

Agreed. The blog posts I wrote toward the end of 2008 before the
Project Coin call for proposals period were intended to nurture in
others the design context we've been using to evolve the language.
Also, a light hand was taken in managing traffic on the coin list to
not scare away those wavering on approaching the doorstep.

-Joe

[Reinier Zwitserloot]

Your complaints about community whining (defined as: People who want
language changes but do not offer to do the work) is entirely
justified.

Where coin went a bit wrong, I think, is in how you required more work
from the community than what you require internally. I presume when
(outside of coin) sun employees decide on java features to add to the
language, they first do some analysis of which ones are worth it, pick
one, nail down with decent certainty that this feature WILL be in the
next release, and only then do the work of writing up specs and
prototypes.

Coin asked the reverse: While knowing that the odds of being accepted
are slim to none, do the work anyway.

I'm not surprised coin didn't work as well as you think it might have.
Asking people to waste time isn't very nurturing, with all due respect
of the awesomeness of being able to work on something as momentous as
the java language.

I've said it before, but for the next coin: Accept pre-proposals, and
do your feature selection off of those, with the understanding that an
accepted pre-proposal can still be cancelled at any time if either of
the following happens:

(1) - laziness rule: author of pre-proposal, nor anyone else in the
community, comes up with a spec and a prototype in the alloted time-
frame.

(2) - Surprise rule: while speccing out the proposal or implementing a
prototype, new issues come up that nobody thought of when the pre-
proposal was accepted.

(3) - overbooking rule: If there are just too many complete proposals
that had also been accepted as pre-proposals out there to overwhelm
the larger java community, your proposal will be put on file for the
next release and reconsidered then. Cancelling more than about half of
all full proposals that passed rule #1 and #2 would probably kill your
community, though technically if you get this far, the community can
handle some disappointment. This year's coin certainly didn't. Also,
because some pre-proposals are bound to fall by the wayside due to the
laziness or surprise rule, more pre-proposals should make it through
than you're actually willing to accept into java. In the unlikely even
they all survive, a few would have to be put on ice until the next
java release as well.


It seems that you're discovering that the community capable of putting
in the rigor is quite small, so I'm a bit confused as to why you're
having them toil away doing work that isn't very efficient. About 95%
of the time I personally spent speccing things out did not help me in
any way gain perspective on the features I was asking for. Asking for
a good pros and cons analysis, rewriting existing sources to the
proposed new feature to see what it would look like 'in real
life' (something a JLS spec is no good at, I might add), and doing a
simple analysis that its likely the current parser architecture (LL
[1]) of javac can be retrofitted rather simply are all simpler to do
compared to writing a full spec+prototype, and yet they would have
helped much, much more in getting a feel for the cost vs. value
relationship of a feature. Also, whatever introspection is gained
solely by working on a JLS patch and a prototype can still be used to
cancel a project, which is why rule #2 is in there.

[Vince O'Sullivan]

On Sep 15, 12:30 am, jddarcy <jdda...@gmail.com> wrote:
> My message announcing the final five makes clear that this
> decision was made based on resourcing concerns rather than the merits
> of the idea itself.

Whilst acknowledging the 'real world' constraints of limited
resources; I'm curious about the fact that it appears that the basis
for inclusion (of a change to Java in version 7) is not based upon
ideas or their merits but on convenience to your project.

Is that a fair interpretation?

[Joshua Marinacci]

> Where coin went a bit wrong, I think, is in how you required more work
> from the community than what you require internally. I presume when
> (outside of coin) sun employees decide on java features to add to the
> language, they first do some analysis of which ones are worth it, pick
> one, nail down with decent certainty that this feature WILL be in the
> next release, and only then do the work of writing up specs and
> prototypes.

Oh, if only it were that easy! I once spent an entire *week* on a 3
line *bug fix* for the Windows Look and Feel only to have to *remove
it* later due to backwards compatibility breakage. The work required
on language changes is far far greater, and the cost of compatibility
far more challenging.

It's just not easy doing software engineering on something that must
be used, compatibly, on nearly a billion computers.

[Joseph Darcy]

I don't think that is a fair interpretation.  This quote from Bjarne Stroustrup's HOPL III paper "Evolving a language in and for the real world: C++ 1991-2006" sums up my opinion:

"As ever, there are far more proposals than the committee could handle or the language could absorb. As ever, even accepting all the good proposals is infeasible. As ever, there seems to be as many people claiming that the committee is spoiling the language by gratuitous complicated features as there are people who complain that the committee is killing the language by refusing to accept essential features. If you take away consistent overstatement of arguments, both sides have a fair degree of reason behind them. The balancing act facing the committee is distinctly nontrivial."

Additionally, running Project Coin was not "convenient."  We at Sun are capable of forming opinions about language changes and implementing them without external input.  Strings in switch and diamond were demoed at JavaOne this year and diamond is now available in the JDK 7 builds.  However, we wanted to open up language evolution to have more community contribution.

-Joe

[Reinier Zwitserloot]

Oh, I'm sure it's difficult. None of that changes the fact that we're
all perfectly capable of judging new language features with:

- a readable description that is NOT up to JLS standard.
- a thorough pros and cons list
- plenty of 'real life' examples, preferably not constructed just to
highlight the feature, but created by taking existing code and
refactoring it to the hypothetical new feature
- (optional, at least at first) some analysis on how to feasibly
extend the grammar to accommodate the feature without changing javac's
parser architecture

compared to:

- a JLS patch
- a prototype

I'd argue the first list is actually quite a bit more useful. And far
less effort to create. I'm also not hearing you say that sun engineers
themselves write up JLS chapter and verse BEFORE doing any of the
other, dare I say, far more interesting work (even if it is hard
work). There's also got to be a certain amount of stewardship on sun's
part - nobody outside of the core contributors are really capable of
making the kinds of decisions you're talking about (withholding one
bug fix to avoid breaking backwards compatibility).

[Bob Lee]

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

[Joseph Darcy]

On Tue, Sep 15, 2009 at 11:51 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:

Oh, I'm sure it's difficult. None of that changes the fact that we're
all perfectly capable of judging new language features with:

 - a readable description that is NOT up to JLS standard.

Sections from the Project Coin proposal form (http://openjdk.java.net/projects/coin/#proposal_form):

OVERVIEW

Provide a two sentence or shorter description of these five aspects of the feature:

FEATURE SUMMARY: Should be suitable as a summary in a language tutorial.

MAJOR ADVANTAGE: What makes the proposal a favorable change?

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

MAJOR DISADVANTAGE: There is always a cost.

ALTERNATIVES: Can the benefits and advantages be had some way without a language change?

 

 - a thorough pros and cons list
 - plenty of 'real life' examples, preferably not constructed just to
highlight the feature, but created by taking existing code and
refactoring it to the hypothetical new feature

EXAMPLES

Show us the code!

SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature.

ADVANCED EXAMPLE: Show advanced usage(s) of the feature.

 

 - (optional, at least at first) some analysis on how to feasibly
extend the grammar to accommodate the feature without changing javac's
parser architecture

compared to:

 - a JLS patch
 - a prototype

I'd argue the first list is actually quite a bit more useful.

Yes, I agree, which is why the Project Coin proposal form asked for a superset of that list :-)

And far
less effort to create.

A serious Coin proposal can still take many hours to draft.  Writing strings in switch took me 8+ hours including incorporating feedback from reviewers (and no one caught the mistake that the proposal implies one can switch on longs).  Strings in switch is a one-word change to the specification; verifying it is only a one-word change makes many more words!
 

I'm also not hearing you say that sun engineers
themselves write up JLS chapter and verse BEFORE doing any of the
other, dare I say, far more interesting work (even if it is hard
work).

As with the general engineering, the specification development is an iterative process.  The final formal JLS text tends to build upon less former earlier draft specifications.  However, the general sense of what aspects of the specification need updating should be determined early on.

-Joe

[hlovatt]

Joe,

I seemed to have failed in the intention of my post. I was trying to
be constructive and offer a way forward; but all I seem to have done
is upset you, this was not my intention.

I think there is an ever increasing feeling that Java is stagnating,
and as a consequence many people, including myself, are starting to
use other languages, like JavaFX and Scala. These are languages
written from scratch; that is a hugh effort. It seems from the outside
that Java is the neglected child of the JVM. How come JavaFX and Scala
can both be written from scratch in the same time scale as Java goes
from 6 to 7? Is the resourcing for Java really significantly less than
for Scala and FX? For myself, and I assume others, I want Java to
continue to grow and go from strength to strength. Hence my proposals
to break the deadlock between backward compatibility and adding new
features.

With regard to the community involvement, you are obviously
disappointed that more people have not produced prototypes. There were
some prototypes, e.g. CICE and BGGA, but these did not really advance
the course of improved inner classes / closures. I can speak for
myself and say that I am reluctant to invest my time in building a
prototype etc. when the chances of acceptance appear to be slim; I
assume from the lack of prototypes that others feel the same. You have
to remember that this is not our day job, we would be doing this in
our own time. People's own time is very valuable and they won't spend
it unless there is going to be an outcome that is favorable (or at
least likely favorable).

Anyway, I hope that the impasse between backward compatibility and new
features can be broken and Java has a long and glorious future. I
apologize again for upsetting you and re-iterate that this was not my
intention. I think you did a really good thing in opening up the
decision making to more scrutiny, and I say that as someone who did
not get any of his pet favorites up!

-- Howard.

On Sep 15, 2:01 am, jddarcy <jdda...@gmail.com> wrote:
> On Sep 13, 12:27 pm, hlovatt <howard.lov...@gmail.com> wrote:
>
> > BIAS DISCLAIMER - features mention below are favored by me!
>
> > The tension between backward compatibility and introducing new
> > features seems be the problem, there are ways out of this problem,
> > e.g.:
>
> > 1. Introduce a source statement before the package statement at the
> > start of the file, e.g. "source Java7;". This way a file that is
> > pre-7, or lacks a source statement, can be compiled with the existing
> > compiler, and a file that is 7 can use the new compiler.
>
> Issues with this idea were discussed in depth on the Project Coin
> list; see
>

> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000249.htmlhttp://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000512.html

[Dick Wall]

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

[Bob Lee]

On Tue, Sep 15, 2009 at 1:06 PM, Dick Wall <dick...@gmail.com> wrote:

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".

It should be clear from my comments (comparing your job to Joe's) that I was responding to your email, not the podcast.

 

Somehow this got personal, and I assure it was not us that made it so.

In your email, you presume to tell Joe what his job is and how he's doing it incorrectly. The Coin changes weren't picked out of mid air with no regard for what users want. Many of the changes are backed up by exhaustive searches of huge code bases and objective measurements of how much the change would help (lines of code saved, reduction in errors, etc.). It doesn't take a compiler expert to do this work. It just takes time, time that you will take if you're passionate about a particular feature. I know because I did this legwork in a couple cases, and I am by no means a language expert.

 

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.

Who was negative about Lombok or at least the general approach? In his blog post, Joe rightly recommended generating a superclass or subclass instead of depending on internal javac APIs. The code generayion approach will work on other platforms, it will continue to work even if the javac internal APIs change, and it will be easier for users to debug. I'd hate to see someone combine multiple Lombok-style approaches in the same code and end up debugging javac's internal AST to figure out why their code doesn't work.

 

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.

I already explained why I think closures didn't go forward. If you agree with my theory, there's no reason for BGGA to serve as a deterrent for others. Also, Java 7 isn't the end of the line. Just because a feature doesn't make it into 7 doesn't mean it will never make it in.

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?

I don't know where multicatch stands. You'll have to ask Neal and Joe. If it's out, I'm sure there's a good reason.

 

Bob

[Casper Bang]

> Also, Java 7 isn't the end of the line. Just because a feature
> doesn't make it into 7 doesn't mean it will never make it in.
> Neal has also stated here and on other blogs

Well no matter how you cut it, the amount of stuff that has been
dropped is staggering and a prospect of JDK8 in another 3-4 years is
just disappointing to the practitioner. It's not scientific study, but
only some 20% appear to be genuinely happy with how JDK7 is shaping
up: http://www.java.net/poll/what-your-reaction-jdk-7-feature-list

Also, it's a little bit ironic and not exactly a sign of health, that
the current javac maintainer is now innovating on a competitive
platform.

/Casper

[Joseph Darcy]

Neal has not been the javac maintainer since he left Sun for Google back in 2004.

Langtools in general and javac in particular have been actively maintained by others since then:
http://hg.openjdk.java.net/jdk7/jdk7/langtools/shortlog

-Joe

[Bob Lee]

On Tue, Sep 15, 2009 at 3:30 PM, Casper Bang <caspe...@gmail.com> wrote:

Well no matter how you cut it, the amount of stuff that has been

dropped is staggering

Well, I find the amount of stuff that's going in to the language in Java 7 to be staggering and even worrying. You could say we're looking at a bigger release than Java 5. We're still discovering unexpected interactions and trying to fix problems introduced in Java 5 (check out the generics discussions on the OpenJDK lists, not to mention my varargs proposal).

Project Coin has 7 proposals, one of which is the not-at-all-small language support for JSR-292: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001131.html

We have JSR-308 (Annotations on Types): http://jcp.org/en/jsr/summary?id=308

We have JSR-294 Modules: http://jcp.org/en/jsr/summary?id=294

That's 9 changes. Java 5 had 7: generics, varags, autoboxing, enum, foreach, annotations, static import. We should spend more time polishing existing features before we pile more on, especially if those features touch the already-complex type system.

Thanks,

Bob

[Joe Nuxoll (Java Posse)]

I am looking forward to our discussion in person hopefully tomorrow
(Wed) after the languages summit. We'll bring a recorder, of course
so the listeners get the benefit of hearing you directly. We're all
huge fans of yours Joe, but of us 4 - probably Carl is the only one
you could label as a "compiler guy" and capable of building a
prototype of these things. We all know languages very well, and
understand the complexity of implementing them.

There is however, a very big difference between looking at a language
change from the perspective of a language implementor vs a language
user. In any case, I look forward to our discussion!

- Joe (the other Joe)

> programmers and existing code bases, 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

[Joshua Marinacci]

> There is however, a very big difference between looking at a language
> change from the perspective of a language implementor vs a language
> user. In any case, I look forward to our discussion!

And I look forward to listening!

[Reinier Zwitserloot]

On Sep 15, 11:28 pm, Bob Lee <crazybob...@gmail.com> wrote:
>
> I don't know where multicatch stands. You'll have to ask Neal and Joe. If
> it's out, I'm sure there's a good reason.
>

That's the crux of the situation, isn't it?

Where's that reason? We keep coming back again and again to the exact
same point:

If multi-catch doesn't make it and the explanation is not publically
known, that's going to put a real crimp on community effort for future
coin endeavours. We're all aware this is a perception issue and yet
nobody is addressing this perception at all: If there's a good reason
for multicatch to get canned, then where is it? That one-liner of:
"Messes with the typesystem" is crud - the proposal specifically
mentioned why it does not in fact require messing with the type
system. Something like "We're going to revisit a lot of types in JDK8,
and we may introduce disjoint types, so we're going to wait as we may
solve it and many others in one fell swoop in JDK8" would help with
_perception_. Which is what the community you want input from is
asking for.

We're trying to help by explaining why the community is not responding
the way Joe had hoped for, and is instead moving towards things like
lombok.

In regards to the coin form: You didn't answer my question, Joe, you
just went on the defense. Why not accept proposals based on less
officious bits and more useful bits, and make decisions earlier? You
yourself said string switch took you 8+ hours to write up including
feedback. You're the coin lead, you knew it had a good chance of
making it. You're a JLS and langtools expert. You know exactly what
you want from the proposal. The people you want input from would have
needed 24 full hours or more, and would instead have the knowledge
that the effort has at best slim chances of making it in. Why are you
surprised the community isn't putting in as many proposals as you
wanted? Putting in that much effort writing excruciatingly boring JLS
spec with virtually no guarantee is of course not going to find many
takers. If you up the odds considerably by asking people to put in the
JLS efforts ONLY after giving them a tentative guarantee that if the
work is done and no surprises crop up, the proposal will far more
likely be in than be left out, *I* would definitely be a lot more
jazzed to put in that effort. I'm making a guesstimate that the rest
of the community would be similarly willing to do so.

I'll give you an example. here's strings in switch, again, this time
in 10 minutes, and this time with the -exact- same ability to make a
_preliminary_ call on its feasibility and suitability for java:

"The strings in switch proposal allows using strings in switches. The
target strings, mentioned in the case statements, must be compile-time
constants.

Such a construct is translated to existing valid java code as such:
Each target string is hashed, and the switch is replaced with an
integer switch on the input string's hashCode. Each 'case' label
contains 1 if(equals) block comparing the input string to the constant
for each string that matches that hashcode, closing with an else that
jumps to the default."


Add a small paragraph with a syntax example and a hint about how the
existing javac grammar can easily be changed to accomodate it, and
you've got all you need to make a preliminary call.

(I know that's not how you've written up string, but exact
implementation is irrelevant at the decision stage of the process, as
long as its obvious it won't be particularly difficult to find a
workable one).

Every other bit (and more) on the coin form eventually becomes
relevant, but please, pretty please, with sugar on top, start
including the decision process into the iterative process, instead of
asking everybody to iterate their way to loads of personal time before
eliminating all that hard work in one fell swoop by simply not listing
it on the shortlist. I can guarantee you more involvement from me, and
if I'm getting the pulse of this thread's participants right, I won't
be the only one.

[Bob Lee]

On Wed, Sep 16, 2009 at 3:32 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:

On Sep 15, 11:28 pm, Bob Lee <crazybob...@gmail.com> wrote:
> I don't know where multicatch stands. You'll have to ask Neal and Joe. If
> it's out, I'm sure there's a good reason.

That's the crux of the situation, isn't it?

Where's that reason? We keep coming back again and again to the exact
same point:

In this particular case, I think you just need to give people some more time. We all have a lot on our plates and there are only 24 hours in a day.

 

We're trying to help by explaining why the community is not responding
the way Joe had hoped for, and is instead moving towards things like
lombok.

I may need to read this thread a little more closely, but where did Joe say the community didn't respond how he had hoped? It's my understanding that Coin got close to or over 100 proposals. Those proposals also enjoyed some great feedback, from you in particular. What more could you hope for?

 

If you up the odds considerably by asking people to put in the
JLS efforts ONLY after giving them a tentative guarantee that if the
work is done and no surprises crop up, the proposal will far more
likely be in than be left out, *I* would definitely be a lot more
jazzed to put in that effort. I'm making a guesstimate that the rest
of the community would be similarly willing to do so.

I don't think they ever asked for JLS specs. I believe Alex is one of the few people who can actually do this. This is a bottleneck in the process, but I don't really see any way around it. On the bright side, if one person writes the final specs for everything, they're more likely to be consistent. Coin proposals are much easier to write than JLS spec.

 

Every other bit (and more) on the coin form eventually becomes
relevant, but please, pretty please, with sugar on top, start
including the decision process into the iterative process, instead of
asking everybody to iterate their way to loads of personal time before
eliminating all that hard work in one fell swoop by simply not listing
it on the shortlist. I can guarantee you more involvement from me, and
if I'm getting the pulse of this thread's participants right, I won't
be the only one.

It would be nice if we could have detailed explanations for why each of the 90 or so proposals was turned down, but the reality is that time spent on this is time they can't spend actually implementing and integrating language features. I prefer they spend time on the latter.

Bob

[Reinier Zwitserloot]

Joe specifically complained about a lack of prototypes in various
places. Here's a verbatim quote from a comment he left on his own blog
( http://blogs.sun.com/darcy/entry/project_coin_final_five ):

> Project Coin explicitly encouraged prototypes as a way to demonstrate the feasibility and utility of a change via an existence proof.
> Yet, despite all this, most of the proposals sent to Project Coin did not have a corresponding prototype, including improved exception handling.
> Rather than complaining after the fact, a more constructive way to influence future language decision is helping to hack prototypes ahead of time.

The post that kicked off this thread was also by Joe Darcy and
includes such gems as:

> KSL received no significant community response.

> 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 tone of disappointment is rather obvious to me.

Replying to your own remarks now:

On Sep 16, 7:40 pm, Bob Lee <crazybob...@gmail.com> wrote:
> In this particular case, I think you just need to give people some more
> time. We all have a lot on our plates and there are only 24 hours in a day.

That's fine, though I suggest it's all sorted out well before the next
coin. The faster the better - if coin proved one thing, it's that it
was far too short a timeframe. I'm trying to convey to Joe that this
lack of response is partly to blame for the 'view from an ivory tower'
perception.

> Coin got close to or over 100 proposals. Those proposals also enjoyed some
> great feedback, from you in particular. What more could you hope for?

Prototypes, obviously. And more proposals; let's get real for a moment
- many of the proposals of coin were dead on arrival, written up with
barely enough detail to make for a valid feature request on
bugs.sun.com. I myself submitted (and some as only a pre-proposal)
less than half of what I planned, because writing up the first one
properly made me realize there's no way I could get it done in the
mere month that was given to us. Consider projectlombok.org my less
rushed response: Real prototypes, usable on real source code bases,
with real development environments, so I can really get a feel for
this stuff.

>
> I don't think they ever asked for JLS specs.

Joe repeatedly asked for references to the appropriate JLS chapters
during the coin process - even on (especially on) proposals where that
was the last thing on my mind to determine whether or not the proposal
was a good fit for java.

> I believe Alex is one of the
> few people who can actually do this. This is a bottleneck in the process,
> but I don't really see any way around it.

This is true, someone has to do this stuff, and its only fair the
community owns up to its responsibility. But as this is the
bottleneck, lets shove the job as far forward as we can: A few
decision iterations worth of culling the proposal list down should
pass before anyone names any JLS chapter, unless its particularly
relevant to the specifics of a proposal.

>
> It would be nice if we could have detailed explanations for why each of the
> 90 or so proposals was turned down, but the reality is that time spent on
> this is time they can't spend actually implementing and integrating language
> features. I prefer they spend time on the latter.
>

Absolutely. Defending 90 denials is next to impossible. Yet another
reason for iterating early and often: If a proposal looks like crap,
then say so. Right away. You can have some sort of officious level of
denial which entails: I really doubt it, but if you go through the
effort of a prototype and a full spec, we may always reconsider, but,
don't get your hopes up. In the unlikely event a proposal you cancel
early did have merit, odds are it has gathered enough cheerleaders
that they may try this, but at least then the people who did put in
the effort aren't disappointed when they are part of that 90. A big
issue with that list of 90 is that the majority of them were
ridiculous proposals, but a select few of them showed rather a lot of
merit. There were a few proposals that didn't make it that
nevertheless received some positive feedback and went through a bunch
of iterations (case in point: Neal's exception handling proposal!),
that were nevertheless not shortlisted. An explanation for this (which
does not directly contradict a properly defended claim in the original
proposal and is more than 6 words long) would be a great boon for the
community, the coin process in general, and really should not be too
much effort. The only problem is that coin let it come to 90 proposals
in the first place.

[markmahieu]

On Sep 16, 4:32 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Why are you
> surprised the community isn't putting in as many proposals as you
> wanted? Putting in that much effort writing excruciatingly boring JLS
> spec with virtually no guarantee is of course not going to find many
> takers.

I interpreted this quite differently - although the majority of us
aren't able to write a JLS quality proposal, Joe wanted us to at least
try to the best of our available time and ability, and in the process
think more deeply, critically even, about our own respective
proposals.

Personally I found that to be the most interesting part by far, even
though I can't claim to have done an amazing job of it. Challenging?
Certainly. Even disappointing sometimes when you realise that a
favourite idea just doesn't cut it. But excruciatingly boring?
Really?

Fundamentally, it was (and is) all about trying to tip the balance of
ideas and analysis in favour of quality rather than quantity, for
once. That's always going to be hard.

Cheers,

Mark

[Reinier Zwitserloot]

Quality over quantity is a fine goal, but I don't think we can
honestly claim coin did a particularly good job on that. As has been
said, over 90 proposals were submitted. The majority of them were
horrid.

[Bob Lee]

On Wed, Sep 16, 2009 at 12:59 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:

There were a few proposals that didn't make it that
nevertheless received some positive feedback and went through a bunch
of iterations (case in point: Neal's exception handling proposal!),
that were nevertheless not shortlisted.

You keep pointing to Neal's proposal, but one example doesn't connote a trend. Let Neal champion his own proposal.

While having a preliminary process might save some people some time, it's not something I'd spend time on. I doubt anyone else would either. Frankly, I hope the Java programming language *doesn't* change much more. I certainly don't want to do anything to encourage more change. In 5 years, Java will look a lot like C++, and we'll look back and say that we should have just stopped 5 years ago.

Bob 

[hlovatt]

You can see in this discussion group the tension between: "don't make
changes" (Bob) and "lets keep advancing Java" (Reinier). I am in
Reinier's camp, but think that both points of view can be satisfied
with a source statement. If there is no source statement then the file
compiles as it does now, but if the file has source "Java7"; at the
start then you can use the new features and most importantly a file
with source "Java7"; at the start does not have to be source
compatible with current Java (though the two need to co-exist on the
JVM - just like JavaFX and Java do today).

This way everyone gets what they want.

-- Howard.

On Sep 17, 2:52 am, Bob Lee <crazybob...@gmail.com> wrote:

[Casper Bang]

I agree with your analysis although I often think of this as a
question. Why is it that it's ok to invent a totally new language but
shaping an existing one according to state-of-the art is not? It seems
like we are forced into making the hard choice between something
radically new (Scala, JavaFX) or legacy (Java).

The only difference is that the radically new has no backwards
compatibility to worry about (yet). So how come we don't just evolve
the existing stuff and let go of some compatibility with the benefit
that you are offering the existing community a gradual and painless
transition (but forego backwards compatibility). It's not clear to me
why JavaFX was not made broader than it is, so it could effectively
function as such as replacement.

/Casper

[Peter Becker]

Dick Wall wrote:
[...]

> 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).
>

Maybe it is just a sign of success ;-)

Peter

[Michael Neale]

On Sep 16, 6:06 am, Dick Wall <dickw...@gmail.com> wrote:
>
> 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).
>

Yes I have noticed that too. I noticed the first 250-ish episodes were
of a more detached almost "reportage" style or tone, but then (after
much listener feedback) opinions and positions were stated more in
later podcasts - it may be nothing, but it *seems* to coincide with
that ? maybe... who knows....

[hlovatt]

All very good points

[Jess Holle]

Joe Darcy recently cited discussion threads in which the source statement was supposedly found to be problematic.

I perused them -- and didn't see any substantive problems uncovered in the course of those discussions.

Personally I think a source statement would be a good thing.  Otherwise if you have a large set of sources in a module you have to go through all sorts of shenanigans to compile some stuff with -source x and others with -source y.  This configuration is unnecessarily complex and is fragile -- since the information is separate from the source files.

The discussion did bring up cases where compilation against different JDK library versions was required.  This problem is rather annoying in cases.  For instance, the JDBC Connection API in Java 6 adds a whole lot of methods, many of which use classes only found in Java 6.  Thus if you have a FilteredConnection class that implements Connection, you have to compile a different source file if using JDK 5 than for JDK 6 -- there's no FilteredConnection source that will compile under both.  Yes, in this case a dynamic proxy would work around the issue.  Overall, however, there seems to be an overly cavalier attitude towards growing existing interfaces rather than adding other interfaces that are used as mixins.  JDBC appears to be the worst case -- forcing one to compile lots of code with Java 5 in order to run under Java 5 irrespective of -source and -target flags.  In the end, however, this whole mess is different than the -source issue -- and can only be addressed by considering such issues when making JDK API changes.

--
Jess Holle

[hlovatt]

Bob,

I think you are being a bit hard on the Posse and Dick in particular.
They produce a podcast in there own time for little reward (OK the
occasional free Beer form Atlassian), surely they are allowed to
express their views - part of the entertainment is disagreeing with
them!

Just a nit picking point - Sun does get some money from Java and they
have said in the past that they think it is valuable to the company
(they even went as far as to change their ticker). It therefore seems
to me likely that they have more resources than most to put into Java.

Keep up the good work Posse,

-- Howard.

[Casper Bang]

I second that. Having never enjoyed the Posse as much as when
engineering issues floats up to the top and they speak their mind from
a technical perspective, for that truly represents the community I
consider myself part of which is all about pushing state of the art.

It's not easy to cater to everyone, certainly I'm known to give them a
hard time (which can come out brutally honest and hit harder than
intended) but I reckon that's because we all care. It's down right
refreshing to hear the Posse tackling controversial issues and if you
look around, they really do appear to represent the community which is
asking these tough questions independently.

/Casper

[Joshua Marinacci]

(warning, this is long).


It's easier to invent a new language than improve the old one for the
same reason it's far faster and cheaper to build a brand new road then
to do minor repairs on an existing road that's *in use*. This is just
the nature of software. Once something ships and is used by customers
it instantly becomes legacy. And the more people use it the harder it
becomes to change. Over the last 30 years of software development
we've come up with lots of tricks to address this, but it's still a
very hard problem with no easy answers.

Why don't we step back and look at the big picture here. Java, the
language, is used by somewhere between 4 and 8 million developers
(depending on who's numbers you use). It's installed on nearly 1
billion desktop computers and even more servers and cellphones. In
short, one of the most widely deployed software platforms ever. In
short, something very powerful and valuable, but also very difficult
to change.

Every change you make to the core must consider the facts above, and
that makes change difficult. Not impossible, but difficult and
therefore cautious. For every person who wants to add a new feature
there are 10 who want no new features (or at least different
features). For every developer who wants to break backwards
compatibility, there are 100 who don't. That's one of the reasons
Swing has been so hard to evolve.

I don't mean to sound depressing or to say that Java will never
evolve. It will. But it will be slow. There will probably never be any
radical changes to the Java language again. Nothing on the level of
generics, at least. But you know what: that's okay. In fact, it might
be a good thing!

I was annoyed when I first came to this realization. I'm an uber-geek.
I love to learn new things, build new programs, and try new paradigms.
I'd love to see the Java language evolve with tons of new things.
But after thinking and talking to a lot of people I also realized the
value in the backward compatibility: stability. Java is a general
purpose language that is becoming built into everything, and thanks to
the compatibility promises it's enables tremendous portability and
reliability. Libs from 10+ years ago will run flawlessly. This is
incredibly valuable.

It still sucks though. We have tension between evolving what we have
and keeping valuable compatibility. Fortunately, we have an out: the
JVM. The JVM is separate from the language and can host new languages
which are compatible with it and with Java. This is incredibly
useful. If you want to keep on the forefront then you can use a
language with cool features like Scala or Groovy. If you need
compatibility you stick with Java. And you can mix and match them at
the class / jar level. This also frees the Java language to focus on
compatibility even more, while freeing the new languages to innovate
in new directions that wouldn't be possible with a mature general
purpose programming language. The best of both worlds.

I've said this a few times, but perhaps not here. Java, the platform,
will be around for a very long time thanks to the separation of the
JVM, the language, and the runtime. JVM bytecode will be running
inside of our computers 40 years from now. Hopefully that bytecode
won't have come from a Java compiler, but the reality is that some of
it probably will be libraries we've been using for decades that still
run great. That's the power of compatibility. And that's why Java, the
language, must necessarily be slow to evolve.

Now as for why JavaFX Script wasn't broader. It's mission has always
been very constrained: to be the best damn language and API for
building GUIs. No more and no less. Being focused results in higher
quality and faster time to market. If JavaFX was more general it would
be less good at being the best damn language for GUIs.

- Josh

[Stuart McCulloch]

2009/9/17 Reinier Zwitserloot <rein...@gmail.com>

Joe specifically complained about a lack of prototypes in various
places. Here's a verbatim quote from a comment he left on his own blog
( http://blogs.sun.com/darcy/entry/project_coin_final_five ):

> Project Coin explicitly encouraged prototypes as a way to demonstrate the feasibility and utility of a change via an existence proof.
> Yet, despite all this, most of the proposals sent to Project Coin did not have a corresponding prototype, including improved exception handling.
> Rather than complaining after the fact, a more constructive way to influence future language decision is helping to hack prototypes ahead of time.

This is probably pouring oil on the fire, but it looks like hacking a prototype even lets you circumvent the JCP ;)

   http://altair.cs.oswego.edu/pipermail/jsr294-modularity-observer/2009-September/000334.html

[ Disclaimer: I work with OSGi every day, and support the recent Simple Module System as a good compromise ]

Now where are my asbestos underpants...

--
Cheers, Stuart

[Serge Boulay]

The reality of bringing a new language into an exisiting organization is that it just isn’t that easy.  Managers and the like see it as another thing they have to maintain. Organizations limit the number of languages in house for both maintenance and support reasons. It's much easier  to get an organization to support a new version of the jdk then it is to introduce and new language into the organization. 

I know that the default answer is that if you want to use language feature “x” then use another vm language. There is nothing wrong with this , but it is also an invitation to investigage a language that is not on vm.

[Alex Buckley]

Stuart,

On Sep 17, 11:22 am, Stuart McCulloch <mccu...@gmail.com> wrote:
> This is probably pouring oil on the fire, but it looks like hacking a
> prototype even lets you circumvent the JCP ;)
>

> http://altair.cs.oswego.edu/pipermail/jsr294-modularity-observer/2009...

Even with a smiley, one should be very careful about making some
statements in a public, archived forum.

Are you claiming that Sun is circumventing the JCP by developing the
Jigsaw module system for JDK7 in an OpenJDK project?

Alex

[Alex Buckley]

On Sep 17, 5:38 am, Jess Holle <je...@ptc.com> wrote:
> Joe Darcy recently cited discussion threads in which the source
> statement was supposedly found to be problematic.
>
> I perused them -- and didn't see any substantive problems uncovered in
> the course of those discussions.
>
> Personally I think a source statement would be a good thing.  Otherwise
> if you have a large set of sources in a module you have to go through
> all sorts of shenanigans to compile some stuff with -source x and others
> with -source y.  This configuration is unnecessarily complex and is
> fragile -- since the information is separate from the source files.

A 'source' keyword is a terrible idea because it does not sufficiently
model the kinds of compatibility needed in practice. That is properly
the job of versioning in a module system.

The bigger issue regarding Java language changes is that Sun is
expected to listen to thousands of ideas per year *and give detailed
responses as to how those ideas could be made workable*.

Alex

[Reinier Zwitserloot]

To Josh, Bob, and all the other 'java is a fossil' arguers:

Please, stop.

Your argument fails almost immediately: Because the JVM has no notion
of a closure, a 'duration' type, and a gazillion other things various
new JVM languages are trying to add (as discussed in posse #278!),
interop between them is much, much worse than dealing with java (the
language)'s ideosyncracies. Fan even attempts to invent a completely
new library to go along with it. Talk about a learning curve! (so does
scala, for that matter. Will noop?). Interop between the new language
and java is similarly useless. Again, refer to the posse episode,
where the act of trying to interop javafx with java on anything but
the highest level was strongly discouraged, and for good reason.

Without that interop, your entire argument boils down to: Everyone is
supposed to at some point either rewrite their project FROM SCRATCH
into a new language, or migrate slowly by starting new projects in a
new language, and continuing to maintain the older projects in java.

This feels like a bad idea. Scratch that, a horrible idea. Even if we
accept java as a fossil, it'll first have to evolve towards being more
interop-compatible so we can all move away from java in an orderly
fashion.


I'm confused, too: You're all the kinds of geek that care about this
sort of thing, so why is everyone just silently accepting the axioma
you've posited here: ALL LANGUAGES DIE - that's what you're saying. At
some point the userbase enforces strict backwards compatibility, and
somehow we've gone from that to - language dies.


Hold on. We're skipping way too many steps here. Says who? Why can't
java evolve AND stay backwards compatible? We've got 3 things, all
named java:

- The JVM (lots of work, but it can and has been evolving, and nobody
seems to be asking for it to stop)
- The core libraries (lots of work. Evolving it is very hard, and
backwards compatibility constraints are choking improvements)
- The langtools project (Compared to the other two not even a drop in
the water. evolving a little, but this is really the entire focus of
coin, lombok, and other attempts to continue evolve the java
_language_).


As the JVM is already evolving, that problem already solved itself.
Moving on to how to evolve the latter two without breaking old stuff:

For the core libraries, it's hard, but handwaving java (the language)
away as a fossil does not make this problem go away. For interop, we
NEED to add closure types and other primitives to the core. To keep
the core clean (unless everyone really feels fans and scala's approach
of writing wrappers on top of everything is a solid plan - where does
that stop? Will we have 8 layers of wrapper in 2020?) we need a way to
evolve it without breaking old stuff. People have been solving this
problem for YEARS though. That's why we have module systems,
versioning, and even advanced ideas such as shipping an API mirror for
version X that is actually interacting with an object of version Y, to
let objects of that module cross the border between 2 modules with
different version requirements for that module.

Similarly, even if you do accept that rewriting/wrapping the core
library is the only acceptable solution, how will you evolve THAT? If
you don't solve this problem now, in 6 years we'll all be calling
scala/fan/noop a fossil and moving on to the next shiny thing. I don't
really feel like rewriting all my projects every decade just to stay
with the times. I'm just not going to accept that. I hope the rest of
you won't, either. We can fix this.


Lastly, there's langtools. A mere trifle compared to the JVM and the
library core. So, why not split it up? Right now maintainance/support
of javac, java.exe (JVM), and runtime library (RT) is tightly bound:
They all go out of support at the same time. Why is this? Decouple
javac from the JVM and RT, completely. Give javac a name and don't let
its version track the core libraries.

You could then have the following situation:

JVM/RT8 is released with a bunch of modern language primitives such as
a closure type. DolphinJavac (what's now known as javac6) has been
updated, bugfixed, and a few very minor backwards entirely compatible
changes have been shipped with it. This v8 version of DolphinJavac may
even require JVM/RT8 if you use all the features (just like javac5
needs JVM/RT5 if you use annotations, or iterable syntax, etc). If
you've got a project under active maintainance, you switch to JVM/RT8
for it, and DolphinJavac8.

A bit later, MahiMahiJavac is released, which contains loads of new
features, including closures, traits, struct classes, pattern
matching, lexically scoped monkey patching, and a bunch of other
features. Old code (written for DolphinJavac) will generate a bunch of
warnings and in some cases may even simply not work, but MahiMahiJavac
is still very much javac - a few minor edits is all you need, and you
should definitely go for it if you're working on an actively in-
development project.


As the early switchers to MahiMahi are clearly preferring updates to
java-the-language, MahiMahi will continue to evolve fairly drastically
for the JVM/RT9 timeframe, but at some point MahiMahi is in the same
boat as dolphinjavac is in now, and it gets major-feature-freeze. A
few months later, Seawolf is released.

This process can be maintained essentially forever, and allows
continues evolution of the language.

[Reinier Zwitserloot]

Alex, 'source' simply acknowledges that java (the language) syntax and
java (the runtime library) dependencies are utterly unrelated things.
Why MUST they track each other? In practice that already doesn't
happen: Code compiled on javac6 is routinely run on jvm5, and vice
versa. javac has -source and -target parameters for a reason.

I should be able to write code with javac6 features (fine, there
really weren't any, but let's imagine there were), and define in my
module that I'm actually dependent on the java5 core runtime
libraries. The compiler should compile against those libraries and
warn if e.g. I use stuff that only showed in v1.6, but it should
compile my usage of new features without complaint. Unless, of course
a feature itself simply isn't expressable in the earlier version's
bytecode.

[Stuart McCulloch]

2009/9/18 Alex Buckley <alex.b...@sun.com>

Hi Alex,

Yes circumvent is a bad choice of words - but while catching up with email
last night I found it interesting to read a post here with the following quote:

   "a more constructive way to influence future language decision is helping to hack prototypes ahead of time"

and a short time later read a message to the 294 observer list that said:

   "In the absence of a concrete proposal by the 294 Expert Group, I would suggest that the Jigsaw documentation is the standing reference"

Now it is true that Jigsaw will be the first modularity system that's baked
into the JDK - it is documenting changes to the language, classfile, JVM,
and javac - and at times I've had trouble working out which changes were
driven by JSR 294, and which were driven by Jigsaw.

So perhaps (like the original topic on this thread) it simply comes down to
a general feeling or perception. This wasn't helped by the numerous recent
emails to the observer list which basically declared JSR 294 as stagnant,
and naming Jigsaw the de facto reference by virtue of having documented
changes to the JLS, etc.

But I recognize those particular emails didn't come from the expert group
or Sun, and I hope that JSR 294 can help clarify that it is very much alive
and in control of the process.

Alex

--
Cheers, Stuart

[Joseph Darcy]

On Thu, Sep 17, 2009 at 5:38 AM, Jess Holle <je...@ptc.com> wrote:

[snip]
 

The discussion did bring up cases where compilation against different JDK library versions was required.  This problem is rather annoying in cases.  For instance, the JDBC Connection API in Java 6 adds a whole lot of methods, many of which use classes only found in Java 6.  Thus if you have a FilteredConnection class that implements Connection, you have to compile a different source file if using JDK 5 than for JDK 6 -- there's no FilteredConnection source that will compile under both.  Yes, in this case a dynamic proxy would work around the issue.  Overall, however, there seems to be an overly cavalier attitude towards growing existing interfaces rather than adding other interfaces that are used as mixins.  JDBC appears to be the worst case -- forcing one to compile lots of code with Java 5 in order to run under Java 5 irrespective of -source and -target flags.  In the end, however, this whole mess is different than the -source issue -- and can only be addressed by considering such issues when making JDK API changes.

Yes, the JDBC API uses a different evolution policy than the rest of the classes in the JDK.

One possible mitigation is to use an annotation processor to generate a JDK version dependent superclass with the new methods with JDK 6 type only being generated when compiled against JDK 6.

Modularity should also be able to help with cases like this.

[hlovatt]

The source statement as proposed for coin did no more or no less than
the -source flag that already exists (OK not quite true, see below).
This is definitely in the spirit of coin, a small change. The only
substantive change, over the current -source flag; would be that
'module' would be a normal keyword, not a context sensitive keyword.
There is nothing in the source proposal that precludes, at some future
date, linking the source version and the module version together. Your
example of linking source version to module version is actually a good
one for showing how the language can evolve with 'source'. We can make
this very minimal change now, introduce a source statement as
proposed, people, compilers, IDEs, etc. can make this small change
practically in a short time. Then for 8 we can do more - that is the
beauty of introducing a series of small changes rather than a few
massive ones. Source is one way of allowing Java to evolve.

What happens when a language doesn't evolve is that it dies and also
its platform dies with it. My day job is as a Scientist and this is
exactly what happened to Fortran. They stopped evolving it and the new
scientists moved on to newer languages and the old scientists kept
saying "what is wrong with Fortran it was good enough in the 70s it is
good enough now?". Now, even in science and engineering, Fortran is a
niche player. Sure it still exists, sure old programs are still
maintained, sure there are still some Fortran libraries going, but boy
is it boring and dead!

I want a bright vibrant exiting future for Java, not a stodgy old
death.

On Sep 18, 1:40 am, Alex Buckley <alex.buck...@sun.com> wrote:

[Jess Holle]

Or if I have an old module containing lots of sources, I might find that many are incompatible with Java 'n'.

I could then compile the whole module with -source 'n-1'.  Great.  Now I need to leverage Java 'n' features elsewhere in the module.  Ooops -- I can't until I clean up all the old sources or rework my build process!  Instead I should be able to keep building the module with -source 'n-1' and either (1) denote all the problem sources as having source 'n-1' in the sources or (2) denote new sources as using source 'n' -- most likely (2) in this case.

As people get used to declaring the intended source level of Java code, they could then stop using the pesky -source and just denote newer sources as source 'n' without hassle.  This would be allow a seamless transition to new language features with the intended source level closely linked to and version controlled with the source -- that would be infinitely better than the -source switch.

Incompatible API changes are another matter.  Sun works hard on this for the most part, but in certain areas, e.g. JDBC interfaces, they really fall down.  Possible solutions are quite clear, but they are also quite unrelated to a source keyword.  Currently, compiling with Java 6 while using Java 5's core libraries is a royal pain.  Sun should stop the sort of API evolution that necessitates this (e.g. growing existing interfaces).  On the other hand, there are times where you really want to compile with Java 5 libraries just to ensure you don't use anything that's new to Java 6.  For such cases, there really should be a simple way to declare that your module depends on the Java n-1 core rather than the Java n core, for instance, in your module...

--
Jess Holle

[Joshua Marinacci]

I never said Java should or would stop evolving. I'm explaining why
Java must, of necessity, evolve slower than a brand new language.

With regards to lang interop and closures in JDK 7: here's my thoughts.

Think of JDK 7 as our Snow Leopard. It's not about sexy new features.
It's about fixing long standing issues in the platform. The two most
important features are modules and invokeDynamic. JDK 7 is about
getting Java ready for the next 20 years. So that it *can* evolve.
This is much needed work and I think reducing the scope of JDK 7 to
just those (no closures, no swing app framework), is vital to the long
term health of the platform.

- Josh

[hayden.p...@gmail.com]

Personally, I'm dying to see the probable start up improvements that
the java plug-in will gain from modularity. (Though you may only gain
that with the Sun implementation because Jigsaw will not be part of
the required Java7 implementation)

> ...
>
> read more »

[Alex Buckley]

On Sep 17, 5:51 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Alex, 'source' simply acknowledges that java (the language) syntax and
> java (the runtime library) dependencies are utterly unrelated things.

Incorrect. Language features often rely on library features. See
http://blogs.sun.com/abuckley/en_US/entry/versioning_in_the_java_platform
for examples.

> Why MUST they track each other? In practice that already doesn't
> happen: Code compiled on javac6 is routinely run on jvm5, and vice
> versa. javac has -source and -target parameters for a reason.

javac6 can emit ClassFiles for jvm5 precisely because no source
language changes happened in java6.

javac5 can emit ClassFiles for jvm6 because Sun's compatibility policy
generally prohibits the removal of features from jvm_n in jvm_n+1.

This discussion precisely demonstrates my earlier point. Some people
don't merely suggest a language feature; they demand a detailed
interactive discussion with Sun on the feature. Luckily, I can short-
circuit this one because I wrote a detailed and closely related blog
entry. But there are millions of people with suggestions, and no
company in the world has enough employees to address each and every
one.

Alex

[Alex Buckley]

Hi Stuart,

On Sep 17, 8:51 pm, Stuart McCulloch <mccu...@gmail.com> wrote:
> Yes circumvent is a bad choice of words - but while catching up with email
> last night I found it interesting to read a post here with the following
> quote:

So you are NOT claiming that Sun is circumventing the JCP by
developing the Jigsaw module system for JDK7 in an OpenJDK project.
That's good. I know you would not do such a thing. The understanding
held by observers of complex topics often comes down to a general
feeling or perception, which can be skewed by offhand comments meant
for those "in the know".

> So perhaps (like the original topic on this thread) it simply comes down to
> a general feeling or perception. This wasn't helped by the numerous recent
> emails to the observer list which basically declared JSR 294 as stagnant,
> and naming Jigsaw the de facto reference by virtue of having documented
> changes to the JLS, etc.

The 294 observer list is of course primarily a way to follow the
Expert Group discussions; there is no expectation that EG members are
even on the observer list. The 294 observer list can be posted to by
observers so that their comments do not get lost on personal blogs,
unrelated mailing lists, etc. It is not surprising that, occasionally,
observers will post a view supporting one aspect of the EG discussion
or another.

> But I recognize those particular emails didn't come from the expert group
> or Sun, and I hope that JSR 294 can help clarify that it is very much alive
> and in control of the process.

There are very important issues at stake in 294 and EG members are
doubtless consulting widely within their organizations. My recent
questions to the authors of the Simple Module System proposal are
intended to light up the road ahead where the proposal is rather
brief. As Peter Kriens said, "please bear with us and allow the EG to
do its work".

Alex

[Alex Buckley]

Replying to my own post:

On Sep 18, 10:05 am, Alex Buckley <alex.buck...@sun.com> wrote:
> This discussion precisely demonstrates my earlier point. Some people
> don't merely suggest a language feature; they demand a detailed
> interactive discussion with Sun on the feature.

It occurs to me that some people will immediately respond to my above
paragraph with:

"I wasn't demanding anything! I was just having an interesting
discussion on a mailing list!"

Technically this response is correct. But the "interesting discussion"
often leads to: "Sun is too stupid to realize how good my suggestion
is, and Java will die without it."

Sun eventually hears about pretty much all Java language ideas made
worldwide. Many suggestions make flawed assumptions and it is not
practical for Sun to correct those assumptions on a one-to-one basis.
Nor is it possible for Sun to engage in a discussion about the design
space which could, perhaps, lead to a small tweak being identified
that improves a proposal tenfold.

Alex

[hlovatt]

Alex,

You have written an excellent post:
http://blogs.sun.com/abuckley/en_US/entry/versioning_in_the_java_platform,
but I don’t see the relevance to the requested source proposal. No one
is asking you to solve the issues you raise. All people are asking is
that the source statement behaves like the ‘-source’ flag for 1.7
will.

So how about putting something along these lines into the JLS.

1. Change the books name to The Java 1.7 Language Specification
(J1.7LS).
2. In the introduction state that the book describes version 1.7 of
Java only and that the reader should refer to The Java Language
Specification (JLS) ed. 3 for older versions of Java.
3. The source statement is compulsory and goes before package and is
source “1.7”;, if the file does not contain this statement then it is
not a Java 1.7 program and is not described in this book. For pre 1.7
Java see JLS ed. 3.
4. If the compiler offers a –source flag or similar on the command
line then this flag is to be ignored for 1.7 files, i.e. the source
statement overrides the –source flag (or equivalent) for the file in
question.

That is it; you don’t need to say anything else because currently the
JLS does not specify what the source encoding is for different Java
version, what the compilation strategy is for different Javas, what to
do with a mixed version compilation, or what to do about libraries.
Yet people manage with the –source flag as it currently is and its
behaviour has not been altered in anyway.

The above J1.7LS is obviously an outline but is more than sufficient
for a yah or nah decision.

-- Howard.

On Sep 18, 7:05 pm, Alex Buckley <alex.buck...@sun.com> wrote:
> On Sep 17, 5:51 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
> > Alex, 'source' simply acknowledges that java (the language) syntax and
> > java (the runtime library) dependencies are utterly unrelated things.
>

> Incorrect. Language features often rely on library features. Seehttp://blogs.sun.com/abuckley/en_US/entry/versioning_in_the_java_plat...

[Ben Schulz]

> You have written an excellent post:http://blogs.sun.com/abuckley/en_US/entry/versioning_in_the_java_plat...,

> but I don’t see the relevance to the requested source proposal. No one
> is asking you to solve the issues you raise. All people are asking is
> that the source statement behaves like the ‘-source’ flag for 1.7
> will.

I am confused. As I understand it, the -source flag allows me to
compile sources of one version against the _binaries_ of sources in
another version. I thought the idea of the source statement was to
compile two sources (which may depend on each other in any way) with
different source versions. And the argument against that (again, as I
understand it) is that every language change would have to be made
compatible with n versions of the language rather than "just" one.

For what it's worth, I feel like the language is evolving at a decent
speed. The changes being made are not necessarily the ones I would
have made, but I was not expecting that. ;) The one thing I really do
wish for is better primitives for language interoperability, meaning a
standardized types for functions, tuples etc. (I don't need an
official explanation why it is or is not coming.)

With kind regards
Ben

[Joseph Darcy]

On Wed, Sep 16, 2009 at 8:32 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:

On Sep 15, 11:28 pm, Bob Lee <crazybob...@gmail.com> wrote:

[snip]
 

In regards to the coin form: You didn't answer my question, Joe, you
just went on the defense. Why not accept proposals based on less
officious bits and more useful bits, and make decisions earlier? You

Why do you ask rhetorical questions suggesting things that were actually already done?

For example, the Coin form did *not* require JLS-level text.  It requested less formal text in a guided attempt to expose all relevant issues.

The "for further consideration" step was a staged acceptance procedure.  This would have been done more formally; the procedures for any coin-like future effort will no doubt be revised based on experiences in coin.
 

yourself said string switch took you 8+ hours to write up including
feedback. You're the coin lead, you knew it had a good chance of
making it. You're a JLS and langtools expert. You know exactly what
you want from the proposal. T

Which included writing a *thorough* proposal as an example for others.
 

he people you want input from would have
needed 24 full hours or more, and would instead have the knowledge
that the effort has at best slim chances of making it in. Why are you
surprised the community isn't putting in as many proposals as you
wanted?

I would actually have preferred many fewer proposals of higher quality being submitted. Being able to focus on 10-20 proposals would have been more producive.  The proposals could have been moderated before hitting the list to provide an initial vetting, but at least this first time around we did want to turn people away before "approaching the doorstep." Future projects may make different tradeoffs.

I will repeat: no one was obliged to send in proposals to Project Coin.  Attempts were made to set expectations before the call for proposals started.  Evolving the language in a responsible fashion is a lot fo work.  Coin invited others to participate in that work and, yes, that work can be time consuming.  My numerous blog entries on the subject should have made clear changing the Java language is not a trivial undertaking.

When writing my proposal, I had a copy of "So you want to change the Java Programming Language..." (http://blogs.sun.com/darcy/entry/so_you_want_to_change) in view and made liberal use of the index and table of contents of the JLS.  Important qualities for writing the proposal are being dilligent and methodical.
 
[snip]

(I know that's not how you've written up string, but exact
implementation is irrelevant at the decision stage of the process, as
long as its obvious it won't be particularly difficult to find a
workable one).

While the exact implementation details are not needed, it is important to know the features is *implementable* at reasonable cost, which a less complete proposal does not confirm.
 
-Joe

[Reinier Zwitserloot]

These are (easily) solvable problems. Especially with a module system.

On Sep 18, 7:05 pm, Alex Buckley <alex.buck...@sun.com> wrote:

> On Sep 17, 5:51 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
> > Alex, 'source' simply acknowledges that java (the language) syntax and
> > java (the runtime library) dependencies are utterly unrelated things.
>

> Incorrect. Language features often rely on library features. Seehttp://blogs.sun.com/abuckley/en_US/entry/versioning_in_the_java_plat...

[Joshua Marinacci]

many hard problems become solvable with a module system. that's why
it's the most important feature for JDK 7

[Reinier Zwitserloot]

Hey, no word of disagreement for me there. *any* step towards letting
the any language stay up to date without causing a small army of
pitchfork wielders when it inevitably breaks old stuff, is a module
system. Go go Jigsaw!

[Joseph Darcy]

On Fri, Sep 18, 2009 at 4:20 PM, Joseph Darcy <jdd...@gmail.com> wrote:

On Wed, Sep 16, 2009 at 8:32 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:

On Sep 15, 11:28 pm, Bob Lee <crazybob...@gmail.com> wrote:

[snip]
 

 

he people you want input from would have

needed 24 full hours or more, and would instead have the knowledge
that the effort has at best slim chances of making it in. Why are you
surprised the community isn't putting in as many proposals as you
wanted?

I would actually have preferred many fewer proposals of higher quality being submitted. Being able to focus on 10-20 proposals would have been more producive.  The proposals could have been moderated before hitting the list to provide an initial vetting, but at least this first time around we did want to turn people away before "approaching the doorstep." Future projects may make different tradeoffs.

I will repeat: no one was obliged to send in proposals to Project Coin.  Attempts were made to set expectations before the call for proposals started.  Evolving the language in a responsible fashion is a lot fo work.  Coin invited others to participate in that work and, yes, that work can be time consuming.  My numerous blog entries on the subject should have made clear changing the Java language is not a trivial undertaking.

A PS to my earlier message, getting a new feature into the language is not the only possible benefit of diligently filling in the Coin proposal form.  If increased knowledge and understanding of the language results from that exercise, that benefit exists regardless of what happens to the actual proposal.  How one values such detailed Java language knowledge is another question :-)

-Joe

[Joseph Darcy]

On Thu, Sep 17, 2009 at 9:34 AM, Joshua Marinacci <jos...@marinacci.org> wrote:

(warning, this is long).


It's easier to invent a new language than improve the old one for the
same reason it's far faster and cheaper to build a brand new road then
to do minor repairs on an existing road that's *in use*.  This is just
the nature of software. Once something ships and is used by customers
it instantly becomes legacy. And the more people use it the harder it
becomes to change.  Over the last 30 years of software development
we've come up with lots of tricks to address this, but it's still a
very hard problem with no easy answers.

Yes, there is always a balance between stability and progress.

When a platform is new, much of its value is that it is new, different, and presumably better than existing platforms in some way.  As a platform gets widely used, some of the value delivered by the platform transitions to keeping the code which uses the platform working.

The compatibility policies used to evolve the JDK [1] aim to keep source and class files working while also improving the capabilities of the platform.  However, the wide use of the JDK does impose some behavioral compatibility constraints.  Two examples from JDK 5, for a time javac switched from using "$" between the component names of local and anonymous classes to using "+".  The names of local and anonymous classes are a contract the compiler keeps with itself; unlike nested member classes, local and anonymous classes can't be referred to outside of the declaring context. [2]  While using "$" in this way is not specified anywhere, people came to rely on that convention over the years and numerous build systems broke with the switch to "+" so we reverted to using "$".  Also in JDK 5, the private int value field in java.lang.Integer was switched to being "final" to play better with the memory model and similar changes were made to the other wrapper classes.  Unfortunately, a program widely used at the time relied on being able to write these *private* fields.  The addition of final was reverted for a time and reapplied later in JDK 5 after the misbehaving external program was fixed.

Developers can rely on many of these accidental details of the platform implementation.  One benefit of adding a module system to the platform is that more of such details can be hidden, making evolving the platform easier.

-Joe

[1] "JDK Release Types and Compatibility Regions"
http://blogs.sun.com/darcy/entry/release_types_compatibility_regions

[2] "Nested, Inner, Member, and Top-Level Classes"
http://blogs.sun.com/darcy/entry/nested_inner_member_and_top