One of the big selling points of Java has been its "write once, run anywhere" capabilities. Of course, in practice, this has always been "write once, test everywhere" you intend to deploy your chosen application. With the planned purchase of BEA Systems by Oracle, I got to thinking about what this meant for the "write once, run …
Krakatoan Tao .... East of Java
Microsoft are also busy on the same issue.
"The single server, single management group configuration is the easiest to deploy, but there are limitations to its capabilities and therefore limitations to what it is commonly used for." ..... Microsoft System Center ..Operations manager 2007.
There are no limitations should ITs Lead Configuration, ITs Drive, not Heed or Recognise Limitations, Preferring to Process Endless Opportunities for Servering to HyperRadioProActive DirectAXXXXIOn Virtual Joint Add Venturers...... AIdD Pioneers, Magical Mystery Turing.
email@example.com appears to be offline. Messages you send will be delivered when they sign in. E-mail this contact instead | Add a mobile number for this contact
Seems like a Good Plan, so I did. A little something luvly jubbly, to savour and flavour, before la Maison Perly Gates. :-) Free Gratis too...... for Monetisation. Bill's Penchant/ESPecial Gift?
write once, crash anywhere, but only after it's hogged all the resources on what so ever computer you have.
One of the problems of course, is competition. If BEA and IBM (and Glassfish and JBoss and ...) were supposed to be 100% compatible, there would be nothing to distinguish them, apart maybe from ease of use, performance and price.
Obviously, different vendors are going to put in value-added non-standard features and if you use them, your application won't run in another container without modification.
Unfortunately, many of those value-added features made J2EE 1.4 bearable and you could not live without them. The Java EE 5 spec is much better, so I hope that from now on this will be a lesser problem and programming to the lowest common denominator actually makes you end up with a decent, run anywhere, application.
Oracle = proprietary
First of lets just say that in the Monopolies Commision etc. were allowed to do thier jobs this takeover would not have been allowed (Company with 15% market share swallows company with 40% market share , duh?).
Second if the Siebel experience is anything to go buy Weblogic customers will be offered smooth migration to Oracle Application Server and the BEA product will slowly fade from view.
Thirdly it is not in the interests of a software suplier with a large market share to follow industry standards. Small suppliers have a vested interest in making it easy to migrate to thier product, large suppliers jave a vested interest in making it difficult to migrate from thier product.
Fourthly it is only a matter of time till the world wakes up to the fact that ".NET" is J2EE done right. Anyone embarking on a large scale project using J2EE without considering the .NET alternative deserves all the "xml" config files they get.
Wow... Sun Light ...... what day is IT?
"Fourthly it is only a matter of time till the world wakes up to the fact that ".NET" is J2EE done right. " .... By James Anderson Posted Friday 14th March 2008 08:13 GMT
Yeah, that can be Right and requires .NET to Splash the Cash to J2EE Done Real Good. ........ Feed for the Intellectual Property Machinery
"Fourthly it is only a matter of time till the world wakes up to the fact that ".NET" is J2EE done right. Anyone embarking on a large scale project using J2EE without considering the .NET alternative deserves all the "xml" config files they get."
Cool, where can I get a version of .NET that will run on my Solaris, Linux and FreeBSD servers? Oh, I can't - granted, there's this Mono thing, but it only runs reasonably well on Linux and it's an incomplete subset of .NET. So I've got to migrate to Windows to run this fabled "J2EE done right", which is a problem as I'd need much more hardware and a wheelbarrow full of cash to pay for the licensing.
J2EE, whether you're using EJB 3.0 or a lightweight framework like Spring, is far ahead of the game compared to .NET. Yet again, MicroSoft aren't innovating, but playing catch up since they wasted so much time trying to extinguish Java. After all, why would I want to run my portable Java code on an OS like Windows that struggles to use anything more than four cores or processors?
As for the usual bull about "write once, debug anywhere", in eight years working primarily in Java, I have never encountered a portability issue. I've seen naive programmers hardcode paths into their applications, but that's their fault for not being competent enough to use a build tool like Ant or an IDE which can at least parameterise such things. (Not that this degree of "unportability" doesn't afflict .NET apps ...)
Purely language-wise, if we just take the CLR functions, .NET is vastly superior to Java and better organised, if we compare Java and C# I'd prefer C# any day. On portability Java is going to be more powerful for a while yet, and I'm sure it'll still be around in some capacity in 10 years in some capacity, a bit like C++, which Java was meant to have killed off 10 years ago.
Write once, run anywhere.... lol
I always find the write once, run anywhere claim of Java to be one of the funniest. Anyone with any real world experience of Java knows that any complex app will be written to run on a particular JVM and will generally either fail to run or at best have different performance characteristics on another JVM. Unfortunately, to try and achieve "Write Once, Run Anywhere" Sun cripple the language and environment. The great example I love is the problem of writing something to read a password in from the console and not echo the characters. In the end, the reason C# has grown so quickly is simple because Java is nothing more than "Cripple everywhere, run somewhere". At least C# doesn't have pretensions of portability.
If you want genuinely portable code, write it in C like any sensible person.
Did you just criticize Oracle for being proprietary and a monopolist, and then plug Microsoft in the same post? Wow...
It really boils down to the implementation
Take these sentences: "For example, we had an application running on one hardware platform using a 64-bit JVM and all was fine. In moving to a new platform, there was only a 32-bit JVM available. On this platform the application suddenly started experiencing out of memory exceptions." What was he doing? Some high performance application that soaked up every iota of memory on the system? In general, the java apps I've worked with do not do this when going from platform to platform, so it's something in the code.
Odds are all too good that it is another app where the developers "assumed" they had unlimited amounts of memory available, and good memory management practices went out the window. Or, worse, they just didn't give any thought as to the memory footprint. No wonder most java apps are slow, clunky memory hogs. Just because the platform reclaims unused memory doesn't mean you don't need to manage it. I can write a perl script for ETL that can use everything our mainframes have and then some, or I can write them to manage what I use. It's up to me and my program, not the language.
I speak from the receiving end of having to push these apps out and manage them -- not all apps are equal, and not all coding memes fix things. Remember the coders that thought their memory problems in wfw 3.11 would go away with win95? It was BS then, and it is BS now. Well written, .NET and java apps are useful and portable. So are perl scripts. But when good practices go by the wayside, portability is lost.
It's not to say that they are poor programmers -- just that apps written that don't follow portability guidelines and best practices won't port all that good, and who should be surprised? As to waving the magic .NET wand at it -- wow. Portability within the Windows platform? <sarcasm>Mighty portable, mighty portable.</sarcasm>
"if we just take the CLR functions, .NET is vastly superior to Java and better organised"
And you clearly don't know what you're talking about. CLR is the runtime environment (bytecode compiler / interpreter), the equivalent of the JVM. The bytecode instructions for both are remarkably similar, which isn't surprising since the CLR evolved from J++ (the deliberately incompatible implementation of Java that got MS into legal hot water).
I think you meant that the .Net class library is "vastly superior" to the Java one. While there is some cruft in the Java class library (just how long are come things going to be deprecated before they're removed?) the differences are minor. The only area where differences are considerable is in the GUI components, and it took a long while for MS to even provide a decent layout manager.
When it comes down to it, the differences between C# and Java (the languages themselves) aren't enough to say one is better than the other. Likewise for the class libraries, although much more third party software exists for Java than C#/.Net. It's really whether you want to be tied to a platform like Windows, with it's indifferent performance, limited scalability, expensive licensing and legendary security issues.
Wow, where to begin?
Oooh, a topic for me. To add to your list:
1. Converting from byte to String without specifying the encoding. Good trap for young players this - 7-bit bytes work fine until... until... you run on an OS/390 box running EBCDIC.
2. java.nio. An absolute dogs breakfast this. Garbage collection is different on Windows or UNIX (to be fair this is due to differences in the underlying file system model, but Java should be abstracting this). If you're copying files to an SMB mounted drive on windows using nio, the maximum block size is 62MB. The maximum number of open files on Sun/Windows 1.4 is much smaller than it should be. The list goes on.
3. Swing. Yes, this should be obvious, but it's not just a case of different layouts, it's different functionality too. I give you JComboBox.setPrototypeDisplayValue, which does not work as advertised on Windows. And don't even start me on the GTK+ widgets. Any moderately complex, well designed UI really has to include different code for different LayoutManagers.
4. Memory requirements. Back in the bad old days on JDK 1.4 we found simply switching JVM from Sun to IBM on Linux raised memory requirements by 50%. Again, less of an issue now but still crops up now and again.
5. JVM bugs. Goes without saying I suppose. The IBM 1.3 JVM was big trouble, but even though it's much better now we still hit a few. We have IBM, Sun, JRockit and Apple JVMs here and find ourselves needing to test on all of them more than I'd like.
6. Security. Different JCE Providers supply different algorithms, different root certificates and have differing support for X.509 Certificate extensions. This is a definite issue for us, although things are much better than they were with Java 1.4.
7. Locales. A variation on point 2, but the number of questions we've had when a client has moved from staging to production and found all their ISO-8859-1 characters are now mapping to some Windows codepage are now legion.
That's off the top of my head, that's just J2SE, and that's ignoring the obvious no-no's like calling the com.sun packages directly.
Obviously things are a lot better than coding in C, but I can guarantee that if you're developing for multiple customer environments, any form of I/O to disk, screen or network is a potential problem.