Sun's Phipps Slams App Engine's Java Support

narramissic writes "Sun Microsystems' chief open source officer, Simon Phipps, said in an April 11 blog post that Google committed a major transgression by only including support for a subset of Java classes in its App Engine development platform. 'Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade,' Phipps wrote. 'That includes being sure as a developer that all core classes are present on all platforms. Creating subsets of the core classes in the Java platform was forbidden for a really good reason, and it's wanton and irresponsible to casually flaunt the rules.' Phipps characterized his remarks as non-official, saying: 'This isn't something I could comment on on Sun's behalf. My personal comments come purely from my long association with Java topics.'"

Pot. Kettle. Black.

[TheRealMindChild (743925)]

'Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade,' Phipps wrote. 'That includes being sure as a developer that all core classes are present on all platforms. Creating subsets of the core classes in the Java platform was forbidden for a really good reason, and it's wanton and irresponsible to casually flaunt the rules.'

You mean like Java ME [wikipedia.org]?

Re:Pot. Kettle. Black.

[DragonWriter (970822)]

The real problem is that Google created their own version of Java ME. Instead of sticking with the existing standard, they came up with their own.

Since AppEngine, Google's cloud platform is (while, like mobile devices, a different environment from the standard desktop or server environment for which the Java Standard Library is designed) not a mobile platform, and doesn't have the same constraints that shape the development of Java ME, it's not surprising that they did something different.

OTOH, the justification is the same for having Java ME when Java SE already exists: the environment in which AppEngine Java is being used is very different from that for which SE was conceived, putting unique constraints on it.

I think that Phipps is upset because Sun is in the process of gearing up their own cloud services, and the last thing they want is Google's Java support drawing enterprise interest to AppEngine while they try to get Sun's cloud service off the ground.

Re:Pot. Kettle. Black.

[sohp (22984)]

What Google should have done was engage in the JCP to define a new profile for supported "device", along the lines of the CDC/CLDC and MIDP. At least that way it would have been within the framework of practice understood and used by Java developers. Instead, Google just said "here's what's available", without tying into any of the already available accepted ways of defining a subset of Java.

This actually looks a lot like what Microsoft got in trouble for with their MS Java.

Re:Pot. Kettle. Black.

[DragonWriter (970822)]

What Google should have done was engage in the JCP to define a new profile for supported "device", along the lines of the CDC/CLDC and MIDP. At least that way it would have been within the framework of practice understood and used by Java developers.

I really don't think that Java developers have much trouble understanding or using a clearly defined subset of existing functionality.

This actually looks a lot like what Microsoft got in trouble for with their MS Java.

What Microsoft did was create an incompatible implementation of core Java classes, supporting similar features but requiring different behavior with the same classes. This has much more serious negative impact than implementing a well-defined subset, since the former makes it hard to move code either way between implementations, and the latter (what Google is doing) makes it very easy to move code off the non-standard implementation (AppEngine) and onto a standard implementation, but somewhat challenging to move code using the unsupported features from the standard implementation onto the non-standard one.

It's actually a really bad thing to do if you want to create lock-in to your non-standard implementation, since it does nothing to keep people from moving off your platform, but makes it harder than supporting the standard would for them to move on to your platform.

Re:

[jrumney (197329)]

Microsoft didn't actually leave anything out of the APIs for their version of Java, they just made sure that their implementation of AWT sucked even more than Sun's and provided their own proprietary UI API which they promoted heavily. When Sun introduced Swing, a UI framework that sucked a bit less, in Java 2, MS stuck with Java 1.1 and promoting their own framework. If Microsoft had played along, Windows users at least might have had a version of Swing that didn't suck back in Java 1.3 days instead of hav

Re:Pot. Kettle. Black.

[ChunderDownunder (709234)]

Microsoft didn't actually leave anything out of the APIs for their version of Java

Yes they did; Sun took them to court. Specifically, they left out JNI and RMI in favour of their own COM object APIs.

Proof? Microsoft's own document [microsoft.com] reveals this.

Re:

[MrEricSir (398214)]

Free or not, at some point you MUST have a standard, or you will not have interoperability. What Google is doing here is no different than what Microsoft has done for years.

Now I'm not saying Java ME is good. In fact, it's awful. But an awful standard is still better than none.

Re:Pot. Kettle. Black.

[Chyeld (713439)]

No. Point blank, no.

Go to the end of the line.

Microsoft goes out and deliberately tries to subvert standards by creating implementations that are slightly off, thus preventing anything written for them from being easily portable to another implementation.

Google has gone and created an implementation that works exactly according to spec, except leaving out items which don't make sense in the app model they use. It would be extremely trivial to port something written for Google's implementation to anything else standard compliant.

This is about as similar to Microsoft as a blizzard in the Alps is to a sunny day in Cuba.

"Flout", not "flaunt"

[beanyk (230597)]

Grr.

"Wonton", not "wanton"

[FrankDrebin (238464)]

Mmm.

I think Sun is jealous

[seifried (12921)]

I think Sun is jealous, they have been pushing grid computing for ages and it's been a flop for them. Google is most likely going succeed here, especially with a "good enough" solution which no doubt pisses of Sun/Sun employees (who have a tendency to go for the engineering "ideal" solution which often results in a very nice and extremely pricey product). Witness the container computing stuff, Sun is making a big deal about seismic tests, and Google is quietly deploying hundreds of these things in their data centers. Sun seismic test [youtube.com] vs. Google data center tour [youtube.com]. I bet for most of us Google's Java AppEngine implementation will be "good enough".

Re:

[betterunixthanunix (980855)]

I hate it when people make snide comments about high quality engineering. Yes, it is possible to hack together a "good enough" system that is fine for consumers and some businesses, but for a lot of applications, a well engineered system is important. In the case of the containers, there are plenty of reasons why you might want to know the seismic test results: maybe you are deploying the container to replace some emergency services IT infrastructure in an earthquake zone, and need to be ready for afters

Mountain out of Molehill

[AKAImBatman (238306)]

As someone who personally loves the Java platform, I honestly think he's making a mountain out of a molehill. As far as I've been able to tell so far, the Google App Engine supports the Java platform in its entirety, with a few caveats. Those caveats deal with the services Google offers (e.g. no JDBC accessible database) and the sandbox the apps run in (e.g. no network support, no filesystem).

AFAICT, there's nothing stopping me from, say, writing a JDBC access layer for their Data Store. Which means that Google is keeping with the spirit of the platform, and that this is mostly just a misunderstanding.

If you want real problems, try running Java apps on a shared hosting provider sometime. The limitations of those sites will have you shouting praise for what Google is offering.

Re:Mountain out of Molehill

[kaffiene (38781)]

Um... no. They're not supporting Threads for a start - which is pretty major. I had a read of the exclusions a while back and there were some significant omisions. I'd list them if I could find the page again, but no luck I'm afraid.

That said, I'm not sure if I see this as a major issue either.

Re:

[AKAImBatman (238306)]

They're not supporting Threads for a start

That would be their locked-down sandbox. You can accomplish the same thing in vanilla Java with a security manager. (Which for all we know, they did. I haven't tried yet.) If the security manager doesn't allow it, you're not using it. Period, end of story.

You may note that everything Google has locked down is either controlled by the security manager or is simply an API to access a service that they don't provide.

which is pretty major

Generally speaking, it's a good

Re:Mountain out of Molehill

[khchung (462899)]

Following /. tradition, I have not looked at the details, but that won't stop me from commenting here... :)

As someone who has been writing Java since '99, I have to say if even Threads is not supported, it is a big issue.

There is a reason why the Core class are called "Core", every Java library expects the Core classes are there. If we now have a popular Java platform that only have a subset of the Core classes, it will cause a lot of headaches down the road, eventually fragmenting the "Java" platform.

What about changing Java's license?

[bogaboga (793279)]

I realize it's now too late but if it were a few years ago, SUN should have considered changing Java's license to make sure that whoever supports Java, supports it in its entirety.

Re:

[burris (122191)]

Google isn't calling their product Java. Google's product is called AppEngine. Google is free to say that AppEngine has "Java(TM) Language Support" without getting permission from Sun or anyone else.

Trademark isn't an absolute monopoly on the mark.

Like J2ME/CLDC?

[Anonymous Coward]

CLDC, the bastardized, stripped version of Java the Sun blessed and which is still the standard on many phones broke the whole "run anywhere" paradigm.

Still causes us major problems since Sun still supports and condones it despite the fact that almost all systems now could easily support a real Java version.

Re:

[CarpetShark (865376)]

Exactly. I can't help thinking that Java might have been a lot more pervasive and standardised by now (not to mention that the CLR probably wouldn't exist) if Sun had been more open with Java licensing years ago.

Re:

[israfil_kamana (262477)]

Heh. I had to write an IoC container that would run on CLDC 1.1. Fun fun fun. No Serializable meant I had to re-compile all my code. Love that fragile base-class problem.

Flout not Flaunt

[onkelonkel (560274)]

The word is flout not flaunt. English is harder than it looks.

Java compatibility has served us all very well for

[Gutboy (587531)]

COBOL compatibility has served us all very well for over a decade, and to develop new programming languages is wanton and irresponsible.

why didn't they complain about GWT?

[pohl (872)]

Hmm...I wonder why they never complained about the limited subset of classes that GWT supports [google.com] in client-side code.

Not a full java environment anyway.

[nietsch (112711)]

As far as I have learnt from a few cursory glances at appengine, it does not offer a complete OS environment. It is severely sandboxed, probably as a measure of security. All classes that deal with those non-existing features can either be non-existing, or exception-generating stubs. Google choose for those classes to be non-existent. That is something different than creating this-environment-only classes and functions, like MS did with their corrupted java. But there are prominent links on the appengine homepage to submit your own featers and bugfixes, so maybe all these complainers can contribute patches instead of contributing whine?

Everything you need is there

[owlstead (636356)]

OK, no Swing, no Corba etc. But I cannot see what part is missing for cloud computing (or any other algorithm. The collections classes (even the thread safe ones), all cryptographic stuff etc. The only thing that really seems to be missing is graphics (images). But for most cloud computing needs, this should be sufficient.

Anything else you may be able to import using the classes from the open source JDK anyway. As long as you don't create files etc. of course, thanks to the sandbox. And we're not talking about a release of another JDK or anything like that, in that case it would be a problem not to include the default functionality.

This seems to be a bit of a cheap shot. He should well know that you cannot display any personal opinions that are directly in his line of work, and then claim that they are not the opinions of his employer. Not in his position.

HOWTO: Using a SUBSET to create LOCK-IN!!!

[onitzuka (1303967)]

1. Remove APIs for Threads, File Access, ThreadGroups, or whatever you feel you want removed (eg. java.io.*, java.lang.*, java.util.*, etc...)
2. Replace those features with APIs that offer features only available on the Google's application server. (eg. google.io.*, google.threads.*, google.db.*, google.util.*, etc...)
3. Have developers write their code for your Google application server.
4. Snicker knowingly because you know that Java Servlet/JSP developers can and do use Threads and file systems and network access in their applications. In fact PHP developers use file systems all the time along with network access. Why do you snicker? Because you know they cannot simply copy their applications to Google App Engine without reimplementing it and creating a version JUST for Google App Engine. As the implementations are different and we know that developers time costs money($$$), managers will eventually have to decided whether to continue to support the open Servlets/JSP implementation (which could be ported to Tomcat, Resin, JBoss, or any others) or if they will just go with the Google App Engine version.
5. Laugh when they cannot port their applications out WITHOUT reimplementing all of the private APIs.
6. Profit

Re:do their own then...

[knewter (62953)]

bahahahaha. Sun? Money?

You've not been here long, eh? :)

Re:

[wawannem (591061)]

You're right... I guess I didn't really think about where the money would come from. But, if anyone has any really expensive hardware sitting around that isn't flying off the shelf the way it used to, I would think it would be Sun. So, maybe they could put some of it to use building a cloud of their own. I've just always been of the school of thought that if you don't like how something is built, build your own.

Re:do their own then...

[tomhudson (43916)]

Seems to me they should put their money where their mouth is...

Sun *DID* put their money where their mouth is. They developed java, then GPL'd it. They bought StarOffice, the GPL'd it.

Google, on the other hand, is an advertising company that is trying to get lock-in, same as Microsoft did with their proprietary java extensions long long ago ...

Re:do their own then...

[fuzzyfuzzyfungus (1223518)]

While I agree that google is not Mr. Friendly, I'd be surprised if this particular move is about lock-in. Not because of any belief in google's virtue; but for basic technical reasons.

If you want lock-in, you create a superset of the competitor's platform, or a variant of the platform that behaves differently, then push people to use your proprietary features. Implementing a subset of the competitor's platform just raises the cost of porting to your implementation, and creates no barrier to moving from your implementation to others' implementations.

The java-subset thing seems like a bad idea; and I'd be curious to know why they did it; but I don't see how a platform subset is a good basis for a lock-in strategy.

Re:do their own then...

[Chyeld (713439)]

http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox [google.com]

The Sandbox
To allow App Engine to distribute requests for applications across multiple web servers, and to prevent one application from interfering with another, the application runs in a restricted "sandbox" environment. In this environment, the application can execute code, store and query data in the App Engine datastore, use the App Engine mail, URL fetch and users services, and examine the user's web request and prepare the response.

An App Engine application cannot:

• write to the filesystem. Applications must use the App Engine datastore for storing persistent data. Reading from the filesystem is allowed, and all application files uploaded with the application are available.
• open a socket or access another host directly. An application can use the App Engine URL fetch service to make HTTP and HTTPS requests to other hosts on ports 80 and 443, respectively.
• spawn a sub-process or thread. A web request to an application must be handled in a single process within a few seconds. Processes that take a very long time to respond are terminated to avoid overloading the web server.
• make other kinds of system calls.

Threads
A Java application cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread. These restrictions also apply to JRE classes that make use of threads. For example, an application cannot create a new java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer. An application can perform operations against the current thread, such as Thread.currentThread().dumpStack().

The Filesystem
A Java application cannot use any classes used to write to the filesystem, such as java.io.FileWriter. An application can read its own files from the filesystem using classes such as java.io.FileReader. An application can also access its own files as "resources", such as with Class.getResource() or ServletContext.getResource().

Only files that are considered "resource files" are accessible to the application via the filesystem. By default, all files in the WAR are "resource files." You can exclude files from this set using the appengine-web.xml file.

java.lang.System
Features of the java.lang.System class that do not apply to App Engine are disabled.

The following System methods do nothing in App Engine: exit(), gc(), runFinalization(), runFinalizersOnExit()

The following System methods return null: inheritedChannel(), console()

An app cannot provide or directly invoke any native JNI code. The following System methods raise a java.lang.SecurityException: load(), loadLibrary(), setSecurityManager()

Reflection
An application is allowed full, unrestricted, reflective access to its own classes. It may query any private members, use java.lang.reflect.AccessibleObject.setAccessible(), and read/set private members.

An application can also also reflect on JRE and API classes, such as java.lang.String and javax.servlet.http.HttpServletRequest. However, it can only access public members of these classes, not protected or private.

An application cannot reflect against any other classes not belonging to itself, and it can not use the setAccessible() method to circumvent these restrictions.

Custom Class Loading
Custom class loading is fully supported under App Engine. Please be aware, though, that App Engine overrides all ClassLoaders to assign the same permissions to all classes loaded by your application. If you perform custom class loading, be cautious when loading untrusted third-party code.

So I would say the reasons behind their decision would boil down to "cutting out the stuff that isn't compatible with the model the App Engine uses to run things".

Re:do their own then...

[lamber45 (658956)]

Those restrictions are very siliar to the ones imposed upon Enterprise Java Beans. Quoting from the Sun documentation [sun.com]:

Specifically, enterprise beans should not:

• use the java.lang.reflect Java Reflection API to access information unavailable by way of the security rules of the Java runtime environment
• read or write nonfinal static fields
• use this to refer to the instance in a method parameter or result
• access packages (and classes) that are otherwise made unavailable by the rules of Java programming language
• define a class in a package
• use the java.awt package to create a user interface
• create or modify class loaders and security managers
• redirect input, output, and error streams
• obtain security policy information for a code source
• access or modify the security configuration objects
• create or manage threads
• use thread synchronization primitives to synchronize access with other enterprise bean instances
• stop the Java virtual machine
• load a native library
• listen on, accept connections on, or multicast from a network socket
• change socket factories in java.net.Socket or java.net.ServerSocket, or change the stream handler factory of java.net.URL.
• directly read or write a file descriptor
• create, modify, or delete files in the filesystem
• use the subclass and object substitution features of the Java serialization protocol

Re:

[Chyeld (713439)]

If you are developing for the App Engine, does it matter the flavor of the error? If you aren't developing for the App Engine and you are just looking to port something you've already written over, shouldn't you be reading the documentation concerning it first?

Developer-wise, this should be a non-issue. Unless you were expecting things to just plug in directly, coding to match how the App Engine works was a given anyway.

I agree with the others who opine that this is simply sour grapes from someone too late

Re:do their own then...

[goofy183 (451746)]

Well sure, If you're re-using a standard library it may have handling for the security exception chain and either fail gracefully or work with limited functionality.

If a JDK class is missing and the library class you want to use references it the code won't even run with an UnsatisfiedLinkError. That is a HUGE difference.

Another case where the library class references a missing JDK class but the use of the library class you're using never touches the forbidden code. In that case you again get a UnsatisfiedLinkError. If the use of the JDK class was just restricted by a security policy you only get the security exception if you actually call the API, a much better alternative.

Re:do their own then...

[goofy183 (451746)]

Except you're not going to get compile time errors from the third party library you're using since it is already compiled, you're still stuck with the ugly runtime UnsatisfiedLinkErrors. The JDK has features to support what Google wants to do built in specifically for this case and they really aren't very complicated to use.

Re:do their own then...

[Thinboy00 (1190815)]

The Right Way:

1. Developer tries to port code
2. javac (compiler) throws security exceptions
3. Dev:"I'd better read the docs on this."
4. Program will now DTRT WRT using the right classes

Google's way:

1. Developer tries to port code
2. javac throws classNotFound exceptions
3. Dev:"WTF! java.lang.System is integral!"
4. Dev is VERY confused since java.lang.System is essential for a basic hello world.

Re:do their own then...

[Fastolfe (1470)]

Google's way:

1. Developer tries to port code
2. javac throws classNotFound exceptions
3. Dev:"WTF! java.lang.System is integral!"
4. Dev is VERY confused since java.lang.System is essential for a basic hello world.

Citation needed, please. Here's what Google's documentation about java.lang.System [google.com] says:

Features of the java.lang.System class that do not apply to App Engine are disabled.

The following System methods do nothing in App Engine: exit(), gc(), runFinalization(), runFinalizersOnExit()

The following System methods return null: inheritedChannel(), console()

An app cannot provide or directly invoke any native JNI code. The following System methods raise a java.lang.SecurityException: load(), loadLibrary(), setSecurityManager()

What about this is unreasonable? Where does it say that apps will get ClassNotFoundExceptions? Please stop spreading unsubstantiated FUD.

Re:do their own then...

[fractoid (1076465)]

It sounds like Google actually did it The Right Way, rather than just excising whole classes.

I like that better than The Sun Way:

1. Implement a nice interface
2. Re-implement it with slightly different naming conventions
3. Deprecate the original, perfectly functional interface
4. Deprecate the re-implementation as well for good measure, and add a totally new package that does the same job
5. Repeat as unnecessary until apps aren't portable between different point releases of the JVM let alone different goddamn operating systems.

Re:do their own then...

[Thinboy00 (1190815)]

It's not the restrictions, it's the implementation. Normally, existing Java code could just be compiled on the embedded system, and compiler errors would specifically identify security reasons for specific classes/methods/etc being disabled. Google removed the classes entirely, so the developer will just get IDontKnowWTFThatClassIs exceptions instead, which are less informative.

It also contravenes existing standards, sort of like making "dangerous" files invisible to unprivileged users in *NIX (via some sort of arcane black magic, perhaps a modified (munged) shell or something...) instead of just setting appropriate file permissions.

Re:do their own then...

[IamTheRealMike (537420)]

The java-subset thing seems like a bad idea; and I'd be curious to know why they did it; but I don't see how a platform subset is a good basis for a lock-in strategy.

Yeah, this is garbage. Watch the "campfire" videos, a boringly large part of the presentations is given over to how you are not locked in, because AppEngine exposes the standard Java servlet container and database access APIs even though it's based on BigTable which is not a standard database. They show how the guestbook app can be taken right across to run on WebSphere with no code changes. The design of Java on AppEngine is pretty much the opposite of lockin - they've clearly put a lot of effort into ensuring a very, very different underlying system can export the standard Java APIs.

As to why it's a subset, I guess the same logic as applied to the Python implementation which is also a subset - due to the way it works the classes need to be audited for security problems. Some of the Java APIs contain native code which probably has to be rewritten or at least very carefully audited to ensure you can't break out of the sandbox. And some I guess just aren't that useful. But I don't really know the reason.

Re:do their own then...

[fm6 (162816)]

While I agree that google is not Mr. Friendly, I'd be surprised if this particular move is about lock-in.

It never is. Whenever somebody modifies standard technology to suit themselves, they get accused of trying to create lockin. That's what happened when Phil Katz [wikipedia.org] decided he could redo the ARC format faster and smaller. That's what happened when Anders Hejlsberg [wikipedia.org] decided he couldn't live with Java's limitations [zdnet.com]. Netscape and HTML. Microsoft and HTML, CP/M, x86....

Lockin does usually occur when people do things in a different way, and the different way ends up being the de facto standard. But that's not why they do them. They do them because developers just plain like to do things their own way.

In the case of Google's "white list" this doesn't even come close to being lockin, because any application that will run on Google's classes will run on "standard Java". Sun's problem is that the reverse isn't true. And I'm not sure that really matters. Unless I've missed something, the missing classes are all legacy cruft that should have been deleted from Java long ago.

So why haven't they been? Lack of will. One Java core engineer told me that Sun got in trouble when they even deprecated an API, never mind removing a whole class. People just don't want to fix up all their legacy code, and Sun was too anxious to monetize Java to stand up to them.

Google has more flexibility, since they don't need for their version of the Java platform to make money anytime soon.

Re:

[DragonWriter (970822)]

Sun's problem is that the reverse isn't true.

Sun's problem is that they are working up to the general launch of their cloud computing services, and Google AppEngine supporting more than just Python makes it that much harder for any new launch to get traction.

Re:

[Chyeld (713439)]

Subtle yet important difference to me, Microsoft released something that did include the 'full set' plus some but didn't work the same as the specs said it should.

Google simply didn't release a full set.

And where Microsoft pulled their stunt to kill Java, I imagine Google did it for technical reasons (i.e. trying to lock down the sandbox) since they have said they want to add more classes to the list of allowed ones.

Re:do their own then...

[DragonWriter (970822)]

IrI'm fine with the GOOG not offering Java support, but what's the justification for only offering half-assed support?

The justification is the same as Sun has when it creates a limited profile of Java for a special environment, like Java ME: the demands of a special environment.

Re:

[ultrabot (200914)]

I used to hate Java (and JavaScript) because it took forever to load, turning a screaming fast Internet connection into a rush hour exercise in patience, but they improved that and I started singing the praises of Java and JavaScript. Then I found that even though JavaScript is still good, Java now drives me crazy

You know this already, but Java and Javascript are technologies that are not related to each other in any way, apart from the unfortunate naming. Javascript is as close to C as it is to Java.

Re:

[LizardKing (5245)]

So your blaming Sun for Ciscos ineptitude. I have code written under the 1.0.2 Java SDK that still runs under Java 1.6. There again, unlike Cisco's engineers I understood what portability was, because I was targeting SunOS as well as Windows.

Re:

[shutdown -p now (807394)]

As far as I'm concerned, Sun (or anyone complicit in their activities re: Java) lost all right to bitch about this once every new version of Java consistently broke backwards compatibility with previous versions.

In some aspects, it is the fundamental deficiency of Java the language. Because all methods are implicitly virtual and all overrides are also implicit, and because override resolution happens at class load time, not at compile time (i.e. if Derived.class derives from Base.class, and both have method void foo(), then Derived.foo will override Base.foo - even if, when Derived.class was compiled, Base.class didn't contain foo yet), you get a specific case of fragile base class problem [wikipedia.org] in Java that's effectivel

Re:

[ultrabot (200914)]

We'd be worried about Microsoft attempting to create an MS-only ghetto that they lock people into

Like .NET?

For most parts, /. seems to be pretty much ignoring what msft is doing these days, as far as server technologies are concerned.

Uh, we did scream

[betterunixthanunix (980855)]

Visual J++ was what we screamed about, and Sun sued Microsoft, and Microsoft backed down and took J++ off the market.