Slashdot Mirror
Java's Backup Plan If Oracle Fumbles
GMGruman writes "In an InfoWorld blog, Paul Krill suggests that those concerned that Java might get lost in Oracle's tangle of acquired technologies should relax a little: Java's future isn't wholly in Oracle's hands, so if Oracle screws up or lets Java languish, the popular language has other forces to move it forward nonetheless."
Oracle uses Java for supporting it's bread and butter database.
The Universal Installer is written in Java as are a number of other tools.
It would cost Oracle millions of dollars to rewrite these tools if they killed Java.
They could still kill Java but it it would not be an easy decision for them to make.
Oracle will not let Java languish, they need Java to exist because it's part of their ecosystem now whether they wanted it or not. It's a lot easier to connect to an Oracle database using Java than it is with .NET, and Oracle really doesn't want .NET to win since MS SQL is now a viable alternative(and substantially cheaper) than Oracle for all but the largest of data sets.
The issues for Java are either Oracle getting into a fight with IBM and resulting in a fork of Java or distrust of Oracle pushing a critical mass of developers away from Java and onto .NET. As to the first, Oracle has to suppress their natural desire to charge like wounded bulls for everything they own, and try not to interfere with the JCP much at all, which is a big ask really. For the second, it's already starting to happen in certain areas. There are shops out there who have spent an awful lot of time and money getting Oracle out of their DC and they don't want it back again.
The issue was violating the the compatibility constraints, so that code would no longer be portable to non-Windows O/S. This was precluded by the license which MSFT signed, so the lawsuit was reasonably decided.
C# is really more sort of the averaging of Java and C++ than anything else, and VB is now C# with a slightly different syntax(sort of wish Microsoft had the balls to just end it rather than farting around with putting god awful VB syntax onto a language which is nothing like it.
I do agree that Microsoft needs to do something about the exceptions though, not necessarily checked exceptions cause those are a pain, but some easy way in Visual Studio to get a list of exceptions that can be thrown by a call so you know what you could check for. You're also right about javadoc.
That said, LINQ is just incredible, and IIS with .NET is a hell of a lot easier to configure and tune than Tomcat, it's really 6 of one and a half dozen of the other with Java and .NET at the moment, which is why what Oracle does is so important.
Oh wait, i thought this was a poll.. Nevermind.
---- Booth was a patriot ----
You are insane.
Not only there is constantly new Java code written for the back end, not only there are millions if not billions lines of code that are running existing services on the back end, but people are writing front end code in Java, at least for corporate environments.
How do I know? I am writing some of it.
You can't handle the truth.
Java's cross-platform compatibility has always been a myth
Don't talk nonsense, man. Back that up with something.
If you write the code properly, and stick to Java (no JNI stuff), it's cross-platform. How is that a myth?
You have an aptly chosen user name. Not only is multi-threaded programming in Java quite easy to use, Java hasn't been interpreted in quite a long time.
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
Is Java doomed to get stuck behind in the single processor world
Far from it actually... of course Java has had the absolute low level concurrency primitives from the very beginning (Threads, synchronized blocks, wait/notify). More than half a decade ago, the java.concurrent library was added to the platform, which added tons of goodies for concurrent/parallel programming like concurrent maps, blocking queues, thread pools and executor services, cyclic barriers, programmatic locks with timeouts (which actually performed better than the build-in locks based on the synchronized keyword) etc.
Now Java 7 will be extended with the join/fork framework, which is essentially a thread pool and support code for (recursively) computational intensive operations and supports advanced features like work stealing. The join/fork framework has been specifically designed to scale into the many, many multi-core range. Not just quad, hex or oct cores but well beyond that.
Parallel array is another topic on the agenda, which allows you to express in an almost declarative style operations on arrays, which the library will then execute for you in parallel. To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest.
This blog post has a nice summary about some of the added concurrency items in Java 7: http://www.baptiste-wicht.com/2010/04/java-7-more-concurrency/
Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.
Don't knock COBOL.
I know a couple of folks who are making a nice living as a COBOL programmer. And they're not that old. AND, when the majority of the IT market craps out, they always seem to have or can get a job. That's something not many programmers can claim.
RIP America
July 4, 1776 - September 11, 2001
"Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance."
The same is true for invoking methods through reflection. Or transforming bytecode through custom classloaders, etc.
But these are low-level techniques that should be used with care -- exactly because they can break things in unexpected ways. But this is not an argument against checked exceptions.
We have java swing code that runs on window, linux, and os-x. We use a custom look-and-feel so things are consistent. Ok, the one-button mouse is a pain.
We java backend code that runs on intel (windows/linux), powerpc, and arm. I routinely deploy and test on linux-x86 and deploy to powerpc and arm targets with zero problems.
Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.
That's the fault of the programmer(s), not Java.
Besides, while you have valid points, they are irrelevant to the topic at hand; MS signed a licence saying that they could not introduce Windows-specific classes into the java.* package hierarchy, and yet they did so. No one would have cared if they'd put them in com.microsoft.*, but they chose not to do so.
It's official. Most of you are morons.
But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment,
Besides Apple no one cares about consistency on the Desktop anymore. Have you looked at Microsoft apps lately ? Visual Studio looks different then the rest, Office looks different from the rest, Outlook looks different from the rest of Office, Media player looks different from the rest, Home Server UI looks different from the rest and I could go on and on.
and this only got worse as Sun kept cranking out a shitty new theme with each release of Java.
In the like 14 years of Swing existence there have only been 3 themes in the JRE: Metal, Ocean and Nimbus. And metal is selected by default. Java never sets one of the newer themes by itself. So basically the default theme hasn't changed.
Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.
So there are people who make crappy programs in Java. How exactly is that different from other languages ?
early on we had to use JDBC drivers that depended on native code (it was a few years before pure Java JDBC drivers were available for some database systems).
A few years before pure JDBC drivers were available ? That was when, 2000 or something ? Since that problem is long solved I don't really see how thats relevant today.
Java has never really been a viable option on Mac OS X, and Mac OS before that.
Apple does the Java implementation by their selves, not Sun / Oracle and yes, it shows. If Sun had done the Mac OS X implementation for Java it would probably be better.
Elegance? Closures? Now you have me scared. Really scared.
The most serious problem with Java today is the whole complexity of the generics feature added in Java 5. Typing container classes was fine (and the only thing any working programmer I have talked to actually uses), but as soon as you venture beyond that it descends into a nearly incomprehensible API, all in pursuit of the elusive and trivial pursuit of absolute type safety (at which it fails anyway). Angelika Langer's FAQ about Java generics is 512 pages long. One of the world's leading Java experts, Ken Arnold, cannot explain the meaning of the Enum generic class's definition, I could go on and on.
As a whole the generics is a useless and dangerous disaster. If you mastered Langer's FAQ and could actually write code using generic wildcards no other programmer could understand and maintain your code. And I am doubtful that you could yourself, 6 months later. Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field).
And the root cause of this disaster, as opposed to a useful tweak (typing containers and letting it go at that) is the search for "elegance" in a formal Comp Sci PhD dissertation type way.
What we need right now is for whoever is guiding Java development to find away to back out of the generics disaster to simplify the language and leaving only features people can actually use. This will clear the field for actual useful innovations.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
I have to agree with you here. I develop (for corporate environments) in a fairly large range of languages depending customer desires. The trend has been (for several years now) that more and more development is being done in Java, whether rewriting legacy systems or completely new development.
The benefits that Java offers are more compelling than just about any alternatives. The arguments against its ability to "run anywhere" are old and most (if not all) are largely inconsequential to todays environments.
A majority of development today is web-centric (intranet or internet) so issues with AWT or pathname incompatibility across systems are rarely encountered, and when they are, there are plenty of best-practices for dealing with them.
The old line about Java performance being inferior is also largely a dead issue as it's be shown time and time again that the newer JIT enabled VMs allow byte code to perform on par with native C/C++.
As far as being a dead language, I certainly don't see that happening any time soon. The language is under constant development and significant new features are being added with each major release, both to the platform (performance, concurrency, garbage collection, etc) as well as the language itself (modularization, closures,annotations, etc). The language is constantly evolving, but still, as much as possible, retaining backward compatibility.
Even if the language itself is not able to keep up with advances in modern language design, there are spin-offs like Scala that can co-exist in the same JVM and are able to take advantage of the large java eco-system while providing a different programming paradigm.
I gave up being an fan-boy for technologies many years ago when I got burned with OS/2, and have since decided to embrace whatever languages and technologies are in demand, be it MS tools (VB and C#), Apple (Objective-c) or non-proprietary (Perl, PHP, Java, etc.).
Folks that are quick to declare Java dead are obviously naive and don't have a clue about the way the IT world works. They can line up with the folks that declared mainframes and COBOL dead twenty years ago, while (according to a recent Computerworld article) more than 200 million lines of COBOL are still in use and a COBOL gig is still considered the safest gig in IT today.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
What about the prospect of having to pay for Oracle Java? The client would continue to be free (JRE) but if you want to compile code it will cost you. How would Java fair if there was a $100 developers license?
Certainly the open source Java compilers would gain a significant foothold, but with Oracle steering the JCP it seems likely they would eventually corner the market...
Eric Sarjeant
eric[@]sarjeant.com
Generics seem pretty straightforward to me, even the "? extends Whatever" syntax. Maybe you could give some concrete examples as to the problems with generics. The only problem right now is that type erasure makes arrays of generics impossible. Hopefully they'll fix that with the next revision.
As a whole the generics is a useless and dangerous disaster
You keep repeating that. Citation needed.
Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)
So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.
I remember using java generics to build a visual keyboard for any kind of text component. I'm reading my code now, and yes, I understand it.
But Java's cross-platform compatibility has always been a myth.
Bollocks.
I've been a Java developer and manager of Java developers for about 10 years now. Before that, 20+ years as C/C++/asm guy across a wide variety of platforms ranging from embedded system to Honeywell/Bull and IBM mainframe and just about every mainstream business platform in between (AS400, VAX/VMS, various Unix flavors, Linux, Windows, Mac, etc.). So application portability is a subject I have a bit of experience with. While in the earliest days of Java portability was more wishful thinking, I can unequivocally say that since, oh, Java 1.4 if not earlier, cross platform portability has been spot on. It just works. I can't even remember the last time I took a Java application I've written to a platform that it didn't work on. Even today I am always mildly surprised to take a fairly complex GUI application I've developed on, say Windows, and drop it on another platform, like Linux or OSX, and watch it run flawlessly. I recently wrote a manufacturing line simulator to use as a test backend for a Java-based shop floor system. This is a multi-threaded GUI app simulating and displaying in real-time movement of product through the line, while interfacing with OPC servers and host applications via message queues and databases. When it was done, I dropped it on an Ubuntu desktop box and aside from the slight differences in the Linux GUI appearance, you wouldn't know which one you were looking at.
The only portability problems I've seen are either from dependency on native JNI code (which is rarely but occasionally necessary) -- and almost all databases these days support pure-Java Type4 drivers without dependency on native clients -- or due to lousy programmers who hardcode platform specific constructs. I have *never* had an issue with filesystem path portability over the hundreds of Java applications I've written or managed in the last decade, because I never assume/hardcode anything specific to the platform I'm developing on. This is a common failure of your typical VB developer that is new to Java -- all they think about is Windows, many have had zero exposure to other environments, so that's all they know. Which is fine I guess if you're a 100% Windows shop or targeting a Windows base, but then I'd certainly question the transition to Java in that case. Regardless, don't blame the language for its misuse by developers -- if so then we could condemn every programming language ever made.
I like Java well enough and am proficient enough with it that even if I were stranded in Windows purgatory forever, I'd still consider using it over .NET even without the portability benefits. I've had the occasion to have to write some C# due to some OPC/DCOM integration code that required it. While there are some things about the .NET platform and languages that I find appealing, there's not enough there to win me over from Java.
Rubbish, Java *is* especially cross platform when compared to other languages. For example, C - which you cite.
If you write a simple command line app, then sure, C and Java are about as cross platform capable as each other. Write a GUI app in C and Java and the former has no cross platform options.
In C, you have to worry about endianness, in Java you don't.
In C, you have to allow that primitives types may have different sizes, in Java you don't.
In C, you have to allow that structures might pack differently, in Java you don't.
In C, critical issues like threading will be platform dependant or non-existent, in Java it's consistent and standard.
Java also has a consistent memory model, which provides a lot of value in working cross platform as well as the huge common library which is likewise valuable.
I could go on, but I think that's sufficient to call BS on your claim.
In Haskell or JavaScript, there are nowhere near as large *common* sets of libraries, so you can't as easily rely on your library of choice being supported on a client system.
Christ, JavaScript doesn't run the same browser to browser, let alone cross platform.
Here's an example of how complex it can get. Extract: