Comment by stephen | Hacker News Reader

Comment by stephen | Hacker News Reader

I wonder how the $$ Google might pay to Oracle compares to the $$ it is spending to move away from Java by building replacements (v8, Go, Dart, Flutter/Fuschia, etc.) that are all essentially "GC languages with a great runtime VM".

E.g. I can understand Oracle/Sun needing some amount of money for stewarding Java, as the teams required to build/maintain/QA/release the JVM were AFAIU in the hundreds, so not cheap. But "Java is free", so they didn't have a way for covering that cost from the majority of enterprise developers who were getting a free lunch, and instead relied on the J2ME licensing almost by accident/happenstance IMO.

So now, companies like Google are not "paying for hundreds of Oracle/Sun engineers to develop a platform/language/ecosystem", but instead "paying hundreds of internal engineers to develop (multiple) platforms/languages/ecosystems".

Which they can do, and still provide v8/Go/Dart/etc. "for free" because they have the luxury of paying for everything with ads, which Oracle/Sun didn't, which forced Oracle/Sun to commit the sin of asking for money.

Granted, don't want to be an Oracle/Sun apologist b/c they messed up in a lot of ways (stagnated the language/etc., don't have a great reputation, etc.) and the competition/iteration of the next-gen languages like Kotlin/TypeScript/Go/etc. is working out great.

Just interesting to think of the economic trade-off, e.g. if Oracle had been a little less controlling, and Google a little more willing to pay licensing/something, if the net effect would have been Java today being in a demonstrably stronger market position than it is.

And, either way, the rest of us are still being spoiled by so many free lunches: amazing tech (languages/libraries/frameworks/ecosystems) built by professional teams that we don't pay a dime for.

V8 has little to do with Oracle, fundamentally. V8 came about because they wanted a higher performance JS VM for their browser; the JVM was never in contention there.

Sure it does. Why did they want a higher performance JS VM for the browser? The language of choice to build interactive applications on the web before JS was really viable was Java.

A high performance JS VM means we don't need to use applets anymore.

By the early years of Google applets were already pretty much dead:

https://www.javaworld.com/article/2076251/core-java/applets-...

(Note that the article is from 2000.)

Remember that Google was already doing AJAX in Gmail in 2004, years before V8.

And V8 was first released in 2008. Java applets were pretty much completely gone from the web by this point. The only competition on the web, from plugins, at that point was Flash (okay, Silverlight deserves a footnote, but little more).

V8 is ten years old?! How time flies...

I have the opposite response: only a decade old? Same with YouTube actually, I can't really remember what the Web was like without video streaming

There was streaming before. You installed Real Player so you couBuffering...

> The language of choice to build interactive applications on the web before JS was really viable was Java.

I find this amusing. No one ever built anything meaningful client-side with Java. There's a reason Microsoft laughed off Java as "write once, debug many".

Um Eclipse? Netbeans? ArgoUML? (just out of top of my head).

Your statement would be true if you have said "anything meaningful client-side on the web with Java". On the web Java was restricted to Java applets and was never really in competition with JavaScript.

Desktop is quite another story.

Agreed, my context was browser specific applets. Clearly Java has some moderate success on the desktop.

I do think Sun entertained Java superseding Javascript in the browser - it just didn't work out that way.

Java applets were huge, and still are quite big in enterprise.

Where? We're not talking servlets or EJBs here right? Adoption across combination of OS & browser was and continues to be an issue.

Both Microsoft and Apple made it difficult in different ways, and the "year of linux on the desktop" has yet to really come (no ChromeOS don't count)

"Adoption across combination of OS & browser"

Not a problem when everyone is using Windows and Netscape. It's as horrible as you'd think.

Not Flash? In my experience Java applets never got anywhere close to the level of adoption of Flash. I suppose it might've been different in corporate environments. I had Flash enabled in my browser long after I stopped using Java applets altogether, if only for video streaming.

Corporate environments were different (easy was to expose Java business program to user without hiring Web people), but the doom of Java in the browser was the whole applet concept and not the DOM integration that JavaScript had. It might have been quite a difference if the JVM could have controlled the webpage like JavaScript.

This is ignorant. The rise of Javascript had little to nothing to do with the fall of Java applets, which failed due to their own issues.

Java applets were already considered a dying tech when Google made their push to heavily-Javascript-dependent apps, and the performance requirements that led to.

Note also that despite the similar name, Javascript and Java have technically nothing to do with each other. It is a quirk of business history [1] that Netscape and Sun partnered to name Javascript as it is when Sun was first pushing Java as a web technology.

[1] https://en.wikipedia.org/wiki/JavaScript#Beginnings_at_Netsc...

The original use of JavaScript was to pass DOM information to the applet and back. https://docs.oracle.com/javase/tutorial/deployment/applet/in... and https://docs.oracle.com/javase/tutorial/deployment/applet/in... are the docs for this largely forgotten functionality.

There was no DOM back in the early days of Javascript. The page was rendered in a single pass, you could inject text and markup via document.write() and anything "dynamic" was accomplished by reloading an IFRAME. Remember, these were the days when too many tables would crash your browser; I recall the early demos of Gecko showing deeply nested tables, and all styling was with font tags still.

Netscape was still trying to sell a browser, and they wanted a common language on the frontend and backend, so Javascript was also on Netscape Server.

Maybe the 'DOM' wasn't the right word choice. However, in 1995 one could foo = document.getElementById and foo.innerHTML as described in https://docs.oracle.com/javase/tutorial/deployment/applet/in...

It was possible to call JavaScript from a Java applet and method in a Java applet from JavaScript (on a web page).

This functionality can be seen in Java 2 (now known as Java 1.2) - http://www.oracle.com/technetwork/java/basics-137133.html .

https://en.wikipedia.org/wiki/Netscape_(web_browser)#Release... has JavaScript and Java as part of the same release for Netscape. The next release of Netscape Navigator (3.0) had LiveConnect version 1 ( http://web.mit.edu/javascript/src/mozilla/js/src/liveconnect... ) which was that cross language communication.

I would be willing to contend that in the view of "Java applets are where the web is going" back then, the difficulty of communication between the applet and the enclosing page was something that needed some scripting glue and that JavaScript, from its inception, was to be that glue. It took about a year to get it working, but this was the initial goal of JavaScript.

> The language of choice to build interactive applications on the web before JS was really viable was Java.

Actually, Java was already mostly dead for the public web when Chrome and V8 were being developed, it was more Flash that was the competition.

Sorry, but for the web java applets were never viable and universally complete garbage.

In underlying code you are correct. But they both work in a C/C++ style. JavaScript has become a 'Write Once, Run Anywhere' foundation because of the web browser. Don't forget projects like NWJS (Node Webkit), Electron, Cordova/PhoneGap, Google Chrome Apps, NodeJS, and ClearScript(.NET).

All of these JavaScript implementations use the V8 JVM and can make desktop and command line application. Depending on security settings they can give partial to full system access to the underlying OS just like Java. If this ruling is upheld I would look for Oracle to float a trial balloon on newer JavaScript implementations and for stealing their Java's API's.

> All of these JavaScript implementations use the V8 JVM

V8 is not a JVM (Java Virtual Machine), but a virtual machine for Javascript.

V8 is not a JVM. It's a JS VM / ECMAScript VM. Java and JavaScript are not the same language. They are not even directly related languages.

Though it has little to do with the parent post's point, technical development of both V8 and HotSpot was led by Lars Bak.

V8 didn't come about because of the JVM, but it was done by the same guy who wrote the JVM.

Gah, I'm an idiot and replied to the top-level thread instead of here. See my "I agree it seems that way" comment down below.

> And, either way, the rest of us are still being spoiled by so many free lunches: amazing tech (languages/libraries/frameworks/ecosystems) built by professional teams that we don't pay a dime for.

Don't those things realistically exist precisely because of a virtuous, continual cycle in the greater tech community of paying that free lunch forward?

Even the strictly free lunch use cases, where someone doesn't contribute time/money/effort back into the system, involve helping to popularize the whole and keeping it going; broadening it, spreading it, bringing more contributors in. Those people end up as popularizers/evangelists, which is a required ingredient for the virtuous cycle to keep going.

In some cases that's probably true. But consider how few resources were devoted to Openssl before they ended up in the limelight.

Reply on news.ycombinator.com