Slashdot Mirror
Sun Is Porting Java To the iPhone
krquet notes an InfoWorld article on Sun's plans for the iPhone. After studying Apple's newly released SDK docs for 24 hours, Sun decided it was feasible to develop a JVM, based on Java Micro Edition, for both the iPhone and the iTouch. An analyst is quoted: "I think going forward, with the SDK, it takes out of Apple's control which applications are 'right' for the iPhone." The article doesn't speculate on how Apple might to react to such a loss of control. "Apple had not shown interest in enabling Java to run on the iPhone, but Sun plans to step in and do the job itself... The free JVM would be made available via Apple's App Store marketplace for third-party applications."
Oh the irony
What Loss of Control? They've got final right of refusal on everything that goes up, and they hold the only means of distribution. If that's a loss of control, I don't want to know what it'd be like when Apple is totally in control.
Sure, possibly security or performance. More likely, NIH.
Now, this is certainly lawyer speak and probably covers more than they'd like - I very doubt they'd care if you used some of your own library code to script custom UI elements in, say, LISP. But it is certainly their intent to stop people from just republishing all the iPhone APIs under a new wrapper, then selling an "Interpreter App" that downloads and runs "jPhone Apps" (aka "data" for your special iPhone app), thereby bypassing all their controls. It certainly seems to rule out a JRE in the sense that we've used to, and from Apples point of view, this is correct (no judgements from me on whether this is a good thing or not).
Now that the Mac is overrun with terrible ports of Java apps with Windows interfaces and menus at the top of windows instead of in the menubar, we can send the iPhone down the same road! Horray for inefficient power wasting slow ports! But at least it's easy to go cross platform with Java, as long as you don't want it to look right or run fast. Ok, I'm a tad cynical. We can hope that iPhone users will demand a higher standard of usability than the "hey, I bet we could make this run on Macs with a few hours of work" that are fairly common in the software market. Otherwise it's going to be overrun with bad versions of apps thrown over from other java capable mobile platforms.
It seems like the iPhone is fully-featured enough to completely support a full, first-class JVM. Why are they porting a crappy pared-down Micro Edition version? That limits a lot of developers in what they're able to do. Maybe that's all they could get Apple to agree with?
Dlugar
Computer Go: Writing Software to Play the Ancient Game of Go
I strongly respect anyone's right to do anything they want. However, I don't see the logic behind this move - or equally, behind anyone writing free apps for the iPhone via a jailbreak app.
The outcome is that they are making a platform with a high degree of Apple lock in more attractive to consumers. When version two comes along with more effective control mechanisms users will be tied to Apple's integration services, and the tenuous foundations of a business model standing on some else's shifting sand will be destroyed.
So why do it? It's bad enough choosing to write apps for Windows, but at least there is some logic given the size of the user base. The iPhone user base isn't very big (compared to, say, s60) but it _will_ be if it becomes the best option in town because everyone has helped Apple make it the best tool around by writing software for it. Then a later version can close you out and bang, lay off time is here again.
Beep beep.
...Or they thought it would be bad for business. Think about it, what's implied here is that Sun has only the publicly available information on feasibility of a JVM in iPhone. I.e. they've not had serious discussions about the JVM implementation (with or without the public SDK). Either Apple has not recognized the value of JVM in iPhone, or they see it as threat to them and are not pursuing it in purpose.
is that Apple is off the hook for anything that fucks up with Java Apps (and Sun knows it so look for very conservative Java apps to get rolled out first.)
That opens up the iPhone (and iPod Touch but who cares about that minority,) for corporate deployment and all those goodies without exposing Apple at all.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
For one thing, if iPhone developers choose to just use Java, then the applications could run on other phones relatively easily.
I strongly doubt that they see it as a threat. If this was the case I think they would be pushing more strongly against Sun's stated intentions instead of their current ambivalence. In regards to them not seeing the value, I expect that they must have considered it; you can't just *forget* about Java.
I wonder how fast java's going to be on the iPhone... I mean, well, you know... java... speed... those two combined...
Java ME is already part of the default platform for DVB/ATSC (European / N American cableTV clients), most mobile phones, and Blu-Ray (so all HD videodiscs). When it's on the iPhone, JME will get high visibility as a development platform (DVB/ATSC/BD-J and even most mobile phone development is nearly all done by a small niche of developers).
The same JME applets will run on any of those devices. In fact, the Java classloader lets any running Java program load a class from any other Java device connected by the network, load it and run it (safely) locally.
I wonder whether having lots of developers targeting a very featureful terminal that can be used as a "universal remote" for all these personal devices will finally offer some good applications for Java's ability to transmit the same objects around all the devices. Like the GUI objects installed in each device being available on any other device, to control the "home" device in familiar terms. Or any other of these.
And if that "mobile objects" platform does indeed come of age, will even Sun's "JavaSpaces" finally have a use for its far-out platform?
Will all of Sun's "useless" Java platforms from the past decade+ eventually be recognized as "visionary"?
--
make install -not war
...third-party apps can't run as a background process? From the documentation: "Only one iPhone application can run at a time, and third-party applications never run in the background." Limited resources or not, it seems like this is going to end up like the older versions of PalmOS.
Here's a short section of the interface design guidelines as released by Apple:
So when the JVM is used by an application, it'll be launched/terminated each time the app is switched to? I'm willing to bet that will make apps that leverage the JVM almost unbearable to use.
Not only that, maybe Apple has even known all along that they wouldn't have to do the work - Sun, or someone else would take care of it.
I think this is great, used to think that I'd had enough of j2me but now I'm finding myself interested to tinker with this gizmo. First the sdk and now java, good times ahead.
Apple uses lots of software that they don't develop in house, NIH has absolutely nothing to do with it. Apple wants to keep the quality of applications high, and Java applications are slow, ugly and integrate poorly with the rest of the system. Java on the desktop is dead outside of horribly conceived enterprise business applications.
P.S. The Apple SDK is actually quite nice. Compared to the standard Java API it's a fucking masterpiece of computer programming.
Others have offered reasons why Apple didn't bother with Java (such as wanting to maintain control or not liking its performance), but I think there's a much simpler reason: Apple's products succeed because they are polished. The graphic artists make sure everything looks nice, the UI designers spend time on special touches, and there is a lot of effort that goes into consistency and uniformity.
So, I think Apple didn't bother with Java simply because it didn't fit in with this. They have their own UI, and Java apps either won't look the same or will require a lot of effort to get there. That alone is enough to make Apple say "why bother?" when it already has one language that does the job.
With all this new porting and the release of iPhone SDK, wont this make the iphone even more insecure than it already is.
"It certainly seems to rule out a JRE in the sense that we've used to, and from Apples point of view, this is correct (no judgements from me on whether this is a good thing or not)."
No, no it is not. It's a Bad Thing.
But I'm sure it will stop viruses and malware on the iPhone, seeing as that is such a huge problem with Windows Mobile, Symbian, PalmOS and portable Linux installations. Oh, wait.
Okay, it will ensure that only the highest quality software that fits Apple's guidelines, including possibly design guidelines, and thus provide the user experience that Apple holds so high, will be available.
Well I guess that's true enough, but if I want to install CrashOTron2000 with a godawful UI on my iPhone, then who are Apple to tell me I cannot? Who are Apple to tell the developer that they cannot even offer it?
Don't get me wrong, I wouldn't want Random Application X messing around with the radio either. And, from Apple's point of view, VOIP over the cellular network may indeed be unwanted (by the telcos). Any other application that could, most certainly, render the thing useless or degrade its performance in standard use is not very nice either. I can even see a ban on the first one, and a moratorium on the second one, but to blanket-ban any application willy-nilly when they don't like it - even if the end-user may very well love it - is, imho, a Bad Thing.
If the only way to get around Apple is to provide a wrapper for the APIs, which they very well could code so that calls to the radio etc. are -not- exposed (not even implemented. Then again, are they even implemented and exposed in Apple's own SDK/APIs?), then I think it would be a Good Thing for it to be available. Any end-user complaints would have to go to Sun, and not Apple, for support / I-bricked-my-iPhone-you-buy-me-a-new-one crap.
comparing it to the Java API (and have you seen the really useful JavaDoc... :-( ) isn't setting the bar very high.
How long before Amiga, Inc announce that they'll have the next AmigaAnywhere running on the iPhone...
Karma Whoring for Fun and Profit.
I've seen a lot of speculation about the iPhone being somehow insecure, but most of the "security issues" I've seen have been from companies who want to sell security software, or that want to lock down company owned phones. The former can be dismissed as sales material, and the latter are at BEST irrelevant to most users.
Unless you're talking about jailbreak? That's not a security hole, that's an advantage. I wish I could jailbreak my own cellphone, since Sprint has locked out most of the functionality that led me to pick the model I did.
May I recommend doxygen for your documenting needs. Does what javadoc can do + more (can create 'call graphs', works on several languages, and outputs to html, pdf, manpages, rtf etc etc). It is truly an impressive piece of software.
Lack of planning on your part does not constitute an emergency on mine.
With Java, one can make one's program look and feel different from other Java programs, but that isn't required. All Sun has to do is make a look and feel similar to the iPhone's and as long as a developer doesn't specify a different look and feel, it will be consistent from app to app.
If Apple hasn't been proactive in trying to port Java to the iPhone I expect they must have a good reason
Control.
Apple wants to control application access to the iPhone.
I've never been a huge fan of the iPhone, and Apple's continual foot-dragging over opening it up is getting increasingly old.
Here's how it works:
* Take something the press has forgotten about because it basically gets no press. Find a product that the press is buzzing about.
* Somehow tie the thing the press has forgotten about to the hot new thing.
* Remind the world your old forgotten thing is relevant and still exist.
* Fade back to obscurity shortly thereafter.
AFAIK, Apple thoroughly customized the version of Java that comes bundled with OS X so as to make it look consistent with the rest of the platform. It certainly doesn't look half as jarring as it does on windows.
Just note that Azureus uses a non-standard Java UI API called SWT. This was developed by IBM for the Eclipse project and it is significantly biased towards Windows, and is more of a fish-out-of-water on other OSes.
${YEAR+1} is going to be the year of Linux on the desktop!
That's great and all, but a lot of us are still waiting for a decent JDK 6 and Java SE 6 releases for Leopard!
- Aetheral Research -
I'm sure there is some overhead, but this is the micro editon which is optimized for small devices. It's a sub-set of the language, no garbage collection, no floating point, etc. and a much reduced standard library. All of this will greatly simplify the runtime environment.
Also, JME doesn't do some of the ridiculously complex runtime optimizations that standard java does, most of which are about improving execution speed at the expense of... everything else. This includes startup time and memory usage which is rather impressive on standard java (but sort of getting better with time).
Logi - I can do anything, but not everything.
I can see you're wholly unfamiliar with Java.
The only part of the Java API that is worse than the Apple SDK is the GUI part. If Sun completely threw out Swing and started again from scratch (or Mac Java developers used Rococoa) it would be brilliant. Java's support for everything else-- from multithreading to data structures-- makes Objective-C look like the 30-year-old grampa it is.
And Java is extremely fast-- almost certainly faster than Objective-C, which suffers from the worst of both worlds in performance: static compilation and extremely dynamic linking. These days, dynamic compilation (which has available to it runtime and usage statistics) can optimize much more efficiently than static, leading to higher performance code. And Objective-C's extreme approach to dynamic linking means almost nothing can be inlined or statically optimized across message/function boundaries.
Finally, the iPhone/Touch has some specific hardware to help make Java fast. Apple's just ignoring it. But Java on the iPhone using Apple's GUI library would be extremely cool.
E pluribus unum
It could have been EMACs. :D
That's some very interesting opinion, but the fact remains that there are relatively few large-scale desktop applications written in Java, and the ones the do exist are known for their poor performance and excessive resource usage. Java Foundation Classes have largely solved the "clunky" UI problem, at least on Windows, but significant issues remain for desktop Java.
.NET, Cocoa) only one has been used successfully to consistently deliver large-scale desktop applications to consumers.
Regular OS X users actually demand Cocoa applications. I can't imagine Java ever reaching that level of acceptance. Of the three big dynamic languages/frameworks (Java,
My jailbroken phone literally stopped working. Performance definitely suffered and the extra apps were not worth the trouble. At this point I'm more than willing to patiently wait and only use Apple vetted apps through the app store. Besides, I don't think it will take very long for whatever authentication method to be broken that Apple is using to prevent SDK apps not purchased through the store to run on the phone.
It would be more exciting if Sun was porting Flash...
Performance? A stretch but I guess it's possible. Security? Naahh... this is Apple, remember.
There's already a port of Java to the iPhone. To run it on a jailbroken iPhone, first install Cydia (http://www.saurik.com/id/1) and then install iPhone/Java.
It even comes with a simple demo Java app that uses the iPhone frameworks!
Admittedly it's pretty primal, and there's a long way from "JVM runs" to being able to run J2ME app's (like, for example, a GUI layer). But it's still really cool!
Enable 3D printed prosthetics!
then how is it going to get on AppStore? They are the gatekeeper.
If you are talking about some sort of hack, then how is that different than all of the other hacks? I suppose it might make the iPhone easier to hack, but how hard will it be for Apple to put out a firmware update every three months or so that wipes out anything related to Java on the phone because it violates terms of service? Will serious users put up with that kind of instability?
If Apple doesn't want it to happen, it ain't gonna happen.
This is a non-issue.
sorry but you are wrong.
if you have a java application and want the menu bar to appear at the top of the desktop (like all other OS X apps), then simply invoke the jvm/java app and pass the following system property as a JVM arg:
-Dcom.apple.macos.useScreenMenuBar=true
as described here
its not that complicated....
to see if apple lets this pass. as i understand, they have final say as to whats made available in the appstore, freeware or not.
should be a nice test of how control freak apple wants to be about the store.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
OK I'll bite == Keep in mind I am more familiar with Java than Obj-C but here I go:
It is my understanding that Rococoa is a wrapper that allows Java to call Obj-C library routines. I guess this would put it in the same ballpark as IBM's GUI library.
I don't know what you are talking about here. All languages support data structures, and Obj-C is no different. I assume you mean built in library templates, and Java may have an edge here. I don't know how big the edge is, since personally I only use a subset of them and a lot of them are just there for legacy reasons. I would put this more in the realm of JavaSE/ME/EE the environment instead of Java the language. I'm sure it would only be a matter of time that Obj-C has a similar class library, if it isn't good enough already.
As for threading, Obj-C has an atomic attribute, @synchronized attribute, exception handling across threads, NSLock, NSRecursiveLock, NSConditionLock, and Semaphores. As for Java, you have the monitor attribute, synchronized, and event handling. I believe that both languages do adequately support threads. Both languages are subject to the limitation imposed by their host OS. Ok the JVM could perform multitasking in its own time slice, but boy would that suck...
I admit I only have written seriously multithreaded programs in Java (I have little demand for ObjC at the moment), but the Apple documentation seem pretty complete and ObjC has 20 more years of multithreading over Java (smile).
Anyway, I think I hit the crux of the problem being that I've had little demand for ObjC compared to Java. In fact, it is this demand that is forcing Apple to support Java. If the native SDK proves popular and the iPhone/iTouch marketshare continues to grow, I'll probably see less demand for Java and more demand for ObjC. This is what Sun is worried about, and this is the motivation for Sun to make a JVM for the iPhone.
You are the first person I have seen (outside of Sun) that has used "extremely fast" and "java" in the same sentence. Do you have references? I would like to read up on the architectural differences. Objective C can drop down to C, but let's face it the speed factor now-a-days is more academic than practical. To be fair, both languages run fast enough to give a good user experience. I always had my doubts on the effectiveness of benchmarks in arguments like these. I am more of a "the right tool for the job" kinda person. This right tool being, what ever you feel most comfortable programming in.
You are sorta right. The ARM 1176JZF does have built in hardware that is capable of running Java bytecode. It is a Software/Hardware solution called Jazelle. I don't know how easy it would be to incorporate its use into OS X lite. I know it's nice in an embedded JVM environment, but I have no clue on how well it would work in a mach environment. I'm thi
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
As a current college student, let me tell you that the Java Hype bomb is still around. I say that Java is to computer languages what English is to spoken languages....clunky but totally acceptable to people that don't know any better. I find myself spending more time solving Java related problems than I do solving the problems of my assignments. I really wish they would do python at the intro level so students could learn how to think about coding and then do C/C++ or something so we can see how shit *really* works at a more basic level. (I believe this is what MIT is doing at the moment?)
There is more to science than physics!
www.iomalfunction.blogspot.com
I am not sure how a Java APP will help developers if Sun follows the SDK license. And I can't explain exactly why because of the same license. But since that would mean all Java applications would load and play in the "Java APP" space Sun would have to reinvent a lot. The shame is that the Samsung chip used has java support built in. And since the SDK severely limits hardware access and the license precludes it as well if you use the SDK, no BT profiles can easily be added, can't play with the dock connector. The chip also supports USB OTG even though the dock connector is not so wired, software could make the iPhone a USB "master". The chip also supports SD/MMC cards but that requires a mod to the hardware and adding some software. So I am pretty safe in predicting Apple will have to make some subtle mods to the SDK license (it stops to many very useful applications ... that there is demand for) and that unofficial development will continue to meet market needs.
- Tjp
I am in wallow with my inner money grubbing capitalistic pig. ... Oink!
Security and Performance concerns? No, it is openness concerns. What is a meaning of iPhone software store if user can click a jad/jar file which is SECURELY signed from their browser and install it?
What if people starts to use the higher than average CPU speed and memory of iPhone to setup "Javatunes Store" ? What if they offer Skype calling? What will phone company say?
If Java was unsecure, we would be fighting eachother with stones and sticks instead of posting to slashdot. Java is secure enough for a BANK, Military, Space, mission critical things. Forget the 1 billion handheld devices having java in them and there hasn't been a single java security issue like worm.
If iPhone gets J2ME, I may consider to buy it since my banks pseudo random password generator runs on it as well as their millions of customers.
Do you remember why Sun took over the Windows Java development even fighting in a court for it? Microsoft. Now Apple gets the same treatment, "If you don't ship it and spread false rumours about it, we code and ship ourselves".
Comparing Windows JRE to OS X JRE, I think it would be a lot better port than Apple would ever provide. As Sun says "Once the capacity of devices are comparable to laptop, we will look for desktop java on mobile" or it is the general thinking, I wonder if iPhone being the only $100+ phone not having J2ME would be the first handset with "real" JRE instead of J2ME in future. That would be really ironic.
SCRABULOUS here I come!
Speaking of Objective-C: there's simply no excuse for a language that claims to be modern to not have namespaces, or some analogous mechanism to deal with name clashes, in 2008.
Look closer at the CPU (arm11) included in the iPhone.
It includes hardware Jazelle DBX extensions:
ARM Jazelle DBX (Direct Bytecode eXecution) technology for direct bytecode execution of JavaTM delivers an unparalleled combination of Java performance and the world's leading 32-bit embedded RISC architecture - giving platform developers the freedom to run Java applications alongside established OS, middleware and application code on a single processor.
Performance isn't really an issue..
liqbase
Trust me, no Java app on OS X feels anything like a Mac app. They look slightly better than on Windows, but they still feel like Java.
If SJobs said "We decided J2ME is too light for iPhone" , it wouldn't bother anyone. Everyone knows when handsets can be comparable to a cheap celeron laptop, J2ME will be a thing of past and people will use real JRE.
Guy said it is insecure and nobody asked for it. With apocalypse like "Taking down entire East Coast network". That is something you would expect from Ballmer but they got a very good $500M lesson for acting like that.
While doing the iPhone J2ME, I hope they use their Cocoa abilities to start coding Java 6/7 for OS X for BOTH Intel and PPC, accelerated for both CPUs. They should have started a very long time ago right at 10.4.x times where Apple showed first signs. They sit and code one of the most good performing, compatible JRE for Windows. Reason? MS hates them and tried to kill it. Guess the very single desktop OS not having JRE 6?
Linux/PPC has Java 6 for more than a year now, thanks to IBM never abandoning their users.
Wow. Your post got me thinking. I could write a remote-control interface for my iPhone that would send commands via TCP/IP to my MythTV box. Change channels, play / record, etc. over wi-fi.
Seth
$5 / month hosted VPS on linux = awesome!
Not only does Apple ship a descent JVM with OSX, they even customized its Swing so that apps look just like native apps. Yes, Swing is a crummy GUI toolkit, but you can't say it's ugly. The rest of Java is actually pretty fast, you just don't notice it because your window has to go through 20 levels of abstraction to draw itself. On the plus side, you'll never see a Swing dialog box with an itsy bitsy input field that you can't make bigger *caugh* win32 absolute placement *caugh*
boldly going forward, 'cause we can't find reverse
People of feeble and creative minds everywhere in the world went into deep comas, the mental institutions survived a major influx of patients.
For now, Steve Jobs dreams again in R'lyeh.
No, they use Scheme. It is MIT, so a non-LISP is not good enough.
Nice pun ;)
[...] but it has no place in embedded hardware.
cuz, lolz, it sure as heck wasn't designed with that use case in mind. At all. Shucks no.
meh.
As for Java being faster? Well, the benchmarks disagree. And, of course, there are ways of making Objective-C as fast as C if you have some bottlenecks where you're willing to sacrifice a little flexibility.
I can definitely see a business case for Java on the iPhone - there is a lot of existing Java (particularly J2ME) code out there for mobile apps. With a JDK that had a nice UIKit wrapper it would be possible to reuse a lot of the existing code and just add a new UI.
I am TheRaven on Soylent News
I am TheRaven on Soylent News
>As for threading, Obj-C has an atomic attribute, @synchronized attribute, exception handling across threads, NSLock, NSRecursiveLock, NSConditionLock, and Semaphores. As for Java, you have the monitor attribute, synchronized, and event handling. I believe that both languages do adequately support threads. Both languages are subject to the limitation imposed by their host OS. Ok the JVM could perform multitasking in its own time slice, but boy would that suck...
Java also has a very nice concurrency library: http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/index.html and VERY good parallel collections library.
>You are the first person I have seen (outside of Sun) that has used "extremely fast" and "java" in the same sentence. Do you have references?
Ok, now you can see the second person who claims that Java is extremely fast.
References: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=gcc - Java is generally about 20% slower than optimized C, thanks to http://en.wikipedia.org/wiki/HotSpot compiler.
Objective C performance is about the same as Python: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=python - i.e. Java is in general more than 1000% faster.
Oh, and Java GUI can be fast - check Google Android, it has a very nice custom Java GUI, which works blazingly fast on 200MHz CPU.
Not quite true. Mocha - Cocoa + Java - apps often felt really nice (although they were rare). These typically took an existing Java application and re-wrote the UI using the Cocoa bridge, and behaved exactly like Objective-C Cocoa apps (to the user). Shame Apple deprecated the bridge with 10.4...
I am TheRaven on Soylent News
That's funny, because very little you said responded to it - in fact you're more guilty of using his posts as a springboard for tangential rants than he is.
Not from where I'm standing - your points are orthogonal to his central argument, and mostly to do with how great Java is for everything.
eh?
The only people asking for Java on the iPhone will be phone developers who want to make a quick buck with a port of their existing J2ME app, and corporate developers who follow the religion - customers will avoid it like the plague because it will suffer from the same mediocre mongrel interface as Java on the desktop does on every platform, and the apps won't feel like they belong, because there won't be proper integration with things like the touch screen, native UI transitions etc etc.
Java on phones is not dead, it just deserves to die, and roping J2ME to the new hot platform is not going to make it magically better. There's an interesting post further up this thread about the mediocrity which is Java as a language, but all that doesn't matter to the users; the ultimate arbiters in this matter, all they care about is the UI and user experience, which is historically Sun's weakest point.
Maybe that's why phone UIs almost universally suck - I know the ones using Java for apps that I have used do, not really because of Java the language, but because of the libraries and UI conventions used, which are presumably closely tied in with the framework itself. I'm sure it's *possible* to do anything, but developers will tend to do what is easiest with a given framework.
Maybe he just felt it was irrelevant and of more interest to Java aficionados than anyone else. Sounds like a solution looking for a problem to me - I'm sure it would be neat and all, but ultimately as a user I don't really care if you use the same objects on several different interfaces, it _might_ even end up a horrible kludge if they have different screen sizes and UI control schemes and the views aren't appropriately tailored. By the by, this facility (distributed objects) has been available in Objective C since the mid 90s, even if it's not available on the iPhone. Java really isn't as original as you seem to think it is. It's just as derivative as Objective-C for example, and if it ever was visionary, it isn't now.
Well the future will tell all (including maybe even telling you you're wrong, if you're willing to listen), but if it's anything like the acceptance by consumers of Java on desktop OS X, you'll have a hard time convincing someone to use your J2ME app over a native one, that's if Sun even manages to get a credible solution supported on the iPhone.
Frankly I find his arguments more convincing that yours, because they're grounded in an understanding of what the *user* wants, not a Java developer's hopes.
No need to provide examples of the current version of Java being faster than the current version of Objective-C. One can prove it analytically.
The Objective-C compiler only has access to the Objective-C source code when compiling the code, and the run-time (AFAIK) only optimises method calls (by caching them).
The Java HotSpot JIT on the other hand has access to the source code but also the run-time profile of the executing code, and can thus optimise the execution in many more ways.
That's how Java can be as fast, even faster, than C, and is currently way faster than Objective-C. This is not to say that the Objective-C run-time couldn't be changed to do more optimisation.
The way I see it, apple had long before a chance to let Java break all the compatibility issues with apps, but it ruined it, and last year, instead of improving so, they made Java support worse, fun?
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
The first Java you used was not advanced as current one. Java 5-6 are huge things , they had to evaluate based on needs. Nobody could code a complex thing like Azureus for example at that time. Nobody had the idea of natively playing a mpeg 4 file, interact with a webcam etc.
Desktop Java has features, libraries which your (or mine) phone would never, ever need or use. Additional security is required along with a strict policy for network usage, phones have features which doesn't exist on PCs (e.g. dialling) or even GPS in new models. Memory is still an issue, even iPhone got limited RAM, my Symbian S60 (E65) has 64MB RAM but when it is booted, only 24-26 MB available maximum.
Funny thing is, Apple would die rather than getting into J2ME process. It is like Nokia, Samsung and Sony may work on same standard proposal together while trying to erase each other from market. It is very visible on J2ME standards.
To see what J2ME has to deal with, start with the CLDC (connected limited device configuration) http://en.wikipedia.org/wiki/CLDC . It is how it became de facto standard for mobile devices.
My guess, because it's not about the *iPhone*, it's about the entire cellphone market: Sun want Java to become the standard language/platform for cellphone app development, and Java ME is already commonly used and has an application base - it's most useful to have all those apps be easily portable to the iPhone, and vice versa for new iPhone apps.
If iPhone app developers code for the full version, their apps won't run on Java ME devices and will be even harder to port to (non-ME) Android, which is the other important 'prong' in their strategy --- with Android on the way, Java looks set to become "the" future platform for mobile devices, and then quite possibly later to basically all computers due to eventual convergence of cellphones/laptops - after nearly dying, Java may be truly getting a 'second chance at life' here, but only if Sun can make it a kind of de facto standard platform.
You Microsoft trolls never learn do you. Go and waste your time on a Silverlight port for the iPhone. Better yet, make it run on a Zune.
Products on all sorts of platforms succeed by at least as much, because they are also polished. And for Java, Opera Mini for example is polished and it succeeds. So I don't see how this is relevant.
And Apple's Quicktime on Windows is one of the worst offenders for not looking the same as other apps, so that's not something to complain about!
Java runs fine on my dirt cheap phone. I'm sorry your iphone isn't up to it.
If Sun make a JVM for the iPhone, then an iPhone + JVM could be considered as a jPhone.
Is basically Java on the desktop done right.
I think he's saying if you read between the lines he's saying swing is total shit.
But really ur right, Apple r just a bunch of thought Nazi's, sure Java would probably make their phone look crap, but it's more about domination and control of their platform. It's the jobs effect, the man is a genius, but he has an ego exceeding that genius by an order of magnitude, whilst he creates great stuff he ruins it with his megalomania. To Jobs anyone elses input or ideas without his right of viteo is just a recipe for imperfection. Nothing will go on the iPhone without Steve giving it his approval and more importantly taking ownership of the idea like he had it all on his own.
This is why, I've always preferred Microsoft over Apple as the lesser of two evils, as Microsoft is really just a business entity. They're not that interested in technical perfection, just perfect business models. They don't care what you do with their platform, they let people do whatever, just as long as it doesn't screw their business model. The net effect is you have a lot of creative and technical freedom on the MS platform, but the day you screw with their business model they'll crush you like an ant.
Where did you read that Obj-C is as slow as Python?
It seems odd to be discussing Obj-C and Java and then give a benchmark comparing Java and Python.
At least grandpa can use unsigned types.
Apple also consistently stays one version out of date because of this, leaving Apple's java-dev list full of bleeding edgers who quote Jobs ad nauseam on his "best platform for java" quip.
B) Even the fastest smalltalks like cincom's can't even get method calls as fast as Java's. When I last benchmarked them they were 4 times slower. And math is typically 20 times slower than Java, or more.
C) Assembly is simpler and more powerful and faster than Java. That doesn't mean jack about whether it is a good application programming language. A language where you can change any part of it can't be used in a secure way and isn't forward compatible. ie it's for scripting. If I sound bitter, it's because I was in college right when the Java Hype Bomb hit, and so I spent about 2 years writing Java code, continuously waiting for Java version N+1 to actually have some features we were begging for. I'm glad I had the sense to get out when I did, because if I was waiting for language features as basic as closures (which are far older than 30 years, gramps), I'd still be waiting, 10 years later. What's funny is that Java's inner classes are almost a direct mapping from the common ancestor of all successful object oriented languages, Simula 67. In another ten years maybe you'll have the context to know that it isn't Java that's making you bitter.
As a current college student, I can say that if you are spending significant amounts of time fighting with Java-related issues instead of the actual assignments, you are hopelessly incompetent.
Yeah good for phones, crap on desktops if you have real big desktops 1920 wide or 3 screens, i prefer localized menus, and hate to drag
all the way to the top to see the menu, its crap.
Liberty freedom are no1, not dicks in suits.
I shall indeed take a look.
;-)
In the meantime I will continue with Google
Most programmers need working examples and an easy to understand overview of what is in an api and how it should be used. Luckily this type of stuff is fairly quick to find - but for me there should be a place for it in JavaDoc, which also suffers from being very dry not to mentin terse.
What specific 'Java related problems' are you having? I'm pretty sure that whatever you're talking about can be easily googled for, and/or asked/answered on one of the gazillion forums out there. This one here is usually helpful for programming at various skill levels. The only real problem I know of, is when teachers insist on using garbage libraries for assignments.
Objective C _is_ as slow as Python when it does dynamic function calls. That's because they both use dynamic binding.
Of course, programs in Objective C use plain old C for most of functionality. But once you start using dynamic binding and other goodies - it's the world of SLOW.
If you compare the languages, Objective C and Java, odds are that Java really can't bring anything to the table that is going to make it stand out from the crowd. Java works if Java can stay in memory, or be the entire application interface so it's always in memory, that's how is can make a decent application for phones -- be the application. That isn't the case here. Apple has their own OS that they are running and it's pretty good. They won't get rid of it. So now you are going to run two on tandem. Which will be very bad for Apple.
JVM based widgets will suck ass and everyone will want to blame Apple for their shitty phone that doesn't run Java apps really fast. Well, it wasn't designed to. But there are like a million little programmers running around saying "Go Java" and banging out every kind of widget they can think of anyways. And still people will blame Apple for making a shitty iPhone because Java widgets don't run fast. Recall that it still isn't designed to do that.
I have a very strong dislike for Java because of what Sun did with it. They lowered the entry barrier to Java by making is really easy for someone to get a certification in a week and then start programming at a job. Problem is you end up with a lot of programmers who are stupid shits and can't code their way out of a paper bag. The really amazing programmers still exist, but they've been diluted by the thousands of overnight contractors that have no experience.
So the net effect is that you end up with a lot of bad programmers making a lot of bad programs on a code base that is very sub-optimal for the applications and platform that they are going to be developing. And even the really good programmers are going to struggle because it's not a native Java machine and they'll have to fight against that one.
I guess I forgot to say, I don't think that there is any problem with what Apple is doing with their SDK and their product development model. They have a different approach to their products. They release what they can and need to in order to ensure functionality. This is contrary to Windows and others who release crap for everything all on the same day and then have a lot of people pissed off with things not working. It is the quality of their products that has been a corner stone in their success in the market.
Opening up the iPhone like this is going to mess that their perception of quality in the market and that is probably one of their most valuable selling points.
When apple owns the portable phone market, then, yes, this would become subject to anti-trust measures.
Why can't people tell the difference between a monopoly in the market for brand X of product B of product category Q and a monopoly in the market for the entire product category.
iPods are kind of close to the borderline, but not really approaching the degree to which MSWindows/MSOffice has become the market for general purpose computers except for mainframes. And, yes, Apple has used various things to keep control of their own products, but have done nothing approaching what Microsoft has done to establish and maintain their monopoly. Give it a break.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Well, I remember, back in the 80s, fans of FORTH who claimed it was faster than compiled C.
Some of those who made those claims understood that the FORTH interpreter was a better run-time execution model than the model that many C compilers for microcomputers back then implemented. So, FORTH interpreted code could be faster than a bad compiler's compiled code.
But some didn't seem to understand the fundamental behavior of an interpreter. I heard one guy talk about, if your program was too slow, just make parts of it words of their own, and then those words would be fast. (Didn't seem to understand that a call to a routine still had to execute the body of the routine. Or maybe he was confusing size optimization with speed optimization. I've done similar things, said "It does cool thing A." when I meant "It does cool thing B".)
There's no way an interpreter can run without putting at least a branch/jump between every primitive executed.
Well, I know the JIT is supposed to solve that, but why not just unroll the invariant primitives? If the code itself is final, it ought to be possible to just pick up everything to the last branch and insert it in the stored instruction stream without the branch. Large primitives aren't going to be helped much, but small primitives would. And, at compile time, you could dredge the unrolled code for things like a move to the parameter stack followed directly by a move from the stack to an accumulator.
Anecdotes: My Mac Mini (1.2G PPC, 512M RAM, slow frontside cache) runs Java about half the speed of my Linux box (1.7G Sempron 2700+, 768M RAM, frontside about half CPU speed). The pause between double-click and application coming up on screen is a bit longer than with native code on both machines, which is not surprising considering the pre-flighting Java does for security and other purposes. You see the effects of the branch being in there, speed-wise, but, as you say, it's fast enough.
On my clamshell iBook, however, rendering of html is seriously slow. Makes the help screen I'm rendering that way more or less useless.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
As a professional cat herder in global mission-critical financial J2EE application environment of a fortune 100 company, I would peg you as a "significant risk" because you are completely willing to judge something on assumption without knowledge of basic requisites like "You are incompetent" without knowing exactly what the guy is trying to do, nor the nature of his difficulty.
I would take it as a personal task to destroy your code's behavior if there were any production impact on any bug. So, mister high-and-mighty "only incompetent people struggle with Java tools or language idiom" you get the prize. Only the best will be tolerated from you. A good teacher will specifically assign work which exposes the limits of a language/tools so that students get real experience learning how to push the envelope. Maybe struggling with Java is *part* of the assignment. I contend that if you went to school and did not struggle in this way, maybe you wasted your tuition and time?
--- Nothing clever here: move along now...
apple.laf.useScreenMenuBar
Can be set on the command line or programmatically. Or in the plist in the bundle, of course.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Do you customize your Mac UIs very much?
By the way, the reason the first item in the bookmarks bar is a menu is because it's a menu of bookmarks. That is not the same as a file menu and you probably at least subconsciously know this, so you are just playing semantics games to try to defend your arguments that everyone should be a poweruser just like you.
I'm a poweruser of sorts, but I'm not a poweruser just like you, thankyouverymuch. I don't really appreciate having to hunt for a safe place to click non-foreground windows to bring them front.
Oh, and the first item on the left in the bookmarks bar (which you can get rid of if arguing about it is going to distract you from real work) is not a menu, I think.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
As far as I know, "there is no optimization", especially when it comes down to "performance". Routines that can enhance the performance of matrix computations are different in every point from routines that enhance the performance of device bandwidth management (used in NIC drivers, of video adapters drivers), and have nothing in common with optimizations related to "responsiveness" (latency management).
What performance are you talking about ? Please be more specific. Extremely dynamic linking Sorry, I can't guess what you can't spell. What is that already ? And Java is extremely fast-- almost certainly faster than Objective-C Citation needed.Looking for benchmarks, I found many references to a "String" benchmark is which Java is supposedly faster due to a certain amount of optimizations in the JVM String handling routines. More, I don't see any reason not to write an String handling library for objective-c that could provide the same kind of optimizations (come on, a String Handling Library. Such a thing is like "you're first assignment as a CS student ever").
I was unable to find benchmarks caring enough to be unbiased i.e. with a valid test methodology, and reasonable explanations of the choices made, measurement of the biases etc.... I didn't spend more than 10mn on google. I'm not trying to prove that either Java or Objective-C is faster than the other though.
Yeah, I do google things and visit forums when I am having trouble, but its a huge time suck.
I just think its amazing that as a novice programmer I managed to write a program in python that does pixel counts in images and will soon be able to clunk them together, but in Java it takes me ages to do my homework. I really do spend more time trying to figure out how to create the algorithms in *java* than I do logically/in my head, if you see what I mean.
There is more to science than physics!
www.iomalfunction.blogspot.com
People like you are the reason why the CS/engineering crowd are considered arrogant douchebags. Java is a clunky language that should not be taught to intro classes. Not everyone is a genius like you are, apparently. FYI, I'm going into a career in neuroscience, and the CS department is overriding me into the AI course next semester even though I have less than a year of programming under my belt.
There is more to science than physics!
www.iomalfunction.blogspot.com
Again you mention no specifics of your problems with Java, only that you spend more time than you perhaps would using Python. You can do most things in similar ways in both languages, Java is just more verbose*.
That said, I agree that it would probably be better for novice programmers to start with Python than Java, it's an easier tool for training your brain into a programming mindset.
*yes, collections and lists are much more cumbersome to work with in Java than Python
Python is a scripting language. It's designed for write-once programs that kinda work. Java is a programming language, for when you need it to work for a lot of people for a longish time. Try running your python script again in 10 years and see how awesome it is... it probably won't even run, since the library interface will have changed or something else will have broken.
Seriously, are you getting assignments so basic as to count the number of pixels in images?
Java is not that hard. In fact, it's several orders of magnitude simpler than C++. It doesn't do any good if you can design algorithms in your head... anybody can do that. The only thing that matters is if you can get the computer to perform them. And it sounds like you are struggling with that part.
Yes I know. But that is a function of Java class library not of the language itself. I written similar libraries for embedded projects using C++ and any language that supports encapsulation and has support for / or have access to semaphores can easily be made thread safe. My personal favorite use of such objects are FIFOs that transport messages between threads (and processes).
You show benchmarks for Java versus C, python versus C, and only provide conjecture that loosely links ObjC versus Java via Python. Unfortunately, you provide no benchmarks comparing ObjC to Python or more importantly ObjC to Java. You did show references for Java, C, and Python but none for Objective-C
It's refreshing to see someone come to the aid of Java. I like Java (and have used it since forever), but I just don't quite fully believe that Java is "faster" than Objective-C. I really don't know why it should matter...
The really cool thing about Objective-C is that you don't have to compare it's speed with C. You can write actual C code in your application. It looks like you can write your dynamically linked objects in Objective-C (which makes the GUI programming nice at least that's what I've heard) and you can write your bare-metal stuff in C. Java only offers JNI.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
I remember several Obejctive-C vs. Java comparisons from several years ago, but I can find only one:
http://web.archive.org/web/20040805153930/http://homepage.mac.com/spullara/rants/C1464297901/E775622191/index.html - In this benchmark Objective-C is 6.4 times slower than Java. And it's nothing unexpected - try to walk an Objective-C method call in a debugger in assembly language view someday...
I wrote several applications for Mac OS X and I don't really like Objective-C. It doesn't have a built-in garbage collector (it's possible to use conservative GC, but it's light years behind GC in Sun JVM), Objective-C is SLOW when you try to use it not only for UI, it doesn't have namespaces, and I also don't like its syntax (though it's a personal preference).
Speed Objective-C is quite OK when you need to write event handlers which are called maybe several times per second. But it's not enough for anything more serious.
You do realize that 99% of Java is dynamically linked. All methods are created to be virtual (makes since it's OO after all), and uses the "final" keyword to make a class more "directly invokable" (final means no more overriding is possible for that class) by reducing the tree of method addresses to a single table. By eliminating the tree searches for the entry point, you do speed up the invocation speed for that method. What you give up is all the nice OOP paradigm that Java has to offer. What you gain is some modularity by being able to use the same block of code / code space within multiple loops. If code space was not a concern, you could simply inline the method and let the compiler optimize it for you. Both ObjC and Java support inlining.
Now if I wanted to "game" a benchmark to promote my favorite language, I could make a simple program with all of its classes marked "final." This makes Java look better on the benchmark, but a proficient programmer would have thought that if he was going to give up all the OOP goodness Java had to offer, he would have written it in C. Technically, ObjC programmers could simply not encapsulate their code in a class, thus producing C code...
Keep in mind that the final trick only works with small code used in benchmarks. Applications that users would want to use would use the SDK and some GUI and that would require dynamic linking...
One final thought. A lot of Java libraries are not "final", otherwise they wouldn't be nice to work with. On the other hand, ObjC takes advantage of the C library which are directly called.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Yeah, Javadoc should have a place for that stuff. Oh wait, it does! It even has a style guide for information about your fields, methods, classes, and packages. They even describe how to embed (wonder of wonders) diagrams and other images into your source documentation.
It's not like Javadoc (or any other documentation tool) can magically create annotated code samples and training tools on its own. Don't blame Javadoc, blame the lazy bums who never bother to actually document their stuff.
- I don't need to go outside, my CRT tan'll do me just fine.
Do you realize that the MAIN feature of the HotSpot compiler is dynamic inlining of virtual methods?
http://en.wikipedia.org/wiki/Java_performance#Adaptive_optimization
That's why Sun JVM is sometimes 'faster' than C++ - it can inline function calls which can not be inlined by a static compiler. So there's no need to abandon OOP niceties to gain some speed.
Please cite where Smalltalk is shown to be anywhere near the speed of Java. A quick Google search reveals this language comparison where Smalltalk gets its ass handed to it, and that was written in 2004. Say what you will about Smalltalk's elegance, but speed was never truly its forte.
- I don't need to go outside, my CRT tan'll do me just fine.
Unfortunately, I couldn't get the source code that was used in the Benchmark. I do find his results about string handling dubious especially when he claims Java is actually faster than C. I really would like to see his code. Of course string benchmarks means squat, and I mean that in a good way (smile). If the benchmark was to allocate a string buffer assign it a value, and then change its value by inserting a substring, I could see Java being faster but not because of its op-code execution speed but how Java designers handle strings as immutable objects, cleaning up the dereferenced original values after execution. C, on the other hand, does exactly as it is told. Of course you can't upscale a string benchmark to a system benchmark...
I also prefer Java, but only because I am more familiar with it than Objective C. It is my understanding that Objective-C 2.0 does have garbage collection. Personally I don't particularly care for garbage collection (I work with resource limited devices most of the time) and do like to be able to clean up my own mess as soon as I want to. I am able to gracefully perform garbage collection with J2ME, but only after experimentally figuring out where to manually invoke garbage collection during "cut-scenes" and sneaking in a garbage collection when the user believes he is actually waiting on the remote server. Admittedly, I use C for 99% of my embedded stuff now, and C++ when there is a need for OOP design.
I can say the same thing about Java and most any interpreted/p-code out there... Maybe I'm misunderstanding the events that you are trying to handle.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
I have to laugh at the histrionics coming from some quarters. Apple sell a hardware device which runs its own software, and so they restrict what third-party software can and can't run on that device. Why is this such a bad thing? I don't hear screams of 'no fair' being aimed at Sony, Nintendo and Microsoft for their similar behaviour in the console industry, so why should this be so maligned here? Frankly, I'm glad they've put this restriction in place, as it means we as iPhone users won't be subject to this kind of crap. Java applications have long been the absolute worst where UI is concerned, and Apple wants the iPhone to be considered the pinnacle of the mobile interface, not the sloppy bottom of the barrel that Java ME represents.
- I don't need to go outside, my CRT tan'll do me just fine.
Beware of market hype. I also believe that JVM could improve its performance when it is able to profile its execution and make dynamic adjustments. The longer the thread is in operation, the greater the chance that the execution speed of a section of code at a given interval can be improved. The performance gains are more noticeable when the baseline performance of the interpreter is poor. What I find hard to believe is that these optimizations make Java faster than other languages.
The problem with marketing literature is that it makes you believe it is a panacea for what ails Java. Java has a legacy of being SLOW. JIT and adaptive optimization came about to improve Java's speed. I do believe that Java's adaptive optimization has the potential to surpass the performance of unoptimized code written in some languages. Unfortunately for Java, people do tend to write code optimized for the expected usage patterns (profiling is great isn't it). I don't see any appreciable gains (if at all) being made by adaptive optimizations when compared to properly optimized code written in other compiled languages.
The problem being that a program that starts fast and stays fast will outperform a program that started slow and eventually got up to speed. Real world usage has proven that as long as the application starts fast and remains responsive the end-user will not notice any minor difference in speed offered by other languages. This is why Python, Perl, and others are still around. The problem Java has is that it must load a huge JVM and it needs to be responsive afterwards. Java has a disadvantage when it comes to starting up, and it does OK in operation. I find Eclipse and Netbeans quite usable, but I do find Xcode, VI, Visual Studio much more responsive and "faster".
The cool thing about using JVM and its adaptive optimizations is that if you have no clues on how your application will be used by the end user (or guessed wrong), it will make the adjustments for you and make the performance the near-best possible in Java for the end user.
The main advantage that Java has is that it can pretty much run on any hardware platform without modification and without the end-user compiling source code. To my knowledge Java is the fastest environment that can make that claim. This is why I use Java for all my cross-platform needs, yet stick to C/C++ for my embedded needs. Yes C++, it works great when used properly and at the right amount.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
I don't know why the parent was modded down, well I might ;).
He provided a shootout link that compared Java6 directly with Objective-C. Objective-C was faster than Java on 7 of the 10 benchmarks (the smallest margin was 1.5 and the largest being 5.7). Objective-C started 28 times faster than Java6 and in all benchmarks Object-C consumed significantly less memory than Java.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
The jailbreak apps are broken by updates because they use security exploits to install. Apple closes those exploits (as they should) to improve the security of their product.
When it comes to officially supported development environments, Apple is no more likely than any other platform company to shoot themselves in the foot by choking off existing apps.
In fact, Apple has a recent history of legacy platform support that is pretty good. The switch to OS X included the Classic environment to support older software for a time. Cocoa and Carbon had equal status as development environments for years. Rosetta transparently handled PowerPC code when they switched to Intel.
An iPhone JVM implemented by Sun through the official SDK can't escape Apple's notice. If it's allowed to released, I see no reason to believe that it would be choked out later.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
I'm going to go out on a limb and say MIT uses Scheme, or some variant of Common LISP. My intro CS courses at Berkeley did the same. It was a real eye opener to build OOP and metaprogramming from scratch using the really quite simple constructs afforded to you in Scheme. Later on we used Java for data structures, but after a semester spent marveling at SICP and the elegance & power of functional programming, that was a painful experience indeed.
I think there is a world market for maybe five personal web logs.
http://wickedpsyched.com/iphone/perl
The only part of the Java API that is worse than the Apple SDK is the GUI part.
The "only" thing... lol. Java does not belong on the iPhone - it brings almost nothing to the table for the iPhone other than being able to run a bunch of ugly ass quirky apps on a superior piece of hardware all in the name of "cross platform". For all of sun's engineering prowess (which is not unsubstantial) they do not get what "end user experience" means. If they did, Java would have advanced user interface options - I mean, it's been around for over 15 years...
the iPhone DSK uses llvm gcc to do ARM compilation. LLVM (low level virtual machine) does similar optimizations when converting to the target executable. With the advantage that it's being done before hand on a faster computer with a lot more memory, so it can be more aggressive.
Do you even lift?
These aren't the 'roids you're looking for.
LLVM currently doesn't support _dynamic_ recompilation in runtime with speculative inlining. iPhone just has the static image of compiled binary, with dynamic calls.
But you don't need Java to do that. A native iPhone app can send TCP/IP commands to MythTV.
Actually, I'd probably code the app in Objective C. The part of your post that gave me the inspiration was your idea of different pieces of furniture (appliances) communicating with one another. I'd love to have a nice touch-LCD remote for my MythTV box, and my phone is always with me when I'm watching TV, so making an iPhone tv remote is a no-brainer. I like the idea of having the wifi-TCP communication, because then it'd be a remote that wouldn't depend on IR hitting the MythTV box. Much like a radio wave remote.
Additionally, it could be used for remote programming of the MythTV recorder.
seth
$5 / month hosted VPS on linux = awesome!
No, the pixel counter was actually a project for image analysis in an animal behavior lab I work in until we got a grant for more funds. And it did more than just count pixels.
:-P ) aren't relevant to the discussion.
And since when was java a long lasting language? I look stuff up in the API and it seems like a good fraction of the stuff is deprecated.
For the record, I am not a CS major, so all the comments trying to provide insight into my programming skills (or apparent lack thereof
There is more to science than physics!
www.iomalfunction.blogspot.com
the iPhone SDK uses llvm gcc. LLVM does optimization (often better than hotspot since there are more CPU cycles and memory than on the iPhone) when it is converted to ARM binary code
Do you even lift?
These aren't the 'roids you're looking for.
The MIDP profile already supports touch screens - after all Sony Ericsson has touch screen phones for years now.
Martin
"... Apple's continual foot-dragging over opening it up is getting increasingly old."
What's getting really old is this kind of hyperbolic comment. I am so tired of hearing about how Apple "wants to keep the iPhone closed" (when they have never actually said anything of the sort), and that it's "taking them forever" (or words to that effect), to open it up.
Fact 1 - they never explicitly ever said it would be closed
Fact 2 - they opened it up to web apps quite quickly
Fact 3 - it's LESS THAN A YEAR since the device has been in existence.
Any statement of the form described above is pure hyperbole plain and simple.
Can't we just stick to the facts and leave the emotions at home?
Am I right in thinking that no one would care about an iPhone JVM port (including Sun) if Apple wasn't being an overprotective nazi mom in reguards to what kind of application can be installed on the phone that I bought? I have "unlimited" data access as long as it's the right kind of data... Fantastic!!! I for one have not been drinkning the Apple Coolaid...
While the Java folks are "going to port it" the Mono project is already running C# applications on the iPhone. Check www.go-mono.org/monologue