From the JSR-139-CLDC (http://jcp.org/en/jsr/detail?id=139), hardware requirement: at least 32 kb of volatile memory. What were you saying about computing power catching up something again?

Then you lose the advantage of not having to upload a file if someone uploaded the same file before. If your files are too sensitive to be anywhere else besides your computer, just don't put them anywhere else!

These days, I'm pretty sure the JIT will do a much better job of cache optimization than any C programmer on a real world application. Anyway, real time JVMs are not about raw performance, they are about predictability and are used in very specific domains so I don't think it applies to smooth animations in desktop programs, as long as the OS and hardware is taking care of these, I couldn't care less which language will call them. But yeah, I'm saying Java is better than something I've never worked with, but I know it's implemented and used from C++, so I'll continue to stand against it because that's not the language I'd choose/recommend to develop desktop programs.

GC is run concurrently, unless your program is using all available memory, there is not lockup, I've only experienced it when the application is on the verge to throw an OutOfMemoryError. If the OS is drawing the UI there is no sense in saying Qt is faster than SWT. I've never worked on Qt but the fact it's implemented in C++ is enough to dismiss it.

I think you didn't read what I posted, SWT (http://eclipse.org/swt/) delegates to the Operating System all drawing operations. You may be confusing it with Swing which draws everything on its own. So yes, it can do SMOOTH animations and anything else the OS can draw. People who call java devs fanboys simply doesn't know Java technically enough to criticize it and believe any BS people keep spreading about it, it's the most used platform in the world for reason.

Java+SWT is miles better.

Language is not a good metric because English was chosen mainly because it's a very straightforward language and the US came up in the best position possible after world wars. Chinese is too complex and time consuming to learn.

Actually you'd write something like this: Collections.sort(list, SomeClass.COMPARATOR); So readability and maintainability is better than your closure example. SomeClass would be in its own .java file like this: public class SomeClass { public static final Comparator COMPARATOR = new Comparator() { ... } }

Hey, the Russian went to space first anyway, it's not like americans were at the bleeding edge.

Yes I did, for android specifically I worked on Android Notifier (http://code.google.com/p/android-notifier/) and we got *dozens* of emails about simple things but it's manageable. It's better than letting every app do everything like the current situation right now, people don't read permission listings too ;)

They won't because the app will get a PermissionDeniedException and almost always show a message to the user explaining that it didn't send an SMS message because the user blocked it. It could even know if it's permanent and just give up that feature completely after the first warning.

You could make it remember your choices.

Humans make mistakes, it's tech's responsibility to help the user to not make them.

Exaclty what J2ME does.

Maybe they could copy the J2ME security model. Everytime the app tries to send an SMS, the OS asks the user "Steamy Windows wants to send an SMS, is it allowed to do so?", if the user denies permission the app receives a PermissionDeniedException and handles it as it sees fit. This way the user will go "Why my wallpaper is trying to send an SMS!?!?". Of course, the user can make the OS "remember" his permission and never ask again.

But you don't get IDE auto-completion and syntax coloring.