Project Jigsaw probably pushed back to Java 9

436 views
Skip to first unread message

Moandji Ezana

unread,
Jul 17, 2012, 2:49:51 PM7/17/12
to Java Posse

http://mreinhold.org/blog/late-for-the-train

I had just read an interesting practical intro to Jigsaw by Paul Sandoz, so I'm sad to see it go.

Moandji

Jan Goyvaerts

unread,
Jul 17, 2012, 3:02:53 PM7/17/12
to java...@googlegroups.com
Personally, I dont care any more. I think its too big a job for oracle anyway...

I once had high hopes about it because it would make desktop applications much faster. And finally make Java applets on par with the performance of flash.

Its too late for jigsaw to be useful anymore. If want something flashy, Ill go for html5 & css. If I want modularity, I'll use osgi. Waiting another two years will only make it more so.

Sad really...
--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
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.

Martijn Verburg

unread,
Jul 17, 2012, 3:05:02 PM7/17/12
to java...@googlegroups.com
A tough decision and yes a little disappointing, especially since it
would be very useful to have the JDK itself split up. However, given
the extra engineering and community effort to have jigsaw fully
supported by tools and containers, I think it was the right call, and
at least they let us know over a year out.

Cheers,
Martijn

Fabrizio Giudici

unread,
Jul 17, 2012, 4:29:32 PM7/17/12
to java...@googlegroups.com, Martijn Verburg
On Tue, 17 Jul 2012 21:05:02 +0200, Martijn Verburg
<martijn...@gmail.com> wrote:

> A tough decision and yes a little disappointing, especially since it
> would be very useful to have the JDK itself split up. However, given
> the extra engineering and community effort to have jigsaw fully
> supported by tools and containers, I think it was the right call, and
> at least they let us know over a year out.

Really, I don't know. As Jan said, the impact on the desktop side, for non
industrial projects, is relevant. JavaFX 2 will stay mostly confined to
the range of industrial apps. It's true that this final of the story has
been already written in the past two years, but there could be still room
for doing something.

Given that, what's now really the meaning of jigsaw? Not useful on the
server side, and I can say that industrial apps aren't affected by
20-30-40 MB more or less.

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

Jan Goyvaerts

unread,
Jul 17, 2012, 5:28:14 PM7/17/12
to java...@googlegroups.com
On Tue, Jul 17, 2012 at 10:29 PM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:
On Tue, 17 Jul 2012 21:05:02 +0200, Martijn Verburg <martijn...@gmail.com> wrote:

A tough decision and yes a little disappointing, especially since it
would be very useful to have the JDK itself split up. However, given
the extra engineering and community effort to have jigsaw fully
supported by tools and containers, I think it was the right call, and
at least they let us know over a year out.

Really, I don't know. As Jan said, the impact on the desktop side, for non industrial projects, is relevant. JavaFX 2 will stay mostly confined to the range of industrial apps. It's true that this final of the story has been already written in the past two years, but there could be still room for doing something.

Given that, what's now really the meaning of jigsaw? Not useful on the server side, and I can say that industrial apps aren't affected by 20-30-40 MB more or less.

That's a way of looking at it.

I'm more thinking about who will care about Jigsaw's release two years from now. Personally (so this is *my* opinion) I see only two groups of people: the embedded- and the desktop developers. For the former I wonder whether the mainstream hardware won't allow to run a regular jvm by then.

For the latter I wonder if that many will still ask for it by then. Yes, JavaFX is able to do many wonderful things. But so is the HTML5/CSS3/JS steamroller. Wonderful enough to be useful anyway. Not to mention what it'll be able to do in another two years. Not that I'm pleased or enthusiastic about HTML5 & co. But I admit having grossly underestimated its momentum, support and consequences Java development. There is almost no reason anymore to develop a (Java) client application. A modern web application looks as cool as a desktop application, runs also full screen, runs also offline, starts much faster and has virtually no system requirements and is easily distributed.

It would have been nice to have something light and kicking ass running the next generation JDK8 applet in your browser. But who's still reading this sentence when they read the word "applet" of the previous sentence ? :-)
 


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it
--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

phil swenson

unread,
Jul 17, 2012, 5:44:02 PM7/17/12
to java...@googlegroups.com
To me this is another sign that Java needs a reboot. It seems like
all the legacy and compatibility issues have become a really heavy
burden to bear.
>> 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 post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.

Kevin Wright

unread,
Jul 17, 2012, 5:51:50 PM7/17/12
to java...@googlegroups.com
Which is part of what Jigsaw, as I understand it, was supposed to address!

Once we've got *versioned* modules, corba can go, and the old date/time stuff, and methods using enumeration, and any other of the things that have been long deprecated (or that should have been)

This is a sad day, it's the one imminent feature in Java that was of real benefit to the platform as a whole. What remains in the Java 8 spec that isn't just about playing catch-up with Scala, Groovy, JRuby, Mirah, etc?

Carl Jokl

unread,
Jul 18, 2012, 4:20:04 AM7/18/12
to java...@googlegroups.com
Reading the title makes me feel a tad better. I thought for a moment that Project Jigsaw was being abandoned altogether. This would be a shame given that I think that it is about more than just JavaFX and as said would be a step towards cleaning up the platform and being able to drop a lot of deprecated cruft eventually. This would be good for everyone surely, client, server and embedded?

--

Moandji Ezana

unread,
Jul 18, 2012, 6:39:49 AM7/18/12
to java...@googlegroups.com
On Wed, Jul 18, 2012 at 10:20 AM, Carl Jokl <carl...@gmail.com> wrote:
Reading the title makes me feel a tad better. I thought for a moment that Project Jigsaw was being abandoned altogether. This would be a shame given that I think that it is about more than just JavaFX and as said would be a step towards cleaning up the platform and being able to drop a lot of deprecated cruft eventually. This would be good for everyone surely, client, server and embedded?

That would be nice, but if it's only released in 2015, that means adoption will only really begin in 2016-2017 (as it has to be adopted not only by applications, but also by libraries, servers and IDEs). In 5 years, the landscape might have changed enough to make Jigsaw unnecessary.

It's also kind of depressing that it would take nearly a decade to roll out something that's supposed to make the platform easier to evolve.

Moandji

Carl Jokl

unread,
Jul 18, 2012, 6:50:19 AM7/18/12
to java...@googlegroups.com
It is frustrating. Enough of these disappointments and setbacks would make me tempted to want to work with something else sometimes yet the problem remains that the alternatives still have issues. Features get into .Net in a timely manner but then developing with that introduces lots of political problems. Go to C/C++? It is moving more slowly than Java and not very productive. Objective-C? Quirky and showing its age. I don't know, I get fed up with the Java leadership promising much and then failing to deliver or repeatedly under-delivering on what was promised. However moaning about it is not likely to change anything. Oracle isn't going to listen.

--

Jan Goyvaerts

unread,
Jul 18, 2012, 6:55:01 AM7/18/12
to java...@googlegroups.com
Yes, but on the other hand I'm *not* going back to the native languages any more. I'm staying with the JVM. Whether it's oracle's, ibm's or anybody's else JVM.

That's why I'm busy with Scala and Clojure these days. Combining a fast VM and modern, productive languages. But that's another story. :-)

Jan Goyvaerts

unread,
Jul 18, 2012, 10:02:16 AM7/18/12
to java...@googlegroups.com

Morten A-Gott

unread,
Jul 18, 2012, 4:46:34 PM7/18/12
to Java Posse


On Jul 18, 4:02 pm, Jan Goyvaerts <java.arti...@gmail.com> wrote:
> Jax started a poll about Jigsaw:http://jaxenter.com/project-jigsaw-delayed-until-java-9-the-reaction-...

Alternatives obviously crafted by someone upset by the exclusion of
jigsaw :-)
How upset are you?
- Upset
- Very upset
- Outraged!

Jan Goyvaerts

unread,
Jul 19, 2012, 2:03:19 AM7/19/12
to java...@googlegroups.com
No, not angry. Rather disappointed...

Because this proves - again - how deeply shallow and mercantile Java's new owner is.

It's sad really...

Cédric Beust ♔

unread,
Jul 19, 2012, 2:30:47 AM7/19/12
to java...@googlegroups.com
On Wed, Jul 18, 2012 at 11:03 PM, Jan Goyvaerts <java.a...@gmail.com> wrote:
Because this proves - again - how deeply shallow and mercantile Java's new owner is.

Aren't you overreacting a bit? They missed a deadline, that's it. It's disappointing, but come on...

-- 
Cédric

Fabrizio Giudici

unread,
Jul 19, 2012, 2:35:56 AM7/19/12
to java...@googlegroups.com, Jan Goyvaerts
On Thu, 19 Jul 2012 08:03:19 +0200, Jan Goyvaerts <java.a...@gmail.com>
wrote:

>
> No, not angry. Rather disappointed...
>
> Because this proves - again - how deeply shallow and mercantile Java's
> new
> owner is.
>
> It's sad really...

Honestly this is not necessarily true. We don't know the details about the
development of jigsaw and let's recall that it has been starving for years
under the ownership of Sun. In the past two years a lot of things under
the Java sky have been improved, such as the roadmap itself that has been
unblocked. Furthermore, the first to suffer from the lack of jigsaw is
JavaFX 2.0, which Oracle is pushing.

I'd rather say jigsaw problems are technical-political: it's a hard task
and they don't want to consider other alternative technologies already
proven (such as Maven dependencies or OSGi), a position that was already
present at Sun. Now I know that Maven or OSGi aren't optimal for the task,
but at this point, with a perspective of waiting for several years before
the optimal solution, I'd like to have an objective evaluation of
suboptimal solutions that could be ready in a shorter time.

Jan Goyvaerts

unread,
Jul 19, 2012, 4:03:03 AM7/19/12
to java...@googlegroups.com
I should have been more explicit - my remark was not targeted to Jigsaw specifically. I'm sure the Jigsaw people do what they can with what they get. And if I need modules, well, OSGi is a proven and well documented technology immediately available.

I meant the attitude. If it doesn't serve any short-term business purpose, they just delay it. And not meant to be any rude, but it's not "just" missing a deadline in this case, or is it ? We're talking re-re-delayed years. When was Jigsaw release announced for the first time ? The very same slides were shown three Devoxx'es in a row. :-p
 

-- 
Cédric

Moandji Ezana

unread,
Jul 19, 2012, 4:51:41 AM7/19/12
to java...@googlegroups.com
On Thu, Jul 19, 2012 at 10:03 AM, Jan Goyvaerts <java.a...@gmail.com> wrote:
The very same slides were shown three Devoxx'es in a row. :-p

One more time and they'll have broken JavaFX's record!

Moandji

Phil Haigh

unread,
Jul 19, 2012, 5:28:33 AM7/19/12
to java...@googlegroups.com

Because this proves - again - how deeply shallow and mercantile Java's new owner is.

It's sad really...
 


Oracle is in the business of making money through its technology. Jigsaw is not a priority because it has no direct, positive impact on its ability to make money. Why would it be a priority?

Its a bit like asking why Oracle isn't busy coming up with "Java 3". Where's the business driver? Why invest huge sums of money when there is no obvious business driver, use case or guarantee of success.

Sun were R&D driven (in hindsight, a bit too R&D driven). I always expected this of Oracle but I'm not sure who would have been a better steward - Google for example are busy creating other languages like Go. Maybe that's because they don't own Java - or maybe it isn't.

Either way we're stuck with Oracle, but as most of my work is now Groovy, Grails and Scala I have less and less interest in the timeline for Java releases. Having a large JRE isn't an issue for my server development work and not having key Java language features isn't either.

Jess Holle

unread,
Jul 19, 2012, 7:22:58 AM7/19/12
to java...@googlegroups.com, Phil Haigh
On 7/19/2012 4:28 AM, Phil Haigh wrote:
Having a large JRE isn't an issue for my server development work...

Agreed.

Jigsaw is lots of things:
  1. A simple module system that is really well integrated into the Java language, compiler, and runtime
  2. A modularization of the JVM itself
  3. Removal of classpath configuration
  4. Integrations with platform-specific deployment tooling

None of these are really *critical* for Java's current bread-and-butter, which is server-side development work, of course.

#1 would be very nice, though -- and I'd love to see just that delivered in Java 8, jettisoning the rest as fluff/frosting to be added in Java 9.  It's unclear, however, how one could be sure the module system is adequate and won't need major rework in Java 9 without also tackling #2 in Java 8, so perhaps one would also need to tackle #2 in part for Java 8 in this case.

#2, #3 and #4 seem like really, really low priority for server-side work.  They are more important in terms of allowing Java to spread beyond (or at least not contract to) its bread and butter.  They are key for allowing Java SE to be right-sized for lots of other environments.  They would also apparently be key to any notion of replacing the antiquated Java ME with something better -- unless Oracle is simply going to concede mobile (including tablets) entirely to Android forever.  [Personally I'd think Google and Oracle should actually be working together to grow dovetail Android and a right-sized/mobilized Java SE in the long term.]  It's a sad statement for Oracle that they can't get their act together here before 2015 at the earliest.  As a server-side developer, though, I have to say I don't really care that much.  Just give me #1.

As for #4, some of the deployment demos we saw at previous JavaOne's seemed truly irrelevant.  Cool, but irrelevant.  If time wasted in this area has held Jigsaw out of Java 8 that would be a real shame.

Overall, if you *need* modularity today, there's obviously OSGi.  If you don't *need* it, but it would be nice to have, then you're left torn between biting off the complexity of OSGi (it's certainly more complex than something integrated into the language, compiler, and JVM runtime) and putting modularity off until Oracle gets around to it someday in the hazy future (2017 after yet another delay?!?).

--
Jess Holle

P.S. I'm talking about modularity that impacts the runtime, of course.  One can get build-time modularity in loads of ways, Maven being the prime example.

Roland Tepp

unread,
Jul 19, 2012, 7:28:14 AM7/19/12
to java...@googlegroups.com
I don't quite understand why is Maven mentioned in this discussion anyway.

Maven's modularity only handles build time dependencies and has no bearing on runtime behavior. As far as I know Maven only handles the task of pulling in the dependency binaries but as far as the runtime goes its still the same old classpath/jar hell.

Jan Goyvaerts

unread,
Jul 19, 2012, 8:06:59 AM7/19/12
to java...@googlegroups.com

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
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.

So, we're all Java enterprise application developers in here ? (I am btw) 

What do our Java desktop application developer colleagues in here thing about this ? Because Jigsaw's delay probably impact them most. Or not ?

Russel Winder

unread,
Jul 19, 2012, 8:31:06 AM7/19/12
to java...@googlegroups.com
On Wed, 2012-07-18 at 23:30 -0700, Cédric Beust ♔ wrote:
[…]
> Aren't you overreacting a bit? They missed a deadline, that's it. It's
> disappointing, but come on...

I think the point is that Jigsaw was supposed to be in Java 7, but got
bumped to Java 8. Now it has been bumped from Java 8 to Java 9. I assume
it will be bumped from Java 9 to Java 10. Someone on Twitter used the
hashtag #vaporware. It is difficult to see an alternative
interpretation.

If the OSGi folk can't use this opportunity to get some traction for
OSGi that would be an indication that no-one needs or cares about
Jigsaw, which means the #vaporware tag is irrelevant.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc

Kirk Pepperdine

unread,
Jul 19, 2012, 8:33:18 AM7/19/12
to java...@googlegroups.com
One of the problems with Oracle is that they've not understood how work with the community. There are a number of people in Oracle saying, let tell our community what's going on.. something Oracle has been historically.. culturally against... and by rallying against those that were brave enough to stand up inside Oracle and say... this is how community works... we need to communicate with them whats going on... Instead of slamming them, we need to some how be constructive so that the shallow and mercantile part of Oracle sees that this communication with the community is actually a good thing. That those who were arguing to engage were actually correct to do so.

So lets look at facts... JigSaw is hard to execution on... no surprise there. Oracle wants to get it right... hurray for them.. wish they had of done that with Generics... they decide rather then push out a half baked idea they need more time for it in the oven. Seems logical so far. So, do I wish they'd made the deadline? Yes but... not at the expense of a half baked solution.

-- Kirk

Sven Reimers

unread,
Jul 19, 2012, 8:37:46 AM7/19/12
to java...@googlegroups.com

+1 for Kirk... And if you want to make sure jigsaw gets in 9... Join the openjdk project and you may get an idea what the problems are the guys are dealing with

-Sven

Reinier Zwitserloot

unread,
Jul 19, 2012, 9:28:19 AM7/19/12
to java...@googlegroups.com
On Tuesday, July 17, 2012 9:02:53 PM UTC+2, Jan Goyvaerts wrote:
Personally, I dont care any more. I think its too big a job for oracle anyway...


Jigsaw is not particularly 'big'. Oracle's java budget certainly is big enough to cover this if they really want to. It's also not just oracle, they can pull in whatever companies and/or people step up to the plate. There are many reasons to be 'against' jigsaw, or even just oracle's stewardship over it (doing a lousy job, just don't like the design, not a priority for the JVM, OSGi fanboy, and many more), but 'too big' seems like a strange argument to make.
 
I once had high hopes about it because it would make desktop applications much faster. And finally make Java applets on par with the performance of flash.

Jigsaw would have done this. But that's not relevant, because...
 

Its too late for jigsaw to be useful anymore. If want something flashy, Ill go for html5 & css. If I want modularity, I'll use osgi. Waiting another two years will only make it more so.

This was true BEFORE jigsaw was even announced. I'd have eaten both my shoes if the existence of jigsaw would have all of a sudden caused a massive resurgence in websart or applets. Flash did NOT suffer from this issue, nor did silverlight (well, not as much). Flash is basically dead. Silverlight is officially dead.
 

Sad really...


There are many reasons to be sad about jigsaw being delayed, but 'oh boo my applets won't start up instantaneously' does not seem to be a particularly sensible reason to be.

Reinier Zwitserloot

unread,
Jul 19, 2012, 9:41:17 AM7/19/12
to java...@googlegroups.com
On Wednesday, July 18, 2012 12:50:19 PM UTC+2, Carl Jokl wrote:
It is frustrating. Enough of these disappointments and setbacks would make me tempted to want to work with something else sometimes yet the problem remains that the alternatives still have issues.

Fast-moving alternatives are 'small' communities: They have a small number of developers that use it, and those developers all fall in the fanboy camp in that they WANT to be there, they made the choice to steer away from the mainstream, and they chose this language because they really like it, not because 'it's what I learned in college / it's what my first job was about / it's the one that shows up most in job ads / isn't that what you just start with?'.

These people are willing to adapt, and they will shrug off some personal inconvenience to them if it evolves the platform (partly because they are willing to 'suffer' for 'their' language, and partly because they are aware of the language's evolution, they want it to evolve, and they can see how this personal inconvenience may pay off at some point).

These languages also tend to not have many, if any, legacy projects written in them anywhere in the world, so the personal inconvenience that breaking changes introduce is kept to a minimum, in addition to the fact that the user base is more willing to deal with them. The amount of whining if you break backwards compatibility between i.e. scala and i.e. java is a vast ocean.

Contrast this to large communities, where absolutely none of this is true. There's a gigantic legacy backlog, there are many many users who do not feel particularly attached to the language and are thus going to get annoyed when personal inconvenience is introduced, no matter how small and no matter how healthy for the platform. There are also more people who want development for their tiny little slice of the pie and are not willing to take a hit and accept and even cheer on work done in areas they personally don't need or care about but which seem like they are right for the language.

This brings us to a dilemma. A fork in the road. Which fork do you take?

* Join camp awesome and new. However, you KNOW that this camp is DOOMED to turn into the very thing you are turning away from: Either your language becomes popular and sinks down into the mud you just ran away from, or it stays obscure and at some point the developers and most of the community will lose interest, meaning you've just turned to a language that is a complete dead end. You'll be switching language and platform every 5 years or so, most likely, and there is disappointment pretty much every single time. This sounds painful, and like a lot of work.

* Stay with camp old and slow. While you have to live with all the aforementioned issues, you do get an established language, which means it's easy to hire / get hired based on this skillset, there are a metric bajillion libraries out there, example code is easy to find, third parties are likely keeping in mind the fact that you and a large number of other yous exist, (i.e. websites will probably have an API library for you if they have API libraries at all), etc.

I'm picking door number 2 here, and will do so every time.  I'll switch the moment a language is created that can make a reasoned argument that they can handle becoming popular without becoming a backwards compatibility quagmire. "I have balls" / "We'll just fork" does not cut it (proof: Python3). If I'm not forced to put "Version 1.0" or what not at the top of every source file in this hypothetical language you've probably already lost me. Unfortunately nobody seems to give a crud about this dilemma :(

But, I _WILL_ cheer on any attempt to try and create a best of both worlds scenario for an existing language. Unfortunately for me, jigsaw was a step towards allowing java to deal better with the old stuff by at the very least introducing both a way to more easily use third party libraries (letting you move away from old stuff you didn't like by using new libraries with better design), and introducing versioning as a concept at the very least in not just any old third party library but in core java components as well.

Well, the good news is that it's just delayed and not dead.

Reinier Zwitserloot

unread,
Jul 19, 2012, 9:45:50 AM7/19/12
to java...@googlegroups.com
I'm flabbergasted that this entire thread is lamenting the fact that we aren't getting 'smaller JREs' now for java 8.

Like 95% of the rest of the world of java, my java apps tend to be long running and tend to be on machines I control, i.e. make the JRE 2GB for all I care, it just doesn't matter one iota. Bootup can take 10 seconds too, still don't really care.

But I'm REALLY disappointed (not annoyed; if this is the right call, it's the right call. A rushed API is never a good idea): I wanted jigsaw for the ability to modularize my projects, and make development simpler by just being able to stick my dependencies in a file. A unification, of sorts, between the maven idea (build-time dependency management) and the OSGi idea (run-time dependency management). I'm probably expecting way more of jigsaw than it really is, but you gotta start somewhere, and a modularization system that is an intrinsic part of the language and which is what the JVM itself is modularized on seems like a fantastic start.

Jess Holle

unread,
Jul 19, 2012, 9:51:03 AM7/19/12
to java...@googlegroups.com, Reinier Zwitserloot
Agreed.  A simple, unified, compile-time/runtime/language-level module system is all I really want from Jigsaw.

Modularizing the JVM and (most silly of all) integrating with platform-specific deployment tools (e.g. rpm) are really uninteresting to me.  I can see how they're all good things for the long-term health and expansion of Java, but those can all be Java 9 or 10 things.  Simple, integrated modularity is the important thing to get sooner.
--
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/-/15vptfPjuvYJ.

Kevin Wright

unread,
Jul 19, 2012, 10:38:46 AM7/19/12
to java...@googlegroups.com, Reinier Zwitserloot
The loss of Jigsaw is massive and significant.  Having modules, especially versioned modules, is what will allow the language to evolve.

Sure, it would lead to smaller runtimes, but also to cleaning up classes where more than half the methods are deprecated.  It would allow type signatures to be changed.  It would allow Java to (finally!) drop some of the baggage that it's been carrying around since before V1.0

It also needs to be a compile-time solution, and not to carry some of the weight that exists in OSGi - Hotswapping of modules is not on the Agenda here.  Maven comes closest, but Jigsaw needs to be fully integrated into the JVM, fully understood by tools and able to resolve and download modules at runtime.  It needs to do all this without breaking backwards compatibility.

Jigsaw was *the* defining feature of the v8 JVM.  Whereas anyone who truly thinks that lambdas are sufficiently important is already using Scala, or Groovy, or JRuby, or Mirah, or Fantom, or...

The reverse argument, however, isn't true.  You can't claim that anyone who cared enough about modules would already be using Fantom, because Fantom's modules aren't applicable across any language on the JVM, and they don't extend into the Java standard library.


My vote would be to postpone lambdas until 9, and focus on Jigsaw instead.  Java developers are more than used to not getting lambdas, and there are already mature alternatives available for functional programming on the JVM (which are more powerful than the lambda specification).  Jigsaw has no equivalent alternative.

Jess Holle

unread,
Jul 19, 2012, 10:51:57 AM7/19/12
to java...@googlegroups.com, Kevin Wright, Reinier Zwitserloot
On 7/19/2012 9:38 AM, Kevin Wright wrote:
The loss of Jigsaw is massive and significant.  Having modules, especially versioned modules, is what will allow the language to evolve.

Sure, it would lead to smaller runtimes, but also to cleaning up classes where more than half the methods are deprecated.  It would allow type signatures to be changed.  It would allow Java to (finally!) drop some of the baggage that it's been carrying around since before V1.0
I don't see dropping baggage, including methods as relevant.  This is "ivory tower" material.  It has very, very little impact on the real world -- unless one just can't deal with the fact that the real world is not an ivory tower.  The only thing I believe really should be done here is treatment of @Deprecated (or a new @Obsolete) annotation in Javadoc to hide all such methods/classes by default -- and to have IDEs do the same.  That's it -- just hide the cruft by default and you can easily forget it's there (unless you're unreasonably anal even for a software developer).

Having a simple, easy-to-use, integrated modularity solution is relevant to everyone who hasn't crossed the OSGi chasm.  Actually, having modularity integrated at the compiler level is relevant to everyone who doesn't need hotswapping of modules or juggling multiple versions of the same module in the same JVM (really in the same classloader, as one can certainly have multiple versions across web apps in the same JVM without OSGi or any such, for instance).

--
Jess Holle

clay

unread,
Jul 19, 2012, 1:16:45 PM7/19/12
to java...@googlegroups.com
Jigsaw type modularity is the #1 big, important feature for the JVM, IMO. But, I expected this delay... there was too little public progress for them to be close to be making a 2013 final release date.

Project Lambda (first-class functions, and concise anonymous functions) are obviously old news to every other language but they are still really important for Java. Even for Scala work, having the flagship JVM language adopt these features makes them easier to use in cross-language libraries.

What else is left for Java 8? There is the new date/time stuff, which is great.

On Thursday, July 19, 2012 8:45:50 AM UTC-5, Reinier Zwitserloot wrote:
I'm flabbergasted that this entire thread is lamenting the fact that we aren't getting 'smaller JREs' now for java 8.

Like 95% of the rest of the world of java, my java apps tend to be long running and tend to be on machines I control

Sure, for server development "smaller JREs" are not important. If Java is going to be relevant in the client, iOS, and non-Dalvik Android development areas, smaller JREs are critical.

I think JavaFX 2 is extremely niche: there is such a small demand for that type of component business GUI framework. I'd like to see Java do a better job of catering to 3D OpenGL programmers who want a high quality low level graphics pipeline to work with.

Kevin Wright

unread,
Jul 19, 2012, 1:32:01 PM7/19/12
to Jess Holle, java...@googlegroups.com, Reinier Zwitserloot
To Paraphrase:

Don't bother fixing the language, just offload even more burdens onto the tooling.  Any other attitude is "Ivory Tower" material

I couldn't disagree more.  This is the sort of thinking that, IMO, resulted in the monstrosity we knew and hated as legacy J2EE, the abuse of SAM types in the swing library, the Calendar class, and the need for generic parameter folding in IntelliJ.

Piling yet more levels of over-engineering on a crumbling foundation is no solution.  Every now and again, the only sane practice is to have a proper spring clean and simply take out the trash.

That can't happen until we have versioned modules, just in case there are folk out there who actually still *want* some of that trash...

Jess Holle

unread,
Jul 19, 2012, 1:57:56 PM7/19/12
to Kevin Wright, java...@googlegroups.com, Reinier Zwitserloot
No, that's not an accurate paraphrase at all.  I'll try again:
  • Fix and extend the language as appropriate
    • Wherever possible without breaking substantial amounts of existing code, changing its meaning, etc.  If you want to go ahead and break all existing code go somewhere else, e.g. Python 3.
    • Not all extensions are good -- care is obviously needed to select and shape these in keeping with the language.
  • Add great new APIs.
  • BUT do not waste any significant time and energy trying to remove clunky old APIs.
Sweep clunky old APIs under the rug and move on.  That sounds harsh and sloppy, but that's life in the real world.  Anything else is "ivory tower" material unless you're talking about an embedded or mobile environment -- in which case, yes, jettisoning cruft (or lazily loading it on demand) is important.  It's a waste of time and energy otherwise.  Just mark the cruft, hide it in Javadoc and IDEs (with an ability to easily unhide it, of course), and move on.  There's no need for the cruft to bother a non-embedded, non-mobile developer.

Kevin Wright

unread,
Jul 19, 2012, 2:19:56 PM7/19/12
to Jess Holle, java...@googlegroups.com, Reinier Zwitserloot
Not a bad summary.

The thing is, we don't actually *have* a rug yet.  Jigsaw is the rug, and things get swept under it by simply removing them from higher-numbered versions of a module.

To do it in Javadoc and IDEs is more akin to "sweeping it under the furniture".  With the catch that we'd have to build a couple of new bespoke additions to our existing furniture for this express purpose.  Try putting a new tenant in the house (e.g. Scala, or Groovy) with their own furniture, and the whole exercise has to be repeated.

*This*, to my thinking, is the over-engineered waste of time and effort.

Java is not just a language, it's a platform.  By forgetting that and only focussing on their "catch-up" features, Oracle is once again snubbing the community.

Jess Holle

unread,
Jul 19, 2012, 2:37:11 PM7/19/12
to Kevin Wright, java...@googlegroups.com, Reinier Zwitserloot
Tweaking Javadoc and IDE support to hide cruft is simple and effective as compared to having to refactor the entire JVM class library.  It allows hiding of methods we'd all like to forget, which Jigsaw can't.  The only other way to remove an undesirable method is to actually remove it -- and break lots of stuff in the process.  That's pointless.  Just tweak Javadoc and IDEs and move on -- simple and effective.

Swinging Jigsaw at this misses the icky method issue entirely and puts far too high a priority on JVM modularity without cause.

As I see it, Jigsaw is primarily for modularizing the rest of the world in a simple, easy-to-use fashion.  The rest of the stuff (including modularizing the JVM) could really be put off until Java 10.

Jan Goyvaerts

unread,
Jul 19, 2012, 2:40:05 PM7/19/12
to java...@googlegroups.com, Kevin Wright, Reinier Zwitserloot
Why not just adding new default packages to replace java.lang & al ? 

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

Jess Holle

unread,
Jul 19, 2012, 2:51:34 PM7/19/12
to java...@googlegroups.com, Jan Goyvaerts, Kevin Wright, Reinier Zwitserloot
How does adding new default packages remove unfortunate historical methods?

By adding new copied classes without the methods in question?  That's not a solution as I see it.  By making the new class a base-class of the other -- that's not a general solution either due to Java's single inheritance model.

Kevin Wright

unread,
Jul 19, 2012, 3:09:19 PM7/19/12
to Jess Holle, java...@googlegroups.com, Jan Goyvaerts, Reinier Zwitserloot
And how does simply hiding stuff deal with this "unfortunate" mess:

No amount of {display: none} in the javadoc CSS will allow those methods to return an iterator instead, not unless you deprecate them all and implement new versions with subtly different names, and that's just one of the more obvious examples!

Jigsaw is the *only* way we'll be able to bump up version numbers and genuinely remove methods or change their signatures.  As you said, this stuff can be hidden in JavaDoc (hell, ScalaDoc already does something similar by banishing them to the bottom of the page: http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.collection.Traversable)

But... That then has to be reimplemented for each and every tool, in each and every language running on the Java *platform*.  And it *still* doesn't allow you to change signatures in a backwardly-compatible fashion.
--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com
vibe / skype: kev.lee.wright
steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Jess Holle

unread,
Jul 19, 2012, 3:20:55 PM7/19/12
to Kevin Wright, java...@googlegroups.com, Jan Goyvaerts, Reinier Zwitserloot
On 7/19/2012 2:09 PM, Kevin Wright wrote:
And how does simply hiding stuff deal with this "unfortunate" mess:

No amount of {display: none} in the javadoc CSS will allow those methods to return an iterator instead, not unless you deprecate them all and implement new versions with subtly different names, and that's just one of the more obvious examples!
Just use a wrapper Iterator (with unsupported operation for remove()).

Jigsaw is the *only* way we'll be able to bump up version numbers and genuinely remove methods or change their signatures.  As you said, this stuff can be hidden in JavaDoc (hell, ScalaDoc already does something similar by banishing them to the bottom of the page: http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.collection.Traversable)

But... That then has to be reimplemented for each and every tool, in each and every language running on the Java *platform*.  And it *still* doesn't allow you to change signatures in a backwardly-compatible fashion.
Ah...  So you're suggesting creating substantially different (gutted) APIs for new versions of the core library modules, thereby forcing one to update everything one would use in their whole JVM process to use the new APIs for that module rather than old ones in order to use anything (including bug fixes) from the new module version.  That's a complete non-starter as I see it -- that's back to Python 3.0 albeit on a more granular scale.  That would be chaos for anyone with millions of lines of code and many dozens of 3rd-party libraries in their JVM, i.e. those with large enterprise applications like many in Java's bread-and-butter space, including me.

In reality Jigsaw is nothing more than a "move crufty *classes* into a separate, optional module" solution here.  Changes within a class still require all the same API evolution considerations one had before.  That's life in the real world.

--
Jess Holle

Kevin Wright

unread,
Jul 19, 2012, 4:20:01 PM7/19/12
to java...@googlegroups.com
Oops, copying list...

---

Who's being forced?

You don't specify modules at all and you automatically get the latest version of the standard lib modules compatible with java 7 APIs.

You specify LATEST, and you're exposed to changes in API's

You specify exact version numbers, and you're certain that your code will compile and run, even against a newer version of java.

People can move at their own pace, however slow that may be, but it may also be a fast pace - in which case you'll no longer be held back by the demands of backward compatibility all the way to java 1.0

Jess Holle

unread,
Jul 19, 2012, 4:25:47 PM7/19/12
to java...@googlegroups.com, Kevin Wright
The problem is that you then can't move to the latest module and thus get access to the new APIs anywhere in your JVM unless/until you expunge all usages of the old APIs from all of your own millions of lines of code and all of the dozens of 3rd-party libraries you use.

This is a Python 3 schism.  You wouldn't be able to move to the latest of module X until your whole world was an ivory tower.

This would be a guaranteed recipe for all enterprise Java shops to stick on whatever release was before this -- forever.  You'd schism the community each and every time you produced a new module version.

For similar reasons most any open source project with any brains keeps all old methods and classes around once their APIs are initially stable -- and moves to an entirely new package when they find they need to violate this.  That allows use of old and new APIs in parallel within the same classloader without any OSGi fanciness.  Breaking API compatibility otherwise is nasty, user-vicious behavior.  Moving to a new package for Java classes is a non-starter in most cases -- better to deal with cruft than to deal with java.lang.String and java.lang2.String interoperability issues.

Note that even with something like OSGi juggling multiple versions of one module within a JVM you still have java.lang.String and java.lang2.String interoperability issues -- except they both have the same class name (just different Class objects, different methods, etc) to add to the confusion.

Oracle's not stupid -- such a move would be digging their own grave.  It's not the sort of language or platform evolution their customers can tolerate.

Mark Derricutt

unread,
Jul 19, 2012, 4:39:52 PM7/19/12
to java...@googlegroups.com
On 20/07/12 12:06 AM, Jan Goyvaerts wrote:
What do our Java desktop application developer colleagues in here thing about this ? Because Jigsaw's delay probably impact them most. Or not ?

Not sure about desktop developers - but we're ALL command line maven/ant/gradle/lein users - having a faster JVM bootstrap time will increase our build times all over the show and makes us all a bit less thread flamey :)

Kevin Wright

unread,
Jul 19, 2012, 4:57:02 PM7/19/12
to java...@googlegroups.com
I'm currently working on an application that consists of 74 distinct modules in GitHub, most of which are in scala.  One of the smaller modules I've recently been working on has 45k lines, this is down from 70k about a month ago (hey, I practice what I preach, and am a strong believer in staying clean of technical debt)

Across all projects, we're well over a million lines of code (most of which is Scala, remember, and so equivalent functionality to 3-5x that many lines of Java), all under 2 years old.  So in terms of size, I'm working at the same order of magnitude.

One of our "secrets" in getting where we are now, having an application that we can work on at blazing speed, is a willingness to cut code and to refactor ruthlessly.  If it begins to look "enterprise", if there's any obvious technical debt, then that's a code smell - it's not bragging material.

I can honestly say that refactoring to new versions of APIs, or removing the use of deprecated methods has never been a problem.  The very same IDEs that you previously referred to are particularly good at this sort of challenge, and *this* is the correct use of a decent tool - instead of simply hiding stuff.




On 19 July 2012 21:13, Jess Holle <je...@ptc.com> wrote:
To give some further insight:

The enterprise application I work on has been on the market for over a dozen years now.  The latest version has millions of lines of code, some portion essentially unchanged in the last 12 years and some using the very latest Java 7 features and much in between.  The latest version uses many dozens of libraries ranging from Java 1.1 era libraries that are no longer maintained to some that require Java 7.  Requiring that everything jump to some new version of java.lang or java.util or any such to move to Java 'n' (or module rev 'n') would postpone any move to Java 'n' (or module rev 'n') by a long, long time and cause us an enormous amount of expense that we'd scream at Oracle about for years to come.


Oracle's not stupid -- such a move would be digging their own grave.  It's not the sort of language or platform evolution their customers can tolerate.


On 7/19/2012 2:59 PM, Jess Holle wrote:
Note that with something like OSGi juggling multiple versions of one module within a JVM you still have java.lang.String and java.lang2.String interoperability issues -- except they both have the same class name (just different Class objects, different methods, etc) to add to the confusion.

There's no free lunch here.

On 7/19/2012 2:43 PM, Jess Holle wrote:
P.S. For similar reasons most any open source project with any brains keeps all old methods and classes around once their APIs are initially stable -- and moves to an entirely new package when they find they need to violate this.  That allows use of old and new APIs in parallel within the same classloader without any OSGi fanciness.  Breaking API compatibility otherwise is nasty, user-vicious behavior.  Moving to a new package for Java classes is a non-starter in most cases -- better to deal with cruft than to deal with java.lang.String and java.lang2.String interoperability issues.


On 7/19/2012 2:39 PM, Jess Holle wrote:
The problem is that you then can't move to the latest module and thus get access to the new APIs anywhere in your JVM unless/until you expunge all usages of the old APIs from all of your own millions of lines of code and all of the dozens of 3rd-party libraries you use.

This is a Python 3 schism.  You wouldn't be able to move to the latest of module X until your whole world was an ivory tower.

This would be a guaranteed recipe for all enterprise Java shops to stick on whatever release was before this -- forever.  You'd schism the community each and every time you produced a new module version.

On 7/19/2012 2:35 PM, Kevin Wright wrote:

Who's being forced?

You don't specify modules at all and you automatically get the latest version of the standard lib modules compatible with java 7 APIs.

You specify LATEST, and you're exposed to changes in API's

You specify exact version numbers, and you're certain that your code will compile and run, even against a newer version of java.

People can move at their own pace, however slow that may be, but it may also be a fast pace - in which case you'll no longer be held back by the demands of backward compatibility all the way to java 1.0

Jess Holle

unread,
Jul 19, 2012, 5:04:06 PM7/19/12
to java...@googlegroups.com, Kevin Wright
It's great if someone foots the bill for religious refactoring.

Not all organizations will.

Nor can I say that I'd argue for footing such a bill when one has millions of lines of code that work just fine but just happen to have been written against older versions of Java.  Who cares if they use Enumeration or Iterator if they work?

Worse, if you have loads of 3rd-party libraries, you can't reasonably refactor all of them to some new version of Java, especially if some are closed source.  You can try to find alternatives, but you can't always.

This puts organizations in an expensive rock-and-a-hard-place spot -- and many will simply stay behind.  That unnecessarily fractures the Java community.  This is coming from someone who has spent a lot of time and energy to run and compile everything with the latest JVM, latest Tomcat, latest of most everything.  Even so, refactoring everything for purity's sake -- that's not even in the top thousand priorities.

Kevin Wright

unread,
Jul 19, 2012, 5:58:15 PM7/19/12
to Jess Holle, java...@googlegroups.com
The bill is much higher if you don't clean up your own mess, and it typically gets called to account when you're most in need of higher velocity.

Case in point... Sun/Oracle took too long to add modules so they could remove deprecated code from Java, they've been suffering from postponed or feature-limited releases as a result.

Once you have modules, it becomes far easier to release everything else in a perfectly useable but less than 100% complete condition, because you then have the scope to revert design choices in a subsequent version.

Josh Berry

unread,
Jul 19, 2012, 7:41:24 PM7/19/12
to java...@googlegroups.com
On Thu, Jul 19, 2012 at 5:58 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
> Case in point... Sun/Oracle took too long to add modules so they could
> remove deprecated code from Java, they've been suffering from postponed or
> feature-limited releases as a result.

I question how much they are "suffering" from this. There is a vocal
minority that wants it, to be sure. The industry, by and large, seems
to not care.

> Once you have modules, it becomes far easier to release everything else in a
> perfectly useable but less than 100% complete condition, because you then
> have the scope to revert design choices in a subsequent version.

This really only works if you don't have entire industries that depend
on your current design remaining. Pollack's critique of Scala's
system for being ridiculously fragile would be a pale candle compared
to the flame that you seem to be describing.


http://lift.la/scalas-version-fragility-make-the-enterprise

Roland Tepp

unread,
Jul 20, 2012, 3:06:45 AM7/20/12
to java...@googlegroups.com
Personally - I don't care much. For my Eclipse e4 based applications, OSGi modularity works fine and I think it is actually quite good at what it does.

neljapäev, 19. juuli 2012 22:06.59 UTC+10 kirjutas Jan Goyvaerts:
On Thu, Jul 19, 2012 at 1:22 PM, Jess Holle <je...@ptc.com> wrote:
On 7/19/2012 4:28 AM, Phil Haigh wrote:
Having a large JRE isn't an issue for my server development work...

Agreed.

Jigsaw is lots of things:
  1. A simple module system that is really well integrated into the Java language, compiler, and runtime
  2. A modularization of the JVM itself
  3. Removal of classpath configuration
  4. Integrations with platform-specific deployment tooling

None of these are really *critical* for Java's current bread-and-butter, which is server-side development work, of course.

#1 would be very nice, though -- and I'd love to see just that delivered in Java 8, jettisoning the rest as fluff/frosting to be added in Java 9.  It's unclear, however, how one could be sure the module system is adequate and won't need major rework in Java 9 without also tackling #2 in Java 8, so perhaps one would also need to tackle #2 in part for Java 8 in this case.

#2, #3 and #4 seem like really, really low priority for server-side work.  They are more important in terms of allowing Java to spread beyond (or at least not contract to) its bread and butter.  They are key for allowing Java SE to be right-sized for lots of other environments.  They would also apparently be key to any notion of replacing the antiquated Java ME with something better -- unless Oracle is simply going to concede mobile (including tablets) entirely to Android forever.  [Personally I'd think Google and Oracle should actually be working together to grow dovetail Android and a right-sized/mobilized Java SE in the long term.]  It's a sad statement for Oracle that they can't get their act together here before 2015 at the earliest.  As a server-side developer, though, I have to say I don't really care that much.  Just give me #1.

As for #4, some of the deployment demos we saw at previous JavaOne's seemed truly irrelevant.  Cool, but irrelevant.  If time wasted in this area has held Jigsaw out of Java 8 that would be a real shame.

Overall, if you *need* modularity today, there's obviously OSGi.  If you don't *need* it, but it would be nice to have, then you're left torn between biting off the complexity of OSGi (it's certainly more complex than something integrated into the language, compiler, and JVM runtime) and putting modularity off until Oracle gets around to it someday in the hazy future (2017 after yet another delay?!?).

--
Jess Holle

P.S. I'm talking about modularity that impacts the runtime, of course.  One can get build-time modularity in loads of ways, Maven being the prime example.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

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

So, we're all Java enterprise application developers in here ? (I am btw) 

Jan Goyvaerts

unread,
Jul 20, 2012, 3:52:19 AM7/20/12
to java...@googlegroups.com
Theoretically, is it currently possible to implement a release of OpenJDK based on OSGi without getting your pants sued off by Oracle ? If technically feasible of course...

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

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

Kevin Wright

unread,
Jul 20, 2012, 4:53:35 AM7/20/12
to java...@googlegroups.com
That's an old article.  Scala's now on 2.9.2 and soon to be 2.10, binary compatibility is being taken very seriously.

The migration manager is now open source, and available as a plugin for SBT:

Compatibility has now become sufficiently trusted that projects are beginning to drop the scala version identifier from their maven artefact names (akka and spray are the first two that spring to mind)


Trust me, the industry *do* care.  All except for those parts of it who see IT as an unfortunate cost centre, and wish it could just have been locked permanently at COBOL so they'd avoid all those awkward programmer salaries.  I'm hoping that the vast majority of people on this list appreciate the futility of such an attitude.

Josh Berry

unread,
Jul 20, 2012, 8:06:25 AM7/20/12
to java...@googlegroups.com
On Fri, Jul 20, 2012 at 4:53 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
> That's an old article. Scala's now on 2.9.2 and soon to be 2.10, binary
> compatibility is being taken very seriously.

My point was that any company that was practicing the fearless
programming you were describing would make those concerns a breath of
fresh air.


> Trust me, the industry *do* care. All except for those parts of it who see
> IT as an unfortunate cost centre, and wish it could just have been locked
> permanently at COBOL so they'd avoid all those awkward programmer salaries.
> I'm hoping that the vast majority of people on this list appreciate the
> futility of such an attitude.

Find me any evidence of this outside of the OSGi camp. Because I just
don't see it. I keep getting the feeling that I'm told I should care
about it, but no compelling reasons why. So... Citations needed.

Kevin Wright

unread,
Jul 20, 2012, 8:42:35 AM7/20/12
to java...@googlegroups.com
Just look at long-term trends of book sales and job availability for various programming languages.  Java rose from nothing, and COBOL usage continues to fall.  This simply wouldn't be the case if people didn't care about upgrading, improving, and modernising their systems to take advantage of new paradigms and techniques.
 

Josh Berry

unread,
Jul 20, 2012, 8:51:05 AM7/20/12
to java...@googlegroups.com
On Fri, Jul 20, 2012 at 8:42 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
> Just look at long-term trends of book sales and job availability for various
> programming languages. Java rose from nothing, and COBOL usage continues to
> fall. This simply wouldn't be the case if people didn't care about
> upgrading, improving, and modernising their systems to take advantage of new
> paradigms and techniques.

That is one possible explanation. Another is that technologies with a
lot of money behind them get a lot of use. Yet another is that people
are willing to try anything, especially if a perceived expert is
pushing it. Or, heck, anyone that can say "it worked for me." This
last is particularly inviting, just going off people's propensities to
try oddball diets.

Also, none of this addresses what I meant the citation to cover, which
is that industries are clamoring for a modular jvm.

Kevin Wright

unread,
Jul 20, 2012, 11:09:13 AM7/20/12
to java...@googlegroups.com
My intent was to claim that the industry care about keeping up to date with things, as can be demonstrated by the evolution of adopted languages.  Not that they care about Jigsaw per-se.

That would be a claim can't be easily demonstrated by citing industry trends.  Then again, I still contend that there is no other proposed mechanism which would allow deprecated methods to truly be removed, and method signatures to be changed (both important aspects of keeping up to date), all without sacrificing backwards compatibility.

Josh Berry

unread,
Jul 20, 2012, 11:18:37 AM7/20/12
to java...@googlegroups.com
On Fri, Jul 20, 2012 at 11:09 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
> That would be a claim can't be easily demonstrated by citing industry
> trends. Then again, I still contend that there is no other proposed
> mechanism which would allow deprecated methods to truly be removed, and
> method signatures to be changed (both important aspects of keeping up to
> date), all without sacrificing backwards compatibility.


I think that is the crux I have been unable to understand. How is it
truly possible to support some of the changes that are desired while
keeping backwards compatibility? Even with jigsaw. Easy example, how
would jigsaw have helped move on to a better api for dates? I can see
how it would work in some cases. Smaller example, we have Vector and
ArrayList because the api for Vector was synchronized, right? With
modules like this, the idea would be that you could change the api
between versions. But doesn't that fall completely on its face when
you have communication between two modules using this datatype, where
one relies on the old api and one the new?

Or are we essentially just talking about the ability to have pseudo
statically linked applications running in a vm? (In a cleaner way
than multiple classloaders?)

My jerk comment. OSGi style modularity has not helped Eclipse compete
with IDEA. Why do we think it will help everyone else?

Fabrizio Giudici

unread,
Jul 20, 2012, 1:16:35 PM7/20/12
to java...@googlegroups.com, Kevin Wright
On Fri, 20 Jul 2012 17:09:13 +0200, Kevin Wright
<kev.lee...@gmail.com> wrote:

> My intent was to claim that the industry care about keeping up to date
> with
> things, as can be demonstrated by the evolution of adopted languages.
> Not
> that they care about Jigsaw per-se.

According to the evolution of adopted languages, Java, C, C# and ObjC
(which BTW has reached the 3rd position according to Tiobe) are the ones
adopted by the industry. That is, there has been no evolution of the top
languages in fifteen years and clearly Scala, Roby, Python and what else
are still irrelevant. ObcJ is a different story, but its percentage is
more related to the community use (many small developers) than the
industry.

Trends are slowly changing, but at this pace many years will be needed to
change the scenario. And I think Tiobe and the available statistics in
general are strongly biased on the community trends, while the industry is
a different thing.


(Given that I'm spot on with Kevin about the reduction of the technical
debt, but it's another story).


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

Fabrizio Giudici

unread,
Jul 20, 2012, 1:18:44 PM7/20/12
to java...@googlegroups.com, Josh Berry
On Fri, 20 Jul 2012 17:18:37 +0200, Josh Berry <tae...@gmail.com> wrote:


> My jerk comment. OSGi style modularity has not helped Eclipse compete
> with IDEA. Why do we think it will help everyone else?

What are we talking about? Eclipse the IDE is much more spread than IDEA,
even nobody is questioning that IDEA is superior.

For the rest, Eclipse is also a platform for making rich clients, such as
NetBeans, and while you find lots of usages of the the NetBeans and
Eclipse platforms (both componentized) I don't think you find anything
which is based onthe IDEA Platform.

Jess Holle

unread,
Jul 20, 2012, 1:30:45 PM7/20/12
to java...@googlegroups.com, Fabrizio Giudici, Kevin Wright
On 7/20/2012 12:16 PM, Fabrizio Giudici wrote:
(Given that I'm spot on with Kevin about the reduction of the technical debt, but it's another story).
I think the question here is what's actual, substantive technical debt.

Having code that calls APIs which return Enumerations (as per one of Kevin's examples) isn't what I'd call technical debt, especially given that there are often no existing alternatives in core API classes.  Having a new version of java.packageX come out that removed all these APIs and prevents one from upgrading to any future versions of the library until one refactors one's entire source base and moves to new library versions and/or changes/drops libraries to achieve the same with all the libraries one uses isn't a case of dealing with technical debt.  It would be a case of insanity -- and a sign to switch platforms to something that doesn't treat its community in such an insane fashion (or never move to a new version of the platform, but that's insane in its own right).

--
Jess Holle

phil swenson

unread,
Jul 20, 2012, 1:52:36 PM7/20/12
to java...@googlegroups.com, Kevin Wright
> According to the evolution of adopted languages, Java, C, C# and ObjC (which
> BTW has reached the 3rd position according to Tiobe) are the ones adopted by
> the industry. That is, there has been no evolution of the top languages in
> fifteen years and clearly Scala, Roby, Python and what else are still
> irrelevant. ObcJ is a different story, but its percentage is more related to
> the community use (many small developers) than the industry.

irrelevant to whom? Go look for a job in Silicon Valley and I think
you'll find they are very relevant. Go work for Giant Faceless Mega
Corporation, yep - irrelevant.

Fabrizio Giudici

unread,
Jul 20, 2012, 2:11:57 PM7/20/12
to java...@googlegroups.com, phil swenson, Kevin Wright
On Fri, 20 Jul 2012 19:52:36 +0200, phil swenson <phil.s...@gmail.com>
wrote:


> irrelevant to whom? Go look for a job in Silicon Valley and I think
> you'll find they are very relevant. Go work for Giant Faceless Mega
> Corporation, yep - irrelevant.

Well, either we go with statistics or we go with anecdotes. The Silicon
Valley might be the Silicon Valley, but it's not the world.

phil swenson

unread,
Jul 20, 2012, 2:34:25 PM7/20/12
to Fabrizio Giudici, java...@googlegroups.com, Kevin Wright
very flawed statistics (tiobe).

If you want to know where the mindshare of new stuff is, take a look at github.

new stuff ends up being mainstream in a few years. silicon valley is
a window into the mainstream's future

basically, you are claiming that "new technology" is irrelevant.

Fabrizio Giudici

unread,
Jul 20, 2012, 3:22:10 PM7/20/12
to phil swenson, java...@googlegroups.com, Kevin Wright
On Fri, 20 Jul 2012 20:34:25 +0200, phil swenson <phil.s...@gmail.com>
wrote:

> very flawed statistics (tiobe).
>
> If you want to know where the mindshare of new stuff is, take a look at
> github.

Tiobe is surely flawed, but github? I don't know any large industry which
is placing its sources under a private github repo. I presume we have to
clarify what we mean with industry.

> basically, you are claiming that "new technology" is irrelevant.

This is a wild generalization of my thinking. I'm saying that the new
languages are, up to now, scarcely relevant or irrelevant. "Relevance" for
me is the % of money. The discussion was related on the industry alleged
to leave Java because it's too old, with the postponing of jigsaw making
the problem worse. My point is that I'm upset with jigsaw delays because
it's jeopardizing the chances Java clients defend or enlarge a bit their
market share, but for what concerns the areas where Java is currently
strong it won't make a big difference because, as others said, server-side
people needing componentization can use OSGi and a few dozens of megabytes
more in the runtime are not a problem.

Back to the technical point, I cited Maven and somebody put a question. I
have to disagree with Kirk's position about it's better a delay that a
half-baked solution. It largely depends on the context. If the good
solution arrives when it's useless, I prefer a half-baked solution. Maven
dependencies provide a mechanism for defining components and relationships
which is far from being perfect, but it is something that has been used
for years, so we know it pretty well. It doesn't deal with runtime, but a
simple mechanism for it can be borrowed from other systems. So, while a
team is working on a full-fledged jigsaw for 2015, another team could have
been working on an intermediate solution that should have been ready in
2013. And looking back, the alternate solution should have been worked
about since the very beginning, so perhaps we could have had it by 2011,
JDK 7. Some said that the community could have contributed instead of
whining and well, this is what I often say for many other things, so I
can't really disagree. But I fear that working inside the core of the JVM
is beyond the capabilities of the community.

Of course, it all depends on which are the actual technical problems of
jigsaw and a big trouble of this discussion is that we're not dealing with
them.

Kevin Wright

unread,
Jul 20, 2012, 3:42:36 PM7/20/12
to Fabrizio Giudici, phil swenson, java...@googlegroups.com
Nothing wrong with a half-baked solution.  Something can have definite value even if it's not "complete".  But without the ability to evolve the thing and change APIs under a different version number, it's too risky to release in such a state.

This isn't about Java-the-language either, it's about Java-the-platform; getting the module system in place would benefit everybody.  Right now it's looking very much as though Java 8 is only including features that already exist in other JVM languages.

This is a poor decision even on pure economic terms from Oracle's perspective; surely they'd have more to gain by offering benefits over and above C#, Python, Haskell, etc. instead of trying to catch up with Scala & co.  They're no less likely to sell support licences for GC tuning or WebLogic just because someone switches to a different language that can run in WebLogic and still has GC concerns.  The JDBC client for the Oracle DB is still used in the exact same way from Clojure.

I've said it before, and I'll probably say it again, but this is just another way in which they've snubbed the community.

Jess Holle

unread,
Jul 20, 2012, 3:54:16 PM7/20/12
to java...@googlegroups.com, Kevin Wright, Fabrizio Giudici, phil swenson
On 7/20/2012 2:42 PM, Kevin Wright wrote:
Nothing wrong with a half-baked solution.  Something can have definite value even if it's not "complete".  But without the ability to evolve the thing and change APIs under a different version number, it's too risky to release in such a state.
No module system will give you what you want -- an ability to radically and incompatibly change longstanding public APIs whenever and wherever this is deemed more correct/pure/perfect, e.g. wherever you'd do it differently if you could do it all over again.

That's a recipe for destroying the community -- irrespective of the module system.  OSGi wouldn't support that any better -- just imagine an application using libraries which had 4 different versions of the java.lang.String that they are trying to call one another with or having to support 4 different flavors of your library (and maintenance bug fixes to each) just to deal with the 4 different versions of java.lang.String.  Now imagine being faced with 4 different versions of java.lang.String and 4 different independently varying versions of java.util (what's the point in having modules if you can't increment some versions indepedently)...

Modularity is important.  Library versioning is important.  Neither allows you to redesign the core language APIs without either providing backwards compatibility or fracturing the community -- those are your choices.

Fabrizio Giudici

unread,
Jul 20, 2012, 3:59:34 PM7/20/12
to java...@googlegroups.com, Jess Holle, Kevin Wright, phil swenson
On Fri, 20 Jul 2012 21:54:16 +0200, Jess Holle <je...@ptc.com> wrote:

> Modularity is important. Library versioning is important. Neither
> allows you to redesign the core language APIs without either providing
> backwards compatibility or fracturing the community -- those are your
> choices.

I think that we should clarify what are our expectations about jigsaw.
Actually I find the scenario described by Jess quite unfeasible to
implement.

phil swenson

unread,
Jul 20, 2012, 4:26:38 PM7/20/12
to Fabrizio Giudici, java...@googlegroups.com, Kevin Wright
I guess I didn't make it clear that my unfair sweeping generalization
'you are claiming that "new technology" is irrelevant.' was a shot at
your sweeping generalization of "irrelevant".

I don't really understand "% of money". what money?

github just did a $100m round at a $700million valuation. So someone
thinks it's interesting….

take a look at github. a huge chunk of the interesting open source
stuff is being hosted there: twitter bootstrap (and all twitter open
source projects), play framework, hibernate, jquery, mongodb, etc,
etc, etc


from http://gigaom.com/2012/07/09/github-finally-raises-funding-100m-from-andreessen-horowitz/
:

"GitHub’s site holds more than 3 million software repositories
(co-founder and former CEO Chris Wanstrath once described it as “the
Wikipedia for programmers”) and counts more than 1.7 million
developers as users. On an average day, 80,000 repositories are
updated and 7,000 individuals push their first repository to GitHub’s
site, according to the company. "

I think it's safe to say github is a measure of active open source
projects. It is not a measure of enterprise usage.

here are the lang stats:

https://github.com/languages

Fabrizio Giudici

unread,
Jul 20, 2012, 4:39:21 PM7/20/12
to phil swenson, java...@googlegroups.com, Kevin Wright
On Fri, 20 Jul 2012 22:26:38 +0200, phil swenson <phil.s...@gmail.com>
wrote:

> I think it's safe to say github is a measure of active open source
> projects. It is not a measure of enterprise usage.

It's precisely what I meant. With "% of money" I was referring to the
revenues of software makers.

Cédric Beust ♔

unread,
Jul 21, 2012, 12:22:41 AM7/21/12
to java...@googlegroups.com

On Fri, Jul 20, 2012 at 8:18 AM, Josh Berry <tae...@gmail.com> wrote:
My jerk comment.  OSGi style modularity has not helped Eclipse compete
with IDEA.  Why do we think it will help everyone else?

You make it sound as if somehow, Eclipse had failed and IDEA succeeded. At the very least, I see these two IDE's in a fifty-fifty tie in mind share, but in terms of ecosystem, number of plug-ins and side projects that were derived from the base IDE, Eclipse is far, far ahead of IDEA. And yes, I do believe that OSGi was a big factor in this lead, as was Eclipse's original vision (which was much more geared toward plug-ins since day one while IDEA focused on making an IDE first and make it extensible later).

-- 
Cédric

Cédric Beust ♔

unread,
Jul 21, 2012, 12:38:15 AM7/21/12
to java...@googlegroups.com, Kevin Wright

On Fri, Jul 20, 2012 at 10:16 AM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:
According to the evolution of adopted languages, Java, C, C# and ObjC (which BTW has reached the 3rd position according to Tiobe) are the ones adopted by the industry. That is, there has been no evolution of the top languages in fifteen years and clearly Scala, Roby, Python and what else are still irrelevant. ObcJ is a different story, but its percentage is more related to the community use (many small developers) than the industry.

Agreed. Two quick comments:
  • The industry moves at much slower pace than early adopters. We're talking twenty/twenty-five years for an industry to embrace a new language. The number of books, articles, conferences and more generally buzz is completely irrelevant to assess this.

  • The motivation for an industry to move to a new software technology is much more driven by how painful the current technology has become than how promising the new one is. I am firmly convinced that as of today, Java remains very popular with developers and businesses alike, so it still hasn't reached the pain point that C++ had reached in the mid nineties. You need a starving population for a revolution to happen, and I'm just not seeing it with Java right now.
-- 
Cédric

Cédric Beust ♔

unread,
Jul 21, 2012, 12:44:04 AM7/21/12
to java...@googlegroups.com, phil swenson, Kevin Wright

On Fri, Jul 20, 2012 at 12:22 PM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:
Back to the technical point, I cited Maven and somebody put a question. I have to disagree with Kirk's position about it's better a delay that a half-baked solution.

We don't need to go back far in time to see an example of a good half baked solution: Java 7.

It was supposed to be much more ambitious but Oracle chose to ship earlier with less features. I think it was a great call, and not just for technical reasons: it restored faith in the evolution of Java and convinced the community that Oracle was finally putting Java back on track after years of inactivity from Sun.

-- 
Cédric

Cédric Beust ♔

unread,
Jul 21, 2012, 12:46:57 AM7/21/12
to java...@googlegroups.com, phil swenson, Kevin Wright

On Fri, Jul 20, 2012 at 12:22 PM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:
My point is that I'm upset with jigsaw delays because it's jeopardizing the chances Java clients defend or enlarge a bit their market share

I'm not convinced about that. If anything, whatever increase in mind share that Jigsaw might have added to Java has been completely dwarfed by the number of new developers that Android added over the past three years.

At the end of the day, it's the products that matter, not language features.

-- 
Cédric

Cédric Beust ♔

unread,
Jul 21, 2012, 12:50:38 AM7/21/12
to java...@googlegroups.com, Fabrizio Giudici, Kevin Wright
On Fri, Jul 20, 2012 at 1:26 PM, phil swenson <phil.s...@gmail.com> wrote:
ake a look at github.  a huge chunk of the interesting open source
stuff is being hosted there:  twitter bootstrap (and all twitter open
source projects), play framework, hibernate, jquery, mongodb, etc,
etc, etc

How many .net projects? And how many Objective C?

A minuscule amount, because these two communities have their own repos (and most of them are proprietary). Yet, .net and iOS account for a very large portion of the software industry.

github has a lot of great qualities but it is a terrible indicator for industry trends.

-- 
Cédric
(oh and by the way, you'll find a lot of Ruby on Rails on github, even though that platform is rapidly heading into irrelevance)


Roland Tepp

unread,
Jul 21, 2012, 3:50:56 AM7/21/12
to java...@googlegroups.com


laupäev, 21. juuli 2012 1:18.37 UTC+10 kirjutas Josh Berry:
My jerk comment.  OSGi style modularity has not helped Eclipse compete
with IDEA.  Why do we think it will help everyone else?

This is a straw man argument. Modularity (OSGi or any other) has nothing to do with IDEA vs Eclipse vs NetBeans.
All of the IDE platforms are modular almost by definition. It's just the implementations of the modularity are different.

I would even argue that the Eclipse architecture (and openness - both in API design and in political/commercial sense) has played huge interests to Eclipse ecosystem. Just look at the amount of various language IDE's and other tooling that can be found in Eclipse ecosystem versus IDEA. Sure the latter is a more cohesive experience, but you can not honestly claim that Eclipse is no competition to IDEA.

Josh Berry

unread,
Jul 21, 2012, 7:58:18 AM7/21/12
to java...@googlegroups.com
On Sat, Jul 21, 2012 at 3:50 AM, Roland Tepp <luo...@gmail.com> wrote:
> This is a straw man argument. Modularity (OSGi or any other) has nothing to
> do with IDEA vs Eclipse vs NetBeans.
> All of the IDE platforms are modular almost by definition. It's just the
> implementations of the modularity are different.

This is my point, though. Apologies to Cedric for skipping his
response to me, but I was never trying to argue anything about market
share. There were far more influential factors that gives Eclipse the
edge there. My point was that, even though they did not use something
akin to OSGi, IDEA manages to have a codebase that manages to sell
quite well. As you say, I wasn't even trying to argue that IDEA is
not modular. Quite the contrary, I expect it is quite modular.

This is essentially the monolithic kernel versus micro kernel argument
again. I'll find the thread somewhere but Linus basically argued you
can be modular without a modular build. That a single codebase can
maintain modularity, in the same way that a modular codebase can be
severely coupled. Neither automatically win over the other. I find
it hard to disagree with that logic.

Which keeps bringing me back to the question of, what exactly is the
win of jigsaw? A faster startup of the jvm? What else?


> I would even argue that the Eclipse architecture (and openness - both in API
> design and in political/commercial sense) has played huge interests to
> Eclipse ecosystem. Just look at the amount of various language IDE's and
> other tooling that can be found in Eclipse ecosystem versus IDEA. Sure the
> latter is a more cohesive experience, but you can not honestly claim that
> Eclipse is no competition to IDEA.

I think Fabrizio and I touched this angle already. And again, my
point was not that eclipse does not have market share, of course it
does. There were years I stuck with it because I couldn't bring
myself to drop a couple hundred on IDEA. That stepping stone alone
makes it a wonder that IDEA has as much marketshare as it does. But
few have ever argued that the main competitive edge of eclipse is the
cost. Not the modularity technology they used.

Jess Holle

unread,
Jul 21, 2012, 8:29:00 AM7/21/12
to java...@googlegroups.com, Josh Berry
On 7/21/2012 6:58 AM, Josh Berry wrote:
Which keeps bringing me back to the question of, what exactly is the win of jigsaw? A faster startup of the jvm? What else?
My assertion is that the only real near-term win of Jigsaw is a simple module system that meets the needs of build-time and runtime modularity for a good portion of the community -- all with a single system that is well integrated into the language itself.

Today one must use both Maven and OSGi (or equivalents) to accomplish this -- and neither is well integrated with the language.

What about modularizing the JVM? That's only important to allowing the Java SE codebase to be more readily re-used in other environments -- and possibly will yield faster startup time (though a good refactoring could likely do that by itself).

--
Jess Holle

Kevin Wright

unread,
Jul 21, 2012, 10:48:36 AM7/21/12
to Jess Holle, java...@googlegroups.com, Fabrizio Giudici, phil swenson
On 20 July 2012 20:54, Jess Holle <je...@ptc.com> wrote:
On 7/20/2012 2:42 PM, Kevin Wright wrote:
Nothing wrong with a half-baked solution.  Something can have definite value even if it's not "complete".  But without the ability to evolve the thing and change APIs under a different version number, it's too risky to release in such a state.
No module system will give you what you want -- an ability to radically and incompatibly change longstanding public APIs whenever and wherever this is deemed more correct/pure/perfect, e.g. wherever you'd do it differently if you could do it all over again.


Radically change - yes
Whenever and wherever - no

I'm only concerned with two classes of issue here:

1. The big, infrequent changes:  removing Corba, breaking swing out into a separate module, a one-off replacement of all methods using enumeration to use iterable.  The sort of legacy stuff that you often hear people wishing could be changed with each new release, but which is tied to backwards compatibility.

2. Very new stuff that's still evolving.  Instead of hiding JavaFX 2 from the public for so long, it could have been released as a versioned module.  Frequent changes here wouldn't be a problem in the same way as for more established functionality, because nobody's yet had time to build up any legacy code around them.

The extreme way that I works because it happens in a very lean environment, where the developers are all co-located, the "application" is made up of numerous modules all communicating via JSON, and where almost all our services are for in-house consumption by our own client app.

I can't imagine that approach working in the Java libs for a second.

Jess Holle

unread,
Jul 21, 2012, 3:03:17 PM7/21/12
to Kevin Wright, java...@googlegroups.com, Fabrizio Giudici, phil swenson
On 7/21/2012 9:48 AM, Kevin Wright wrote:
On 7/20/2012 2:42 PM, Kevin Wright wrote:
Nothing wrong with a half-baked solution.  Something can have definite value even if it's not "complete".  But without the ability to evolve the thing and change APIs under a different version number, it's too risky to release in such a state.
No module system will give you what you want -- an ability to radically and incompatibly change longstanding public APIs whenever and wherever this is deemed more correct/pure/perfect, e.g. wherever you'd do it differently if you could do it all over again.

Radically change - yes
Whenever and wherever - no

I'm only concerned with two classes of issue here:

1. The big, infrequent changes:  removing Corba, breaking swing out into a separate module, a one-off replacement of all methods using enumeration to use iterable.  The sort of legacy stuff that you often hear people wishing could be changed with each new release, but which is tied to backwards compatibility.
Most of this isn't worth the sort of heartburn / community fracturing it would engender.  Removal of CORBA is a separate case, of course, as this largely can just be moved to a separate module without actually changing APIs in any incompatible fashion.  Rather it can just be pushed out of the way.  That said, it wouldn't buy me anything whatsoever either -- not because I use CORBA but rather because CORBA packages being present does not hurt me in any way whatsoever.

2. Very new stuff that's still evolving.  Instead of hiding JavaFX 2 from the public for so long, it could have been released as a versioned module.  Frequent changes here wouldn't be a problem in the same way as for more established functionality, because nobody's yet had time to build up any legacy code around them.

The extreme way that I works because it happens in a very lean environment, where the developers are all co-located, the "application" is made up of numerous modules all communicating via JSON, and where almost all our services are for in-house consumption by our own client app.

I can't imagine that approach working in the Java libs for a second.
As you say, that works in a very lean, colocated, environment.

This sort of change would fall on its face for large distributed environments with large less modular source bases, lots of usages of external Java libraries, etc.

In short, it wouldn't fly for a good number of large Java-based development organizations.

--
Jess Holle

Reinier Zwitserloot

unread,
Jul 22, 2012, 1:30:13 AM7/22/12
to java...@googlegroups.com, phil swenson, Kevin Wright, ced...@beust.com
A thousand times this. As important as it is to keep evolving the platform, it would be a capital mistake to rush features out the door half-baked in a bid to stem off some sort of mass exodus. That's just not going to happen, nor would java all of a sudden shove a dagger in C's back and bury that particular giant once and for all because it gets some extra features.

That's not to say we should stop caring about features - just because something does not immediately translate to a massive shift in userbase (in one direction or the other), that's no reason to disregard it. Also, language features, or lack thereof, does have an effect on user base, especially if you take a long-term view.

Reinier Zwitserloot

unread,
Jul 22, 2012, 1:45:45 AM7/22/12
to java...@googlegroups.com, Josh Berry
On Saturday, July 21, 2012 2:29:00 PM UTC+2, JessHolle wrote:
What about modularizing the JVM? That's only important to allowing the Java SE codebase to be more readily re-used in other environments -- and possibly will yield faster startup time (though a good refactoring could likely do that by itself).


Modularizing a fairly large program usually leads, down the road, to a project with better code quality, less bugs, and all that. That's one more thing to chalk on the 'pro' side of jigsaw. Also why delaying it is acceptable to me, if the conclusion is that this can't be done properly in time for java8.

Jess Holle

unread,
Jul 22, 2012, 9:30:35 AM7/22/12
to java...@googlegroups.com, Reinier Zwitserloot, Josh Berry
Modularization of the JVM itself can be delayed without any real issue from my perspective.

Same goes for native packaging integration (though how is it that Java still doesn't have a standard Windows service wrapper!?!).

Getting a simple all-in-one build-time and runtime module system integrated into the language, however, is key and far more important.  That piece should come in Java 8 -- without the rest of the less critical, and thus distracting, stuff.

--
Jess Holle

Jan Goyvaerts

unread,
Jul 24, 2012, 4:22:10 AM7/24/12
to java...@googlegroups.com
As suggested in the latest podcast, I'm definitely in favor of having Mark Reinhold interviewed. So he can express his opinion about the future of Jigsaw if delayed to JDK9.

Jess Holle

unread,
Jul 24, 2012, 6:58:19 AM7/24/12
to java...@googlegroups.com, Jan Goyvaerts
Along these lines I'd really like to know why the "core" of Jigsaw (a simple, language-level, integrated module system for developers) cannot be delivered in Java 8 and the rest of it (modularizing the JVM, integration with native packaging systems, etc) in Java 9.

On 7/24/2012 3:22 AM, Jan Goyvaerts wrote:
As suggested in the latest podcast, I'm definitely in favor of having Mark Reinhold interviewed. So he can express his opinion about the future of Jigsaw if delayed to JDK9. --
You received this message because you are subscribed to the Google Groups "Java Posse" group.
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

unread,
Jul 24, 2012, 8:30:42 AM7/24/12
to java...@googlegroups.com
I'm in favour of having Mark on the podcast, regardless if Jigsaw gets delayed or not.  ;-)

clay

unread,
Jul 24, 2012, 7:54:28 PM7/24/12
to java...@googlegroups.com, Fabrizio Giudici, phil swenson
On Friday, July 20, 2012 2:42:36 PM UTC-5, KWright wrote:

"This isn't about Java-the-language either, it's about Java-the-platform; getting the module system in place would benefit everybody.  Right now it's looking very much as though Java 8 is only including features that already exist in other JVM languages."

Java 8 is still absolutely huge, even for the non-Java languages:

- Having lambda expressions in the flagship language is a big deal. Lambda use will become pervasive in cross platform libraries. Similarly with annotations on types and functions in interfaces.
- VM optimizations obviously benefit all languages. JRockit integration. No perm gen.
- Library enhancements generally benefit everyone. The collection library enhancements look major. Having a decent date time library is a big relief.

"I've said it before, and I'll probably say it again, but this is just another way in which they've snubbed the community."

I don't follow this. I consider myself and my coworkers part of the community and we don't feel snubbed. 

The critics are correct that Java has been outrageously slow to ship certain features that have been in all the other major dev platforms. But all of the platforms have strengths and problems. Personally, I like Haskell for it's theoretical purity and Python for the science and engineering community that has built up around it, but both those platforms have there share of problems as well. JVM is still the king for flexibility and a vibrant computer science type community. It has a great for a mix of cutting edge theory (Scala and the like) and practicality.

Sure, I wish the JVM would ship some things faster (lambda, jigsaw, value types), but I'm quite happy with what it is and where it's going.

Reply all
Reply to author
Forward
0 new messages