Oracle's Ambitious Plan For Client-Side Java

snydeq writes "Fatal Exception's Neil McAllister suggests that the real news out of this year's JavaOne is Oracle's ambitious plan to revitalize Java on the desktop, the Web, and mobile devices. 'It's been tempting to assume that Oracle, with its strong enterprise focus, would ignore the client in favor of data center technologies such as Java EE. This week, we learned that's not the case. In fact, the real news from this year's JavaOne conference in San Francisco may not be Oracle's plans for Java 8 and 9, but the revelation that Oracle is gearing up for a new, sustained push behind Java for the desktop, the Web, and mobile devices. If it can succeed in its ambitious plans, the age of client-side Java could be just beginning.'"

Comments

licenses

[roman_mir]

I have a set of systems I am building that are used by a store chain. It's my line of products, one of the components is a store management system that is used in the stores. Every piece is server/client, but in this component the client is a Java swing application that also can be used as an applet (that's the good part about Java, with minimum work you can have it working as an applet if it works as an application.)

So I know that most people on /. are derisive about such solutions, but I am moving the stores from Window platform to GNU/Linux (Ubuntu actually). Of-course it's possible to build everything in C and C++, etc., but when the entire solution is java with every component on every server / client, even though most clients here are thin, that run in a browser of choice, using Java as a client is really the most logical thing.

Every component is compatible with each other, the communications between components are all built in exactly the same manner, be it a server-server or server-full client.

The important thing is that moving from Windows to GNU/Linux is easier, because the look and feel stays almost the same.

The one real problem for me is actually some driver for certain types of devices, like zebra thermal printers and such, but that's not a problem with Java itself, that was a problem with moving the clients from Windows to GNU/Linux (haven't figured this out yet, so one of the computers in stores is still Windows, because the configuration and font setup software supplied with the Zebra printers is for Windows.)

I can accept the hate, that the Java solution may not be wonderful or uber-cool or whatever the current feelings are about what people hate today, but the point is that it's working. If I couldn't get it to work, I would have had no choice but to go with something else, but that would require extra work, to get it all communicating with the server sides, that are Java based.

The speed of this application totally depends on the data model, database work, algorithms and communications, but the Java GUIs themselves are not presenting any major problems. If I want to, I can even style the main frame of the window with anything, any kind of graphic that doesn't look like a normal window, this works with JNI, but I don't really need that in this project.

I have used this in a browser as an applet and I have used this to communicate over the Internet, not just within the stores themselves, which is an interesting feature.

So can somebody tell me what they think I should be on a look out for here? Is Java going to blow the fuses or are the tables going to catch on fire?

Re:licenses

[Anonymous Coward]

We thought (signed) Java applets would be a sound method to get cross-platform client software onto desktops. What we found is that the browser plugin from Sun/Oracle and even OpenJDK is buggy and unstable on most platforms. We get assertion failures out of the plugin loader that have been listed as bugs on Sun's tracker for almost a decade, as well as bizarre GUI related exceptions. Things seem to get worse the more you use the applet/browser interfaces, for example to access the cookie store or the page DOM.

It crashes or hangs Firefox and Seamonkey on Linux x64 perhaps 10% of the time the applet loads. It crashes Safari on Mac OS X over 50% of the time. It seems most stable, but still not foolproof, on older Windows systems.

Re:*yawn*

[Xugumad]

> resource and memory hog

Got anything to show it's worse than .Net?

> there's tons of Java exploits out there but none for .NET

What, language-level exploits in Java? Care to give an example?

> Java development is light years behind .NET and C#.

Erm. Hey, quick, distraction! Behind you! *runs*

Seriously though, yes Java lags behind in features. Cross-platform development; Java runs on Windows, Linux, the BSDs, Blackberry phones, Android (well, it's a close varient) and frankly pretty much everything else too. I'll admit game development in Java is decidedly mixed (I believe, anyway, have never tried it myself).

Ultimately, there's a lot of code out there in Java, and it's not at all a bad platform, the world does not move on just because something a bit better comes out.

no need. javascript has too much momemtum

[GodWasAnAlien]

Google was the best bet in bringing Java back to life.

But Oracle is suing Google for making Java somewhat popular again ...

I imagine even Google will give up on Java at some point with some new platform that exposes binder services to javascript, deprecates Java, and merges with Chrome OS.

Re:*yawn*

[Xugumad]

Brilliant, now try making it run on OpenBSD. Too weird? How about OS X?

Well done, you used a tool appropriate to the job, and got a good result. I've written C# apps to integrate with MS Office, platform-agnostic server apps in Java, high performance stuff in C, text processing tools in Perl and text adventures in Inform. In all cases, the language fitted what I wanted to do, well, but that doesn't make it inherently better than another language in some grand scheme of things.

Re:No Thanks

[Cwix]

If these IT monkeys really wanted to remove the most targeted attack vector from their "users" machines they would replace "Windows" with something secure.

Actually if they wanted to remove the most targeted attack vector they would remove the users from the machines.

HTML5 etc.

[lkcl]

um, i know it's being said quite a lot, already, but it's worth repeating: java's pretty much dead on the desktop. people are even replacing Flash applications with HTML5, as it's reaching high market share and maturity, especially now that IE9 has actually better (read "stricter") HTML5 compliance than the Free Software equivalents. how in god's name is oracle expecting to break into that?

the other thing that's worth emphasising is that when you have alternative language bindings to HTML5, you get the best of both worlds. so... why doesn't oracle put its money behind getting java bindings (or, better "generic" bindings like DCOM and XPCOM) on top of HTML5 browser engines? with Trident (the engine behind MSHTML aka IE) that's a done deal already: Trident (MSHTML.DLL and MSXML.DLL) already *has* DCOM bindings so it's a matter of about 2-3 weeks to get something like that up-and-running. XPCOM (XulRunner) is a little trickier: you'd have to find or create java bindings to XPCOM (they don't exist afaik) and the hardest (technically speaking) is webkit (used in android, safari, ipphon etc.)

then you have literally the best of both worlds. HTML5 as the "front-end", and whatever-language-you-choose to control and direct it. btw this is exactly what's been done for the pyjamas project (http://pyjs.org) except using python not java.

Re:Time to move on

[leenks]

SWT is awful. At least Swing is pretty clean, and logical. SWT is often utterly insane - look inside the code for proof of that. Swing is also totally extensible. SWT is not (the number of classes that state the class is not final but must not be extended is quite impressive). I say this as someone working on a small (450k semicolons) SWT/RCP application which integrates components written in Swing, JOGL and Processing.org.

Re:Never ever going to happen

[angel'o'sphere]

Dalvik which used a different byte-code format that is almost a one-to-one byte code replacement to the JVM format.

That is incorrect. Javas byte code manipulates a stack, the Dalvik VM is a register machine.