Networking: GM, GE embracing Java

United Press International ^ | August 15, 2005 | Gene Koprowski

[kerrywearsbotox]

CHICAGO, Aug. 15 (UPI) -- General Motors Corp. is embracing Java-based technologies -- hoping to drive down decisively the cost of integrating network applications used in manufacturing, purchasing, sales, marketing and even engineering, experts told UPI's Networking. The GM decision -- along with a deal disclosed during the first week in August by General Electric Co. -- signals the mainstream corporate acceptance of Java. By Gene Koprowski

[kerrywearsbotox]

Many companies are using Java-based technologies to drive down costs of integrating network applications.

[dr_who_2]

Nifty. Who's using .NET software? And where are all these Java programs? Are they mostly web-dependent applets, or what?

[Keith in Iowa]

My employer is using .Net & Java applications for ASP products for our global clients in the financial services & accounting industries. User interfaces are browser-based.

[Myrddin]

I used C++ .Net to implement a voice recognition driven door to door routing system. The managed C++ eliminated much of the typical pain of standard C++. It completely eliminated the need to track down memory leaks and over/under runs of arrays with BoundsChecker. I used C# to implement all the web interfaces to external systems via HTTP. Internal interfaces were done with C#/XML to interact with the Webraska geospatial server (Java based). All database interfaces with mySQL were done from C#.

The user interface on the Windows desktop was coded in C# using the restricted Compact .Net Framework. All the networking code moved to the HP5555 PDA unchanged. The only part of the user interface that needed a change was the screen geometry because of the small screen on the PDA. Totally portable.

I've been down the Java road from 1996 to 2000. It was Ok when used to implement "lights out" processing on servers. Very small applets work fine too. Java is a major league failure when people try to deploy mega applets over an internet connection. I had a German customer that wanted a mega applet for a maintenance application. They worked with us every step of the way. We delivered exactly what they requested and passed all the functionality tests when Windows machines accessed the database server via a local area network. The fly in the ointment was discovered when the application was deployed on the corporate network. The outlying offices had ISDN lines (2B+D). Downloading a 2.5 megabyte applet over a line that slow is unacceptably slow.

I've just joined a project that is struggling with a networking implementation in C++. The early project members have already run for the hills. The C++ has to be portable across Win32 and Linux using native Windows Win32 threads and pthreads in Linux. Argggh. One of the many vendors in the mix adopted the ACE/TAO CORBA package (C++). A part of that library has a global delete of malloc'ed memory that trashes the heap...very shortly after startup. Too bad the stuff wasn't coded in C#/Mono. It would have been portable, thread safe and a bunch more stable. Now I have a new millstone to wear until the bugs and design flaws are hammered out of the system.

[Jeff Chandler]

The user interfaces at Home Depot appear to be JAVA based.

[stainlessbanner]

ping ping

[cspackler]

Java efficiency is also a design issue, just like any other code base. Our application is pure Java, deployed to the client as a Webstart app. Requests are sent to the app server, all data is retrieved and packaged on the server side, and delivered back to the client ver the internet.

It's all in the design. A 2.5 MB applet is just plain nuts.

[monkeyshine]

I have contracted with two teams to integrate certain aspects of my business. One team is working in Java. They are weeks and weeks behind schedule as compared to the PHP aand HTML programmers. It's very annoying. I dunno if its the team or the technology but as a result I am turned off by Java.

[AFreeBird]

It's all in the design. A 2.5 MB applet is just plain nuts.

Yep, 2.5MB kinda takes the "let" out of applet.

Still, like you said it's all in the design. Even if you had to have an app that was that large, it could still be downloaded to the client on first run and run from the client from then on, unless a check revealed that a new version was available and then downloaded again.

The difference between that approach and the windows driven install application is: the java based app works on any java capable browser and OS. Which of course is the whole point of java.

[AFreeBird]

I have contracted with two teams to integrate certain aspects of my business. One team is working in Java.....

Without knowing the details of certain aspects of your business, the architecture on which it is to be implemented, and the goals and constraints you have placed on those teams, it would be difficult to asses what the problems are, and whether or not the problem is java, the teams, or your expectations.

[smokeman]

It's the team. I have been programming in Java since 1996. Believe me when I say, it's not a complicated language to learn especially when compared to C or C++. (e.g. no malloc and no pointers)

[smokeman]

Still, like you said it's all in the design. Even if you had to have an app that was that large, it could still be downloaded to the client on first run and run from the client from then on, unless a check revealed that a new version was available and then downloaded again.

You have just described Java Webstart.

[AFreeBird]

You mean I wasn't the first to think of it? Darn, there goes my beech front Maui vacation home...

;-)

[DenverCossack]

Well, GM will go out of business for sure now. Every Java project I have seen (about ten different companies) runs over cost and takes about twice as long as other technologies. Just as well, we have one too many car companies in the US right now anyway.

[monkeyshine]

Maybe Java is great, but perhaps too great for most applications. I mean, simple relational databases exist in so many forms. Our team is doing the slightly more involed part in Java. I think for what we are doing PHP would've been fine. The HTML/PHP team completed their project on time and under budget, the Java team is months behind and claims to be over budget (my price is fixed for the project). I get the impression it may be good and secure, but perhaps too much for most small to mid size implementations.

Not to mention the gosh knows how many hours they've spent trying to get the two to interface and share data. I flat out told the Java people they should've done it in PHP - because for my app why do I want two (or three) different interfaces to manage data? I guess I am being vague but suffice to say I am disappointed in the team, at least, and it makes me think Java is overly complex for more simple relationships.

[cspackler]

That's where Webstart comes in. Loads the application once, and detects automatically when the app is changed to download new versions if necessary. Quite nice, actually.

[Myrddin]

Recall the timeframe here for Java. It was 1998-2000. The customer insisted on using the Netscape browser. I modified the code to run on Internet Explorer and it ran 10 times faster because the memory managment in the Microsoft JVM was much better than the Sun product. The project was nearing completion just as the first usable releases of Java 2 appeared. Too late to switch to the new release because of the vastly revamped security model. The OptimizeIt native Java profiler made a huge difference in being able to deliver satisfactory performance to the customer. I also used a product from Parasoft to expose potential soft spots in Java methods. It autogenerates calls to methods with a variety of whacky data that has the potential to blow up. Defensive coding against the mechanically generated attacks made the code exceptionally robust and stable.

The recent improvements in Java that would allow a download that persists until the code on the server changes would have been a big help to that customer. Frankly, I would have preferred a real desktop application that could have been installed once on the desktop, but everyone was convinced that the applet/network model was THE fix for delivering code and fixes on an ongoing basis. The auto-update model of tool like the Adobe PDF reader makes more sense for a complex application that needs top local execution speed.