Though to be honest I wonder what could possibly replace Java on the (JEE) server side. Java has been brilliant for this use case.

JEE isn't going anywhere, let's not forget that Oracle has a lot of business there. And also let's not forget that this is about Android/Dalvik.I'm concerned too, but I think a lot of people here are waaaay too panicy about the whole thing.

Indeed. We have to put this in perspective: this isn't actually about Java at all. Although I think Google have been a bit cheeky, they have a very good case. This is why the suit is about patents, not about the use of Java.

well its nice to see google spinning this to say that Oracle is suing not only them but also the open source community.

If Oracle really goes through with this and wins, who knows who they will go after next.The ref to SCO was quite fitting.

But you can rest assured, Java will die if they do win. And if they do not, Java is still threatened.

I'd really like to see what the developer base thinks about this. Does this already effect them (i.e. bad publicity for Java). Do they think it will?Let's forget about facts or whatnot, this is about emotions and they drive us.

As far as emotions go, I think everyone is over reacting. Oracle won't necessarily kill Java (they might, they've been silent and somewhat inept, but they might also have a good turn around), but fear of them killing java certainly will.

Also, IMO if Oracle does win, it could mean good things for Java. Right now, Oracle is targeting Google's Android, which isn't that big of market share of Java programs out there. Any change to Android's programming language wouldn't kill Java. If Oracle wins, they get more revenue which they very well could put back into Java.

Now all of this is optimistic (and potentially naive) but I think it's useful to realize that legal battles between heavy hitters doesn't necessarily mean bad things.

As far as emotions go, I think everyone is over reacting. Oracle won't necessarily kill Java (they might, they've been silent and somewhat inept, but they might also have a good turn around), but fear of them killing java certainly will.

I actually think Dalvik/Android sucks. It should have had a proper J2SE stack, end of. Then it would at least have been pretty fast from the outset.

Cas

I agree with you and I'm not motivated, I don't want to code on Android. Things that are usually fast on J2SE are slow on Android (getters, setters, etc...). I don't want a fake renamed J2SE on mobiles, I want a real J2SE-scale JVM with a good JIT compiler and an OpenGL access with the same OpenGL binding that I use on a desktop computer.

"J2SE Embedded" is well designed for a low memory footprint (it requires only 32 MB).

I actually think Dalvik/Android sucks. It should have had a proper J2SE stack, end of. Then it would at least have been pretty fast from the outset.

Cas

J2SE on phones doesn't really make much sense. I mean, Swing on a phone? CORBA anyone?The only problem with Android is the Dalvik VM pre-2.1, in 2.2 it's already much better (still not perfect, but really better).

J2SE on phones doesn't really make much sense. I mean, Swing on a phone? CORBA anyone?The only problem with Android is the Dalvik VM pre-2.1, in 2.2 it's already much better (still not perfect, but really better).

Ok some things could be removed but it would be fine to be able to use exactly the same libraries on desktop computers and on mobiles without a lot of painful modifications, without needing an explicit port to Android except for features that really depend on specific features of such a phone (multi-touch screen, trackball).

Ok some things could be removed but it would be fine to be able to use exactly the same libraries on desktop computers and on mobiles without a lot of painful modifications, without needing an explicit port to Android except for features that really depend on specific features of such a phone (multi-touch screen, trackball).

What painful modifications are you thinking of? My experience so far is that porting to Android is really quite straightforward and I even kind of like how some of the specific android stuff is designed.Even OpenGL ES access is pretty similar to LWJGL and doesn't require much porting effort.

In my opinion it's just runtime JVM performance that needs improvement (especially the GC). J2SE in itself is not really a guarantee for a better JVM, especially on a phone.

In my opinion that's not so much because of Android in itself, but a phone is just a *really* different platform in all aspects. So even if Android would support a full fledged J2SE implementation, the effort in porting would not be so much different as it is now. Like I said, Android's main culprit is the VM's lack of performance.

Agreed, I haven't found anything useful is actually missing from the libraries, it's just that you quickly find you're better off not using them (in your main loop) once you take a look at the allocation tracking tool. The GC is a hog.Outside of the rendering loop, on the other hand, it's all gravy.

What painful modifications are you thinking of? My experience so far is that porting to Android is really quite straightforward and I even kind of like how some of the specific android stuff is designed.Even OpenGL ES access is pretty similar to LWJGL and doesn't require much porting effort.

In my opinion it's just runtime JVM performance that needs improvement (especially the GC). J2SE in itself is not really a guarantee for a better JVM, especially on a phone.

Who said anything about Oracle killing off Java? You have to remember that there are two sides to this, Oracle and the people that use it.So this could be a 'suicide by cop' kind of thing. Bad press et al can kill your product.

What Oracle wants is for J2ME to be on the phones, not Android/divawhatever. Maybe Oracle missed the memo but J2ME sucks and exactly the reason why Google made it.

As far as Oracle putting money back into Java ... yeah, right. Put more money into it? Why? It works doesn't it? Spending money on stuff to make lazy developers happy is not really a business case.And you can bet what ever they do put into Java, won't be done because it is 'right' but because there is a market value behind it (design by comity).

Java ME's fragmentation was far worse than we would have liked. Some of it was politics in the early days, then 10 years later, small cracks in interoperability become gaping holes. A big factor was that the incredible constraints of the handsets 10 years ago made consistency almost impossible. Today's high end phones have an incredible amount of RAM and CPU, which makes interoperability hugely easier for Android.

Fragmentation limits programmers freedom because it increases the amount of work that a developer has to do to address a large market, and the larger the market you can address, the better your chances are of being financially viable. So long as handset makers are "lazy" about implementing Android and don't take advantage of the freedom they have to alter the Android source code much, life for developers can be good. But differences will creep in as the Android world ages: version skews, different bug fixes, and the handset makers attraction to "added value" and "product differentiation" will all take their toll without strict governance.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org