None of that matters. Basically, as long as Google is not using the mark "JAVA" to sell anything they are not infringing Oracle's trademark.
Yes but what about copyright? Google is using APIs and a language developed by (...) Oracle, and their copyright grant explicitly states that clean room implementations are allowed only if they do not constitute either a superset or a subset of the specification. Which is exactly what Google is doing instead.
[Not that I approve Oracle's behaviour, I think they're severely damaging the image of Java with this lawsuit.]
The full Java SE is not appropriate for a mobile phone, far to heavyweight and full of APIs like the AWT, SWT etc.
The full Java SE ran at full speed on desktop computers that had a fraction of the computational power of today's mobile phones (think about 75 MHz Pentiums with 16 MB RAM). The cheapest smartphone of today could run Java SE with no problems. Except for the fact that many desktop-oriented APIs would make little sense on a phone (e.g. Swing UIs). SWT was never part of Java SE.
Java ME was created in a time when phones had alphanumeric, monochrome displays and CPUs without floating point math, so it was designed with a *very* minimalistic approach. That's why it really sucks for all purposes today.
Apparently, you didn't bother reading that FAQ either, because just a couple of lines after the point you quoted, it clearly says that the FAQ refers to GCC 3.1. We're at 4.5.1 now, and GCJ supports AWT and Swing.
Flawlessly? You're claiming there are no flaws on Android apps? The miracle platform!
No, I didn't mean that Android has no flaws (sorry about the weakness of my English), in fact I have quite a history of Android-bashing here on Slashdot. I just meant that "perceived slowness" or "memory exhaustion" aren't among them.
Apple COULD allow GC on iPhone, and it would work. Someone might even claim flawlessly. But the fact is it would be slower and more memory hungry.
Yes, and it's a fact that objc applications will be slower and more memory hungry than applications directly coded in ARM assembly. But the world is moving in the opposite direction, end users are happy, and developers are even happier.
By the way, shall we bet that sooner or later Apple will enable GC by default on all of its platforms?
Let's put it another way: IIRC the least powerful iPhone has a 600 MHz CPU with a GPU, the cheapest Android phone I know (mine!:D) has a 500 MHz CPU of the same family and no GPU. It still handles Java's GC just fine.
And why is GC allowed on the Android platform, whose applications are written in Java, and run flawlessly on hardware which costs half as much as the one of the iPhone?
Java was built with the braindead/naive idea that it would run equally on all platforms.
And it's the language that got closer to that achievement.
Of course every software architecture has its limits, and in particular, no language can stop a programmer from making bad choices (although the original Java strove to, and received quite a bunch of complains from "good" programmers for this reason).
So when we found that the implementation on some obscure platform had a bug, we couldn't just #define a way around it like you can in C. Therefore you have to use more hackish tricks like these.
Using #define would produce an entire set of incompatible, specific binaries for each of those obscure platforms. I can't see how this would be less "hackish" than inserting runtime checks.
You can also use cpp on the.java sources if you really miss that thing!
If you really want to horrify Java coders, think about what would happen if all the com.sun libraries got renamed to com.oracle. =) =)
That would distinguish regular coders, from "coders" who chose to use proprietary, unpublished, deprecated apis despite the fact that all documentation and tools warned not to make use of them. And nothing of value would be lost:) .
Try writing some high level code in C, then some equivalent code in Java.
Run the results.
Notice which one is faster, and which one was easier to write, is easier to read, and will be easier to maintain. Hint: it will be the same one in both cases.
Yes, because you can't write puzzlers in any other language.
It's also interesting to note that the publishers of that video choose Java as (among other things) the language for their mobile operating system (Android) and for their web widgets toolkit (GWT).
Actually, if you look at the EPA page about the Smart fortwo, you'll see that the car is rated at the end of the scale (on the "best" side) for the "climate change" rating, and if you look at the 2010 EPA fuel economy guide report, page 4, you can see that at least the EPA believes that the fortwo is the "2010 fuel economy leader" for the "two-seater cars" category, and that anyway it consumes less than *any* non-hybrid car.
is totally useless as-is and is only owned by eco-posers with too much money and too little sense
And people who want to save on fuel, park easily, and still own a car that is nice to drive.
Now they should just replace all iPhone 4 ads showing a "naked" phone with a bumper-covered one, so customers will know what their product will actually look like if they want to effectively use it as a phone.
I have a different experience with HTC. My HTC phone is not "moddable" at all per se. Its bootloader only accepts ROMs digitally signed by HTC.
Some modders found a way around this protection, but they exploit bugs in the firmware's security, it's not that HTC happily allowed this. Also, HTC is known to send cease-and-desist letters to the sites who host their ROMs. So I don't think they're interested in letting you hack their firmwares more than Motorola is. When hackers find a hole in eFuse, Motorola's phones will be just as hackable as HTC ones.
By the way, all modded ROMs for my phone suck because they are lacking major hardware features such as camera or FM radio, or major software features like Android market. Which means I'll never use them, and rather keep my original firmware. Which has received 0 official updates from HTC, who also has stated that they won't release any new update because they're now focusing on new models. 7 months after my phone was launched, its support is already dead. So unlike you, I won't ever buy an HTC phone again.
To you, because the installer that installs or upgrades Qt on the device if it's not there, is provided by Nokia in the Qt SDK.
To your customers, because they don't need to even realize that Qt is being installed alongside your application. It's simply part of the application's installation procedure.
I'm optimist. Today we have Android, and every day we see some new kind of gadget running it.
We see a bunch of major laptop manufacturers forming a consortium for the sole purpose of easing the development of linux-based ARM devices. This means that they must have something cooking, otherwise they wouldn't be investing that money.
We also have MeeGo shaping up, which will be even more open than Android, and is championed by the world's biggest phone maker and CPU maker - and it will run on ARM too.
Even on the closed source front, millions of people are now familiar with using Apple's devices instead of Windows-based hardware. And Windows Mobile simply disappeared from existence.
As for Office, well, I know people who are more used to OpenOffice.org's old-school interface rather than MSOffice 2007's advanced next-generation ribbon. And IIRC Nokia is funding the development of KOffice so I think we can expect some nice office applications on MeeGo in the near future.
My conclusion: Windows has never been so weak as it is today. So 2011 might be the year of non-Windows on the netbook. Or, to be more politically correct, the year of fair competition on the netbook.
Symbian^4 will be the first release to *use* Qt as its native toolkit. But all recent (less than 4 years old) Symbian phones support Qt as a runtime for third-party applications, so you can already develop Qt-based applications for current handsets.
Qt can be installed on all S60 3rd edition devices, that is every Symbian phone sold in the last three years or so (source). You can put Qt in you application package. Symbian^1 devices got Qt with their latest firmware updates. Symbian^3 devices have Qt factory-installed.
* Download a very heavy C++ ide which was, till recently, locked down. You had to get a "professional" license if you wanted to do something useful. There is the "express" version but it was deliberately crippled. Oh yeah it only runs on Windows.
1) It's free now so what's the real problem? If you grieve because you had to pay in the past, then you should compare with how much the alternatives costed at the time.
2) It runs only on Windows? Well, everybody develops for the iPhone, whose SDK works only on OSX, which means even less machines than Windows. Anyway, the new Nokia-recommended SDKs for developing on Symbian work on Windows, Linux and OSX.
3) The "heavy C++ ide" is Eclipse, which was at the time one of the most used IDEs.
3) If you target Java, then you can use any IDE of your choice, you're not bound to use Nokia's heavy ide.
* If you wanted to distribute your app you had to get it signed.
Yeah, that's a pain, but every phone platform in the world won't accept unsigned apps without annoying the user to death. Some won't accept them at all. Still they seem quite successful.
* If you're a developer like me who is uncomfortable using a low level language you can go the Java route. Yeah. Write once, debug everywhere. It's a mess. I can't even get my midlet to get the IMEI code of the phone so I can use it for authentication.
Nokia did their job: they support the standard Sun APIs, and added specific APIs to access platform-specific features. Their phones will run unmodified JavaME JARs. What's specifically wrong with their Java implementation? They're even contributing a free virtual machine to the Symbian project. Btw I hear that System.getProperty("com.nokia.mid.imei"); will work on any S60 phone released after february 2007.
* A beautiful middle ground is Python for S60. I tried to install it recently on my Nokia N73. A huge bag of fail.
How exactly did it fail? It appears to work on my N73, and it's a 2006 phone. You have to sign the interpreter to access all phone features.
* Yeah sure Symbian is open source. I want to download the source, build it and run it. Have you read the instructions to get it up and running under Linux? Let's just say that it goes way over my head. I heard on a podcast that Nokia uses some kind of circuit board made by Texas Instruments. Ok, so I need to go get some specialized device just to run the kernel? Please.
You mean to be able to run it in an emulator? The emulator is currently windows-only, alas. Don't know if it works under wine.There's a project devoted to run Symbian on off-the-shelf hardware, too.
Did they fix the alarm clock in the Desire? My HTC Tattoo's alarm clock will just *not* go off at all if the phone is turned off. So I can't rely on it waking me up in the morning, because the phone might turn itself off during the night (e.g. because it's low on battery). Every phone I've ever used in my life does turn itself on to ring the alarm. Every phone *with a clock*, that is.
Slashdot Mirror
None of that matters. Basically, as long as Google is not using the mark "JAVA" to sell anything they are not infringing Oracle's trademark.
Yes but what about copyright? Google is using APIs and a language developed by (...) Oracle, and their copyright grant explicitly states that clean room implementations are allowed only if they do not constitute either a superset or a subset of the specification. Which is exactly what Google is doing instead.
[Not that I approve Oracle's behaviour, I think they're severely damaging the image of Java with this lawsuit.]
The full Java SE is not appropriate for a mobile phone, far to heavyweight and full of APIs like the AWT, SWT etc.
The full Java SE ran at full speed on desktop computers that had a fraction of the computational power of today's mobile phones (think about 75 MHz Pentiums with 16 MB RAM). The cheapest smartphone of today could run Java SE with no problems. Except for the fact that many desktop-oriented APIs would make little sense on a phone (e.g. Swing UIs). SWT was never part of Java SE.
Java ME was created in a time when phones had alphanumeric, monochrome displays and CPUs without floating point math, so it was designed with a *very* minimalistic approach. That's why it really sucks for all purposes today.
GCJ supports most of java 1.5 since version 4.3 (2007).
Apparently, you didn't bother reading that FAQ either, because just a couple of lines after the point you quoted, it clearly says that the FAQ refers to GCC 3.1. We're at 4.5.1 now, and GCJ supports AWT and Swing.
Flawlessly? You're claiming there are no flaws on Android apps? The miracle platform!
No, I didn't mean that Android has no flaws (sorry about the weakness of my English), in fact I have quite a history of Android-bashing here on Slashdot. I just meant that "perceived slowness" or "memory exhaustion" aren't among them.
Apple COULD allow GC on iPhone, and it would work. Someone might even claim flawlessly. But the fact is it would be slower and more memory hungry.
Yes, and it's a fact that objc applications will be slower and more memory hungry than applications directly coded in ARM assembly. But the world is moving in the opposite direction, end users are happy, and developers are even happier.
By the way, shall we bet that sooner or later Apple will enable GC by default on all of its platforms?
Let's put it another way: IIRC the least powerful iPhone has a 600 MHz CPU with a GPU, the cheapest Android phone I know (mine! :D) has a 500 MHz CPU of the same family and no GPU. It still handles Java's GC just fine.
And why is GC allowed on the Android platform, whose applications are written in Java, and run flawlessly on hardware which costs half as much as the one of the iPhone?
Java was built with the braindead/naive idea that it would run equally on all platforms.
And it's the language that got closer to that achievement.
Of course every software architecture has its limits, and in particular, no language can stop a programmer from making bad choices (although the original Java strove to, and received quite a bunch of complains from "good" programmers for this reason).
So when we found that the implementation on some obscure platform had a bug, we couldn't just #define a way around it like you can in C. Therefore you have to use more hackish tricks like these.
Using #define would produce an entire set of incompatible, specific binaries for each of those obscure platforms. I can't see how this would be less "hackish" than inserting runtime checks.
You can also use cpp on the .java sources if you really miss that thing!
If you really want to horrify Java coders, think about what would happen if all the com.sun libraries got renamed to com.oracle. =) =)
That would distinguish regular coders, from "coders" who chose to use proprietary, unpublished, deprecated apis despite the fact that all documentation and tools warned not to make use of them. And nothing of value would be lost :) .
Try writing some high level code in C, then some equivalent code in Java.
Run the results.
Notice which one is faster, and which one was easier to write, is easier to read, and will be easier to maintain. Hint: it will be the same one in both cases.
There, fixed that for you.
It's also interesting to note that the publishers of that video choose Java as (among other things) the language for their mobile operating system (Android) and for their web widgets toolkit (GWT).
No, it's like painting your name in new releases, that *you* are developing, of that painting.
is totally useless as-is and is only owned by eco-posers with too much money and too little sense
And people who want to save on fuel, park easily, and still own a car that is nice to drive.
Hmm, on the other side, commercial font vendors will be rubbing their hands now.
Now they should just replace all iPhone 4 ads showing a "naked" phone with a bumper-covered one, so customers will know what their product will actually look like if they want to effectively use it as a phone.
Some modders found a way around this protection, but they exploit bugs in the firmware's security, it's not that HTC happily allowed this. Also, HTC is known to send cease-and-desist letters to the sites who host their ROMs. So I don't think they're interested in letting you hack their firmwares more than Motorola is. When hackers find a hole in eFuse, Motorola's phones will be just as hackable as HTC ones.
By the way, all modded ROMs for my phone suck because they are lacking major hardware features such as camera or FM radio, or major software features like Android market. Which means I'll never use them, and rather keep my original firmware. Which has received 0 official updates from HTC, who also has stated that they won't release any new update because they're now focusing on new models. 7 months after my phone was launched, its support is already dead. So unlike you, I won't ever buy an HTC phone again.
To you, because the installer that installs or upgrades Qt on the device if it's not there, is provided by Nokia in the Qt SDK.
To your customers, because they don't need to even realize that Qt is being installed alongside your application. It's simply part of the application's installation procedure.
That's why your application's installer, provided by Nokia, will install Qt on the device if it's not there.
We see a bunch of major laptop manufacturers forming a consortium for the sole purpose of easing the development of linux-based ARM devices. This means that they must have something cooking, otherwise they wouldn't be investing that money.
We also have MeeGo shaping up, which will be even more open than Android, and is championed by the world's biggest phone maker and CPU maker - and it will run on ARM too.
Even on the closed source front, millions of people are now familiar with using Apple's devices instead of Windows-based hardware. And Windows Mobile simply disappeared from existence.
As for Office, well, I know people who are more used to OpenOffice.org's old-school interface rather than MSOffice 2007's advanced next-generation ribbon. And IIRC Nokia is funding the development of KOffice so I think we can expect some nice office applications on MeeGo in the near future.
My conclusion: Windows has never been so weak as it is today. So 2011 might be the year of non-Windows on the netbook. Or, to be more politically correct, the year of fair competition on the netbook.
Is Android OSS enough for you? People seem to like its user interface.
10 hours is already more time than I know what to do with with my netbook.
Watch YouTube and the 10 hours become 5.
Play a game and the 10 hours become 3.
Do any of the above over 3G wireless and they become even less.
Symbian^4 will be the first release to *use* Qt as its native toolkit. But all recent (less than 4 years old) Symbian phones support Qt as a runtime for third-party applications, so you can already develop Qt-based applications for current handsets.
Qt can be installed on all S60 3rd edition devices, that is every Symbian phone sold in the last three years or so (source). You can put Qt in you application package. Symbian^1 devices got Qt with their latest firmware updates. Symbian^3 devices have Qt factory-installed.
* Download a very heavy C++ ide which was, till recently, locked down. You had to get a "professional" license if you wanted to do something useful. There is the "express" version but it was deliberately crippled. Oh yeah it only runs on Windows.
1) It's free now so what's the real problem? If you grieve because you had to pay in the past, then you should compare with how much the alternatives costed at the time.
2) It runs only on Windows? Well, everybody develops for the iPhone, whose SDK works only on OSX, which means even less machines than Windows. Anyway, the new Nokia-recommended SDKs for developing on Symbian work on Windows, Linux and OSX.
3) The "heavy C++ ide" is Eclipse, which was at the time one of the most used IDEs.
3) If you target Java, then you can use any IDE of your choice, you're not bound to use Nokia's heavy ide.
* If you wanted to distribute your app you had to get it signed.
Yeah, that's a pain, but every phone platform in the world won't accept unsigned apps without annoying the user to death. Some won't accept them at all. Still they seem quite successful.
* If you're a developer like me who is uncomfortable using a low level language you can go the Java route. Yeah. Write once, debug everywhere. It's a mess. I can't even get my midlet to get the IMEI code of the phone so I can use it for authentication.
Nokia did their job: they support the standard Sun APIs, and added specific APIs to access platform-specific features. Their phones will run unmodified JavaME JARs. What's specifically wrong with their Java implementation? They're even contributing a free virtual machine to the Symbian project. Btw I hear that System.getProperty("com.nokia.mid.imei"); will work on any S60 phone released after february 2007.
* A beautiful middle ground is Python for S60. I tried to install it recently on my Nokia N73. A huge bag of fail.
How exactly did it fail? It appears to work on my N73, and it's a 2006 phone. You have to sign the interpreter to access all phone features.
* Yeah sure Symbian is open source. I want to download the source, build it and run it. Have you read the instructions to get it up and running under Linux? Let's just say that it goes way over my head. I heard on a podcast that Nokia uses some kind of circuit board made by Texas Instruments. Ok, so I need to go get some specialized device just to run the kernel? Please.
You mean to be able to run it in an emulator? The emulator is currently windows-only, alas. Don't know if it works under wine.There's a project devoted to run Symbian on off-the-shelf hardware, too.
Did they fix the alarm clock in the Desire? My HTC Tattoo's alarm clock will just *not* go off at all if the phone is turned off. So I can't rely on it waking me up in the morning, because the phone might turn itself off during the night (e.g. because it's low on battery). Every phone I've ever used in my life does turn itself on to ring the alarm. Every phone *with a clock*, that is.