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
--
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.
On Tue, 17 Jul 2012 21:05:02 +0200, Martijn Verburg <martijn...@gmail.com> wrote: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.
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.
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
--
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.
--
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?
--
Because this proves - again - how deeply shallow and mercantile Java's new owner is.
--Cédric
The very same slides were shown three Devoxx'es in a row. :-p
Because this proves - again - how deeply shallow and mercantile Java's new owner is.It's sad really...
Having a large JRE isn't an issue for my server development work...
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.
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.
--
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.
+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
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...
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.
--
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.
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'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
Don't bother fixing the language, just offload even more burdens onto the tooling. Any other attitude is "Ivory Tower" material
--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
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.
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
What do our Java desktop application developer colleagues in here thing about this ? Because Jigsaw's delay probably impact them most. Or not ?
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
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:
- A simple module system that is really well integrated into the Java language, compiler, and runtime
- A modularization of the JVM itself
- Removal of classpath configuration
- 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.
So, we're all Java enterprise application developers in here ? (I am btw)
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/OTRxQ3bXVR4J.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
(Given that I'm spot on with Kevin about the reduction of the technical debt, but it's another story).
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.
My jerk comment. OSGi style modularity has not helped Eclipse compete
with IDEA. Why do we think it will help everyone else?
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.
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.
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
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
My jerk comment. OSGi style modularity has not helped Eclipse compete
with IDEA. Why do we think it will help everyone else?
Which keeps bringing me back to the question of, what exactly is the win of jigsaw? A faster startup of the jvm? What else?
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.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.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.
Radically change - yesWhenever 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.
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).
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.