• Post Reply Bookmark Topic Watch Topic
  • New Topic

Project Jigsaw - but why?  RSS feed

 
Theo van Kraay
Ranch Hand
Posts: 51
1
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand that this will be the most major change introduced in Java 9, but I have to admit I am still struggling to understand why it is even being added?  I do understand the design goals, and I've certainly experienced "JAR hell" before, but I've never thought this is something that should be remediated by reverse engineering Java itself, especially not at the cost of backwards compatibility (and it seems there is a high potential for modularisation to cause existing dependencies for some code to be broken). Any thoughts on this? Am I missing something? Do you think the benefits will outweigh the negatives?
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 37255
519
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Theo van Kraay wrote: especially not at the cost of backwards compatibility

There's backward compatibility issues when pulling in later versions of open source jars too. So while we all try hard not to make that an issue, I don't think the risk should prevent progress.

It also allows Java itself to have a smaller memory footprint because you won't need all of Java for every application.
 
Theo van Kraay
Ranch Hand
Posts: 51
1
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I take your point. However, open source is one thing... re-factoring all the JRE and JDK libraries will mean virtual every enterprise project will have some code somewhere that will break as soon as they try to upgrade. Seems like quite a big difference between that and the normal pain of just adding some later open source code to a few projects. Also, yes I understand the memory footprint improvement, but with the cost of both disk and RAM on a downward trajectory, this seems really only of benefit to mobile devices (and it doesn't seem like that will be for long). So again, the gains seem outweighed by the pain. Maybe it's just my own perspective. After all, I can't disagree with Jigsaw in concept, it's just that backwards compatibility issues bug me, and one of the reasons I'm a fan of Java is that it has always been big on avoiding them.
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 37255
519
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Theo van Kraay wrote:I take your point. However, open source is one thing... re-factoring all the JRE and JDK libraries will mean virtual every enterprise project will have some code somewhere that will break as soon as they try to upgrade.

I disagree. Many enterprise projects run on very powerful services and would keep running the full JDK. So everything would be there.

Also, plain old jars (POJs?) will continue to run in Java 9. So on upgrade day, you only have to worry about the JVM itself. So I don't expect much breakage just by upgrading to Java 9. I do expect breakages as people update their open source libraries to start using modules. But again, we have that now.
 
Theo van Kraay
Ranch Hand
Posts: 51
1
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. I think I may have overestimated (or misunderstood) the extent of the risk. I'll have to look at it again. Thanks!
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 37255
519
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nobody really knows yet. But historically code that ran on the previous version of the JDK would run on the next version. On occasion, you'd need to compile with a compatibility flag (when they introduced a new keyword like assert or enum). So I'd expect that tho continue. And everything I've read implies that old style jars still exist. So I expect a slow incremental migration to modularity.
 
Theo van Kraay
Ranch Hand
Posts: 51
1
Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's what I was hoping, but had read in a few places to the contrary. Perhaps this was scaremongering. I can't find the place I read this now which is frustrating. Anyway, we'll soon find out. I have read that backwards compatibility is a huge priority for the project so I'm going to assume all will be ok until I hear otherwise
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16028
87
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Formerly Sun, and now Oracle, have always been extremely careful to keep new Java versions backward compatible with old Java versions.

That's why, for example, things that have been deprecated in the standard libraries are never removed, they just stay in there, forever deprecated. And it's also why we are still stuck with things like raw types, and why Java is slow to innovate; for every new feature, Oracle elaborately evaluates whether it will cause any backward compatibility issues, and if it isn't possible to do it without major incompatibilities, they prefer to not implement the new feature at all. Backward compatibility is very important to make companies want to upgrade to the new version.

Oracle is not going to break with this tradition and make Java 9 incompatible with older versions in a major way.
 
Campbell Ritchie
Marshal
Posts: 55772
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:. . .  backward compatible with old Java versions. . . .  things that have been deprecated in the standard libraries are never removed, they just stay in there, forever deprecated. . . .
Look up the Eiffel way to do things. Object‑Oriented Software Construction (2e) Pearson (1997) by Bertrand Meyer. He says one shou‍ld mark code as obsolescent and then six months later it is removed. That means that an application which worked nicely for 15 years will suddenly stop working after an upgrade. I can't find the link, but somebody here said that deprecation allows the coders to decide whether and how to upgrade their applications at leisure.
It is unfortunate if backward compatibility means new features can't be introduced, but it is worse if old code ceases to work.
Yes, I remember that raw types were going to be prohibited in new Java6 code.
Yes, it means you have to remember that nobody uses Vector, StringTokenizer or Enumeration any more.

It was not an easy decision to make, but I still think maintaining backwards compatibility is correct.
 
Tim Moores
Saloon Keeper
Posts: 3893
91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you want this kind of functionality NOW, and more powerful than what Java 9 will provide, and with no risk to compatibility, then check out OSGi, which has been around for ages. One can only hope that the interoperability between both that Oracle promised will materialize; it would be a shame if one had to choose between them.

Of course, OSGi has a distinct learning curve, but IMO that's the price to pay for such powerful capabilities.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!