Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Android's "Non-Fragmentation Agreement"

Zonk posted more than 6 years ago | from the i-hate-it-when-my-agreements-fragment dept.

Google 142

superglaze writes "The biggest doubt cast over Android (whose SDK was released yesterday) has been the fact that much of it is licensed under Apache. There have been worries that manufacturers might fork the code road in a non-interoperable kind of way. I.e., they would have no obligation to feed back code to the wider Open Handset Alliance, or even tell the other members what alterations have been made. However, it turns out that Google made all the members sign a 'non-fragmentation agreement' to make sure everything works with everything. In theory at least. 'All of the partners have signed a non-fragmentation agreement saying they won't modify [the code] in non-compatible ways ... That is not to say that a company that is not part of the OHA could not do so.' Google's spokesperson highlighted the historical dangers of working with Java, the programming language that lies at the heart of Android. 'One of the current problems with mobile Java development is that Java has fragmented ... Java virtual machines have fragmented, but all the members of the OHA have agreed to use one virtual machine that can run script in Java'"

cancel ×

142 comments

Java? Fragmented? (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21336101)

What, java has "recently" fragmented? What about all the incompatible versions of the JDK/JRE that people must install to use the latest Java Crapplet(TM)?

What about java's promise of 'write-once, run anywhere'..more like, write-once, maintain 5 different versions of the JRE, each at 100Mb+.

Seems fitting that with most cellphones these days, being nothing more than over-priced toys, that just happen to be able to occasionally make and receive calls, that they use a fragmented, broken toy programming language.

I'll stick to a basic phone, and follow the *NIX philosophy, "just does one thing, and do it well", thank you very much.

Re:Java? Fragmented? (5, Funny)

jdeisenberg (37914) | more than 6 years ago | (#21336233)

I'm going to lose all my karma points, but here goes...

From this (and other comments in the previous postings about Android), one might get the impression that the people at Google are a bunch of idiots who just didn't do any basic research. Why, if only they had read Slashdot occasionally, they'd know that Java is slow, has 10^6 different versions, is very slow, is inferior to C++, is extremely slow, takes up too much memory, is abominably slow, is a programming language that no real programmer uses any more, and in general is teh sux0rz. <grin/>

Re:Java? Fragmented? (2, Insightful)

crush (19364) | more than 6 years ago | (#21336355)

Agreed 100% about the unfair commentary that there usually is on Java. But, Google are behaving rather bizarrely by on the one hand warning about the problems of forking and then on the other releasing their own JVM Dalvik instead of using JavaME [infoq.com] . So they're going with Apache's dodgy non-GPL approach and further causing fragmentation of the Java platform right when sun is doing the right thing by releasing a GPL'ed Java and Red Hat and others have stepped up to the plate to integrate the OpenJDK work with IcedTea. Google aren't stupid, I wonder what they're game is? I suspect they're trying to GPLv3-proof themselves.

Re:Java? Fragmented? (5, Insightful)

omeomi (675045) | more than 6 years ago | (#21336437)

behaving rather bizarrely by on the one hand warning about the problems of forking and then on the other releasing their own JVM Dalvik instead of using JavaME.

You've never written a JavaME (J2ME) app, have you? Getting a J2ME application to work properly on all phones is a huge nightmare. Just when you have it working on your phone, and all of your coworkers phones, you try it on your wife's phone, and find that it completely doesn't work. There's plenty of fragmentation just within J2ME, and it's made worse by the fact that it's almost impossible to test an application on every different phone that's out there. If Google can come up with an SDK that makes "write once run anywhere" a reality in the mobile world, I'm all for it.

Re:Java? Fragmented? (3, Interesting)

crush (19364) | more than 6 years ago | (#21336603)

That's fine, but you're avoiding the central point: Google are causing further fragmentation and forking within Java at a time when there are significant efforts being made to re-unify and stabilize the platform. Also they've chosen a license which has the potential to allow leachers to benefit from any work anyone does on the distributed code. A pity that they didn't put their efforts into improving J2ME instead.

Re:Java? Fragmented? (2, Insightful)

rubycodez (864176) | more than 6 years ago | (#21336845)

or we could say you're missing the point, java is so very fragmented already one more little fragment in the broken heap of glass won't make any difference at all. java: write once, run well only in the IDE of the developer.

Re:Java? Fragmented? (4, Insightful)

dintech (998802) | more than 6 years ago | (#21337017)

'Write once, run anywhere'. Hmm, I'm a java programmer and have been for 10 years. I know, as every java developer knows and realises, it actually means 'write once, run on the important places'. Meaning something that works on your desktop PC will also work on the Solaris server you intend to deploy it to.

Mostly people who use 'but I thought you said run ANYWHERE' argument should actually try to think about what that would mean in real terms. For example, should you expect a huge Swing application or something like Weblogic 9 to run on your 8 year old J2ME phone? Be sensible please...

Re:Java? Fragmented? (0)

Anonymous Coward | more than 6 years ago | (#21340901)

"'Write once, run anywhere'. Hmm, I'm a java programmer and have been for 10 years. I know, as every java developer knows and realises, it actually means 'write once, run on the important places'. Meaning something that works on your desktop PC will also work on the Solaris server you intend to deploy it to."

Well, so what you are saying, is a 'hello world' application will run on all the important places.

How about something a little more complex?

Not all apps are conent with simple objects and methods.

I'm pretty sure a C programmer can write a hello world app that compiles and works on 'all the important places'.

Re:Java? Fragmented? (0, Redundant)

crush (19364) | more than 6 years ago | (#21337063)

And I could respond that again you're missing the point which is that there are very significant recent moves towards unifying the java platform which had mostly fragmented because of Sun's licensing policies which have now changed. There is significant potential right now to create Free software community around Sun's version and yet right at this time Google chooses to make this move.

Re:Java? Fragmented? (2, Interesting)

EmperorKagato (689705) | more than 6 years ago | (#21337077)

There are Java profiles that work across most cellphones. Most of the new phones implement the profiles with ease.

Re:Java? Fragmented? (3, Interesting)

forgotten_my_nick (802929) | more than 6 years ago | (#21337349)

No idea why you got modded off topic. You are correct. Normal J2ME commands will work across all phones. It is when you get into graphics or messing with screen resolution that you have to be aware of different devices. That is why you can get emulators for different screen/phones and test.

Re:Java? Fragmented? (1)

omeomi (675045) | more than 6 years ago | (#21337519)

That is why you can get emulators for different screen/phones and test.

The emulators I've found don't adequately emulate the various limitations of these phones. You're probably right that basic J2ME commands will work across most phones, but writing games, for instance, can be a huge headache.

Re:Java? Fragmented? (4, Interesting)

crush (19364) | more than 6 years ago | (#21338221)

Whoever modded him offtopic was either being childish or desperate to hide the information. Probably just a fanboy.

Reading further on this, the interesting thing about Dalvik is that it's a non-Sun-controlled JVM. The thing about JavaME (aka PhoneME) is that although it (like JavaSE and JavaEE (Glassfish)) is released under GPLv2 [linuxdevices.com] , there is no exception clause [java.net] (there is for JavaSE). This means that you can only run GPLv2 code on PhoneME. Obviously Google and it's partners didn't like this, so they wrote their own JVM. In order to avoid infringing on Sun's IP they've made the bytecode unique to Dalvik. So Java goes in ---> Dalvik bytecode comes out, runs on Dalvik. Very clever.

Re:Java? Fragmented? (0)

Anonymous Coward | more than 6 years ago | (#21338519)

So then it sounds like..
  - Many of the "2000" classes were reimplementations of the base libraries
  - Google cannot use the Java trademark or refer to their VM as Java.

The fact that they are calling it Java makes me think Google is willing to break the license because they're big enough and can spread enough FUD to make Sun think twice about suing.

Re:Java? Fragmented? (1)

omeomi (675045) | more than 6 years ago | (#21337581)

A pity that they didn't put their efforts into improving J2ME instead.

Improving J2ME would mean updating he basic standards of what it takes to be considered a J2ME phone. Right now, the standards are so out of date as to be completely useless, so you end up writing for what you think will work on most current phones, and then testing to find out...available emulators don't adequately emulate phone limitations, and not all manufacturers publish all of the relevant implementation specifications, so testing requires actually having a wide array of phones, which can be pretty expensive.

Re:Java? Fragmented? (1, Interesting)

crush (19364) | more than 6 years ago | (#21338295)

As I've said before, I think you're missing the point. And having read a bit more about Dalvik I think that Google needed their own fragmented platform because the GPLv2 (sans-exception) license of JavaME/PhoneME meant that if they want to encourage partners to write proprietary, non-Free code then they had to get their own JVM. See my post here [slashdot.org] for more information. This is a license war. It has fuck all to do with technical excellence or the ease-of-development on the platform. The only reason I care is that I don't like non-Free stuff. It doesn't really matter a fuck to me whether I get proprietary apps from the OHA or from Microsoft. I also dislike fragmentation of Java, especially when it has the chance of being an even more viable platform.

Re:Java? Fragmented? (0)

Anonymous Coward | more than 6 years ago | (#21338391)

It's a good thing no one gives a shit what you think then...

Re:Java? Fragmented? (1)

crush (19364) | more than 6 years ago | (#21339001)

Whoever modded this as "redundant" is on crack. There was absolutely nothing else posted on this thread about the JavaSE exception licensing and it's the heart of the matter.

Re:Java? Fragmented? (1)

bjourne (1034822) | more than 6 years ago | (#21339629)

available emulators don't adequately emulate phone limitations, and not all manufacturers publish all of the relevant implementation specifications, so testing requires actually having a wide array of phones, which can be pretty expensive.
Seek and you shall find. At least both Sony Ericsson [sonyericsson.com] and Nokia [nokia.com] have public discussion boards where you can get in touch with handset developers, bug reporting [kpimdp.com] and free test suites [sourceforge.net] . You can also, if you represent a reputable ISV, borrow phones to test with and (if you sign a bunch of NDA:s) even get unreleased phones to experiment with.

Re:Java? Fragmented? (1)

muyuubyou (621373) | more than 6 years ago | (#21338473)

Since Google is doing this, my guess is they looked into J2ME, found a mess of legacy code and outdated standards, and decided it wasn't worth it.

Even Microsoft was wise enough to do something similar when they decided to scrap the whole pre-NT platform and start anew.

J2ME (1)

edxwelch (600979) | more than 6 years ago | (#21339367)

The core J2ME API was made by several commities and "evolved" rather than was designed. Those commities were controlled by the operertors who were more concerned about using the API to generator revenue for themselves than advancing technology. Google is right in starting from scratch rather than building on J2ME.
However, some extension apis are rather well designed (for instance bluetooth and mg3), it would be not be a bad way to re-use those apis.

Re:Java? Fragmented? (1)

ClassMyAss (976281) | more than 6 years ago | (#21340427)

Google cares little either way about fragmenting Java - what they want to avoid is fragmentation of Android, and I think they will accomplish this, more or less. They just decided that J2ME didn't do it technically for them. As far as the license, I think they wisely realized that Apache would be seen as more business friendly, and it leaves service providers with the illusion that they can still lock everything down.

Illusion? Yup - in practice, this will be extremely difficult. IMO, Google's play is to make a huge fuss about how open the platform is, and get a whole crapload of software written for it that requires fully unlocked phones in order to operate, which will all exist before the first phones even come out. They're even dumping $10 mil into this, and I all but guarantee you that most of those 50 finalists will be using all the cool API features that providers would be happier to lock independent developers out of. By the time phones hit the market, people will be so used to seeing all the sweet things that full Android phones can do that it would be tactical suicide for a phone company to release crippled versions - they would be instantly accused of misleading their customers, with very good reason. I'd be freaking pissed if I was expecting to get a phone that could run all sorts of free map-based software with P2P gaming and all that fun stuff, and when I picked one up none of the software I was promised (implicitly, by their marketing of it as an Android phone) would run.

Think about it - what are the buzzwords associated with Android as far as the press releases go? 1) Open, and 2) Business-friendly. These are largely mutually incompatible, but a lot more people will be pissed if the phone companies strip out 1), so they will have no choice but to succumb to a different business strategy. Google is going to force their hand by making their customers insist on keeping the phone open, just watch - it's rather clever, if you ask me, and I hope it works.

Re:Java? Fragmented? (1)

supermansuper (1183487) | more than 6 years ago | (#21340687)

"people will be so used to seeing all the sweet things that full Android phones" Once again, slashdot user != typical user. Normal people want what they see on TV or what their friends have. Not something from videos in the developer section of google's website.

Re:Java? Fragmented? (1)

crush (19364) | more than 6 years ago | (#21340877)

That's one of the more thoughtful posts on this topic that I've read. It's also optimistic which is nice.

Re:Java? Fragmented? (1)

Sancho (17056) | more than 6 years ago | (#21340695)

That's fine, but you're avoiding the central point: Google are causing further fragmentation and forking within Java at a time when there are significant efforts being made to re-unify and stabilize the platform.
Java (and even J2ME) is a strange little beast. It's not quite a platform, but it tries to be one. Google is trying to create a true platform based upon Java. It's probably true that code written for their platform will have issues (or not run at all) on non-Android platforms, but that's something that would happen anyway, even if Google had chosen J2ME and tried to improve it. With everyone else fragmenting Java, coupled with versioning problems, software written for Android probably still wouldn't work by default on other J2ME phones.

The reason that one forks or fragments a project like this is in order to try to do it right. With so many vendors working on and supporting Android, I think they've got a real shot at making a platform where tweaks aren't necessary to get code to work on another Android phone (compare to getting the same software to work in different J2ME phones.)

Re:Java? Fragmented? (0)

Goaway (82658) | more than 6 years ago | (#21339259)

right when sun is doing the right thing by releasing a GPL'ed Java
Except that is the exact reason they did what they did. Sun's license requires all surrounding code to also be GPL'd on mobile platforms (but have a special exception for this for the desktop version). This is basically so that phone providers, who neither want nor can release this code have to pay them for commercial licenses.

Re:Java? Fragmented? -- Google? Non-evil? (1)

crush (19364) | more than 6 years ago | (#21340143)

I know that's why they did it, which is why I posted this [slashdot.org] comment. I'm also aware that people inside Sun have been trying to streamline Java SE further. I think it's pretty clear that Google is working hard to facilitate the creation of non-Free software by mobile phone makers. I guess the company slogan changed to "Do lots of evil". Meet the new Microsoft, happily embracing and extending Java.

Re:Java? Fragmented? (0, Offtopic)

Comatose51 (687974) | more than 6 years ago | (#21337003)

I'm not sure if I should mod you flamebait, insightful, or funny. Well I guess it doesn't really matter now...

Re:Java? Fragmented? (1)

ComputerPhreak (1057874) | more than 6 years ago | (#21337441)

Java is slow, has 10^6 different versions, is very slow, is inferior to C++, is extremely slow, takes up too much memory, is abominably slow, is a programming language that no real programmer uses any more, and in general is teh sux0rz. There, just proved your point.

either/or? (1)

m2943 (1140797) | more than 6 years ago | (#21337583)

the impression that the people at Google are a bunch of idiots who just didn't do any basic research

They did do research, which is why they replaced most of the Sun bloat with native C libraries.

they'd know that Java is slow, has 10^6 different versions

They know that; it's one of the reasons they created Android in the first place.

Java is slow

They know that, too, which is why only the high-level apps are written in Java and why they replaced the JVM with Dalvik.

Re:Java? Fragmented? (2, Insightful)

gEvil (beta) (945888) | more than 6 years ago | (#21336245)

Isn't the scenario above EXACTLY what this non-fragmentation agreement should help to avoid? Seems like a reasonable way to ensure device compatibility to me. If a non-OHA entity fragments the code, that's fine, because their code/app/SDK/whatever isn't guaranteed to run on all of the devices anyway. If some hobbyists want to create their own derivative platform for device X, they're perfectly free to do so. Seems like all of the benefits of the open source model to me.

With Andriod, you are free... (2, Insightful)

WindBourne (631190) | more than 6 years ago | (#21336331)

to develop in non-java. Of course, it may not work on ALL handsets (in fact, all but certain that it will not). But if you do the work in Java, AND use their API, it is being guaranteed to work across all of the handsets. So, what is your gripe?

Re:With Andriod, you are free... (1)

ceroklis (1083863) | more than 6 years ago | (#21338597)

And if I develop for Windows Mobile, PalmOs or Symbian I can write in C/C++, compile once, and have the guarantee that the code will run everywhere, because every device is based on the same architecture/ABI (f.i. ARMv4). This is what make these platforms superior.

The only reason to offer Java *exclusively* is if you run on a limited device (i.e. no MMU). In this case a VM is necessary to isolate untrusted third party applications. But in the case of modern ARM chips (with MMU), which can run a POSIX system, the OS can achieve process isolation even if they are written in machine code. Java is thus unnecessary on modern phones.

Now I realize a good jazelle based VM may render Java almost as fast as C++, but there is another reason beside performance to support C++, easy porting of existing code.

Therefore the absence of well defined C/C++ ABI is a deficiency.

Re:Java? Fragmented? (0)

EmperorKagato (689705) | more than 6 years ago | (#21337015)

Mod parent down.

The first comment to any article about Java on slashdot is by someone who always trolls Java as Anonymous Coward.

What about java's promise of 'write-once, run anywhere'..more like, write-once, maintain 5 different versions of the JRE, each at 100Mb+.
That's up to the SUN Java Runtime Environment developers not the public that codes in Java

Seems fitting that with most cellphones these days, being nothing more than over-priced toys, that just happen to be able to occasionally make and receive calls, that they use a fragmented, broken toy programming language.
Toy? Where have you been, it's been a "toy" in japan since the late 90s. The United States is just now catching up to the innovations of the cellular phone in Japan.

This is the age of information and there are many that want information on the go or entertainment while waiting for the bus.

Re:Java? Fragmented? (0)

Anonymous Coward | more than 6 years ago | (#21339743)

That's up to the SUN Java Runtime Environment developers not the public that codes in Java
So if your Java code doesn't work on an already widely platform you need it to, what do you do? Do you spend time figuring out and developing a work-around for someone else's bugs so it does work, or do you just whine?

Re:Java? Fragmented? (1)

ianare (1132971) | more than 6 years ago | (#21338389)

I'll stick to a basic phone, and follow the *NIX philosophy, "just does one thing, and do it well", thank you very much.
You have perfectly described Apple philosophy, not *NIX. *NIX is more like "do as many things as you want to do". The fact that Apple uses *nix to a large extent, and has put it on a phone, while at the same time some of these same tools help run huge render farms, workstations on different architectures, datacenters, embedded devices, routers, etc.. ad nauseam -- just goes to show the versatility of *NIX.

Google versus Apache (0)

webword (82711) | more than 6 years ago | (#21336119)

In a strange kind of way, this is Google versus Apache. Or, commercial versus non-commercial. I know that this is a ridiculous simplification but it kind of smells that way to me.

Normally Google and open source play together well. But, in this case, we have the potential for a real issue down the road.

With all of that aside, here's a question for you...

If you absolutely had to choose, would you pick to align yourself with Google or Apache?

This isn't a "real" question. It's more of a thought question about who you like and what you believe in. I'm just wondering what people value the most.

Re:Google versus Apache (3, Insightful)

kevin_conaway (585204) | more than 6 years ago | (#21336291)

In a strange kind of way, this is Google versus Apache. Or, commercial versus non-commercial. I know that this is a ridiculous simplification but it kind of smells that way to me.

How exactly? I don't see it that way

Google releases all their open source under the Apache license. I'm sure they have various reasons for choosing the Apache license, but I'd wager a major one is that it is very business friendly. They most likely understand what a pain it can be to include OSS products that are licensed under a different licensing scheme in a commercial product.

Re:Google versus Apache (5, Insightful)

Kadin2048 (468275) | more than 6 years ago | (#21336343)

In a strange kind of way, this is Google versus Apache.

I really don't think it is. This is Google taking the Apache license and then fixing a major perceived weakness in it, at least within the context of their application (creating a single, uniform, mobile platform). And even then, they're not really restricting the software; they're just getting the people who are part of their trade group to agree not to stab each other in the back.

It's not Google "versus" anything or anyone, except perhaps maybe the closed-source phone manufacturers. Certainly not Apache.

Re:Google versus Apache (1)

crush (19364) | more than 6 years ago | (#21337425)

Well, if the licensing of the SDK is anything to go by [livejournal.com] it seems more like it's a case of Google vs. Free Software.

Re:Google versus Apache (2, Insightful)

Kadin2048 (468275) | more than 6 years ago | (#21339671)

Well, if the licensing of the SDK is anything to go by [livejournal.com] it seems more like it's a case of Google vs. Free Software.
Well, we always knew that there were going to be parts of the software stack that aren't going to be Free software. The FCC won't allow the parts that control the radio, for example, to be user-modifiable. So there have to be some big locked-down chunks, just because it's a cellphone.

If Google actually said that the "full stack" would be OSS, then shame on them. But it seems like they're going to be way more open than anyone else, and possibly as open as they can be while still getting FCC approval for the device.

At any rate, I find the whole project interesting but I'm not getting personally invested in it yet. I'll see what the license is like on the real thing before praising or condemning it.

Re:Google versus Apache (1)

Kazrael (918535) | more than 6 years ago | (#21336357)

Apache. While Google does have the mantra "Do No Evil", you must remember, they are a corporation. Their goal is to make money. While they are good now, down the road, you can't be sure. The heart of the system is always corporate gain. The heart of Apache is public gain.

Que? (1)

$1uck (710826) | more than 6 years ago | (#21336209)

How is this google vs apache? I don't understand (its early and I'm feeling fuzzy headed so forgive me). Google is using an apache license to release this... other than that I don't see asf involvement in the project. Maybe I'm missing something here? This article talks about all the involved parties signing an additional agreement separate from the license agreeing not do what MS did to Java before being sued.

So... how is this google vs apache?

Re:Que? (1)

$1uck (710826) | more than 6 years ago | (#21336237)

blah... this was supposed to be in response to someone else and not the main article... I am out of it this morning sorry.

Re:Que? (1)

rumith (983060) | more than 6 years ago | (#21336251)

I'm not sure how exactly it is Google vs Apache, too, but the Apache License is not the only way ASF is involved in this story: Google's custom Java VM, named Dalvik, is heavily based upon Apache Harmony.

Pretty cool start (1)

Zebra_X (13249) | more than 6 years ago | (#21336217)

I took a look at the SDK yesterday and some of the videos - having done windows mobile development it looks like it will be almost as easy and have a number of similar features.

My concern with all of this though - is that there is no hardware available.

One of the things about emulators is that they run really fast, much faster than the actual hardware runs - so it's hard to tell how responsive an application will be. So given that google has been plowing ahead on development but not been testing on real hardware, one has to wonder if things are going to get seriously challenging when they move to hardware...

Re:Pretty cool start (2, Informative)

FinestLittleSpace (719663) | more than 6 years ago | (#21336539)

You have a valid point, however Google /have/ been running Android on mobile handsets. You can see videos of them in action on the main site.

Perhaps they want to avoid symbians mistake? (3, Interesting)

SmallFurryCreature (593017) | more than 6 years ago | (#21336673)

Symbian was developed on hardware, on the lowest hardware then available so that it would be sure to run on everything. This made the design obsolete at launch and now it is so archaic(?) that people really resent that original decesion.

Perhaps Google wants to avoid this. Wants apps that push the hardware requirements so that the Android phones will HAVE to be powerhouses, and it doesn't get trapped in the symbian or even MS trap of having to work on the cheapest shit some company can throw together.

Apparently (I only have this from hearsay) symbian phones often miss basic hardware capabilties that drive a pc programmer up the wall because he suddenly has to code for features that have been present in PC's from the dawn of computing.

All google now has to do, is convince mobile phone makers that it is in their best interest to make their phones capable of actually running the software currently being developed.

Don't forget mobile tech moves fast but is expensive. If the companies could get away with yesterdays tech they would. That ain't good for us consumers, we want them to be pushed so we finally get some fully capable smart phones and not the same crippled yunk they have pushing on us.

Re:Pretty cool start (1)

$1uck (710826) | more than 6 years ago | (#21336981)

"almost as easy" Are you saying that J2me is easier than this? or... are you comparing to a different embedded sdk?

Re:Pretty cool start (1)

Zebra_X (13249) | more than 6 years ago | (#21337891)

Almost as easy as developing for windows mobile...

I suppose you can limit it yourself. (1)

SanityInAnarchy (655584) | more than 6 years ago | (#21336985)

Run your emulator in another emulator, maybe two or three levels deep. Emulators, not virtualizers. That should make it run slowly enough for you.

(I'm sure there's a way to simply slow down the one emulator, but I just had to post the Rube Goldberg solution...)

Re:Pretty cool start (0)

Anonymous Coward | more than 6 years ago | (#21338367)

IIRC, a quick look at the emulator documentation showed an option to "emulate" the slowness in the hardware!

Revisionism? (2, Interesting)

AKAImBatman (238306) | more than 6 years ago | (#21336247)

One of the current problems with mobile Java development is that Java has fragmented ... Java virtual machines have fragmented

Whoa, he-llo? That's a rather interesting (and bold!) statement to be making there. I don't know if Google has noticed, but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs. Which isn't that huge of a deal when you consider that "porting" then becomes a straightforward matter of applying a minor patch between "versions". (Often you can just inline the workarounds and have a single version that works everywhere.)

Meanwhile, Google has created a JVM that's not actually a JVM, that's incompatible with the J2ME/MIDP standard, and then has the gall to claim they're the solution to a more or less non-existent problem? That's ballsy even for Google. :-/

Re:Revisionism? (4, Informative)

Anonymous Coward | more than 6 years ago | (#21337869)

but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs
This is just plain wrong. Once you start looking at graphics, audio, keyboard input, bluetooth, gps, network, photo or video capture or anything beyond very basic apps, you reach the murky world of JSRs, which are bits of java that may or may not be included in a particular j2me installation. If they are included, many of them have lots left up to the implementation to decide, for example MMAPI leaves it up to the implementation whether to support MIDI sound, whether to support playing audio directly from code rather than from a file, whether to support recording, what file formats to support etc. You can't even reliably play audio files across platforms, let alone do interesting things like get at the camera, get video frames etc.

Nokia phones for example, most will let you grab a single frame from the camera, some won't, but you can't grab multiple video frames without a 1/4 second delay per frame, whereas motorola phones, many will not let you at the camera at all, but those that will, will let you record multiple frames properly, except for a few which will only let you take single frames.

Re:Revisionism? (0)

Anonymous Coward | more than 6 years ago | (#21338369)

It sounds like what you're talking about has nothing to do with Java, and everything to do with variation in phone capabilities or hardware standards.

Re:Revisionism? (1)

bjourne (1034822) | more than 6 years ago | (#21339399)

but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs

This is just plain wrong. Once you start looking at graphics, audio, keyboard input, bluetooth, gps, network, photo or video capture or anything beyond very basic apps, you reach the murky world of JSRs, which are bits of java that may or may not be included in a particular j2me installation. If they are included, many of them have lots left up to the implementation to decide, for example MMAPI leaves it up to the implementation whether to support MIDI sound, whether to support playing audio directly from code rather than from a file, whether to support recording, what file formats to support etc. You can't even reliably play audio files across platforms, let alone do interesting things like get at the camera, get video frames etc.
No it is not wrong. Not all phones has camera snapshotting or audio recording capability which is why you need API:s that leaves it up to the manufacturer what to support. The only other alternative is that each manufacturer writes their own API for whatever features their phones support. All manufacturers had such API:s but are now trying to phase them out because it is easier to stick to standards than to invent your own. Which is exactly what Google is doing, which is exactly why they will fail to attract developers.

It is the same thing with other widely deployed specifications, POSIX, the C library, etc.

Nokia phones for example, most will let you grab a single frame from the camera, some won't, but you can't grab multiple video frames without a 1/4 second delay per frame, whereas motorola phones, many will not let you at the camera at all,
Alright, that sucks. But what is your alternative? Try writing a PC program to record frames from a USB camera, easier than MMAPI?

Re:Revisionism? (1)

ClassMyAss (976281) | more than 6 years ago | (#21341209)

FWIW, Android also leaves it up to the handset manufacturers to decide whether or not a particular piece of functionality is available. However, it provides a simple and standardized mechanism to determine whether or not it is, and use it if it is there.

And besides this, even just having a single VM with a single set of bugs will seriously simplify things - right now entire companies exist for the purpose of making J2ME code run on enough phones to take the thing to market (I know - my brother works at one), and the process is anything but simple.

Re:Revisionism? (1)

sacrilicious (316896) | more than 6 years ago | (#21339805)

Whoa, he-llo? [Claiming that jvms have fragmented is] a rather interesting (and bold!) statement to be making there. I don't know if Google has noticed, but J2ME phones all run the same code and the same APIs.

Each time I've developed for a particular phone, I've had to visit the website of the manufacturer and download one or more jars that specify what subset of j2me is supported on the phone. Does this not qualify as having different APIs for different phones?

Issues between phones almost always come down to working around JVM implementation bugs.

Don't jvm implementation bugs indicate that there's different -- and potentially incompatible -- code in the jvms?

Oh, FORK!!! (1)

tomhudson (43916) | more than 6 years ago | (#21336253)

Sounds to me like they don't want anyone forking it.

This is not as bad as Tivo ... or is it?

Non-fragmentation my you-know-what.

Re:Oh, FORK!!! (4, Informative)

ajs (35943) | more than 6 years ago | (#21336391)

Sounds to me like they don't want anyone forking it.
Read it again. The members can't fork the development. Non-members can. They're just trying to prevent the situation where, 5 years down the line, NTT says "thanks for all the hard work Google, but now that we've achieved brand loyalty, we're going to stop working on our competitor's OS." The idea is to make the cell phone OS a commodity and let cell phone makers focus on higher level features that will work on any phone.

Re:Oh, FORK!!! (3, Interesting)

tomhudson (43916) | more than 6 years ago | (#21336497)

Riiight - but who are these potential non-members? Its not like you can have half you development team be members, and the other half non-members.

And its not like there's a huge field when it comes to cell phone manufacturers. There's not thousands of different manufacturers, so google starts out with a de facto quasi-monopoly.

So even if a fork came along that was better, the companies can't use it.

No wonder Microsoft is afraid google will be the next Microsoft - they're using Microsofts' playbook.

Re:Oh, FORK!!! (0)

Anonymous Coward | more than 6 years ago | (#21337301)

Maybe if you checked who actually is in Open Handset Alliance, and compared it to the world market share of sold mobile phones. 40% of all phones and 25% of smartphones is hardly a monopoly.

Re:Oh, FORK!!! (0)

Anonymous Coward | more than 6 years ago | (#21337895)

So even if a fork came along that was better, the companies can't use it.

My understanding of this is that if a fork came along that was better and they wanted to use it, they would all have to agree that it becomes the main branch.

Re:Oh, FORK!!! (1)

yasth (203461) | more than 6 years ago | (#21340203)

Ummm the members are the potential non members. No business would sign a death pact. There is bound to be some termination clause. So given a few months lead any member of the alliance can fork the code.

So wht if it's a web service? (0)

Anonymous Coward | more than 6 years ago | (#21339785)

Do I have to stop it forking? After all, that isn't distribution...

Forking is not necessarily bad (1)

Geof (153857) | more than 6 years ago | (#21336767)

Forking - and even just the threat of forking - can be powerful forces for coordination. Reducing the freedom to fork tends to centralize control and reduce the size of the community for a project, while also restricting potential innovation. From Stephen Weber's The Success of Open Source (pp. 169-170):

Forking, like speciation, is an essential source of variation and ultimately of radical innovation. Too much forking would undermine the open source process in the obvious ways that people worry about all the time - scattered efforts, duplication of work, incompatibilities, and so on. But to _little_ forking (in other words, too much successful coordination) be as dysfunctional in a different way.

Forking helps distribute influence and the freedom to make choices about development (pp. 180-181):

by creating the right to fork code, the open source process transfers a very important source of power from the leader to the followers. The privileges that come with leadership then depend on the continuous renewal of a contingent grant from the community.

So by preventing forking, Google maintains control. The relationship seems to go the other way too - open communities may tend to fork less (p. 160, 227):

The more open a project is and the larger the existing community of developers working on it, the harder it is to attract potential followers to a fork.

One interesting difference between the Linux and BSD worlds is that the Linux kernel (and associated OS core utilities) have never forked, but BSD's has, at least three times. What makes this interesting is that the social structure of the BSD groups is centralized in a way intended to define clear lines of authority and to prevent forking, while the decentralized and amorphous Linux community takes no such measures. It appears that the projects that open up development the most actually have the least tendency to fork!

Linus is right (0)

Anonymous Coward | more than 6 years ago | (#21336303)

I am with Linus on this one. For the life of me I can't understand what this sucking up to RMS is about. Linus himself does not think GPLv3 is a good thing. So why do people keep adopting it.
Without Linus FOSS is tossed. Not following Linus is dangerous for the survival of FOSS.

Re:Linus is right (1)

Dunbal (464142) | more than 6 years ago | (#21336339)

So why do people keep adopting it.

      For the same reason people keep voting for the same old corrupt politicians?

Re:Linus is right (0, Offtopic)

Kadin2048 (468275) | more than 6 years ago | (#21336571)

I am with Linus on this one. For the life of me I can't understand what this sucking up to RMS is about. Linus himself does not think GPLv3 is a good thing. So why do people keep adopting it.
Without Linus FOSS is tossed. Not following Linus is dangerous for the survival of FOSS.
What are you getting on about?

Look, I know I'm going after a sacred cow around here, but if Linus had decided to do something else with his time instead of Linux, it wouldn't have been nearly as big a deal as you're making it out to be. He was the right person, at the right time, satisfying a very specific need, namely for a freely-licensed OS kernel. In the worst-case scenario, the whole thing would have been set back a year or two, waiting on the BSD kernel. More likely, I think somebody else from the MINIX community might have done it (who knows, maybe Andrew Tanenbaum might have done it himself, had he not gotten in a pissing match with Torvalds). We'll never really know, but the key point is that Linux was evolutionary; it was what was needed at the time, it was there first, and it gained traction as a result. (And at least early on, it wasn't all that great from a software engineering perspective; it was the license that distinguished it from technologically superior alternatives, not the other way around.)

But the fact that the demand for a free kernel existed at all is due to a whole lot of other people, and I'm not sure why you'd give Linus' opinion more weight than you'd give to the people who created the license that made Linux successful.

Re:Linus is right (1)

Seen (58422) | more than 6 years ago | (#21337673)

Regardless of why Linux is popular, the fact remains that it is (arguably) the best known open source project.

Even assuming that the GPL is the reason Linux occupies in its current position in the computing landscape, the points you make (which I agree with BTW) about being in the right place at the right time and somebody else stepping up, don't change a thing. Linux is here and it is important and by extension Linus is here and he is important.

Ultimately, disregarding what Linus says isn't the best way to push adoption of the new license.

What the fuck? (1)

SanityInAnarchy (655584) | more than 6 years ago | (#21337009)

I could go into all the reasons you're shortsighted, wrong, and really a fanboy -- is sucking up to Linus so much better than sucking up to RMS?

But I have a bigger question. What the fuck does the GPLv3 have to do with Android?

Someone slap this tool with -1 offtopic, please.

Re:Linus is right (0)

Anonymous Coward | more than 6 years ago | (#21338657)

get some kneepads!

Could it be??! (-1, Offtopic)

porkThreeWays (895269) | more than 6 years ago | (#21336409)

Could it be that when smart management couples with some of the best engineers in the world you come up with a great idea? I really think Google has shown everything doesn't have to be closed and secret and can still make some really badass products along the way.

GPL solves these problems (4, Funny)

dmoen (88623) | more than 6 years ago | (#21336415)

I agree that the use of the Apache licence is the biggest problem with Android.

If Android had just used the GPL (which prohibits forking), then this problem would have avoided. There are lots of examples to back this up. For example, if Emacs had used the GPL, instead of the Apache licence, the XEmacs fork would never have occurred. And if Gnome and KDE would both switch to using the GPL licence, then the projects would just magically merge into one, and we wouldn't have the duplication of effort and lack of standards that you currently see on the Linux desktop.

Oh, wait... (consults Google). Never mind.

Yep - Article Is Nothing More Than A GPL Troll (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21336607)

It is good to see more and more companies like Google dumping the viral GPL and embracing open and free code licenses.

The kooky GPL is quickly becoming a relic like Perl - both use to be Slashdot favorites but now days are looked upon a discarded relics.

Re:GPL solves these problems (1, Informative)

domatic (1128127) | more than 6 years ago | (#21336647)

What? The GPL does NOT prohibit forking. There are dynamics associated with it that tend to discourage forking but it certainly is not prohibited.

Re:GPL solves these problems (0)

Anonymous Coward | more than 6 years ago | (#21336783)

WHOOSH!

Re:GPL solves these problems (0)

Anonymous Coward | more than 6 years ago | (#21338173)

You missed the sarcasm - "if Gnome and KDE would both switch to using the GPL licence, then the projects would just magically merge into one" was a key tip off for me, and "Oh, wait... (consults Google). Never mind." seals the deal.

The fact that the GPL doesn't prohibit forking was exactly his point.

Free FUD. Re:GPL solves these problems (0, Troll)

Erris (531066) | more than 6 years ago | (#21336691)

If Android had just used the GPL (which prohibits forking), then this problem would have avoided.

The GPL solves the problem by giving you freedom not by taking it away. Forking is not a problem when code is free as you can tell by looking at the hundreds of "forks" in the Debian repository, or if you look at the thousands of distributions that all get along famously. Java has problems because it was not free and two or three companies were able to control it's destiny. Real community developed and owned software does not have this problem because everyone is free to ignore, remove or otherwise fix problems that an antisocial person might add.

For example, if Emacs had used the GPL, instead of the Apache licence, the XEmacs fork would never have occurred.

The XEmacs fork was permitted under the GPL and would not have been a problem if the XEmacs people had been careful about licensing. The problem came when they were unable to verify that all of their code was free. This allowed anti-social contributors to deny distribution of the whole until all of the code was replaced with GPL'd versions.

if Gnome and KDE would both switch to using the GPL licence, then the projects would just magically merge into one, and we wouldn't have the duplication of effort and lack of standards that you currently see on the Linux desktop.

Gnome and KDE are GPL'd, work very well with each other and are good as separate projects. I run Gnome and KDE applications under other window managers without problem. The "Linux Desktop" is far more unified than non free equivalents from M$ and others where you can't be sure the clipboard is going to work across applications or the network. GNOME and KDE have different approaches to the same problems, so the user gets to chose what works best for them. Users can also chose from a dozen other good window managers and frameworks. This is a wonderful thing because one size does not fit all. Once again, this is because the software is free and the community can make things work.

Re:Free FUD. Re:GPL solves these problems (1)

Joe Jay Bee (1151309) | more than 6 years ago | (#21337941)

Forking is not a problem when code is free as you can tell by looking at the hundreds of "forks" in the Debian repository, or if you look at the thousands of distributions that all get along famously.

Yeah, cos Ian Murdock didn't say that he wished Ubuntu hadn't forked so far from Debian as to be entirely incompatible.

Oh, wait. He did. [ianmurdock.com]

*complete shite about Java*

What? What are you talking about?

The problem came when they were unable to verify that all of their code was free.

Bollocks, frankly. XEmacs has always been GPL. The problem came because the FSF wanted copyright assigned to them for XEmacs. So yes, complete horseshit, Twitterris.

The "Linux Desktop" is far more unified than non free equivalents from M$ and others where you can't be sure the clipboard is going to work across applications or the network.

I haven't had a single problem copying and pasting between any application in Windows. Or for that matter, Mac OS X and Linux. Care to explain more about this mythical uncertainty? And no, the *NIX desktop isn't more unified than Windows or the non-free equivalent. Windows and OSX have visual styles which export the global style to all applications that are coded to use it. The *nix world has 2 major APIs and numerous other smaller ones. Slightly different, no?

Re:Free FUD. Re:GPL solves these problems (0)

Anonymous Coward | more than 6 years ago | (#21338893)

The "Linux Desktop" is far more unified than non free equivalents from M$ and others where you can't be sure the clipboard is going to work across applications or the network.

What?! Do you have an actual example of clipboard problems in Windows? Or have you been reduced to inventing Windows problems whole-cloth to support your crusade?

Re:Free FUD. Re:GPL solves these problems (1)

Macthorpe (960048) | more than 6 years ago | (#21340403)

where you can't be sure the clipboard is going to work across applications
Just want to add my non-AC voice to this - why don't you cite your examples of where the clipboard doesn't work between applications and we'll see if we can verify them.

Re:GPL solves these problems (0)

Anonymous Coward | more than 6 years ago | (#21340495)

If Android had just used the GPL (which prohibits forking),

if Emacs had used the GPL,


You keep using that word. I do not think it means what you think it means.

Google is EVIL!!! (for your convenience) (1)

R2.0 (532027) | more than 6 years ago | (#21336465)

Lets just get it over with - all "GOOG is the AntiChrist" posts please file under this one, so as to have a neat and orderly flamefest.

Brought to you by the Lawful Neutral alignment since 1984 - "I don't care what you do, just as long as it's in a neat and orderly fashion"

Android? Non-fragmentation? (1)

SlipperHat (1185737) | more than 6 years ago | (#21336503)

Say it isn't so! It's all these guys [wikipedia.org] can do!

If portable Java fragmented (1)

Burz (138833) | more than 6 years ago | (#21336583)

...it is largely because cellphone mfgs are so tightly wedded to telecoms that they have little interest in offering a platform that attracts 3rd party development.

Open up the network, as Google is proposing, and mfgs have to compete more in terms of coherent feature sets and what 3rd party apps they can attract.

Gist of the Apache license: Anyone? (1)

bogaboga (793279) | more than 6 years ago | (#21336591)

Can a kind Slashdotter educate an ignorant soul about the gist of the Apache license? I sincerely would like to know.

Re:Gist of the Apache license: Anyone? (1)

Anonymous Coward | more than 6 years ago | (#21337359)

BSD
with patent clauses
and a few other restrictions that the BSDers won't go for.

Apache license not interoperable with GPL2 or BSD licensed code, though if the BSD code is included in the Apache license only, then only Theo will throw a hissy fit.

Hype again for nothing? (1)

Iloinen Lohikrme (880747) | more than 6 years ago | (#21336687)

I don't know about you others, but I seriously think that Android is over hyped. Yes, it's Linux based platform for mobile devices, but so what? There's already Maemo, but you don't see it hyped to death. Yes, the Android can also run Java ME applications, so what? All mobile phones can run Java ME applications...

And one last thing... there are no devices yet! No nothing! And you know what, there probably won't be even many of them. If you look at the alliance that Google has put together, the only serious vendors are Motorola and Samsung. But hey hey hey, Motorola just bought half of UIQ from Sony-Ericsson. UIQ is an user interface used primarily by Sony-Ericsson on top of Symbian. How serious Motorola is about Android when they have just made an serious investment into an Symbian company? And Samsung... they are just as much flip flopping as Motorola.

You know I'm not saying that you should not discuss about Android or not develop applications to it. I just say that Android seems to be again an over hyped thing. If I would be developing mobile applications running native in a phone, I would be damn sure that there is adequate installation base before jumping in, otherwise it could be very well be just seriously wasted time.

Re:Hype again for nothing? (1)

ElBeano (570883) | more than 6 years ago | (#21336999)

I'm guessing you are posting from another country. Japan, perhaps? The point isn't the hardware. The point isn't even the software. The point is creating a different paradigm for phones and service in a country with an oligarchic mess, one that is open and free of extraordinarily ridiculous limitations. In this environment, it really only takes one hardware manufacturer with enough courage to step out of line to shake things up.

Re:Hype again for nothing? (1)

AmericanInKiev (453362) | more than 6 years ago | (#21339613)

Right (ATTN MODDERS see parent)

Apple got Time's invention of the year nod-- not for the device but for the breaking of an anti-consumer technopoly.

This isn't about Google /choosing/ linux, its about the calvery finally showing up to address the crippling backwardness of a corrupted FCC/MEN/Telecom bloc. The Linux, apache, GPL, fork driven is hopelessly beside the point. This is a political seachange,far more than a technical one.

AIK

Re:Hype again for nothing? (2, Insightful)

m2943 (1140797) | more than 6 years ago | (#21337687)

How serious Motorola is about Android when they have just made an serious investment into an Symbian company?

Motorola is already shipping lots of Linux phones (far more than Symbian), but they have almost no developer community. Android might be the answer to their problems.

Motorola just bought half of UIQ from Sony-Ericsson

I think UIQ is a short-term fix for them. I also don't think UIQ is going to make it in the long term. For Symbian, Series 60 is going to be the de facto standard.

Java is simple to decompile (1)

gilesjuk (604902) | more than 6 years ago | (#21336969)

So long as the person fragmenting the platfrom hasn't used a Java obfuscator then it would be incredibly easy to decompile the bytecode back to Java source.

Re:Java is simple to decompile (0)

Anonymous Coward | more than 6 years ago | (#21337237)

They compile to Dalvik bytecode not to .class, retard. I'm sure it strips debugging strings because they would be useless once on the phone.

Re:Java is simple to decompile (2, Informative)

AKAImBatman (238306) | more than 6 years ago | (#21337303)

it would be incredibly easy to decompile the bytecode back to Java source.

#1 Who cares? Only young'uns with little experience with how the industry works actually care about someone "stealing" their (incredibly boilerplate, easy to duplicate, hard to integrate into my own project) source code. Did you know that it's easy to "decompile" your HTML, Javascript, Actionscript, PERL, Python, Ruby, Shell scripts, and even Assembler too?

Oh noes! Do not want!

#2 The "Java" that runs on the phone isn't Java at all. Java is used as a development language, and is actually compiled down to Google's Dalvik VM instead. Thus while it will still be decompilable (there's no such thing as code that can't be decompiled) it might be made more difficult by the non-standard bytecode.

Prize money (1)

u01iz (164116) | more than 6 years ago | (#21337103)

Sorry, that I go to a different subject, but do I miss something?

(50 * $25.000) + (10 * $100.000) + (10 * $275000) = $5 million
Where are the $10 million ???

Re:Prize money (1)

uhmmmm (512629) | more than 6 years ago | (#21337439)

There are two stages to the competition with the prize money split evenly between them. Details for the second stage will be released later.

Wait a sec... (1)

LingNoi (1066278) | more than 6 years ago | (#21337797)

'All of the partners have signed a non-fragmentation agreement saying they won't modify [the code] in non-compatible ways
To me that reads as they could close off the code and fork it into a proprietary monster as long as everything is still 100% compatible with the Google framework (user apps run correctly, etc).

So you still can't modify the source code on your phone and run the changes. I bet they are still going to lock down the phone software with DRM (Example.. Motorola A1200)

Developers, Developers, Developers (1)

un1xl0ser (575642) | more than 6 years ago | (#21338399)

"We've built some interesting applications for Android, but the best applications are not here yet, and that's because they're going to be written by developers,"
It seems that most of Skyne^WGoogle's code has been written by robots so far. WATCH OUT!

Toolkit Fragmentation != Device Fragmentation (1)

efornara (1165681) | more than 6 years ago | (#21338405)

Wow, that was quick. I posted an hour ago on the other thread about my worries about Device Fragmentation.

IMHO the differences in the J2ME API is not the main issue for a developer. Differences in screen size, processing power and keypad layout is much more important.

Is google going to force 240x320 (or whatever) on everyone? Is it going to prevent a manufacturer to heavily customize the look and feel? Are we going to have a split between devices having a touch screen and devices not having it?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...