Opinions: How long to wait for Jigsaw?

[Hayden Jones]

I'm curious to hear people's opinions on how long JDK8 should be delayed for Jigsaw.

Assuming (and please state your own assumptions when you offer your opinion): 

• The current release of JDK8 (without Jigsaw) stays scheduled for August 2013
  
• Oracle does not want to release more than once every two years. (so if JDK8 is shipped with Jigsaw then JDK9 would arrive the earliest at August 2015)
  
• The ETA on the work to be done is accurate within 20%
  

Then, if the work on JDK8 + Jigsaw could be shipped prior to September 2014 then I would prefer to wait.  Otherwise I think that the new DateTime API and Lambda should be shipped on August 2013.

Other opinions?

[Ricky Clarkson]

I want my lambdas now and I'm in a job where using non-Java languages
will be a difficult sell. The earlier the release the better for me.

I've seen classpath hell exactly once, actually in a current project,
and plan to deal with it in a different way - attempting to
find/create a combination of libraries that don't have version
conflicts, and where that is not possible, moving tasks out of the
same JVM process.

The other benefit would be JVM startup time, which is less and less an
issue each year as machines get faster and Java doesn't get bigger.
I'd like to see the startup time be improved further, but lambdas will
affect me more than cutting down startup from 5 seconds to 1.

> --
> 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/-/53J8nPwzdIAJ.
> 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.

[Hayden Jones]

So, I take it you're a fan of the delay time being ZERO.  :-)

I appreciate that point of view (I want my ThreeTen yesterday and 308 should have been in JDK7) and another advantage I can see in it is that it is less new stuff for me to learn in one chunk (as well as giving the tools people less to do).

[Ricky Clarkson]

0?  It's already five years since the fully-working BGGA compiler for lambdas and six years since the proposal.  >10 years since MS added delegates to their fork of Java (I don't mean C#, but the one the court case was about) which are not lambdas but meet some of the same needs.

I expect tooling support will be there before release, the IDEs had the Java 7 features ready before it was released.  Less maintained tools like jad or some of the lint tools might not be ready on time though.

Compare that to Java 5 though, where the IDEs were terrible on generics for quite a while.  I think that was because the process was more closed back then.  I don't like the slow speed of progress but I do appreciate that it's at least visible from the outside.

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

[Thomas Matthijs]

On Thu, Aug 30, 2012 at 4:03 PM, Ricky Clarkson
<ricky.c...@gmail.com> wrote:
> I want my lambdas now and I'm in a job where using non-Java languages
> will be a difficult sell. The earlier the release the better for me.
>
> I've seen classpath hell exactly once, actually in a current project,
> and plan to deal with it in a different way - attempting to
> find/create a combination of libraries that don't have version
> conflicts, and where that is not possible, moving tasks out of the
> same JVM process.
>
> The other benefit would be JVM startup time, which is less and less an
> issue each year as machines get faster and Java doesn't get bigger.
> I'd like to see the startup time be improved further, but lambdas will
> affect me more than cutting down startup from 5 seconds to 1.
>

I agree fully, jigsaw won't fix any problem i currently have, lambdas
on the other hand would be very beneficial

[Kevin Wright]

I always figured that anyone who wanted lambdas that much would be sailing the choppy JVM waters on a differently lingual boat by now.  It's not as though you even have to change your ops infrastructure or much of your tooling to do so.

(hint: rename scala.jar/clojure.jar/groovy.jar/whatever.jar to apache-closures.jar, release your project binaries as you always did.  Don't make a song and dance about it, it's easier to ask forgiveness than to request permission)

Jigsaw on the other hand... That means distinctions like SE/ME can be done away with, long-deprecated code can finally be removed, startup time, download time, and memory foot print can be reduced, etc.  It makes Java far more suitable for running on something like the Raspberry Pi.  These are cross-cutting concerns that benefit all languages on the Java platform.

Defender methods and method handles are also just plain awesome.  Even without lambdas, I'd fully expect some powerful optimisations to be realised on top of those two.

[Thomas Matthijs]

On Thu, Aug 30, 2012 at 5:16 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
> I always figured that anyone who wanted lambdas that much would be sailing
> the choppy JVM waters on a differently lingual boat by now. It's not as
> though you even have to change your ops infrastructure or much of your
> tooling to do so.

If it was up to me sure, but convincing my coworkers :x, in the end
everyone on the team needs to be able to understand/fix any part of
our codebase, (guess you'll tell me to find another job).
It's a lot easier to push an upgrade to java x through then to teach
them scala/.../.. (along with their tooling for compiling, IDE setup,
etc )

> (hint: rename scala.jar/clojure.jar/groovy.jar/whatever.jar to
> apache-closures.jar, release your project binaries as you always did. Don't
> make a song and dance about it, it's easier to ask forgiveness than to
> request permission)
>
> Jigsaw on the other hand... That means distinctions like SE/ME can be done
> away with, long-deprecated code can finally be removed, startup time,
> download time, and memory foot print can be reduced, etc. It makes Java far
> more suitable for running on something like the Raspberry Pi. These are
> cross-cutting concerns that benefit all languages on the Java platform.

I think most of us are using java server side, where none of these
things matter at all, i don't even think it starts up slow.
Sure it can help with very limited jarhell with like xerces/jaxb etc,
but for the average joe these things have been solved long ago or our
application wouldn't function at all.

Also if jigsaw is in the same release as lambdas and the classpath no
longer exists and all tools/scripts/whatever need to be updated, this
will make it a lot hander to push the upgrade to that java version
through, and delay when I can use the other new shinies even longer.

However if you already jumped ship to an alternative jvm language,
there is not much in java8 for you, so i understand those people
pushing hard to get jigsaw in it.

>
> Defender methods and method handles are also just plain awesome. Even
> without lambdas, I'd fully expect some powerful optimisations to be realised
> on top of those two.

I kind of lump those together with lambdas :)

>
>
>
>
> On 30 August 2012 15:57, Thomas Matthijs <li...@selckin.be> wrote:
>>
>> On Thu, Aug 30, 2012 at 4:03 PM, Ricky Clarkson
>> <ricky.c...@gmail.com> wrote:
>> > I want my lambdas now and I'm in a job where using non-Java languages
>> > will be a difficult sell. The earlier the release the better for me.
>> >
>> > I've seen classpath hell exactly once, actually in a current project,
>> > and plan to deal with it in a different way - attempting to
>> > find/create a combination of libraries that don't have version
>> > conflicts, and where that is not possible, moving tasks out of the
>> > same JVM process.
>> >
>> > The other benefit would be JVM startup time, which is less and less an
>> > issue each year as machines get faster and Java doesn't get bigger.
>> > I'd like to see the startup time be improved further, but lambdas will
>> > affect me more than cutting down startup from 5 seconds to 1.
>> >
>>
>>
>> I agree fully, jigsaw won't fix any problem i currently have, lambdas
>> on the other hand would be very beneficial
>>

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

[Ricky Clarkson]

No, it would be unprofessional to change the language silently, because it could leave the company with an unmaintainable codebase and invalidate their current automatic code quality checking.

By unmaintainable I don't mean that the code could not possibly be maintained, but that the current staff would have a ramp up period to maintain it, and the worst time to have that would be just after I stop working for them.

The most I would do under the radar is a prototype, and I'd propose converting to Java or accepting the other language at the point of becoming something likely to live longer than a prototype.

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

[Ricky Clarkson]

Removing the classpath is not a part of the proposal.  Java is not intended to break over time.

[Thomas Matthijs]

It was one the main stated goals for a long time to replace it, unless
I read it wrong, but i guess they'll still be hardcore backwards
compatible as always

On Thu, Aug 30, 2012 at 5:39 PM, Ricky Clarkson

[Joseph Darcy]

On Thu, Aug 30, 2012 at 7:54 AM, Ricky Clarkson
<ricky.c...@gmail.com> wrote:
> 0? It's already five years since the fully-working BGGA compiler for
> lambdas and six years since the proposal.

There are significant technical differences between the feature set of
BGGA and the feature set of Lambda. As noted in the JEP for Lambda
(http://openjdk.java.net/jeps/126):

"Project Lambda started with a straw-man proposal and has gone through
several "State of the Lambda" iterations which have evolved both the
syntax and feature set of the project.

The work on lambda expression portion of Project Lambda is informed by
numerous previous efforts, including but not limited to:

* BGGA,
* CICE
* FCM
* Pizza [dates back to 1997 and predates the GJ work which was the
basis for Java generics -ed.]

The feature set of Project Lambda is judged to better address the
needs of evolving the Java platform than the earlier proposals.

The design of virtual extension methods is likewise informed by a
large body of prior work in the programming language community
including:

* multiple inheritance in C++
* static extension methods in C#
* traits in Fortress
* traits in Scala
* mixins in Strongtalk"

There are active discussions about Project Lambda over on its OpenJDK
mailing list.

>10 years since MS added
> delegates to their fork of Java (I don't mean C#, but the one the court case
> was about) which are not lambdas but meet some of the same needs.
>
> I expect tooling support will be there before release, the IDEs had the Java
> 7 features ready before it was released. Less maintained tools like jad or
> some of the lint tools might not be ready on time though.
>
> Compare that to Java 5 though, where the IDEs were terrible on generics for
> quite a while. I think that was because the process was more closed back
> then. I don't like the slow speed of progress but I do appreciate that it's
> at least visible from the outside.

One reason there was prompt IDE support for Project Coin/JSR 334
features that the Project Coin/JSR 334 team made sure to reach out and
work with people from all three major IDEs; more timely IDE support
for the new language features than in JDK 5 was an explicitly
recognized goal this time around.

[Ricky Clarkson]

BGGA was always overreaching(*) and likely to have things
removed/changed. Non-local breaks, continues, returns and throws, and
writes to non-final local variables would always be contentious. I
didn't mean to say that everything was ready in 2007, as there were
always more discussions to have, but there was quite a period of
apparent indecision on whether to have lambdas at all. I'm sure
without the period of indecision we'd have had them in Java 7, and in
quite a similar form to the current plan for Java 8, i.e., I'm not
sure we've collectively learned anything

That's excellent about cooperation with IDE maintainers, I hadn't
realised that had happened.

Joe, would you say that C#'s lambdas informed the Java design?

* BGGA's overreaching was because Neal Gafter wanted to make sure that
code within a closure meant exactly the same as code outside a
closure, down to a continue inside the closure being able to cause a
loop outside the closure to continue. It was, engineering-wise, a
very good solution, and I had lots of fun breaking that compiler while
it was in alpha, but I think everyone involved knew that a sample of
the features would be chosen.

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

[Jess Holle]

Realistically Jigsaw in no way facilitates removal of long-deprecated code.

At *best* it would allow for deprecated *classes* to be moved to a separate, optional module.  It can't do a thing about deprecated methods.  Removing those would still utterly fragment the Java community.

Personally I'd like to just see the basic "app developer level" modularity from Jigsaw and leave the native-package-system integration and core class library modularization to Java 9 or 10 or whatever.  Having a simple module system that is understood by both the compiler and runtime would help ordinary developers who don't need something as complex as OSGi (e.g. don't need to juggle multiple versions of 1 jar within one JVM or web/enterprise app as they just manage to figure out a combination of versions of different libraries that works and move forward using those -- it's usually pretty easily done).

How long would I hold Java 8 for this?  Not terribly, but I don't think this is really being considered.  The Jigsaw folk seemed really hung up on the native-package-system integration and core class library modularization in previous talks.

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

[Joseph Darcy]

On Thu, Aug 30, 2012 at 9:55 AM, Ricky Clarkson
<ricky.c...@gmail.com> wrote:
> BGGA was always overreaching(*) and likely to have things
> removed/changed. Non-local breaks, continues, returns and throws, and
> writes to non-final local variables would always be contentious. I
> didn't mean to say that everything was ready in 2007, as there were
> always more discussions to have, but there was quite a period of
> apparent indecision on whether to have lambdas at all. I'm sure
> without the period of indecision we'd have had them in Java 7, and in
> quite a similar form to the current plan for Java 8, i.e., I'm not
> sure we've collectively learned anything

Closures (and generics) were known to the team originally working on
the language, but were left out for various reasons, including making
release dates, etc.

Advocacy for adding some form of fuller closures in Java from some
people working on Java date all the way back to circa 1997:
http://gbracha.blogspot.com/2008/06/incremental-development-environments.html?showComment=1212937440000#c5772865805884729418

BGGA and Neal's promotion of it several years back certainly can be
credited with bringing a much greater awareness of closures to typical
Java developers; although the need for closures was not universally
acknowledged and there were fierce debates over the details of what
could or should be added:

http://www.parleys.com/#st=5&id=116&sl=1

Even today, there is still lots of traffic on lambda-dev even on minor
syntactical points. Project Lambda has a superset of a subset of the
features of BGGA; that is, based in part on looking at BGGA,
fundamentally different design decisions were made in Lambda than in
BGGA. For example, Lambda does not have function types.

However, it is certainly true that Jigsaw was not the only JDK-related
project impacted by Sun going out of business.

> That's excellent about cooperation with IDE maintainers, I hadn't
> realised that had happened.
>
> Joe, would you say that C#'s lambdas informed the Java design?

I think it is fair to say both the C# and Java language teams keep on
eye on what each other is doing.

-Joe