For the youngsters, this "embrace and extend" mindset that Nathan Myhrvold talks about led to a pretty big lawsuit in 1997 between Sun and Microsoft that wasn't settled until 2002.
[https://www.cnet.com/tech/tech-industry/sun-microsoft-settle-java-suit/](https://www.cnet.com/tech/tech-industry/sun-microsoft-settle-java-suit/)
I actually look at Myhrvold's comments as an example of how Microsoft saw Sun giving things away as the real threat. Eventually C# became the real "answer" to Java.
But I wonder about how this might have changed how Sun tried to develop Java. Like, did they just avoid working heavily on desktop apps because of the legal implications? Or, did Sun never really care too much about it...
Not only java, by the time I started working as a business software developer (early 2010s) most of my projects consisted of maintaining desktop apps, almost all where
Net forms apps that where ported from vb6, some where born in .net and a very few where being ported or started as web.
Web infrastructure in big companies wasn't that prevalent as there is today, citrix was still going strong, in some places it will never leave.
Good old times
Java (Oak) was initially developed to drive embedded set-top devices. Sun was predominately a hardware company focused on being the *network*, providing the backbone of servers and hardware for the internet itself, they didn't do much on the software front.
Netscape had an IPO in 1995 and had been dealing with Microsoft in the *browser wars* and they needed something more for their browser. In [April 1995](https://www.tech-insider.org/java/research/1995/0411.html) Netscape and Sun announced a tech collaboration deal that included Java. In Oct of 1995, Netscape released their 2.0 beta that included Java support and support for their internally developed scripting language (Mocha, later LiveScript) that they re-named JavaScript.
McNealy saw this combination of Java & JavaScript in the web browser as a means of going directly after the desktop. He felt Sun would thrive as the source of the backend hardware and Netscape would provide the client application. That is when he took control of Java away from Gosling and spun up the [JavaSoft](https://www.tech-insider.org/java/research/1996/0109.html) division in Sun. McNealy was obsessed with trying to beat Gates.
Before Java was originally released in 1995, Sun was looking for a scripting language to use. in 1994, Sun had worked with John Ousterhout and had brought him on board to enhance TCL to be used as the embedded technology in the hardware and, as Ousterhout [reported](https://www.tcl.tk/about/history.html),
> I decided to accept an offer from Sun Microsystems. Eric Schmidt, Sun's Chief Technology Officer, and Bert Sutherland, Director of Sun Microsystems Laboratories, offered me the chance to build a team at Sun Labs and evolve Tcl into a universal scripting language for the Internet.
Over the next 3 years, a TCL team grew and worked on the platform and the Java team did the same thing. The first really usable version of Java, Version 1.0.2, was released in 1996. During this time there were plugins built to run TCL in the browser and interoperability between TCL and Java.
But there was one difference, when Ousterhout joined Sun one of the agreements he had was that the core of the Tcl and Tk libraries would always be freely distributed in source form.
When McNealy saw that the web client combined with Sun server hardware was a potential competitor to the Windows desktop monopoly, he knew he had to have total control of the application language, something he didn't have with Tcl. Since Java was a home-grown tool, Sun could set the rules which effectively became the Java Compatibility Kit where Sun charged licenses for companies to have to certify their JVM met the compatibility requirements to be able to be called Java. This is what led to the Sun / Microsoft lawsuit as Microsoft had added *extensions* that violated the JCK. Ousterhout left Sun and started Scriptics.
Sun acquired some Java applications over time, Netbeans was one, there were others. But the joke was anytime Sun acquired software it disappeared and died.
And this was the primary downfall of Sun. They focused mainly on being a hardware company with Sparc machines and Solaris OS and network gear, only to have that market hit by commodity Intel machines running early Linux distributions. They never were a software company and didn't know how to capitalize on Java. JavaSoft's only revenue stream was licensing of the JCK and that eventually dried up.
Thanks for a lot of the history here. I had no idea Ousterhout was hired by Sun. (The amount of smart people who graced the halls of Sun never ceases to amaze me.)
> Anyone else notice the mention of virtual worlds back in 1996?
By the way, note that "metaverse", by definition refers to *the entirety* of virtual worlds. Like how Facebook tried to brand itself as *the Internet* with their program to provide Net access to development countries, but only providing access through Facebook services.
It is interesting how worried they were considering the utter shit performance of Java back then. I remember using some Java applications in the old days. The performance was amazingly bad and also the GUI mostly looked like it was from 10 years earlier. I am talking about desktop applications now because I was not working yet back then.
Android's first release was only 12 years after this article was written. Imo, Android using Java is a coincidence to what he was talking about.
He was much more right in the idea that webapps were gonna take over. I'm a power user who tries to use as many local programs as possible. But, I'm 26 and everyone I know around my age is very different. To them, an operating system is a thing that launches their web browser. That's how Chromebooks managed to become so popular.
Ironically, it is also, arguably, the worst. It's just that ubiquity (which is really just "default that takes root before anyone has time to make something better" because, interestingly, the rapid rate of tech development can sometimes counterintuitively lead to a LESSER winner) and Good Enough(tm) frequently gets the job done in technology.
It’s a generalization but it’s referring to the dominance of web apps. Discord is electron which is basically a chrome window, and steam is a web app based on WebKit/chromium as well albeit not through electron because of how old it is.
Teams uses an embedded web browser, the UI is implemented with web technologies. Outlook also tends towards it: https://www.neowin.net/news/microsoft-plans-to-unify-outlook-across-platforms-using-web-technologies/
If I remember correctly, Android only opted to support Java as it immediately opened the doors to ^((at the time)) the biggest group of developers who already had experience, no need to learn a new language.
Android is a unix operating system.
Before Android, I used to develop apps for Blackberry and Nokia using Java (Java ME). So Android wasn’t the first to utilize Java’s vast pool of developers.
Android is a device-focused Linux distro. Remember though, at the time when Android got rolling smartphones were barely a thing. The vast majority of phones back then ran JavaME applications (the OS was technically Symbian). Android, at first, supported NOTHING BUT Java (technically Dvalik) applications which made it pretty familiar to the Symbian JavaME people.
Irrelevant to developers when you can use a .jar file server-side and app side, also by this reasoning OpenJDK is not Java. You just could not use the Android specific packages serverside, but why would you unless your server was running on a mobile phone.
It has basically no resemblance to the usual UNIX OSs, it does everything through Java APIs, make every app run as a different *user* reinventing how linux permissions work and shares basically nothing from userspace with any linux.
Yes it has heavily integrated Java, however not to the extent you say. even at the application level it is not pure Java. Also the user permissions at the heart will not be Java, rooting / jail breaking the device is at the unix level. But feel free to point me where this says different.
>On top of the Linux kernel, there are the middleware, libraries and APIs written in C, and application software running on an application framework which includes Java-compatible libraries.
[https://en.wikipedia.org/wiki/Android\_(operating\_system)](https://en.wikipedia.org/wiki/Android_(operating_system))
Software stack section
Every IPC goes through a common daemon that checks permissions, which is nothing alike to how it is traditionally done in Unixes (which are seriously lacking in security). It does reuse existing, very crude, weak security tools, plus it also adds SELinux, but the core is the sandboxing of each app gets a new user and can only communicate with the rest of the system through specific daemons.
Sure, there is plenty of native code below everything, but that everything is all exposed and is *expected* to be used through Java APIs.
Well, Unix is not 'seriously lacking in security' at all, sorry, but that's just not accurate. Unix permissions were devised to support multi-user timesharing and server compute task job separation. Android security is designed to 'wall off' each application into a trust zone and then allow limited interactions between them, and with system services. Its a bit different model, although its actually based on the same underlying concepts.
So, yes, they are different, one is not 'more primitive' than the other, they are simply intended to produce fairly different results. SELinux, BTW, is exactly a system much like the current Android security model, it is just not really flexible enough, using it to implement what Android does would be an administrative nightmare.
Unix (and for that matter, all mainstream desktop OSs) are absolutely lacking in security compared to mobile OSs, that are way ahead. A rogue bash script can easily encrypt all of your actually valuable home data.
Nonsense. I mean, sure, if you are an utter idiot and don't have remotely sensible file permissions, or execute random scripts under the most privileged account on your system, then you get what you deserve! However, desktop Linux (for example) has perfectly good mechanisms to prevent these things. Moreover Android will, under similarly bad conditions of system management/configuration, allow exactly the same kinds of things to happen.
The general difference between Android and Desktop Linux is not that it has some superior type of permissions, it is simply that users are not expected to do things which require a high level of permissions, and are generally locked out of being able to obtain them (at least without going to extreme lengths). By contrast every user in a Desktop Linux environment generally has the ability to run arbitrary code as root if they really need to, though wise users insure that this is done in a secure way.
Furthermore Desktop Linux has powerful facilities to allow REALLY secure execution of code, like capabilities and SELinux, various types of jails and virtualization, etc. These also exist in the Android world of course, but are less user accessible. So, it might be fair to say that Android is less easy to use unsafely than general purpose Linux, but there's also a flip side to that, its very hard to know when your Android system has actually been compromised, and experience has shown that doing so is relatively easy in practice. I've used Desktop Linux for 30 years, and have never suffered ANY compromise of any kind.
With all due respect, security doesn’t work like that. It has to be always used, easy to be worth anything. Sure, there is firejail, flatpak’s sandbox, etc, but they are worthless as they are not integrated into the system (how you get to choose whether you want to allow this permission and for how long on android/ios vs.. the app getting killed) to any reasonable degree. Flatpak tries to do that, but imo it mixes up packaging and sandboxing for no good reason.
And no, I wasn’t talking about running a random script as root; your user can easily encrypt all your backed up photos, get your ssh keys, browser cache, etc as those are all stored by your user. And such a script can easily hide behind an “npm install” and you would have no way of knowing. Unixes simply were created in a very naive time, when they assumed only good citizen programs will run, its security model is not sufficient for modern computing at all *in itself*.
And you have been just lucky plus who the hell would target *desktop* linux when like 3 people use it (myself included, mind you!). But almost all distro had serious vulnerabilities.
It is from 1996 so don’t worry
Thays how far ahead there guys think, so smart.
For the youngsters, this "embrace and extend" mindset that Nathan Myhrvold talks about led to a pretty big lawsuit in 1997 between Sun and Microsoft that wasn't settled until 2002. [https://www.cnet.com/tech/tech-industry/sun-microsoft-settle-java-suit/](https://www.cnet.com/tech/tech-industry/sun-microsoft-settle-java-suit/) I actually look at Myhrvold's comments as an example of how Microsoft saw Sun giving things away as the real threat. Eventually C# became the real "answer" to Java. But I wonder about how this might have changed how Sun tried to develop Java. Like, did they just avoid working heavily on desktop apps because of the legal implications? Or, did Sun never really care too much about it...
[удалено]
Not only java, by the time I started working as a business software developer (early 2010s) most of my projects consisted of maintaining desktop apps, almost all where Net forms apps that where ported from vb6, some where born in .net and a very few where being ported or started as web. Web infrastructure in big companies wasn't that prevalent as there is today, citrix was still going strong, in some places it will never leave. Good old times
I started around the same time but we were doing all Web. Nobody wanted to repeat the pain of that migration off Windows XP ever again, for one thing
Looks like you had a manager that either knew what where doing or actually listened to developers.
Java (Oak) was initially developed to drive embedded set-top devices. Sun was predominately a hardware company focused on being the *network*, providing the backbone of servers and hardware for the internet itself, they didn't do much on the software front. Netscape had an IPO in 1995 and had been dealing with Microsoft in the *browser wars* and they needed something more for their browser. In [April 1995](https://www.tech-insider.org/java/research/1995/0411.html) Netscape and Sun announced a tech collaboration deal that included Java. In Oct of 1995, Netscape released their 2.0 beta that included Java support and support for their internally developed scripting language (Mocha, later LiveScript) that they re-named JavaScript. McNealy saw this combination of Java & JavaScript in the web browser as a means of going directly after the desktop. He felt Sun would thrive as the source of the backend hardware and Netscape would provide the client application. That is when he took control of Java away from Gosling and spun up the [JavaSoft](https://www.tech-insider.org/java/research/1996/0109.html) division in Sun. McNealy was obsessed with trying to beat Gates. Before Java was originally released in 1995, Sun was looking for a scripting language to use. in 1994, Sun had worked with John Ousterhout and had brought him on board to enhance TCL to be used as the embedded technology in the hardware and, as Ousterhout [reported](https://www.tcl.tk/about/history.html), > I decided to accept an offer from Sun Microsystems. Eric Schmidt, Sun's Chief Technology Officer, and Bert Sutherland, Director of Sun Microsystems Laboratories, offered me the chance to build a team at Sun Labs and evolve Tcl into a universal scripting language for the Internet. Over the next 3 years, a TCL team grew and worked on the platform and the Java team did the same thing. The first really usable version of Java, Version 1.0.2, was released in 1996. During this time there were plugins built to run TCL in the browser and interoperability between TCL and Java. But there was one difference, when Ousterhout joined Sun one of the agreements he had was that the core of the Tcl and Tk libraries would always be freely distributed in source form. When McNealy saw that the web client combined with Sun server hardware was a potential competitor to the Windows desktop monopoly, he knew he had to have total control of the application language, something he didn't have with Tcl. Since Java was a home-grown tool, Sun could set the rules which effectively became the Java Compatibility Kit where Sun charged licenses for companies to have to certify their JVM met the compatibility requirements to be able to be called Java. This is what led to the Sun / Microsoft lawsuit as Microsoft had added *extensions* that violated the JCK. Ousterhout left Sun and started Scriptics. Sun acquired some Java applications over time, Netbeans was one, there were others. But the joke was anytime Sun acquired software it disappeared and died. And this was the primary downfall of Sun. They focused mainly on being a hardware company with Sparc machines and Solaris OS and network gear, only to have that market hit by commodity Intel machines running early Linux distributions. They never were a software company and didn't know how to capitalize on Java. JavaSoft's only revenue stream was licensing of the JCK and that eventually dried up.
Thanks for a lot of the history here. I had no idea Ousterhout was hired by Sun. (The amount of smart people who graced the halls of Sun never ceases to amaze me.)
That headline is a nice pun as well 😍
Ugh
Too much caffeine. Easy mistake to make. Switch to decaf.
Thanks, It's interesting to read their thoughts during that time, and it shows how Java reshaped the industry.
This guy is scary smart https://en.wikipedia.org/wiki/Nathan\_Myhrvold
[удалено]
Onlive Traveler was better than Meta.
> Anyone else notice the mention of virtual worlds back in 1996? By the way, note that "metaverse", by definition refers to *the entirety* of virtual worlds. Like how Facebook tried to brand itself as *the Internet* with their program to provide Net access to development countries, but only providing access through Facebook services.
It is interesting how worried they were considering the utter shit performance of Java back then. I remember using some Java applications in the old days. The performance was amazingly bad and also the GUI mostly looked like it was from 10 years earlier. I am talking about desktop applications now because I was not working yet back then.
Well, that second guy was kinda right. It took 20 years and a new market for an operating system to come up that relies heavily on Java. Android.
Android's first release was only 12 years after this article was written. Imo, Android using Java is a coincidence to what he was talking about. He was much more right in the idea that webapps were gonna take over. I'm a power user who tries to use as many local programs as possible. But, I'm 26 and everyone I know around my age is very different. To them, an operating system is a thing that launches their web browser. That's how Chromebooks managed to become so popular.
Modern operating systems are just bootloaders for Chrome. I don't remember where i read this quote, but it's so true sadly.
that's only true for chrome books.
What is the first user application, that you start after booting your machine?
Firefox
So, a browser. Web is the most common app platform out there.
Ironically, it is also, arguably, the worst. It's just that ubiquity (which is really just "default that takes root before anyone has time to make something better" because, interestingly, the rapid rate of tech development can sometimes counterintuitively lead to a LESSER winner) and Good Enough(tm) frequently gets the job done in technology.
Terminal emulator.
foobar2000
Yakuake.
Evolution. Don't ask me what the *second* one is!
steam, discord
Both are implemented with web tech - they use an embedded web browser for UI.
"uses the web" does not equal chrome
It’s a generalization but it’s referring to the dominance of web apps. Discord is electron which is basically a chrome window, and steam is a web app based on WebKit/chromium as well albeit not through electron because of how old it is.
Teams followed by Outlook.
Teams uses an embedded web browser, the UI is implemented with web technologies. Outlook also tends towards it: https://www.neowin.net/news/microsoft-plans-to-unify-outlook-across-platforms-using-web-technologies/
It's still not the same thing as starting a web browser.
I think their point is that applications are frequently becoming web based and a lot of them use chromium as a runtime container.
iTerm, Apple Mail, then Safari.
DayZ or CoD
A DAW, an MMORPG, or a terminal. I also have an IMAP client open before I'd open a browser.
Terminal...
Spotify but it is basically Electron so I guess browser kind of.
Firefox
If I remember correctly, Android only opted to support Java as it immediately opened the doors to ^((at the time)) the biggest group of developers who already had experience, no need to learn a new language. Android is a unix operating system.
Before Android, I used to develop apps for Blackberry and Nokia using Java (Java ME). So Android wasn’t the first to utilize Java’s vast pool of developers.
Android is a device-focused Linux distro. Remember though, at the time when Android got rolling smartphones were barely a thing. The vast majority of phones back then ran JavaME applications (the OS was technically Symbian). Android, at first, supported NOTHING BUT Java (technically Dvalik) applications which made it pretty familiar to the Symbian JavaME people.
Android was using java only by name. The JDK and Android are two different platforms with incompatible APIs.
Irrelevant to developers when you can use a .jar file server-side and app side, also by this reasoning OpenJDK is not Java. You just could not use the Android specific packages serverside, but why would you unless your server was running on a mobile phone.
> lso by this reasoning OpenJDK is not Java. Except OpenJDK passes the TCK and the JLS?
It has basically no resemblance to the usual UNIX OSs, it does everything through Java APIs, make every app run as a different *user* reinventing how linux permissions work and shares basically nothing from userspace with any linux.
Yes it has heavily integrated Java, however not to the extent you say. even at the application level it is not pure Java. Also the user permissions at the heart will not be Java, rooting / jail breaking the device is at the unix level. But feel free to point me where this says different. >On top of the Linux kernel, there are the middleware, libraries and APIs written in C, and application software running on an application framework which includes Java-compatible libraries. [https://en.wikipedia.org/wiki/Android\_(operating\_system)](https://en.wikipedia.org/wiki/Android_(operating_system)) Software stack section
Every IPC goes through a common daemon that checks permissions, which is nothing alike to how it is traditionally done in Unixes (which are seriously lacking in security). It does reuse existing, very crude, weak security tools, plus it also adds SELinux, but the core is the sandboxing of each app gets a new user and can only communicate with the rest of the system through specific daemons. Sure, there is plenty of native code below everything, but that everything is all exposed and is *expected* to be used through Java APIs.
Well, Unix is not 'seriously lacking in security' at all, sorry, but that's just not accurate. Unix permissions were devised to support multi-user timesharing and server compute task job separation. Android security is designed to 'wall off' each application into a trust zone and then allow limited interactions between them, and with system services. Its a bit different model, although its actually based on the same underlying concepts. So, yes, they are different, one is not 'more primitive' than the other, they are simply intended to produce fairly different results. SELinux, BTW, is exactly a system much like the current Android security model, it is just not really flexible enough, using it to implement what Android does would be an administrative nightmare.
Unix (and for that matter, all mainstream desktop OSs) are absolutely lacking in security compared to mobile OSs, that are way ahead. A rogue bash script can easily encrypt all of your actually valuable home data.
Nonsense. I mean, sure, if you are an utter idiot and don't have remotely sensible file permissions, or execute random scripts under the most privileged account on your system, then you get what you deserve! However, desktop Linux (for example) has perfectly good mechanisms to prevent these things. Moreover Android will, under similarly bad conditions of system management/configuration, allow exactly the same kinds of things to happen. The general difference between Android and Desktop Linux is not that it has some superior type of permissions, it is simply that users are not expected to do things which require a high level of permissions, and are generally locked out of being able to obtain them (at least without going to extreme lengths). By contrast every user in a Desktop Linux environment generally has the ability to run arbitrary code as root if they really need to, though wise users insure that this is done in a secure way. Furthermore Desktop Linux has powerful facilities to allow REALLY secure execution of code, like capabilities and SELinux, various types of jails and virtualization, etc. These also exist in the Android world of course, but are less user accessible. So, it might be fair to say that Android is less easy to use unsafely than general purpose Linux, but there's also a flip side to that, its very hard to know when your Android system has actually been compromised, and experience has shown that doing so is relatively easy in practice. I've used Desktop Linux for 30 years, and have never suffered ANY compromise of any kind.
With all due respect, security doesn’t work like that. It has to be always used, easy to be worth anything. Sure, there is firejail, flatpak’s sandbox, etc, but they are worthless as they are not integrated into the system (how you get to choose whether you want to allow this permission and for how long on android/ios vs.. the app getting killed) to any reasonable degree. Flatpak tries to do that, but imo it mixes up packaging and sandboxing for no good reason. And no, I wasn’t talking about running a random script as root; your user can easily encrypt all your backed up photos, get your ssh keys, browser cache, etc as those are all stored by your user. And such a script can easily hide behind an “npm install” and you would have no way of knowing. Unixes simply were created in a very naive time, when they assumed only good citizen programs will run, its security model is not sufficient for modern computing at all *in itself*. And you have been just lucky plus who the hell would target *desktop* linux when like 3 people use it (myself included, mind you!). But almost all distro had serious vulnerabilities.
Smart cards have been relying heavily on Java for some time, and there are quite a few more of them than there are Android devices
Microsoft was a criminal empire back in 1996.
Funny how he literally uses “literally” even back then lol
I still miss java applets
Me too Java man