IST announced the launch of its Motif to Java Migration Solution, a complete solution for the rapid and automated conversion of legacy C/C++ X/Motif based applications to the Java Platform.Based on a blend of tools and services centered on IST’s X-Designer and Visaj development environments together with a suite of in-house translation tools, this migration solution significantly speeds the ordinarily complex Motif to Java migration process. This unique technology addresses the conversion to Java of both the application’s Motif-based GUI front-end and the back-end toolkit dependant code significantly reducing the amount of re-coding work required to complete such a migration.
IST Launches Motif to Java Migration Solution
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
move anything that has GUI to java platform…oh ye..WOR(s)A thing: write once, run (slow) anywhere..
eh,I would keep java as server side….till we get some really speedy processors..
move anything that has GUI to java platform…oh ye..WOR(s)A thing: write once, run (slow) anywhere..
Amen. Limewire is one of the few applications I run that makes my 2.4GHz Pentium 4 feel like a 200MHz Pentium. I swear it takes longer to start up than Windows XP does to boot.
eh,I would keep java as server side….till we get some really speedy processors..
In implementing a multinetwork short message utility, I noticed that one of the cellular carriers’ text message gateway took an unusually long time (20 seconds) to send a message, whereas all other systems were virtually instantaneous. Said service was also implemented in JSP. Coincidence?
Coincidence?
Yes.
Yes.
Heh, touche.
I run SUN Forte for Java using Java 2 1.4.1_2 on both my x86 Solaris and Sparc Solaris, both work at a reasonable speed. Sure, it is rocket fast but it is perfectly usable and loads in a reasonable space of time.
The people who complain probably have a piss poor amount of memory and a shit slow hard drive. 99.9999% of the time when users complain about responsiveness is because they have a crappy amount of memory, namely 128MB and a crap slow hard disk, aka, 5400rpm. I am running a Pentium III 550Mhz with 768MB RAM and a 60gig 7200rpm hard disk, java applications load with out a sweat. I say the speed issue is more about cluess morons with cheap ass computers running a century old version of Java on a third rate version of Windows, namely Windows ME.
For the sake of completeness, ICS who is the other commercial grade Motif GUI builder provider has just launched a similar tool in addition to a Qt training program.
The people who complain probably have a piss poor amount of memory and a shit slow hard drive. 99.9999% of the time when users complain about responsiveness is because they have a crappy amount of memory, namely 128MB and a crap slow hard disk, aka, 5400rpm. I am running a Pentium III 550Mhz with 768MB RAM and a 60gig 7200rpm hard disk, java applications load with out a sweat. I say the speed issue is more about cluess morons with cheap ass computers running a century old version of Java on a third rate version of Windows, namely Windows ME.
Your point being? These same sorts of applications, if implemented in C/C++, could run on the sort of low end system you’ve described without problems. Saying Java’s slowness is a hardware problem is definitely dodging the real issue…
Don’t you have any regrets that your choice of programming language dictates to these people the minimum level of hardware/software that should be considered acceptable? Why force people with working systems to upgrade?
“The people who complain probably have a piss poor amount of memory and a shit slow hard drive.”
Yes, Java will work fine on the UltraSparc 80 with dual 800 Mhz processor and 1 gb of memory. However, not all people want to pay $ 15.000 just to run a Java program, when a $ 199 PC from Wallmart will be enough when you use native programs.
Well, okay, you do not need an Ultrasparc but a pc is mostly used about three years. And how many pc’s between 1-3 years old have 768 MB memory?
Ya all must be running some pretty poor implementations of Java. My server/gateway is a 333MHz PII box and runs a Java based proxy server. It loads in about five seconds and is lightening fast.
Java isn’t as fast as C, but it’s no where near as bad as people claim. There are applications that shouldn’t be written in java, but for general purpose programs modern PCs are up to the task.
>Limewire is one of the few applications I run that makes
>my 2.4GHz Pentium 4 feel like a 200MHz Pentium. I swear it
>takes longer to start up than Windows XP does to boot.
it slow to startup. yes. so what? you are talking about a program used to share files on a network. that’s not a text editor that you open and close a zillion times in a day. that’s a program that you start and let running for hours. so wait some seconds or change program, it’s simple. isn’t it?
so wait some seconds or change program, it’s simple. isn’t it?
I no longer have LimeWire installed, partially due to its horrible slowness, and partially due to the poor design of the Gnutella network, which is now essentially useless.
LimeWire had a wonderful UI, perhaps the best I’ve ever seen in a p2p application. I’ve since switched to WinMX, which deserves a high ranking position in the Interface Hall of Shame. However, with WinMX I don’t have to deal with infuriating start up times… and the GUI, despite its poor arrangement, doesn’t lag.
I agree. I think Java is a fast language, but it has a lot of overhead (in startup and RAM size). When people say, “Java is slow because my application takes 45 minutes to startup” they are mostly referring to the VM overhead and not the actual speed of the language.
With the JDK1.4, Java is suprisingly fast using the JIT VM. For example, for numerical operations it is much much much much (orders of magnitude) faster than using an interpreted VM from JDK1.3, and several times faster than equivalent scripts in, say, Python (which should be getting a JIT compiler soon, though). One thing about the JIT’ed code annoys me though, it is ‘forgotten’ after the program exits. It would be nicer not to have to incur that startup cost every single time (so-called ‘delayed compilation’)… then startup times would probably be reasonable. I think this is what .NET does.
As a matter of fact, there is a Win32 program called “JET” which translates .class files into .exe native files. It’s expensive for the super-duper version, but boy does it make a difference.
One thing is for sure — there are crap applications in Java just like there are crap applications in C++. With Java though, you usually (ironically) have to be more careful about memory allocation because the garbage compiler is a stingy bastard and usually doesn’t like to give memory back after it’s been allocated. Sometimes I really wish there was a “delete” keyword in Java, in fact I really don’t know why you’re not allowed to explicitly remove objects from memory…… having GC taken care of for you (setting things to null) is nice, but for performance-intensive and especially memory-intensive operations that would be invaluable.
To help with memory, perhaps a shared VM between Java processes could be used, something like Mozilla’s quickstart. Or, perhaps an option to (almost) fully compile code in native binaries and cache and still have part of the code JIT’ed. This would be best of both worlds — you would get better startup times, but the benefits of ‘intelligent’ dynamic compilation.
One thing about the JIT’ed code annoys me though, it is ‘forgotten’ after the program exits. It would be nicer not to have to incur that startup cost every single time (so-called ‘delayed compilation’)… then startup times would probably be reasonable. I think this is what .NET does.
Yes, .NET compiles MSIL to the native instruction set at which point it is stored in the Global Assembly Cache. After the compiled MSIL has been cached, application startup times aren’t much worse than the time required for non-prebound dynamic linking.
With Java though, you usually (ironically) have to be more careful about memory allocation because the garbage compiler is a stingy bastard and usually doesn’t like to give memory back after it’s been allocated.
I believe this is a design decision made by Sun out of concerns for performance. Java will not actively attempt to reclaim memory until the system is low on resources. This is especially problematic when a Java application is running and a resource intensive application is started. Java may already be consuming so much memory that the resource intensive application can’t start. I’ve experienced this very problem on an application I work with here… we attempted to introduce a Java application to manipulate atmospheric modeling output. This application was to serve as a replacement for an older, buggier, and less feature-filled Motif application. The application did process large data sets (50-400GB) which seemed to make it especially problematic as far as memory usage. When people discovered that they couldn’t start the modelling program with the Java implementation of viewer program running, virtually everyone switched back to the buggier Motif application, simply because the Java one was too resource intensive to allow them to get their work done.
Sometimes I really wish there was a “delete” keyword in Java, in fact I really don’t know why you’re not allowed to explicitly remove objects from memory……
This is a somewhat unrelated matter, but after discovering System.gc(), I was incredibly amused by the wording of its description in the documentation:
[ From http://java.sun.com/products/jdk/1.2/docs/api/java/lang/System.html…) ]
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse.
Call me old fashioned, but I prefer a language where commands are commands, and not “suggestions” that the underlying system “expend effort” towards some task
“Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse.”
🙂 Sometimes I have this mental image of the GC code sitting in RAM as a Slashdot troll…
Me: System.gc();
VM: First post!
Me: No dammit, give me my RAM back you arse
VM: HOT GRITS!
Me: Aaaargh…
Me: System.gc();
Me: System.gc();
Me: System.gc();
Me: System.gc();
VM: Slow down cowboy….
Bascule is .NET puppy. He is always posting things related with Java’s slowness etc. Why should we care at all? I’m happy with Java. It is quite fast. If you people are not satisfied with the VM overhead, wait for java 1.5, or grab a free native source compiler. I am not very unhappy about it, since i use the program for hours after running it. 1 minute (exaggerated, but, anyway.) initialization lag is nothing when compared with hours of usage.