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."
... when being owned by Oracle?
It is the universe that makes fun of us all.
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.
I think checked exceptions are largely misunderstood. When people complain about them, they unknowingly, but almost always complain about the try..catch construct -- it is very wordy, annoying, inflexible and is almost impossible to factor out common idioms.
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.
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.
In a rare fit, I actually read the TFA (I know, I don't know what I was thinking), and it leaves with the feeling that Paul is concentrating on the wrong argument...
He appears to be arguing that third-party vendors control Java through the development of their frameworks and tools. While most modern-day development is relegated to gluing together frameworks instead of actual programming, I think this misses the point in the same vein as when people talk about JEE being Java.
Java is a language upon which these frameworks and tools are built. For all of the good things Sun did for Java, they had a tendency to take the path of least resistance when it came to fixing existing features and adding new features to the language. If Oracle continues the trend, or does a worse job of it as many are predicting, third-party vendors will lost interest in developing these wonderful toys and will move on to other languages that are better supported.
I for one, abhor the ownership of Java by Oracle. Sun had a tenuous grasp on it through its design-by-committee approach, and I have no reason to believe that Oracle will improve on that approach given its history. Java had some wonderful ideas behind it, but I for one have been transitioning my investments over to alternate languages that have caught up and, for the most part, surpassed Java in functionality.
Well, that's my two cents and my cat agrees with me. So there.
Oh wait, i thought this was a poll.. Nevermind.
---- Booth was a patriot ----
>Does Java still have checked exceptions in common use?
/**
No, I'm sorry for you. The standard platform is moving away from them and is resorting to run time exceptions being mentioned in Java doc. E.g. an excerpt from the platform standard class EntityManager:
public interface EntityManager {
* Make an entity instance managed and persistent.
*
* @param entity
* @throws EntityExistsException if the entity already exists.
* (The EntityExistsException may be thrown when the persist
* operation is invoked, or the EntityExistsException or
* another PersistenceException may be thrown at commit
* time.)
* @throws IllegalStateException if this EntityManager has been closed.
* @throws IllegalArgumentException if not an entity
* @throws TransactionRequiredException if invoked on a
* container-managed entity manager of type
* PersistenceContextType.TRANSACTION and there is
* no transaction.
*/
public void persist(Object entity);
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.
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
Go away, lying revisionist troll.
The lawsuit in 1997 against Bill's Microsoft by Sun was about contract violation. Microsoft had a contract to distribute java, not their own proprietary version of java, but bona fide java true to the published specifications. The allegations, proven in court, were that Microsoft aimed to harm to Java platform, violated the Sherman Act by illegally monopolizing and illegally maintaining aon the Intel-compatible PC OS market and the web browser market and the office productivity suite market. Microsoft was also illegal tying products, and illegally entering into exclusive dealing and exclusionary agreements (violation of Sec 1 of Sherman Act), and engaging in copyright infringement, and restraint of trade and unfair competition. It was also attempting to illegally start a monopoly in the server operating system market.
Not only do you Microsoft toads ruin the economy, you make the net more expensive and create security problems. It'd be just fine if DHS started checking hard drives during entry or exit at the US borders and nuked any and all NTFS partitions they find. HFS, FFS, UFS, or EXT would be put on instead. Give a few months warning first and hand out Fedora CDs to those getting a warning. Then after the deadline, bam.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
"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.
By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link. The *point* of webbased apps is that there is no download involved and that the application integrates well with the browser. Neither is very true for Java webapps. Besides, even the Java people tell me that applets are a deadend.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
C# is really more sort of the averaging of Java and C++ than anything else,
C# is just like Java except without some of the problems and with some good things added. E.g. Java generics aren't really worthy of the name, while C# generics are pretty spiffy.
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.
I don't think generics are a 'disaster'. More like 'potential disaster if you don't watch your ass'. And to date, I still haven't seen a better way to do it. (Your suggestion, "typing containers and letting it go at that", makes no sense; there was no way to do that without adding generics to the language, or something that works like generics.)
Anyway, it doesn't matter. There's no way in hell that they'll be removing a widely-used feature from future versions of the language. As long as we're coding in Java, we're stuck with generics.
Scala is multiparadigmal; you can use the functional features when you want, and ignore them and program Java-style when you want.
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
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.
So what?
- for real, you are asking me 'so what' and that's your argument? My response is simple: I am recreating an application in a browser that my users have used in the past and that is now no longer supported that used to be a stand alone applications. Some of my users think that their 'computer is broken' when somebody re-sizes a window on their desktop, those are not the kind of people who will want to switch paradigms from a desktop application to a web based one that is purely running as HTML/Javascript, so those people need to have the same experience they are used to from a desktop app, however the new app will not be installed locally, it is now a web app for reasons varying from cost of maintenance to security to ease of deployment and availability.
This single argument that you are giving: 'so what' completely dismisses actual reality.
And I bet a Java applet which attempted to render 20,000 lines all at once would perform just as poorly. It really wouldn't take much JavaScript to replicate what Java is probably doing here -- render only the rows which are actually visible, and cache the rest in RAM.
- and you would be wrong and it shows your ignorance on the issue. Rendering done by the Java applet is completely different from what a browser does. Browser needs to parse HTML out, it needs to create some form of a document (DOM) it needs to prepare for quirks, it needs to decide how to display this and then render it and THEN it also changes what it renders on the fly re-rendering it with styles etc.
Java applet has none of those issues, it does not need to parse out any documents, there are no CSSs, no javascripts, it's a layout with a table with data that needs to translation and multiple rendering passes, so as a result it responds immediately. 1 second after I load the 20,000 rows into it I can scroll ALL THE WAY TO THE BOTTOM. At this point a browser rendered maybe 300-400 rows only that can be scrolled through and as you are scrolling you are making it work slower, it will modify the page and re-render what was done already.
Your mention of "constantly calling the server" suggests that would be a bad thing, too. The browser's HTTP cache works with XHR, so I really don't get where that's an issue unless you need the data to be downloaded all at once. - precisely, I do need it to be downloaded all at once so that user can see all of it in a single table by immediate scrolling.
And did you try anything other than GWT? Certainly, if you're going to claim this:
- about 2 months worth of all kinds of things, from plain HTML, to GWT with paginating, incubators, Bulk Renderers, Javascripts, CSS all sorts of things. Absolutely NOTHING beats an applet.
Java, as a language, is verbose as hell
- I can see your bias from this.
- for a compiled language it is not that much more verbose than C or C++, in fact less so depending on what you are doing.
so I would guess that a Java library that outputs HTML is worse than a Java library
- you have no idea what you are talking about. GWT is not a library. It is a full environment that allows writing CSS/XML (for layouts and configurations) + Java instead of using javascript, a compiler that does NOT include all of the features in Java or in GWT libraries, it creates the most dense code as far as javascripts go, but to your point, if GWT was written in C or C++ or PHP or whatever it still would have been as bad in terms of amount of code as GWT is with Java right now, not because of Java but because of what GWT is doing. GWT architecture requires much more code to be written that will have to be translated into Javascript/HTML
You can't handle the truth.
Really? I don't know what planet you're on, but here on planet earth, much of the real work is being done in Java (by a very wide margin). (See http://www.langpop.com/ ). .Net languages.
Haskell and Erlang are barely a blip on the radar. I like and use Python regularly and it has it positives, but I have a hard time recommending it to my corporate customers (for various reasons having to do with availability of trained developers, performance and or broad industry support). By and large most work I see getting done is being done in Java or
I can see why you posted as AC since clearly this was intended as flamebait.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
C# has declaration-site variance for generics, while Java has use-site variance. What this means is that interfaces which are always co- or contravariant (e.g. IEnumerable in .NET, which is analogous to Iterable in Java) can be declared as such. But if an interface has a mixture of methods, some of which are covariant and some are contravariant, the result has to be invariant in .NET. For example, IList<T> is invariant, because it has both Add(T), and indexer returning T.
In Java, due to use-site variance, you can have a method which takes a List in a covariant or contravariant way (with "? extends T" and "? super T" wildcards), at which point you're restricted to using only those methods of List which can legally be used covariantly or contravariantly. You cannot do something like that in C#.
To sum it up: Java generic variance is more powerful, but places a higher burden on API clients, because they have to use wildcards whenever they want variance. C# generic variance is more limited, but is completely transparent to API clients - for them, passing an IEnumerable<Derived> where IEnumerable<Base> is expected "just works".
But then, of course, C# generics are reified, while Java ones are not. So there is some compromise whichever side you take.
As a whole the generics is a useless and dangerous disaster
You keep repeating that. Citation needed.
Since this is the first time I have ever commented on this topic it seems unlikely that I "keep repeating it". And I gave two examples in my comment. But also see Ken Arnold's opinion: http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html and http://www.artima.com/weblogs/viewpost.jsp?thread=222021 and Joshua Bloch's attempts at favorable treatment are pretty damning: http://java.sun.com/developer/technicalArticles/Interviews/bloch_effective_08_qa.html.
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.
Indeed it is a bad thing. A problem that all excessively obscure and complex languages have rapidly revealed (C++, Perl) is that every difficult-to-use feature gets used (if it is usable at all) and has to be supported by every other programmer eventually since 90% of all programming is support of existing code.
The saving grace for Java generics is that beyond container typing it seems sufficiently hard to use that it rarely gets used. Some time back I scanned the source of several substantial and active open source projects without finding any examples in use beyond container typing.
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.
Beyond container typing what aspects did you actually use? Have you ever written one genuine generic algorithm? That is - an algorithm with a generic interface that takes any appropriate generic type and returns an appropriate result type while maintaining typing throughout?
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
Java doesn't force you to handle exceptions, it forces you to be aware which exceptions can happen. You just have to declare your own functions as throwing them if you don't handle them.
I keep wondering why people forget about Big Blue these days. Java and Linux support are the keys to their offerings and both are said to save mainframe/big server business of them.
Eclipse is Java too. A lot of IBM applications, even client side stuff relies to Java.
Lets not forget Google Android which is a huge success is enhanced J2ME/Java, billion cell phones have J2ME built in, the "winner" high definition format, Blu-Ray has J2ME/Java.
Sorry to say the idea of Oracle wasting Java is really stupid to begin with. Perhaps Java will focus on the thing it does best is a better theory, I mean huge servers, databases, J2EE?
Here's an example of how complex it can get. Extract: