Even if I hadn't seen any screenshoot or known any details about Meego, I think the odds are that a new O.S. will consolidate (or in some cases, copying) the best lessons learned among the competitors. By lessons learned I mean things like ease UI, fast development of applications, a functional app store, interoperability with own vendor services&tools since day-1 (come on Nokia, don't forget to allocate Ovi Maps/Suite/Services development team BEFORE launching the first Meego device, as happened with Maemo...), etc... It is just common sense for new projects, and a Project Manager is obligated to know and avoid repeating the same mistake from previous projects!!

I am also considering that Nokia and Intel are companies with more than extensive experience and skills to innovate in this market, so it would be a disappointment if they came out with something not that great.

But having two large companies support and applying the best practices is not a warranty that Meego will be better than any other O.S.. Creating an innovative product ultimately depends on inspired employees behind the curtains, with bosses who actually listen and incentive their ideas.

I agree.
On that thought, I really wonder why Nokia stopped QTJambi development; QT for Java.
Maybe even next generation of Swing could be developed over QT; if it is really multiplatform capable.

They should read this in Nokia and rethink the decision:
http://trs-new.jpl.nasa.gov/dspace/handle/2014/18351
Java can be faster and require less battery energy, than same program done in C++ (in family of programs which use relatively much dynamic memory and are run "long" time, like www-browser)

Because it never caught on in the Java world. GUI was never as important there (plus most people already knew swing), and the rest of the framework was mostly just duplicating functionality.

I see you like this link and post it over and over, but I feel obliged to tell you this is fairly old stuff - the article talks about what later became known as JIT, which did improve Java performance a lot (and later influenced modern JavaScript engines), but never quite rose to the super-fast levels promised and hoped.

Nope, this is not about JIT. I wonder if you read the study at all.

There is many optimization techniques in modern compiler science which are impossible on C/C++ because they use pointers. The whole basic structure of C/C++ should be changed to overcome the obstacles.

Heap memory fragmentation is always a problem with C++ when program uses lots of dynamic memory and is run "long" time. I suspect Firefox will never get rid of memory leaks, as long as it uses C++. There is tricks to try to avoid memory fragmentation in C, but they are much more inefficient techniques what Java JVM can do with less effort.

I think you also know the importance of L2 cache, and what are cache misses. In Java-bytecode, (live) objects can be reordered during the run-time according to usage pattern, so making L2 cache misses more rare. For C++, this is not possible, unless C++ factually is changed to be bytecode based also. JIT, and re-JITing when there is benefits in run-time, is the key in Java.
The mordern compiler technology optimizations are not yet all implemented in JVMs. Running java with "--server" settings does take some of those optimizations to use, over normal --client mode.

edit: One good book to read about subject is Modern Compiler Implementation in Java, where in the sections which talk about optimizations it introduces many techniques which are impossible to fully compiled code, but are possible when the final phase of the compiling steps are done in run-time.

I know, it seems like against common sense that interpreted code could be faster than fully compiled assembly code, but the trick is just this: "there is information which can be gathered during the run-time, which is not available in compile-time". C++ cannot use that information, Java can.

I have low expectations, to be honest. Very low.

The moment EA announced that they will be developing games for MeeGo, that made it officially better than Maemo for me. I mean seriously, EA making games for Linux should be big news! MeeGo means more developers = many more fancy shiny application to attract the mainstream to Linux.

If EA is there, that means DRM is there. Which to me... is not a problem. But the whole "MeeGo is freedom for the rest of us" types will moan and groan something fierce perhaps.

EA needs to make more money. Google how the current EA CEO is being questioned.

If it is going to be anything similar like the work the Foundation is doing with Symbian, what´s gonna happen is that a base "MeeGo" UI will be developed, which is going to be fully open source.

Vendors would have the chance to replace such UI by their own, like "Nokia's MeeGo UI" in order to introduce differentiation and added value (though better features I guess). And is probably going to be developed in secret because an UI, which nowadays can make people flock to a product and ensure its success, can be considered a critical asset.

Pure speculation, mind you.

That was an early development release of MeeGo, not a final commercial release.

This paper shows that it is possible Java to have better general performance than C++, and that it is likely that this will actually occur. Java performance can exceed that of C++ because dynamic compilation gives the Java compiler access to runtime information not available to a C++ compiler.

Java bytecode + dynamic compilation *WAS* the idea JIT was based on. The article is apparently old enough not to take into account concepts that came in later with HotSpot, etc. Seriously, those we all dreams. Big dreams that looked great on paper, but never came through, and likely never will considering the fate of Sun. And before I get a you-dont-get-it, I must say I was actually a Java guy in my younger days (even wrote my Master thesis in Java). As for interpreted language speed considerations, I’m very much aware of those and the conclusion I came to in the end is that no JVM magic wand can help as much as the additional brainpower I can throw at the problem, and that’s why I prefer Python nowadays, with C(++) for the heavy artillery (the ability to use Qt from both makes this very sweet). Long story short, you don’t have to convince me, been there, done that, said goodbye to Java