To programmers, Sun seemed earnest about its intentions. Thats why we adopted its Platform. Could anyone name one guy like James Gosling in Oracle ? Didn't thinks so.
With Oracle, everything they do with Java seems to be slimy. Suing Google, JCP elections ( Hologic ?? ). premium for JVM . I fear this trend is to continue.
There are those who think that Oracle would continue to invest in Open JDK and continue to evolve it. I am sure they also believe that MySQl has an even brighter future ahead of it.
The unfortunate sideffect is that cool new languages like Scala and Clojure could end up as collateral damage as JVM is no longer seen as a viable and open platform.
I just might have to bite the bullet and learn me some Haskell after all !! Or GO programming language.
I think the best option for the community is to stick to JDK 1.6 and never upgrade. If people get sick of the Java language going nowhere they can just use Scala on JDK 1.6, or some sort of fork of the Java language that compiles to bytecode that runs on 1.6, etc. I really can't see any of the open source projects embracing the commercial feature set.
1.6 is a really great platform. I don't see it being obsoleted, at least on the server side, for at least 5 more years and no doubt code will live on in production that runs on 1.6 practically forever.
This is really bad idea. Java and the JVM can still be greatly improved. Closures, fixing generics, tail call optimization, module system, faster startup, etc.
JavaFX will be a nice improvement once it's integrated with Java.
Yeah but unless Google buys Oracle or wins the Dalvik lawsuit and implements a better server side JVM than Oracle, I just don't see how it can happen. Closures work fine in Scala, BTW.
Google cannot buy Oracle but maybe they can buy Java. But even the latter possiblity has become much less likely with the premium JVM announcement. Apparently Oracle is determined to monetize Java.
Hitting a couple of your points:
What about Generics is broken? For the extent of power they seem to intend to provide (forcing methods to only take a particular type, and providing syntactic sugar so you don't have to cast everywhere.
Tail-call optimization is just that, an optimization. A 1.6 compliant, open-source JVM could provide that. Same with the faster startup time.
As I don't generally use closures, and would replicate their abilities through interfaces and anonymous classes, I don't have a comment on them; and you'd need to expound upon "module system" for me to say anything.
What's wrong with java generics: erasure. "Cast everywhere" is still happening. And useful info is hidden: eg there is no access to generic type info via reflection. Another wrong thing: generics are incompatible with subtyping. (No co/contra-variance, to use the pointy headed terms)
Tail call optimization is not a mere optimization. A jvm cannot provide it and still provide conforming exception stack traces, for example.
True, although you have to be careful about "incorrect": the code will still compile (unless there's some corner case I'm missing?), so for that particular definition of correctness it is just fine without TCO.
I suppose so; but not in the sense I was thinking of: a Collection<Firetruck> is not a subclass of Collection<IVehicle> (and it is impossible for you to create your own generic class where this type of relationship would be true).
While Collection<Firetruck> has an indeterminate relationship with Collection<IVehicle>, this is good! If Collection<String> was a subclass of Collection<Object>, you could fill the collection with Strings and then pass it off to someone who is using it for Objects and adds in his own Integer. Now your collection is borked. :(
If you find yourself wanting to pass in Collection<Firetruck> to a method that only accepts Collection<IVehicle>, this usually means that the method isn't correctly typed. The rule of thumb for using 'super' and 'extends' is "Producer extends, Consumer super" or PECS. By applying this, the typing problem should go away, as your method is now accepting Collection<T extends IVehicle> and possibly returning Collection<? super T>, so you can both pass in your Collection<Firetruck> and reassign to a different variable of type Collection<Firetruck>. :)
(I think Josh Bloch wrote up a decent blog post about the PECS principle a couple of years ago. It might be worth reading for more information.)
As I enjoy the benefits of immutable data structures and read-only interfaces, it is absolutely not an unmitigated good. Replace "Collection" with "Iterator" above, and the borking you mention is impossible ...
Yes, tail call optimizations include mutually recursive functions.
Note that your example was not of tail calls, however. (Tail call would be: return A(...); that is, a tail call is one whose result is immediately returned.)
I'm going to be slightly handwavy, so forgive me: Generics are implemented by doing type erasure[1] rather than as 'real generics' through some other method. This causes issues with runtime reflection.
> would replicate their abilities through interfaces and anonymous classes,
This embodies exactly what I hate about Java: In other languages, where I simply 'do/end' or ' \ ->', I have to create a whole giant pile of boilerplate bullshit to pull off something that's supposed to be easy.
On Generics: I did not know they performed that slight-of-hand, internally. That does make them rather weak.
On Java-bloat: to be fair, it's really not that much, especially if it's already a known interface:
new TreeSet<Foo>(new Comparator<Foo>() {
public void compare(Foo a, Foo b) { mycode(); }
});
However, your point stands. I've just come to accept that as being a part of Java, myself.
To the extent that Clojure's heath depends on the Java ecosystem, that's true.
To the extent that Clojure is the next big Lisp as many are predicting, not so. The development of Clojure-in-Clojure will make it relatively easy to do more specific platform backends (e.g. x86_64 POSIX); some of us with no love of Java (or of OOP or in extreme need of existing Java libraries) are looking forward to that day.
And while this won't appeal to many, Clojure was originally targeted to the CLR as well as the JVM. Rich Hickey punted his CLR efforts when he decided he'd prefer developing the language at twice the rate, but others have resurrected it.
When Parrot has its concurrency and GC acts together, it's potentially worthy of consideration. As I understand it, neither (which are inextricably linked) are in good shape today.
I have a GC tuning branch which improves performance by about 10%, and we have a new GC in progress as well. Our target date for the latter is for the 3.0 release in January.
2. How do these work with the new concurrency (threading) system that as I remember Team Parrot was going to write?
Ideally, for the multicore future that is now today, I'd like to see multiple simultaneous mutators and scavengers without a stop the world requirement. That said, stock HotSpot doesn't supply the latter, although Azul has done some neat stuff to extend it and apparently Do A Right Thing (their Pauseless mark and compact GC and their open source release of that in their Managed Runtime Initiative).
It would be nice if Parrot can someday do this without extreme pain.
The GC is mostly precise. We haven't yet eliminated our use of the C stack (so full GC has to examine the appropriate registers and memory locations to find pointers not otherwise anchored), but when we do, we'll have a fully precise GC.
Our current GC in trunk right now still stops the world, even when concurrency is active, but that's an incidental detail of implementation and not a requirement for the algorithm. We could make it incremental with a small investment of time, but our priority now is to migrate to the improved generational GC on the branch first.
Oh yeah, as I recall Hotspot doesn't have production quality generational GC yet. That tends to pay off big in functional languages and if I'd had to guess before reading about your priorities I would have bet that generational would be fairly advantageous for a lot of Perl code, certainly the majority I've written (e.g. ETL programs).
Good luck! Nail down this and your concurrency by the time Clojure-in-Clojure is written (there's no guess when that'll happen) and I wouldn't be surprised if someone chooses Parrot as a porting target.
Generational GC will be very useful for Perl 6 and other languages running on Parrot, especially if we can add reliable escape analysis. The ability to perform the equivalent of stack allocation in C offers many performance benefits.
>...as JVM is no longer seen as a viable and open platform.
With Apple dropping work on future major updates to the JVM for OS X, Oracle would be wise to speak up promptly indicating what support/development they'll provide for the platform. Apple has done a pretty good job integrating the JVM with OS X. If Oracle is able to continue from the code-base Apple has been using (and perhaps hire some from that Apple team?), announcing those things would certainly add to the believability of robust support actually coming. Apple isn't very likely to want to part with skilled developers though.
If Oracle doesn't get or (still?) have developers with heavy OS X experience, and perhaps some code to build on, one has to wonder if/when they could ever deliver a quality release for the platform.
IMHO all law suites over patents in software are slimy. This my opinion as a programmer. If you are indeed a programmer, please feel free to look at this and tell me if you see any of the stuff mentioned in the lawsuit not fairly obvious. http://www.theserverside.com/report/The-Oracle-Google-Patent... . I do not think algorithms should be patentable as this stifles innovation. Oracle vs. Google lawsuit would be fun to watch -- if you like the "SAW" movies.
Like it or not, this is how the game is played. If the situation were reversed, Google's lawyers would be all over Oracle like a cheap suit. They'd be neglecting their responsibility to their shareholders if they weren't.
If you think Google is "different" from any other multinational public corporation then you've fallen hook, line and sinker for their PR.
May be so , but so far no software patent lawsuits from Google. Yet.
I read somewhere that Schawrtz, the nincompoop former CEO of Sun, pitched Google lawsuit as an asset. A typical Asshat CEO meets douchebag investor love story.
May be my visceral reaction stems from the gradual acceptance of the fact that I would have to learn Haskell after all.
Its bait and switch-- thats what makes it slimy. With Sun at helm, you never had to wonder if your JVM was intentionally crippled.
I stayed with Java because it was write once run everywhere (on the server side). Oracle is making it into write once, renew your license annually on every platform for every CPU.
Oracle's JRockit is older than the OpenJDK. All they have announced is that their merging the two codebases, and that the next version of Oracle's proprietary JVM will be based off the result. In no way does that resemble a bait and switch.
"Messinger didn't explain how the premium JVM would differ to the free version, but the premium edition will likely see performance tuning and tie-ins to Oracle's middleware."
If one day there are two versions of the JVM based on the same core, and one has more features than the other, the non-premium version will be perceived as crippled. Much depends of course on the kind of features affected. Tie-ins to Oracle middleware would not be a problem. Optimizations appearing first in the premium version before they eventually come to the open version would be a huge problem.
But I think Oracle's strategy is not to cripple the open version so much that it's really worse. I think they're trying to create a perception with big customers that they are on the safe side if they make payments to Oracle. So Oracle is effectively creating an SKU for the kind of people who also buy their other overpriced enterprise stuff. Smart move on Oracle's part, at least in the short run.
It has the potential to kill Java in the longer run though.
Most people do indeed consider it slimy when "hackers" package up something that used to be open source and start selling it. And, hackers generally don't have the power to turn off the free and open source versions of the project, or start suing people, like Oracle does.
This isn't really an announcement, per se, but what I like about it is that it means they're going to continue working on JRockit (that they got from BEA's acquisition).
I've seen gains of over 100% using JRockit with Weblogic, which I also worried might fall by the wayside with Oracle's acquisition.
I'm still not 100% sure on which way Webcenter is headed, and what exactly it's based on (as I'm not in that particular business anymore) -- but hopefully it scrapped all the aging AquaLogic code that BEA was still peddling as 'cutting edge'.
I have no problem with them releasing a commercial JVM with extra bells and whistles and middleware - most people don't need that anyway, and the few who do are more than willing to pay.
But they had better not nerf OpenJDK relative to what it can do now.
Fortunately they can't do that. It's GPL'd, no take-backs. They could conceivably remove things from future releases, but I'd expect to see a community fork in that case.
I really wonder 5 years from now what will be the impact of all this. It seems that Oracle's strategy is to squeeze out every bit of penny from the assets acquired from Sun, which is fine I guess, but I think they are taking it too far.
I am starting not to trust Java,MySQL and all other products, they really give me the impression that these will all be commercial-only.
I think people are reading too much into this. Redhat has RHEL and Fedora, there is Jboss Community Edition, and JBoss Professional edition.
Nothing is nerfed, in fact the 'premium' offerings are usually behind the free versions in terms of features, but they do offer better management, upgrade options, etc.
JBoss has a long tradition of not leaving anything out of its free versions. To the contrary, as you noted, one usually does not get support for the more bleeding edge features under a support agreement (although one JBoss project group I know personally of has tended to provide that support in practice to paying customers).
I think the fear is that the "good stuff" for the JVM will only be available in paid form.
SpringSource now employs a pretty high percentage of the Tomcat committers and offers it's "TC server," a non-free version of Tomcat with a bunch of managability features on top. No one seems too upset about this. Perhaps because there are so many other servlet container choices out there?
> see how Sun's policies are being reversed in all public-facing fronts.
Like "making money"?
Kidding aside, I think you can mix free with proprietary in a way that's beneficial to the community without giving away too much. Google seems to do a lot of open source these days even though there is tons of stuff they keep to themselves. They seem to have a decent image for the work they do perform.
Sun had sort of a weird image, IMO - they were kind of heel-draggers in some ways, ahead of the curve in others. More than anything they just seemed confused. I don't think that, overall, they ever really figured out open source and what they should do with it.
Oracle's ideas about open source seem to be along the lines of "take what we can, give as little as possible back". We'll see though...
Not really. Remember Sun's stock during the dotcom boom.
Sun failed because of poor execution. They blew the cloud computing opportunity. Their sales people did not chase orders like the HP guys did (this is for a personal experience ). Their Java application server sucked when compared to Websphere and Weblogic. They could not deliver a good story with MySQL acquisition. They let Linux get ahead of Solaris , at least in mind share.
And get the free version of Oracle, as easily as you can get MySQL. You can't do that with DB2. Oracle has a public Yum server too: http://public-yum.oracle.com/
With Oracle, everything they do with Java seems to be slimy. Suing Google, JCP elections ( Hologic ?? ). premium for JVM . I fear this trend is to continue.
There are those who think that Oracle would continue to invest in Open JDK and continue to evolve it. I am sure they also believe that MySQl has an even brighter future ahead of it.
The unfortunate sideffect is that cool new languages like Scala and Clojure could end up as collateral damage as JVM is no longer seen as a viable and open platform.
I just might have to bite the bullet and learn me some Haskell after all !! Or GO programming language.