65 posts • joined Friday 19th March 2010 12:59 GMT
Pulse is Infrare, So Silver Paint Probable Won't Make A Difference
These lasers operate in the infrared region where silver paint absorbs, so it's not going to make any difference how shinny the silver paint is in the visible region. A Gold coating may work better but still you would need a surface with a reflectivity of 99.99...% for no real damage to occur.
Dart -- Great in theory, but doomed to fail?
After keeping up with Dart progress for the better part of it's lifespan, I can see why hard core developers would like the concepts it bringing to the table for web developement. However, aside from the performance gains, most of what dart would deliver can already be done with existing stuff. For example, for structured development GWT/GXT presents a much better option since all the knowledge, tools, middleware etc ... are already entrenched.For more basic needs, there are enough JS frameworks and planned language additions to fit most people needs.
So the question remains, is there enough developers from those 2 camps who will by into Dart?
Recently had to do a web based manager app, and did it using GWT/GXT, and the results were great. Being able to use the full IDE support for Java, compile time checks, and generics, definitely reduced the time to market and increased the maintainability of the code. There is also the fact that my backend and frontend code was more or less seamless connected which further reduce the amount of coding needed.
Performance is the only area where there is a slight trade-off, but I can leave with that. I just hope the Dart language takes off soon and make this approach to JS based apps the norm.
Codename One seems to have a much better tool for doing this, or they will once the program matures.
Maybe all those adobe AIR developers will finally materialize?
When I first read about BB new OS, I went looking for what they add to offer their current Java devs. Answer, nothing! After scoping my Jaw of the flaw, can't realize no one was driving the ship at that point at RIM.
The only thing that can save RIM now to get mass developer interest is to OS 10, is to implement Java SE embedded (http://www.oracle.com/technetwork/java/embedded/overview/getstarted/index.html?origref=http://www.oracle.com/technetwork/java/javase/downloads/embedded-jsp-135769.html). This is not Java ME that's in the current BB OS, but a full Java SE stack with some optional stuff removed. They would probable just have to implement a mobile swing profile for graphics, or built something on JavaFX, and hardware access API. In any case it's would get a bunch of Java devs on onboard, since the dev tooling will be what they are already used to.
Slap winXP or win7 on that baby, I will be first in line to get one!
One Word ... DOA
It always amazes me that companies still push the whole HTML5 for app development, when all attempts so far have led to utter failure (Web-Os, RIMs new OS, Chrome OS, and Apples second gen iPhone?)
What these guys fundamentally don't understand is that though there are a lot of html 5/JS "developers", most of those only do relative basic coding (no Unit/Integration testing, MVC etc ..) Anyone who has done serious programming, knows the value of such technology when you talking about relatively complex tools. Moreover the tooling for "native" coding (Java, Object C, .Net) is simple a lot more mature, and standardized. There is also, the issue of actually having a set of standardized APIs for stuff desktop devs take for granted (UI, I/O, Network etc ...).
A good take on allot this is is in a talk by Gilad Bracha, about Google's Dart. Now the focus is on Dart, but he gives a good overview as to why you really need structured programming/good tooling) if you want to do complex web apps that are maintainable by none code Ninjas.
Tsunami of Failure, that is
RIM's new OS dead. By saying f*ck you to their current Java devs, they basically drove yet another proverbial nail in the coffin.
If I was RIMS board, I would be pushing for buyout by M$.
Re: A couple of "really not corrects"
Hmmm, you clearly not a Java developer if you think it would be a good idea to run the full J2SE stack on a smartphone (going back 10 years or so). It might be cool, but no, you have to work with subsets of the main J2SE platform. Also I am not sure how that would be fragmentation, It's just good platform design.
Google, and by default its' Partners are in Trouble
As I said when this case was filed couple years ago, Google should just have licensed Java and be done with it. In the end, Android would look exactly the same, aside for some additional J2ME stuff added in. Also, with time, the J2ME and Andriod APIs would have likely just been merged.
Aside from the legal issues, a more interesting aspect of the case to me is the fact that Google seems to be one of the few mobile platforms developers who actually did their research to see what SDK would work in that space. If you look at RIM, HP (WebOS), and Nokia, all the other mobile Linux distros they all pursued some other brand new, and unproven (in the sense of mass developer uptake, not technical merits) "html5/css APIs", or worst some native C/C++ library like QT (nthoign wrong with QT, but number of mobile developers who would know QT is very low) etc ...
Kudos to Google, and Apple for that matter, for realizing that success in the mobile space has less to do with developing a sexy, new set of APIs, but more about leveraging what's already being used in a similar capacity. Or a better way to put this "first and foremost, appeal to lazy developers who don't want to lean yet another language/APIs, just for some potential incremental benefit".
So rather that providing a single (Java based) API based on your old API, but improved for you new OS. You instead provide 3 APIs for developers to target. Well given how well that has work for the Playbook, can't see why it wouldn't be a success and your smart phone market share goes to 99% this time next year.
BB mistake with their new OS is not having a Java API to code against. Not sure who was the idiot in company who decided to push the AIR platform for apps (Adobe isn't even pushing that any more) on new OS, but they should be fired.
Its the API's That Matter!
Right now in mobile, there are just 2 APIs that matter most to developers. Java based of Andrioid/RIM (older OSs), and Object C base of iOS. In a few years, then maybe win phone API will also be more attractive.
With WebOS, there just isn't an attractive API to code against, which is a real shame seeing how earlier version of WebOS did have a Java API in there. HP/Palm just decide to promote the whole HTML/CSS/AJAX API, which hasn't proved attractive to developers. Something to do with native apps can be more readily monetized. Rim is also facing the same issue with their new OS.
In short, developers are just not interested in learning some radically different API if the device/OS market share is not that high no matter of good the OS is ( i.e. low return on investment).
As such, I don't see WebOS going anywhere, open source or not. Much like Linux hasn't gone anywhere on the desktop (speaking as avid Linux user for the past 14 years).
Good point. People should really ask themselves, if HTML5 is so good then why is Android's and iOS main APIs are not based on it? As a matter of fact, only OS which did have HTML 5 based API is effectively dead (WebOS),
What I have noticed is that developers who only do html/css/AJAX stuff really don't seem to understand what's needed to do a complex of applications. They take a look at web mail client or something, and think anything can be done in ajax/html. Those of use coming from desktop app world seem to have much better idea of the limitations.
With the exception of C in you great languages list, what exactly is the adoption of the rest combined? Less that 2% I would guess. Being a great language from the stand point of design doesn't mean it worth the investment is using it if some other general purpose, more widely used language exists.
Anyone remember when RoR was suppose to to kill PHP? Years later, PHP is still going strong while RoR usage is pretty flat, said for some high profile sites.
It's the APIs Stupid
The reason why all these mobile OS have failed so badly is because of the Language/APIs they decide to push. If you look at Andriod, and from recent emails made public from the Oracle/Google lawsuit it's was/is clear there isn't many languages/APIs that make sense in the mobile space. Yet time and time again we see companies coming up with these new programming Languages/APIs for which no significant programming community exists. Now WebOS was JS/html/CCS based, but to make that work, they had to build proprietary APIs which of couse few developers are going to take the time to learn if there wasn't a big uptake of the hardware. I see the same thing with BlackBerry new OS: Adobe Air ???? Why?
It's pretty much Java and Object C for now, since that's where you have the biggest developer pool exists.
Cloud it Out?
Why don't they simply rent this things out to average people? I caculate for about 400.00 dollars and ~ 8000 people paying, they might turn a profit. Now, not sure what cool things can be done, but I am sure someone can think of something.
Maybe combining renting with launch of amateur satellites sent up into space. I can see trying to send home built satellites to Mars etc ..., and using these babies to communicate with them. Would be interesting to see how far they actually make it. Cost of lunching would be an issue, but we just need find company to do so relatively cheap, or just use a bunch of model rockets.
J2ME licensees can ship what ever other API they want
Once you have a J2ME license, you are free to ship what ever other APIs you want on top of that. You only have to implement the APIs need for J2ME to satisfy the license agreement. For example, RIM ships a standard J2ME VM, but they add a lot of their own APIs on top of that. If you look at Andriod, is essentially the same approach in that they do not really have a full fledged Java 2 platform since no Swing etc., but if they simple implemented the J2ME API then they would be in compliance with the J2ME license.
My prediction is that Oracle Google reached an agreement in which the Andriod APIs becomes core the next mobile Java platform. Both sides would be foolish not to do this.
Relevance to Oracle Lawsuit?
This may help Google with their Oracle lawsuit. Since Motorola is a J2ME licensee, then as a result of this purchase, Google becomes one also. The still would have to pay damages and such, but at least they would now have a license to ship Java in mobile devices.
As they should!
Unfortunately for Google, the more successful Andriod is, the more they will have to pay out. Oracle should have really bought Sun when they had the chance, now their best option is to settle this ASAP.
It always surprising me how people who come from a HTML/JS background always believe you can do all sorts of complex apps using that technology, while those of us coming from Java/Swing who do AJAX stuff quickly sees that it's a bad idea to go completely that direction. What's needed is a good balance, and once of the best I have found is GWT.
Wrongly Focus on Techonology and Not Sustainable Business Model
I Agree with you that what you discussed sound really impressive, but at the end of the day, no matter how good the technology is, if it's tied to dying platform then developers simple won't use it. To put it another way, there has to be the potential to easily monetize software and have a sustainable business model.
Moreover, for any platform to be a success there must be large pool of available developers who can quickly use their skills to code for the platform. With the Java, that is the case with AJAX/HTML that clearly is not. Odds are, someone who does AJAX webapps is going to have pretty hard time understanding OO principles and APIs that all major mobile OS embrace.
Just look at the three most popular mobile platforms and those that are failing.
iOS => Object C
Andriod => Java API
Rim BB => Java API
Rim Tablet => Adobe AIR
WebOS => AJAX/HTML/CSS
Now you can always do native coding on any of those, but from a business point of view, unless you are Apple, then having a Java API seems like the only viable approach for having a successful mobile OS platform currently. Even Rim and HP seems to be coming to that conclusion seeing how they now want it to run Andriod Apps.
Another DOA Open Source Product
Hmmm, don't see much point in this with Android around. And oh yeah, android uses Java API for development. What does this use? Maybe something cool and revolutionary like AJAX/HTML API's? Oh wait WebOS tried that and dev support has been dropping fast.
Any serious developer knows this, and that's why even with all the issues Java has, there is nothing that comes close when it comes to standard set of cross platform APIs that a ton of developers know. Why do people think that Android uses a Java API and not native C, C++, or even AJAX.
Also, unless Redhat is going to spend billions marketing this, then I can't see it going anywhere.
Hmmm, this is going to be as successful as Zune. WebOS is more or less DOA as far as I can tell. No developer ecosystem and competition is just to far ahead. What exactly does WebOS offer that Andriod/Apple/Rim can't?
This is surprising that none of these coders choose given all the web 2.0 talk these days. I guess when it really comes down to it, programmers in the know are going to chose the right language and platform for the Job.
Greedy lawyers at Work Again
Let see, the lawyers stand to get millions if this is given class action status and all users would get is, well maybe the ability to install Linux. Something that almost no ps3 users care to do to begin with
Not Super Computer?
By this reasoning then an Linux cluster is not a super computer either (which is what this is) since they are just commodity hardware. I am sure that thing well in the TFLOP range. Does any one have those figures.
Maybe to Late
RIM should have had this Java SDK ready to go from the start. This would have made a huge difference in developer interest. I guess it's apparent to them now that the whole webkit API thing just doesn't attract the number of developers they thought it would. You would think they would have know this from Apple (web based programming was the only way apps could be written for iPhones before) and the lack luster developer interest in WebOS.
Another DOA tablet
RIM is a good example of this. In their BB devices, the API is Java based, in there tablet it's not. And what has happened with that device? Simply, they now have to try to bring over the Andriod Java API in desperation. One wonders why they just didn't recognize this in the first place and ported the BB Java API over to the device. Now that would have been the smart thing to do. However, I guess this is what happens when Marketing folks blinded by web 2.0 talk end up making software decisions. You don't ever here apple talking about web 2.0 is the way to go with iOS.
Don't Blame Them
Oracle is a business, and from what I can tell it makes little sense for them to keep funding stuff that's not their priority.
It's simple, if you a RoR person use another IDE, I hear Emacs is really popular with a lot of those users. Also, if people really want it supported in Netbeans, then they can add it in themselves, after all it's open source.
DOA, Not going to get strong developer support!
No matter the technical merits of this product, it's DOA because developers are simple not going to invest in this platform when there is Andriod, iPad, and Windows to code to.
This will suffer the same fate as blackberry tablet device, unless of couse they do the smart thing and also ship a Java SDK for it.
That's Just Wrong Sprint
Just switched to Sprint in the neck of time it looks like. In any case wouldn't charging by usage be a more fair way to handle this. For example I have a BB, and really only use for email. text messages, and of course phone calls, why should I pay 10 bucks more because they finally realized unlimited data plans are just not sustainable as smart phones become more computer like?
Miss my point
All those things you mention would be best done as a native apps, and that's my point. You could do them as Java Applets very easily (There was a quake port to java and there are voice recog java software out there), but that's not going to make much sense from a business point.
Very little reason any one would want to have those things run in a browser. The point about applet is that, if you compare performance of the JVM on modern hardware to that of native code the difference is minor for most task. Even google recognizes this, and that why the are basing NACL on reuse of native code that already exists and not rewrites. This is the same thing with JNI(access native libraries) and Java.
Can't see this being successful
Unless, Google makes this a browser natural technology, don't see this being successful. Most of situation you would use this in can already be done using Java. And if you really need performance then my guess it native apps will still be the way to go.
Those anyone have any comparison between performance of a realistic piece of code in NACL and a Java applet? I bet the applet competes pretty well, and least well enough as far as the end user is concerned.
Not Really, GWT will always be based on Java
If you are Java Developer and use GWT (I am doing so currently), you quickly realize that GWT only really make sense using Java. Here is why, a big part of what makes GWT appealing is because the huge army of java developers out there get a very familiar API/environment to develop JS webapps in, and the front and backend code are all in the same language. This is the same reason Andriod uses Java, and not because Google felt Java is the best platform out there. When it comes to platform success, number of developers matter.
Basing GWT on some other language/platform (except maybe .Net) simple wouldn't make much sense.
Talk about DOA, if am getting netbook I might as well get windows 7 on it, instead of some half functional OS. We have seen this with Linux netbooks already, users want Windows on those things so they can run the apps the know and love. Chrome OS, it like a solution looking for a problem to solve, frankly.
P.S. I have been a Linux user for the past 12 years, but on my notebook I want windows because I like the fact I don't have to fight to configure anything and all the apps I need, run no problem. I still can't figure how to get Skype to work with webcam on my Linux box, and not even going to bother.
DOA, No Java SDK
Wow RIM, talk about shooting your self in the foot by not making the Java SDK central to this device?
You are basically telling all your BB developers that they are second class citizens on this device. Moreover, there isn't any word on whether those apps would even run on that device. This is like the IPAD not being able to run iPhone Apps and all the apps would have to be done using a different SDK.
Maybe I missed the part about your app stores having 100000 apps so you can afford to loose a few developers.
RIM you need all the developers you can get if you hope to remain relevant in the next 3 years.
What world do you leave in?
Java is already all the things you mentioned. Nothing stopping you from rolling you own JVM, running Java natively, or what ever else. The issue Apache has is that they are not allowed to use the TCK to officially sanction there VM as Java.
Also, there have been a few open source JVM in the wild for a while. but they never caught on for a very good reason. When it comes to support, developers target the official JVM. There is no practical reason to target a non-sanction VM unless ofcouse you coding to Andrioid.
Also, JavaME runs on more handsets than any other VM. As a matter of fact, Blackberries API is based on J2ME so I can where you say its rubbish?
I don't know why RIM is pushing this web app approach when no company has found success with this approach in the mobile devices. Palm webOS failed (we-based apps), iOS: native apps rule, and Andriod: native apps rule.
So why take a failed approached when you already have a solid Java API to work with.
Another thing people don't realize is much easieir to monetize native apps rather than web apps.
Oracle Lawsuit Probable has Something to Do With This
Saying they will never offer an Android phone is all well and good since they claiming that they can't be sued by oracle because they don't make any Android phones. Now if you are going around waving a Google branded Android phone then something is not adding up.
Hmmm Why Don't This Apache Guys do Something Useful
Rather than spend endless resources implemented a JVM (Harmony) that no one really uses (Android doesn't count, that's Google's own implementation) they should probable take up the goal of implementing a rock solid JVM for future Mac OSX. Now that's something I will be willing to get behind.
They should leave JCP and let Oracle deliver products that those of us who actually code Java for a leaving get the next version of Java ASAP.
You clearly don't get my point about J2ME!
Since J2ME in just a subset of the standard Java 2 API, then anyone who license J2ME simple have to implement those APIs as part of their stack. What ever else they choose to build on top of that and how they implement it that's there business. Hence, Google simple had to provide J2ME API (like RIM) and continue pushing their own API (like RIM).
And about j2ME, I can guarantee you that their are more devices running that than iOS and Andriod combined. It's just that the network operators locked down their phones to a point they made it very hard for small developers to target those devices without paying them somewhere along the line.
This is Google Fault!
Google should have done the smart business thing and just license J2ME and build their API on top of that. There would be no difference to developers or users. This is basically what RIM does. I can code a J2Me app on RIM or use their APIs.
Now they will just have to end up paying Oracle for patent violation and must get a licence. Moreover, any company that's shipping an Android device can also be sued by Oracle.
In short, I wouldn't be investing in Android long term unless a settlement is reach fast since any company using Andriod would be liable. And the more devices shipped the more liable you become.
Now, some of you may say why not just do a clean room implementation. It really doesn't matter they will still be liable for all Devices shipped with Andriod until the clean room ships. It's actually much cheaper just license J2ME.
Bad Business Discission on Part of Google not to license J2ME
I said it before, Google should just license J2ME and build their API on top of that, like Blackberry does with their devices. To the end user and developers, there would be no real difference. Consumers might even benifit since they could run any J2ME software without first transforming it.
Now, they going to have to pay a boat load of money to Oracle, and the greater the success of Andriod the more they pay.
Some of you may say, well why not just do a clean room implementation. Doesn't matter, you still have to pay for all infringing devices sold. Much cheaper to just reach a licensing deal before Oracle decide to start going after the manufactures (they have every right) for money also.
Java VM should be central.
- Product Round-up Smartwatch face off: Pebble, MetaWatch and new hi-tech timepieces
- Geek's Guide to Britain BT Tower is just a relic? Wrong: It relays 18,000hrs of telly daily
- Geek's Guide to Britain The bunker at the end of the world - in Essex
- Review: Sony Xperia SP
- FLABBER-JASTED: It's 'jif', NOT '.gif', says man who should know