From Project .Lombok Group on the JSR process...

[Lenny P]

Anyone get this to the right people and get it fixed?

.....
Re: [project lombok] Why not request a JSR to include it in Java SE?

We've tried to get far less ambitious changes into java, and I'm holding back when I say that the experience has been "disappointing".

Our most recent 2 attempts:

* Allow 'any annotation' as a valid option for annotation fields. This lets us enable onMethod, onConstructor, and onParam properly. This was shot down under the motto: "Looks like you put in all the effort we usually ask for" (including patches to both the JLS and javac, and a lengthy discussion on the effects), but there is 'no time'. Note that the 2 persons involved in this part of java, Joe Darcy and Alex Buckley, created an entirely different annotation-related feature a few months later, so I can only conclude that either Not-Invented-Here syndrome is involved, or, anything that isn't directly requested by other departments in oracle is simply not important.

* Show how that other proposal (multiple annotations of the same type on a single member) is ill thought through and is clearly being rushed, with a spec half-baked. I've been informed my comments are not welcome, and that there is at this point no time (heh, that sounds familiar) to fix things. Note that right now the spec is being changed anyway due to comments from the JavaEE lead that originally asked for this feature. Yet again that 'no time' things seems to be a convenient excuse, but, then, I don't know how things are run inside oracle. That is a big part of the problem - opaqueness.

You can see why, personally, I've given up. The process to add things to java is too opaque and the effort required to satisfy requirements is far too large knowing that so far we've been turned down every time. If I had a reasonable guarantee that, if the spec is near perfect, the patches to javac are bug free, and there are no outstanding issues, that it would happen, I'd put in the effort.

I get the strong feeling that if no project lead within Oracle personally cares, your odds of getting anything into java is pretty much nil, but no Oracle project lead is going to go public with support in case things backfire.

--Reinier Zwitserloot

On Sun, Jan 6, 2013 at 12:35 AM, Mike Dias <mike.rodr...@gmail.com> wrote:
I was upset with Java by ALWAYS force me to write getters/setters. I love Java, but I hate the unnecessary verbosity of getters/setters.

So I found the Project Lombok and my eyes can shine again with clean code! =)

In my humble opinion, this project should be part of the Java SE and fortunately this is possible through of Java Community Process:

"Any individual, organization, or company that signs the Java Specification Participation Agreement (JSPA). (Members may also be called Participants elsewhere on this web site.) Members enjoy all the privileges of Public participation, plus they can:
propose new or revised Java API specification projects by filing a JSR..."
What do you think?
--

--

[Simon Ochsenreither]

Hi Reinier,

that's exactly my experience. See all the fun with Lambdas and Option.

OpenJDK is as much open source as Android: it is in the licensing sense; but not in the community and collaboration sense.
Someone should probably invent a new word for it, so that people don't have false assumptions.

The "no time" seems to be a result of the (intended) strict adherence to release dates. I guess all the individuals are just deeply afraid of causing a disruption here. And since pretty much everything going into OpenJDK needs to be "sponsored" by some Oracle group (exceptions apply) and everyone is busy there, there is no one left picking up even the small, random bits and pieces coming from the community (like fixing that "public constructor" in j.m.BigInteger, which is actually package private since decades already).

Pretty much the only chance is getting into Project Coin (which would probably mean in this case that nothing else could go into Coin) or building up public pressure long enough for the marketing department to realize and act (see Lambdas).

Maybe you should have a look at other projects which are more welcoming to community contributions.

Nevertheless, I wish you good luck.

Bye,

Simon

[Casper Bang]

On Sunday, January 6, 2013 11:24:41 PM UTC+1, Simon Ochsenreither wrote:

OpenJDK is as much open source as Android: it is in the licensing sense; but not in the community and collaboration sense.
Someone should probably invent a new word for it, so that people don't have false assumptions.

For far too long, people (in this group as well) have inflated "open source" with artificial attributes. It's odd really, because the wording is quite precise; the source code is open for inspection, and depending on the license, open for modification. However, just how the project is governed is out of the scope of any OSS-license that I am aware of.

While it's really nice to have code available, at the end of the day, it's more important to use an open standard than open source - the source is simply an implementation detail, nothing more and nothing less. That's my main beef with Java, it is not as much a standardized syntax and API as it is a narrow 3-tier product (JME/JSE/JEE); as Microsoft, Apache and Google would come to learn each their own way (arguably Microsoft the least elegant of the crowd).

It seems the best we can hope for then, is when open source and open standards intersect. However, even so, regardless of it being a committee or Linus Torvalds, somebody needs to coordinate and standardize around a mainline with a trademark (Java, .NET, Android, Ubuntu etc.). In the case of Java, it's just unfortunate that there's a heavy tie to a required runtime environment which Oracle doesn't really know what to do with. Let's keep in mind, that Lombok itself is a symptom of lack of features in the language which btw. Google is also exploring (i.e. Android R file generation). The Java space seems divided into 3 groups now: those who continue the vanilla road, those who explore workarounds and finally (an ever increasing) group of people who left the ecosystem over alternatives like Clojure, Scala etc. and who for practical purposes might as well substitute the JVM with Parrot, CLR, whatever.

[Kevin Wright]

In Scala at least, I'm finding almost the entire community still think of themselves as Java programmers.  Java nowadays is first and foremost a platform, and you're still programming against Java even if you're not not using Java-the-language.

Java in this sense is about web application servers, and netty, and joda-time, and JDBC, and maven repositories, and the memory model.  All stuff that can't be trivially ported to run on parrot or .NET.

What Java *isn't* about here is default mutable collections, and use-site variance, and get/set property accessors, and lambdas being delayed at the same time as you gain the ability to put underscores in numbers, or any of the other delays and setbacks that cause a project like Lombok to even be needed in the first place!

[Casper Bang]

In Scala at least, I'm finding almost the entire community still think of themselves as Java programmers.  Java nowadays is first and foremost a platform, and you're still programming against Java even if you're not not using Java-the-language.

Fair enough, but you aren't really programming against Java (the API) either though are you? You constantly live in this shadow world (not unlike Java arrays vs. generics, C const vs. non-const etc.).

 

What Java *isn't* about here is default mutable collections, and use-site variance, and get/set property accessors, and lambdas being delayed at the same time as you gain the ability to put underscores in numbers, or any of the other delays and setbacks that cause a project like Lombok to even be needed in the first place!

 

However, the JVM and bytecode is so heavily tied to Java that it seems like an uphill battle, which is what Lombok is now hitting. The bytecode is still OO (new, invokeinterface, invokevirtual), with operators required to having been assigned a type (iadd vs. fadd) etc. 

Considering how many of the later advanced features of Java (the language) relies on hacks and workarounds (inner classes, generics by erasure, reference equality) and how we are now getting silly unsigned int arithmetic utilities in JDK8 rather than simply a new unsigned byte, I can only imagine what goes on underneath with Clojure, Scala etc. when implementing i.e. "yield" efficiently.

[Kevin Wright]

Assuming you mean "yield" in the sense of for-comprehensions, that's one of the easy ones! It's a nice localised rewrite of the syntax tree:

for(x <- myCollection) yield { x.toString }

becomes

myCollection map { x => x.toString } 

All comprehensions are translated like this, using the necessary combinations of map, flatMap, filter and foreach.  When people say that "for" in Scala is a comprehension and not a loop, they really aren't joking :)  The programming in Scala book has an entire chapter on the subject.

More interesting and challenging is the lambdaLift, which converts x => x.toString into a synthetic inner class with an apply(x) method that encapsulates the lambda.  It gets more interesting still if that lambda is actually a closure and has to "close over" contextual state.

I'd also hesitate to call erasure a hack, without it we'd be stuck with use-site variance and cripple a lot of work on type systems in the JVM*.  Erasure is actually the norm in most languages.  What Java lacks here is not reification, but a convenient mechanism to supply the erased type information at runtime if it should be necessary.

Fortress had a nice approach here, and Scala's manifests (or typeTags since 2.10) are also a step in the right direction.  But they're still rather clunky in some scenarios and won't be a complete solution until pattern matching can automatically "unerase" via manifests whenever they're available.

* e.g. The approaches used by JRuby, Mirah or Fortress. Not to mention declaration-site variance, or Martin Oderky's "delimited object types" proposal.

[Cédric Beust ♔]

On Mon, Jan 7, 2013 at 3:13 AM, Casper Bang <caspe...@gmail.com> wrote:

For far too long, people (in this group as well) have inflated "open source" with artificial attributes. It's odd really, because the wording is quite precise; the source code is open for inspection, and depending on the license, open for modification. However, just how the project is governed is out of the scope of any OSS-license that I am aware of.

Couldn't have said it better myself. Open source means... well, you can read the source. That's it.

Even Linux, the poster child of open source projects, is extremely closed for contributions (as in "the bar seems impossibly high to contribute"). Actually, most open source projects are like this. The height of that "contribution bar" depends on many factors, among which popularity, complexity and assholeness of the benevolent dictator. Scala is no exception, by the way (I remember Simon himself complaining a few months ago that his simple doc fix pull requests in the Scala documentation were not even receiving a response, much less being merged).

-- 

Cédric

[Fabrizio Giudici]

On Mon, 07 Jan 2013 15:29:41 +0100, Cédric Beust ♔ <ced...@beust.com>
wrote:

> On Mon, Jan 7, 2013 at 3:13 AM, Casper Bang <caspe...@gmail.com>
> wrote:
>
>> For far too long, people (in this group as well) have inflated "open
>> source" with artificial attributes. It's odd really, because the
>> wording is
>> quite precise; the source code is open for inspection, and depending on
>> the
>> license, open for modification. However, just how the project is
>> governed
>> is out of the scope of any OSS-license that I am aware of.
>
>
> Couldn't have said it better myself. Open source means... well, you can
> read the source. That's it.

Correct. Indeed, we should have adopted the term "Open community" or such
to mean the broader thing.


I guess, BTW, what are the popular projects that can be designed as "Open
community".


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Graham Allan]

Jenkins?

http://kohsuke.org/2013/01/04/the-other-side-of-forking-and-pull-requests/

[Fabrizio Giudici]

On Mon, 07 Jan 2013 17:21:22 +0100, Graham Allan <grundl...@gmail.com>
wrote:

> Jenkins?

Well, I hope also a few more things...

[Cédric Beust ♔]

On Mon, Jan 7, 2013 at 7:45 AM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

I guess, BTW, what are the popular projects that can be designed as "Open community".

I think this kind of openness can be harmful, but like I said earlier, it's actually a very good indication of where a project stands in its life cycle. Very young projects or projects that are not getting a lot of traction can benefit a lot from having very liberal commit rules because they are trying to build a community, add features and have very low backward compatibility risks.

As your project becomes popular and increases its user base, you owe it to your existing users to lock down the external contribution process, period. I've been on both ends of that spectrum and speaking from a personal open source standpoint (TestNG) and corporate one (Android), it was absolutely enlightening to me to see all these commits that look very strong, have good tests and even comments and documentation and yet having to turn them down because they break other subtle parts of the product that the contributor either didn't know about or doesn't care about.

-- 

Cédric

[Fabrizio Giudici]

On Mon, 07 Jan 2013 18:09:41 +0100, Cédric Beust ♔ <ced...@beust.com>
wrote:

> I think this kind of openness can be harmful, but like I said earlier,
> it's
> actually a very good indication of where a project stands in its life
> cycle. Very young projects or projects that are not getting a lot of
> traction can benefit a lot from having very liberal commit rules because
> they are trying to build a community, add features and have very low
> backward compatibility risks.
>
> As your project becomes popular and increases its user base, you owe it
> to
> your existing users to lock down the external contribution process,
> period.
> I've been on both ends of that spectrum and speaking from a personal open
> source standpoint (TestNG) and corporate one (Android), it was absolutely
> enlightening to me to see all these commits that look very strong, have
> good tests and even comments and documentation and yet having to turn
> them
> down because they break other subtle parts of the product that the
> contributor either didn't know about or doesn't care about.

I completely agree. In the end, there's a similar thing than the "open
closed" principle, and the focus point is which is the best trade-off.

[clay]

What is really wide open about Java is that anyone can write a library, framework, build system, code analyzer, ide, jvm language, etc, and that there is a broader community and culture around that. The Java ecosystem has a really strong track record of success stories: Ant, Maven, JUnit, Scala, Groovy, Lucene, Hadoop, eclipse, IntelliJ, Jenkins, etc.

The core Java language, library, and VM are only partially open in that the source and version control has public read access, some of the genuine internal design discussions take place on public live read/write dev mailing lists, and the core Oracle team really does incorporate lots of outside contributions. But, Oracle doesn't offer full participation to the public, and expecting that is probably unrealistic and impractical.

You can criticize the Java platform because the core language/vm being semi-closed, but .NET is even more closed in that the .NET culture is much less open to any using any non-Microsoft library or framework or language. I can't imagine a community build tool taking off in the .NET culture the way that Ant or Maven did or a third party language taking off the way Scala did or a third party IDE taking off like IntelliJ or such polished first-class cross-OS support for Linux/Windows/Mac.

[clay]

I would also add that if boilerplate code drives you nuts, you may want to simply consider Scala. That language really addresses most of the lombok issues, and since they don't have to patch it on top of a legacy language, they were able to address the issues more elegantly. Scala handles the getter/setter issue particularly elegantly.

[Ricky Clarkson]

Scala could do better on getters and setters by exposing a Java foo.getBar() as foo.bar.

Similarly it's about to be left behind when Java adds lambdas because Java lambdas get assigned a type according to the context they're used in, whereas Scala lambdas get assigned a type based on their arities, parameter types and return types, so e.g., executor.execute(() -> { System.out.println("hello world"); }); in Java 8 will be

executor execute new Runnable { override def run() { println("hello world") } } in Scala, unless you use/write some wrappers converting Scala's () => Unit to Runnable.

On Jan 8, 2013 3:32 PM, "clay" <clayt...@gmail.com> wrote:

I would also add that if boilerplate code drives you nuts, you may want to simply consider Scala. That language really addresses most of the lombok issues, and since they don't have to patch it on top of a legacy language, they were able to address the issues more elegantly. Scala handles the getter/setter issue particularly elegantly.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/L33RPtkOi8cJ.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Fabrizio Giudici]

On Tue, 08 Jan 2013 19:28:22 +0100, clay <clayt...@gmail.com> wrote:

> What is really wide open about Java is that anyone can write a library,
> framework, build system, code analyzer, ide, jvm language, etc, and that
> there is a broader community and culture around that. The Java ecosystem
> has a really strong track record of success stories: Ant, Maven, JUnit,
> Scala, Groovy, Lucene, Hadoop, eclipse, IntelliJ, Jenkins, etc.

I pretty much agree with clay - while everybody can disagree on whether
the trade-off in the open-closed mix choosed by Oracle for the
Java-language-and-VM (for sure we live in a sub-optimal world and as many
things it could be better), I think that the most valuable heritage from
Sun has been the community and the culture. Of course it wasn't
exclusively a merit of Sun, open source existed on its own, but the
corporate contributed in giving it a boost. If I think of the common bag
of tools, libraries and frameworks that I use, well we get used to that,
but it's a very high number of pieces from different sources that fit
together and give us a huge number of combinations to pick from. This is
somewhat extraordinary and it's one of the things that keep the Java
success, in spite of the language slowly evolving.

[Martijn Verburg]

For those who are interested in contributing to OpenJDK or the various JSRs out there and want some support, please do take a look at the JUG lead adoptajsr.java.net and adoptopenjdk.java.net projects.  We've been quietly working away at improving things for day to day developers and we welcome all levels of experience.

Cheers,

Martijn

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

[Reinier Zwitserloot]

I'm looking for the other way around: A java feature (or alternate spec for a proposed feature) designed by some member of the community - how do you get that into java? I'm talking about extremely small changes that do not involve any contentious issues. Simple stuff like: Allow 'Annotation' as a legal type for annotation member methods, in addition to the already existing: Any specific annotation type, any primitive, String, Class, any enum, and a 1-dimensional array of any of those.

There used to be JSRs (there still are), there is this new JEP thing, there are various documents that suggest what needs to be done to try and start the process to get such a change into java itself, but there aren't any details I can find on who to contact. When contacting people I know at oracle who are in charge of very similar features, you get the rude treatment of 'no time' (clearly false as we now know).

As others have said, 'open source' does not imply the above is possible, but right now I get the feeling Oracle is trying to paint a picture that it _IS_ possible to do this given enough support. This picture does not seem to be realistic.

Also, the other annotation feature, the one requested by the JavaEE team and the one where all of a sudden there is time after all, is not going to get its own JSR, it's going to be shoved into the umbrella JSR. This feels a lot like a bad habit that US laws have: Big umbrella laws get random pork shoved in there, so that nobody dares to vote it down, because it's all or nothing. This too feels like Oracle paying lip service to the idea of community.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

[Martijn Verburg]

Hi there,

This is why we started the Adopt a JSR and Adopt OpenJDK programmes.
Please join us at adoptajsr.java.net and adoptopenjdk.java.net and
we'll help get you contacting the right people in the right way.

PS: There's a global dial in for Adopt a JSR in 2 hours - details:

https://blogs.oracle.com/jcp/entry/adopt_a_jsr_program_online

Cheers,
Martijn

>>> javaposse+...@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/javaposse?hl=en.
>>>

> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/javaposse/-/vcKfImgVtbsJ.

> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to

> javaposse+...@googlegroups.com.

[Simon Ochsenreither]

Hi,

I'm looking for the other way around: A java feature (or alternate spec for a proposed feature) designed by some member of the community - how do you get that into java? I'm talking about extremely small changes that do not involve any contentious issues. Simple stuff like: Allow 'Annotation' as a legal type for annotation member methods, in addition to the already existing: Any specific annotation type, any primitive, String, Class, any enum, and a 1-dimensional array of any of those.

as long as your employed by Oracle, the change doesn't even need to be that small. As it looks, Java 8 will be getting static method implementations for interfaces (in addition to default methods) and a new visibility modifier keyword and I haven't seen an official announcement, a debate, a JSR or a JEP about it.

Imho, getting a feature/change into Java is all about keeping a low profile and knowing the right person at Oracle to sneak it in. If the politics start, your chances decrease tremendously that you will get it shipped in time.

Bye,

Simon

[Ricky Clarkson]

I'm quite happy about the static methods in interfaces.  Please pick on a different feature to complain about the process with. :)

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/sfaUET_9H_AJ.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Simon Ochsenreither]

I'm quite happy about the static methods in interfaces.

For a language which has already gone down the rabbit hole of having “static” elements, I think the change is nice, because the interface can now be used for factory methods. No “Arrays.asList” non-sense anymore!

Please pick on a different feature to complain about the process with. :)

The point I'm making is that the decision whether something gets the “official” treatment or is merged in behind the curtains seems to be driven more by marketing aspects and less so by technical aspects.

So, if people want to get stuff into Java, don't make too much noise, don't wake sleeping dogs/politicians and try to sneak it in.

[Ricky Clarkson]

The specific reason why I'm happy with static methods in interfaces is that I'm planning on updating Functional Java for Java 8, and fj.F is.. a.. class.  So you can't use it as the target for a lambda expression.  It used to be an interface, but the static method temptation was too great and it was converted to an abstract class so that static methods could be added.

I converted it back to an interface and found that I had to rehouse the static methods, breaking all callers of those static methods.  With static methods in interfaces the only callers I'll need to break to do that are the ones who implemented it with a named instead of an anonymous class, which is probably reasonably rare for that particular library.  Even so they'll only need to change 'extends' to 'implements' so it's no great shakes.

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/REbwJ3iun8wJ.

[Cédric Beust ♔]

On Fri, Jan 18, 2013 at 8:08 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

The point I'm making is that the decision whether something gets the “official” treatment or is merged in behind the curtains seems to be driven more by marketing aspects and less so by technical aspects.

There are a lot of aspects that impact the decision of adding a feature to the JDK but I haven't seen a shred of evidence that "marketing" is one of them. Some of the aspects I have observed first hand:

• Technical. Obviously, the complexity of that feature should weigh heavily on the decision to include it. Compilers are very complex beasts that are hard to keep clean under the covers.
  
• Design. Is the feature a good fit for the language? Does it play well with the other features?
  
• Backward compatibility. Breaking existing users is a non-starter. How much work is required to maintain backward compatibility with this feature?
  
• Schedule. What's the impact of adding this feature on the release schedule?
  
• Technical quorum. Are there any experts strongly opposing such a feature? If yes, are their concerns valid?
  
• Usefulness. Does the feature fix a big gap in the language? What percentage of existing users will be helped by this feature? How many will be negatively impacted?
  
• Public support. Do a lot of existing users ask for such a feature?

Just to name a few.

-- 

Cédric

[Joseph Darcy]

On Fri, Jan 18, 2013 at 7:55 AM, Simon Ochsenreither
<simon.och...@gmail.com> wrote:
> Hi,
>
>
>> I'm looking for the other way around: A java feature (or alternate spec
>> for a proposed feature) designed by some member of the community - how do
>> you get that into java? I'm talking about extremely small changes that do
>> not involve any contentious issues. Simple stuff like: Allow 'Annotation' as
>> a legal type for annotation member methods, in addition to the already
>> existing: Any specific annotation type, any primitive, String, Class, any
>> enum, and a 1-dimensional array of any of those.
>
>
> as long as your employed by Oracle, the change doesn't even need to be that
> small. As it looks, Java 8 will be getting static method implementations for
> interfaces (in addition to default methods) and a new visibility modifier
> keyword and I haven't seen an official announcement, a debate, a JSR or a
> JEP about it.

As long as you have an approved JSR with a mandate to make supporting
language changes, you can make supporting language changes. The JSR
for Lambda, http://www.jcp.org/en/jsr/detail?id=335, covers this work.

The ideas of static methods in interfaces and a "package" modifier are
not new and their addition has discussed on the various lambda lists
and documents, for example:

http://mail.openjdk.java.net/pipermail/lambda-spec-experts/2012-December/000146.html
http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.0/

-Joe

[Simon Ochsenreither]

As long as you have an approved JSR with a mandate to make supporting
language changes, you can make supporting language changes.

I wouldn't call a change which basically obsoletes the way people have written helper and utility classes for the last 17 years a “supporting change”.
From a user perspective, the move from the “(final) class + private constructor with thrown exception” pattern to static interface methods is probably as huge as from AICs to lambdas.

But hey, I guess everything is subjective.