Hacker News Reader

Comment by badmash69 | Hacker News Reader

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.

View on HN

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.

That makes sense, but people really like to see a future before investing (money or sweat).

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.

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 about Generics is broken?

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.

1: http://en.wikipedia.org/wiki/Generics_in_Java#Type_erasure

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.

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.

As far as closures: you're missing out :)

Also tail call optimization changes the semantics of the language - it allows you to write code that would normally be incorrect

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.

It just won't run (for very long). :)

I agree, but compilation is a low barrier for correctness :)

Would it be that impossible to keep a counter of what iteration of function X the user is on? Or, does tail recursion also count things like:

int A() { return 1 + B(); }

int B() { return 1 + A(); }

(with necessary ending conditions)

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.)

That does become harder to follow, then.

And, woops...

Wait, generics support co/contra variance through the 'extends' and 'super' keywords. e.g. Collection<? extends Foo>

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 ...

The only thing that I would fix in Java Generics is the syntax, the use of angle brackets is what makes me reject the whole implementation.

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.

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.

Hey whatever happened to Parrot? You know the common VM for Perl and Python that was supposed to be the basis for Perl6?

Here's an old HN story about it. In fact, in the comments someone proposes porting Clojure to Parrot: http://news.ycombinator.com/item?id=552850

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.

Thanks for your reply!

1. I assume this is precise, not conservative GC?

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.

Sounds promising.

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.

Has anyone played around with LLVM's JVM Implementation? It supposedly runs Tomcat and Eclipse...

http://vmkit.llvm.org/

>...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.

I was going to say Bob Miner and Ed Oates but I've just checked and neither of them is a current Oracle employee.

Why is "suing Google" automatically slimy? They're a corporation like any other. In fact they're not unlike Oracle was at a similar age...

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.

Haskell is great! And there's OCaml and F# too...

Google would have nixed Hadoop if they were playing the same game. Instead they gave them a BigTable patent license.

There are many shades of evil, but theirs is far less dark than Oracle's.

So when Oracle monetizes it's products it's slimy, eh? What about when hackers do it for their apps?

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.

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."

Explain to me how the free version is crippled?

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.

Reply on news.ycombinator.com