Personally, I'm dying to see the probable start up improvements that the java plug-in will gain from modularity. (Though you may only gain that with the Sun implementation because Jigsaw will not be part of the required Java7 implementation)
On Sep 18, 10:55 am, Joshua Marinacci <[email protected]> wrote: > I never said Java should or would stop evolving. I'm explaining why > Java must, of necessity, evolve slower than a brand new language. > > With regards to lang interop and closures in JDK 7: here's my thoughts. > > Think of JDK 7 as our Snow Leopard. It's not about sexy new features. > It's about fixing long standing issues in the platform. The two most > important features are modules and invokeDynamic. JDK 7 is about > getting Java ready for the next 20 years. So that it *can* evolve. > This is much needed work and I think reducing the scope of JDK 7 to > just those (no closures, no swing app framework), is vital to the long > term health of the platform. > > - Josh > > On Sep 17, 2009, at 5:46 PM, Reinier Zwitserloot wrote: > > > > > To Josh, Bob, and all the other 'java is a fossil' arguers: > > > Please, stop. > > > Your argument fails almost immediately: Because the JVM has no notion > > of a closure, a 'duration' type, and a gazillion other things various > > new JVM languages are trying to add (as discussed in posse #278!), > > interop between them is much, much worse than dealing with java (the > > language)'s ideosyncracies. Fan even attempts to invent a completely > > new library to go along with it. Talk about a learning curve! (so does > > scala, for that matter. Will noop?). Interop between the new language > > and java is similarly useless. Again, refer to the posse episode, > > where the act of trying to interop javafx with java on anything but > > the highest level was strongly discouraged, and for good reason. > > > Without that interop, your entire argument boils down to: Everyone is > > supposed to at some point either rewrite their project FROM SCRATCH > > into a new language, or migrate slowly by starting new projects in a > > new language, and continuing to maintain the older projects in java. > > > This feels like a bad idea. Scratch that, a horrible idea. Even if we > > accept java as a fossil, it'll first have to evolve towards being more > > interop-compatible so we can all move away from java in an orderly > > fashion. > > > I'm confused, too: You're all the kinds of geek that care about this > > sort of thing, so why is everyone just silently accepting the axioma > > you've posited here: ALL LANGUAGES DIE - that's what you're saying. At > > some point the userbase enforces strict backwards compatibility, and > > somehow we've gone from that to - language dies. > > > Hold on. We're skipping way too many steps here. Says who? Why can't > > java evolve AND stay backwards compatible? We've got 3 things, all > > named java: > > > - The JVM (lots of work, but it can and has been evolving, and nobody > > seems to be asking for it to stop) > > - The core libraries (lots of work. Evolving it is very hard, and > > backwards compatibility constraints are choking improvements) > > - The langtools project (Compared to the other two not even a drop in > > the water. evolving a little, but this is really the entire focus of > > coin, lombok, and other attempts to continue evolve the java > > _language_). > > > As the JVM is already evolving, that problem already solved itself. > > Moving on to how to evolve the latter two without breaking old stuff: > > > For the core libraries, it's hard, but handwaving java (the language) > > away as a fossil does not make this problem go away. For interop, we > > NEED to add closure types and other primitives to the core. To keep > > the core clean (unless everyone really feels fans and scala's approach > > of writing wrappers on top of everything is a solid plan - where does > > that stop? Will we have 8 layers of wrapper in 2020?) we need a way to > > evolve it without breaking old stuff. People have been solving this > > problem for YEARS though. That's why we have module systems, > > versioning, and even advanced ideas such as shipping an API mirror for > > version X that is actually interacting with an object of version Y, to > > let objects of that module cross the border between 2 modules with > > different version requirements for that module. > > > Similarly, even if you do accept that rewriting/wrapping the core > > library is the only acceptable solution, how will you evolve THAT? If > > you don't solve this problem now, in 6 years we'll all be calling > > scala/fan/noop a fossil and moving on to the next shiny thing. I don't > > really feel like rewriting all my projects every decade just to stay > > with the times. I'm just not going to accept that. I hope the rest of > > you won't, either. We can fix this. > > > Lastly, there's langtools. A mere trifle compared to the JVM and the > > library core. So, why not split it up? Right now maintainance/support > > of javac, java.exe (JVM), and runtime library (RT) is tightly bound: > > They all go out of support at the same time. Why is this? Decouple > > javac from the JVM and RT, completely. Give javac a name and don't let > > its version track the core libraries. > > > You could then have the following situation: > > > JVM/RT8 is released with a bunch of modern language primitives such as > > a closure type. DolphinJavac (what's now known as javac6) has been > > updated, bugfixed, and a few very minor backwards entirely compatible > > changes have been shipped with it. This v8 version of DolphinJavac may > > even require JVM/RT8 if you use all the features (just like javac5 > > needs JVM/RT5 if you use annotations, or iterable syntax, etc). If > > you've got a project under active maintainance, you switch to JVM/RT8 > > for it, and DolphinJavac8. > > > A bit later, MahiMahiJavac is released, which contains loads of new > > features, including closures, traits, struct classes, pattern > > matching, lexically scoped monkey patching, and a bunch of other > > features. Old code (written for DolphinJavac) will generate a bunch of > > warnings and in some cases may even simply not work, but MahiMahiJavac > > is still very much javac - a few minor edits is all you need, and you > > should definitely go for it if you're working on an actively in- > > development project. > > > As the early switchers to MahiMahi are clearly preferring updates to > > java-the-language, MahiMahi will continue to evolve fairly drastically > > for the JVM/RT9 timeframe, but at some point MahiMahi is in the same > > boat as dolphinjavac is in now, and it gets major-feature-freeze. A > > few months later, Seawolf is released. > > > This process can be maintained essentially forever, and allows > > continues evolution of the language. > > > On Sep 17, 6:34 pm, Joshua Marinacci <[email protected]> wrote: > >> (warning, this is long). > > >> It's easier to invent a new language than improve the old one for the > >> same reason it's far faster and cheaper to build a brand new road > >> then > >> to do minor repairs on an existing road that's *in use*. This is > >> just > >> the nature of software. Once something ships and is used by customers > >> it instantly becomes legacy. And the more people use it the harder it > >> becomes to change. Over the last 30 years of software development > >> we've come up with lots of tricks to address this, but it's still a > >> very hard problem with no easy answers. > > >> Why don't we step back and look at the big picture here. Java, the > >> language, is used by somewhere between 4 and 8 million developers > >> (depending on who's numbers you use). It's installed on nearly 1 > >> billion desktop computers and even more servers and cellphones. In > >> short, one of the most widely deployed software platforms ever. In > >> short, something very powerful and valuable, but also very difficult > >> to change. > > >> Every change you make to the core must consider the facts above, and > >> that makes change difficult. Not impossible, but difficult and > >> therefore cautious. For every person who wants to add a new feature > >> there are 10 who want no new features (or at least different > >> features). For every developer who wants to break backwards > >> compatibility, there are 100 who don't. That's one of the reasons > >> Swing has been so hard to evolve. > > >> I don't mean to sound depressing or to say that Java will never > >> evolve. It will. But it will be slow. There will probably never be > >> any > >> radical changes to the Java language again. Nothing on the level of > >> generics, at least. But you know what: that's okay. In fact, it > >> might > >> be a good thing! > > >> I was annoyed when I first came to this realization. I'm an uber- > >> geek. > >> I love to learn new things, build new programs, and try new > >> paradigms. > >> I'd love to see the Java language evolve with tons of new things. > >> But after thinking and talking to a lot of people I also realized the > >> value in the backward compatibility: stability. Java is a general > >> purpose language that is becoming built into everything, and thanks > >> to > >> the compatibility promises it's enables tremendous portability and > >> reliability. Libs from 10+ years ago will run flawlessly. This is > >> incredibly valuable. > > >> It still sucks though. We have tension between evolving what we have > >> and keeping valuable compatibility. Fortunately, we have an out: the > >> JVM. The JVM is separate from the language and can host new languages > >> which are compatible with it and with Java. This is incredibly > >> useful. If you want to keep on the forefront then you can use a > >> language with cool features like Scala or Groovy. If you need > >> compatibility you stick with Java. And you can mix and match them at > >> the class / jar level. This also frees the Java language to focus on > >> compatibility even more, while freeing the new languages to innovate > >> in new directions that wouldn't be possible with a mature general > >> purpose programming language. The best of both worlds. > > >> I've said this a few times, but perhaps not here. Java, the > >> platform, > >> will be around for a very long time thanks to the separation of the > >> JVM, the language, and the runtime. JVM > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
