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.
The article fails to mention Google, certainly one of the big players and evidently a big supporter of Java. There's GWT, there's Android, they really push hot stuff onto the dusted platform.
IBM was also not mentioned, another huge company that really pushes Java forward - although in a direction I personally don't like.
If you weigh more than 400lbs and have Aspergers and you can't get laid and the only job you can get is cleaning out Supermarket trash then you are a java programmer. Meanwhile winners use C#.net Professional.
Which is pretty much Visual Basic with Java syntax. I find Java source code a tad easier to read and Javadoc make C#'s cumbersome "compiled comments" look silly. Does Java still have checked exceptions in common use? In that case I envy you guys. Scratching my head over which exceptions can spew out of a library is annoying, even if checked exceptions can be annoying at times too.
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.
There have been many discussion about multi-core processing being the way forward as we have already, more or less, reached the limit of what can be done with a single processor. Multi-core and multi-processor methods are expected to transition to multiple cores. At the moment, we have the core OS managing processor time on multiple processors but that's not the efficiency that has been imagined even it if it helpful and yields good results. So what about Java? The language itself is of the classical variety. The "interpreter/VM" of Java is what runs the code, but I haven't seen or heard anything in the way of it advancing to take advantage of multi-processor platforms.
Is Java doomed to get stuck behind in the single processor world or will it actually pave the way forward by running its VM across multiple cores?
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.
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 ----
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.
Whatever AC.
Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data. HTML + browser is one of the slowest ways of doing it, Java beats that by orders of magnitude.
I know, because I measured it. An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.
Even that makes a huge difference, forget about the entire desktop like feel for the app, which is hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT, it takes much less code to get the same functionality as well.
You can't handle the truth.
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 vs. Microsoft movie trailer
The java language isn't that important to develop any further.
It is the platform that matters and the platform will live on long after java the language goes into decline.
Currently the successor to java looks to be Scala.
http://www.scala-lang.org/
Scala compiles to java byte code, so standard java libraries will work just fine.
It is type safe (unlike ruby and groovy)
It performs about the same as java code
If you are a java developer, I will highly recommend getting "Programming Scala"
but who will release, in a timely fashion, the important Java client updates to patch holes in the existing code?
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.
Oracle will not let Java die. It needs Java for a lot of its applications plus other company's need Java so stay alive. I was just at a customers just recently that runs Novell and the entire infrastructure is OES Linux and Free Suse. All most every desktop tool and web tool was Java based.
http://www.thetechnologygeek.org
I don't think that Paul Krill has realized yet that Java is absolutely dead for new development.
...for you. While I have moved on to other languages as well for personal and outsourced projects for many of the same reasons you state, I'll have to tell the Fortune 100 company I work for that the millions of dollars per year they pour into new Java based projects doesn't actually exist...
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.
Yes, Java core language is stagnating. Even JDK7 has not much new features.
Java does have a nice ecosystem of libraries, but by now we've explored about 100% of what can be done in libraries without changing the core language. But there are limits, and a lot of things are just not possible to do in libraries.
For example, java.util.concurrent library is quite nice. But it's rather clumsy even with the planned closures support, any parallel algorithm is quickly drowned in the clutter of anonymous classes. In comparison, Parallel LINQ in .NET is much easier to use.
Or take QueryDSL as another example - it allows to build nice typesafe queries, but it's not really feasible to use it to query simple collections because of huge runtime overhead. While LINQ works just fine.
Reified generics in C# also make a lot of things MUCH nicer.
Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data.
So what?
An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.
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.
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.
hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT
And did you try anything other than GWT? Certainly, if you're going to claim this:
it takes much less code to get the same functionality as well.
Java, as a language, is verbose as hell, so I would guess that a Java library that outputs HTML is worse than a Java library that talks directly to a graphics system. But those aren't your only choices -- JavaScript is decent, and has its own libraries.
You're also assuming that the functionality you get from Java is worth the functionality you lose. You're now requiring people to download a plugin -- no, not everyone has Java already, certainly not a recent version -- and your app is now rendered as an opaque blob, which means users can't script it with greasemonkey, it doesn't work with back/forward or bookmarking, it can't easily interact with other things on the page that want to behave like a webpage... Believe it or not, there are places where the Web beats a desktop app.
You may be able to replicate that native web feel, but that's going to take a hell of a lot more code than it'll take me to develop a decent native web-based app.
I'm not saying I agree with AC, but I really don't see much of a reason for doing browser-based Java -- though I do use it on the server side for other things.
Don't thank God, thank a doctor!
If you're the same AC, that's a remarkable change of position -- you seemed to be claiming that Java wasn't seeing new development, and now you're claiming that it is, and it's just stupid.
Don't thank God, thank a doctor!
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
Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.
Be specific. How are they impractical? In particular:
Clojure is just a reimplementation of one of the oldest programming languages around, Lisp.
And what's impractical about Lisp, particularly a Lisp with STM?
It's also funny that you mention this:
Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl.
Here's the thing: For awhile, JRuby was faster than MRI, the main interpreter. YARV, the new MRI, is faster still, but JRuby seems to be catching up. And JRuby can do real threads, without a GIL, something MRI can't or won't. It runs all sorts of stuff Ruby people expect, including Rails. There are even a few examples of Java libraries which had Ruby equivalents, but the Java versions are the only ones still maintained -- for example, DataMapper supports Oracle just fine, but the only current low-level Oracle adapter that's supported is the JDBC one.
Then there are the crazier things, like running Rails on Google App Engine. I don't necessarily like the JVM, but it does mean I can run any language I like so long as it fits into that Java container.
I'm not sure how close Jython is to that kind of status, but I've been forced to develop stuff which runs on Oracle's WebLogic, and, surprisingly, the WebLogic Scripting Tool is written in Python, and runs on Jython.
It's also funny you mention Perl. What's the #1 reason for using Perl? CPAN. There's tons of Java libraries out there, though not as nicely organized as CPAN last I checked. If I were to take one such library -- say, a nice, well-behaved, self-contained jar -- I could use it trivially from my Ruby app. The Perl concept of grabbing existing CPAN libraries, maybe some only thin wrappers around C libraries, and binding them together with a thin bit of scripting glue to make something cool, is definitely alive and well here -- except you don't have to write any glue, it's trivial to just use the Java APIs.
So, I hate Java as a language. There are languages I merely dislike, or prefer not to use, like Python or Erlang, but I actually hate Java. But the JVM looks like it's turning into something cool.
The JVM is an absolute mess compared to .NET, of all things.
Except that .NET really isn't even to the point the JVM is for "write once, run anywhere." The main implementation is Microsoft's, and Mono is always two or three steps behind. You can either write stuff using Microsoft's APIs and hope Mono keeps up -- which would be like declaring your Windows app is "cross-platform" because it runs under Wine -- or you can stick to purely Mono stuff, which means you'll have to distribute native libraries (like GTK) with your app.
I think I've given up looking for the perfect VM. I'm sure the JVM isn't it yet, and I would guess that some other VM will take over. After all, the JVM physically can't (and may never be able to, may never want to) do some of the tricks the Erlang VM does.
But you're writing Scala and Clojure off as "shitty" without giving a real reason why, and you're either claiming people aren't using Java (or the JVM) for new development, or saying they're stupid for doing so. Where you're not factually wrong, you're just spouting opinions without backing them up.
Don't thank God, thank a doctor!
no, you are stupid!
Dalvik, and the language used are VERY similar to Java and the JVM. The libraries may be different, but Android appears to be a major platform. If nothing else, Android will be around, and can probably be coded into a very similar to Java platform.
Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.
Ever heard of Twitter? Their back-end is written in Scala. How's that for a large-scale real-world application?
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.
By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link.
- sure, but JNLP makes the entire experience into a click and done, and you have an applet that looks like a desktop application running in the browser, it immediately is installed and connects to the server securely. It can be ran outside of the browser, but that fact is irrelevant, the applet is a complex application but it is still part of the business portal so it is a web app.
The *point* of webbased apps is that there is no download involved
- that is a very narrow minded view of what a web application is. Also once it is installed one time, it is cached and any new invocation is immediate. Besides, in corporate environments this is not an issue - a user will wait the extra 10 seconds, it's his job.
and that the application integrates well with the browser.
- to an applet the browser is just a delivery mechanism, but it can operate with the DOM and scripts on the page/windows anyway if that is a requirement, that's not a problem.
Neither is very true for Java webapps.
- actually neither of it is an issue. Applets download slower if they are huge, once loaded they are cached, they provide desktop-like experience, they are much faster at rendering any data, something browser + html - dom - css - javascript cannot boast. Desktop-like applications are often easier to use than web-apps actually, depends on the task.
Besides, even the Java people tell me that applets are a deadend.
- that's just not an argument. Some people would tell you anything until they themselves get on a project that requires that functionality. It's just not true, that's all I can say about it.
You can't handle the truth.
To be fair I've only visited that site twice and both times I saw a fail whale =(
However, we're seeing absolutely no innovation coming out of the Java community. Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl. The JVM is an absolute mess compared to .NET, of all things.
And we all know that .NET are the solution to everything? Right?
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Nobody is owning java. Maybe oracle owns the java trademark. Java is owned/supported by millions and millions of java developers and supporters worldwide. If anybody thinks of killing or undermining is just making fool of themselves.
Well, substitute your "java applet" with "normal fat application", and you will get all the same advantages, except the fantasy about "1 click and it works" :) Sorry, 1 click will not even get you past the "please download the appropriate plugin" screen. Then the start is horrible slow --- I know, since I use one applet from my bank. We are talking 20-30 seconds, and the applet is very, very small (and probably cached, as you say). That is just not acceptable for a modern web application.
Personally, I prefer fat apps. Dependable, quickly developed and the open source nature makes them less of a security issue. Such an app can then use a (restful?) web service to get all the advantages of being in a browser. The only price I get is that I have to install it. Last I checked I was not lacking for HD space.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
Java was never in the hands of any one company, not even Sun- because Java (both language and frameworks) is controlled and evolved using the JCP (Java Community Process).
There are a variety of companies on the various panels so any one company cannot hijack (or kill) the language or platform.
That was always part of the strength of Java, instead of going through a more hidebound standards body they created one specifically for Java, run by the people of the Java community.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Do you understand what it means to work in a corporation with distributed clients? It means that every update to a fat app that needs to be pushed through is a new installation. This is just not the case with web applets. An update is transparent to the user and is immediate across all clients from administration perspective.
I think you don't understand the use case.
You can't handle the truth.
Many of these new languages have very strong features, it's just not always the features that corporate environments want. If you want a well structured, understandable and *maintainable* language, Java is still a long way ahead on all those new languages. Even worse, most of all those new languages are worse.
I'm also aching for a new language. A language that is even better supported by IDE's (refactoring, background compiling, static code checking and such). A language that has a better module system than Java. A language that takes all these things learned by Java and other OO languages and removes the awkwardness. I'm just not sure that functional languages provide these things.
There are many languages that are easier to write than Java. There are few that are more easily read and maintained. Guess what a smart enterprise is waiting for?
Do you understand what it means to work in a corporation with distributed clients? It means that every update to a fat app that needs to be pushed through is a new installation. This is just not the case with web applets. An update is transparent to the user and is immediate across all clients from administration perspective.
I think you don't understand the use case.
Oh, point taken. My company is linux through and through, so we just update the repository and all apps are upgraded automatically. Naively, I thought windows could do the same. Even so, that usecase could be handled more generally by simply using self-updating apps, like e.g. online games do, without being restricted to Java.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
I read TFA and I didn't see anything about "Java's Backup Plan". I'm not sure anyone really has a plan per se.
But I will say that Java has enough momentum now that if Oracle really does a poor job of managing it, Java can and will be forked.
The history of XFree86 shows that when the leadership of a project stop leading effectively, the community can and will fork the project and abandon the old leadership.
In the case of XFree86, it was Keith Packard's X.org fork that made the original irrelevant. In the case of Java, I predict it would likely be Google that would lead the forking effort.
Google likes Java and runs much of their business on it. When you do a Google search or use Google maps, you are using server-side Java code. When you run an app on an Android phone, you are running Java code.
You might have heard that the VM in Android is called Dalvik. When Google made their plans for Java on Android, they made their own VM which is Java-compatible (in features, although not bytecode-compatible). They also provided a tool that can take a compiled Java program and swap the bytecodes around to make a Dalvik program. In this way, Google leveraged the development tools available for Java, while avoiding making any deals with Sun. Google paid nothing, promised nothing, and didn't even need to ask permission.
Of course Dalvik was originally based on Apache Harmony, a free software project to make a Java VM. The Apache project felt that Java was insufficiently free, and you could call Harmony a fork. So far it is a fork intended to be feature-compatible, and nobody is talking about adding new features to Harmony that Java doesn't have. Yet.
With James Gosling gone from Oracle, it may be already too late for Oracle to continue leading the direction of Java. Or it may not be quite too late. But if Oracle does anything that would displease the Java community in general or Google in particular, watch out.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
> However, we're seeing absolutely no innovation coming out of the Java community
Funny, I have orientdb open in the other tab.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
I still didn't explain it right. It's not the same company, it's not the same environment, the users are across companies, we don't control their environments at all. But they are using the same application and that application is delivered over the web and it is a Java applet. I don't really know all of the possible client configurations, but they all have the necessary components, which are: a browser and a JVM plugin for the browser. Some our clients are definitely using GNU/Linux as their OS, some are definitely Windows something, there are even a few Macs AFAIK.
You can't handle the truth.
Most of the new Java code written is business software for banks, corporations etc... ~70% of the Java development as a whole is bug fixing and extending existing Java applications. Java is far, far, far behind in web development - Ruby On Rails, ASP.NET, PHP are pretty 4/5 of the market. Java is even loosing in shitty internal corporate apps. The only places were Java is winning are: - mobile space - smart phones - Android, most of mobile devices have some sort of Java on them - where portability is needed - but I have rarely seen a GUI app in Java. My 2 cents.
Some see them more than others. I have developed a few over the past 10 years, one was a video-feed management application, built for Christie Digital through Alt Software that is used to monitor different video feeds and display them on a large video-wall (a stack of 70" rear-projection TVs) or with just projectors. Another applet written for the same company was a remote video-wall controlling piece, it was used as a remote control with VNC like capabilities to rearrange what is on the video-walls.
For an electrical power distributor in Ontario (Ontario Hydro) I created a few applets that were used to visualize state machines (their development was based on state machines with states stored in databases but they didn't have anything to visualize and visually modify the states.) Another piece for the same company was tester software.
Earlier I built something for International Financial Data Services, a proof of concept that they could move to Java + Oracle off of their Progress + 4GL language platform.
Even earlier an online merchandise catalog with upload to the server capabilities.
A few more I can't remember anymore, but currently I am working on a piece that is a desktop like replacement for a POS management app that they have for a desktop app they are running right now.
Things are happening, just applets are definitely less common than simple HTML + CSS + Javascript and there is a good reason for that! Not ALL web applications need to be desktop-like. But the point is that for those that do need to be that way Applets are indispensable.
You can't handle the truth.
Given the feature set of Twitter, I'm gonna assume it won't be bigger than some of the projects I wrote alone in my spare time.
to html+javascript addicted: please explain how to interact with the computer clipboard using proper mimetypes so that copypaste works trought different clients.
- signed, an anonymous coward java applet developer.
p.s. html scan all the table because it needs to computate column size based on the table content (stupid design decision), java has (could have, should I say) the column width defined beforehand.
His point is that you still have to perform apt-get upgrade eventually. Or your admin does. Or a cronjob does. Something does. On the web app site, users load the page and they get the updated version. They don't even have a choice of going back to the previous version. There's no management of upgrades because there are no upgrades. Everything is just accessed from a central location with a web app.
But the reality is that with DEBs and a repository, RPMs, and a repository, or MSIs and a SMS or Zenworks server, things Just Work(TM).
.war to an extant Tomcat install.... .WARs solve only self-imposed problems, but don't even bring one back to the normal of 1993, let alone making a sysadmins job easier then everything else in 2010). But the applet which was built inhouse, and the Cisco ASA tool just about never work when I try to run them after an arbitrary amount of time.
With Java, and "Java Web Start", any regular person runs such JWS programs so infrequently, that something working the last time is little guarantee that it will work this time. They upgrade their browsers between sessions, and break Java. Upgrade Firefox from 3.0.17 to 3.5.0 and *boom* everything gets faster, except Java applets, which break. For that matter, upgrade from 3.5.1 to 3.5.2, and things break. Go to java.sun.com and spend an hour finding the right JVM, JRE, JSE, JEE, JWTF, and click through licenses 3-4 times per, and you might get the right thing to make Java work again. Or give up trying.
Java - Sun, Oracle, whatever - has shot themselves in the foot here, I grant. Their asinine redistribution policy's all but forbidding anyone else solving this really trivial problem for them. The Java technology (in the billion senses of that word) is passable.
The Java politics is so mindbogglingly stupid that it managed to drag down a pretty good hardware company to scraps a software company bought up for pennies on the dollar.
Personally, I deal with a bunch of things that run Java. The server stuff isn't that bad, it does generally Just Work (though, I'll point out that Atlassian generally encourages people to run their "bundled" apps, rather then trying to add a
I'll grant that JWS stuff works better then getting the unbathed masses to install a fat app. Is that a really high bar to get over? Has no one at Sun looked at management tools in the last 20 years?
Comparing JWS to DEBs, RPMs, or MSIs with a reasonable and quite doable management infrastructure, Java isn't playing the same sport, let alone being in the same league.
But the reality is that with DEBs and a repository, RPMs, and a repository, or MSIs and a SMS or Zenworks server, things Just Work(TM).
They don't at all. Your admin may update the app faster than the other company's admin. MSIs don't make things happen the same everywhere, neither do repos. The action of updating isn't guaranteed to happen *everywhere at once* just because you really really want it to.
No. It's been asserted time and time again, to the point that many people believe it must have been shown, or why would everyone be asserting it?
The fact of the matter is that JITs do not, in practice, make the JVM as fast as C/C++. The tests that have actually been performed show that it can reach that level in artificial microbenchmarks, but in real-world applications it rarely gets close, and it requires much more memory in the process.
It is also true that this is completely irrelevant, because it is fast enough for pretty much everything other than supercomputing and action games, and memory is cheap.
Hey, welcome to 2010, traveller! Do you have flying cars in the future?
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?
If you ask the J2ME developers and game vendors, J2ME is doing pretty fine on billon devices.
Seen the numbers released by Opera Asa every month? Now add "Gameloft", "EA Games" to it. That is your "dead" language.
It will eventually merge with "real" Java and that time, it will be "dead".
I always wondered why didn't Google enhance the J2ME language to become undisputed app king on billion devices instead of going with their own unbranded J2ME.
Now reading such posts from supposed to be clever "developers", I wonder if Google wnt with their own "Dalvik" Java just to convince these idiots that it is not Java they will be developing for?
It is just like some Mono developers illusion that they aren't actually coding for Microsoft .NET framework.
Lets grant your point then. Lets assume that the general problem of updating software hasn't been solved by your local admin, your OS or the universe in general. Lets assume that updating software is the responsibility of the software VM and the various miscellaneous politics and technology that surrounds it.
.spec? It couldn't be harder, that I know. But I'm not a developer. I have 0 desire to have Java on any of my systems; it is a means to an end. Why must I think about it? Why is a developer tool trying to install a shitty search toolbar on my user centric web browser?
Java imposes a set of problems *at least as bad* as just straight upgrading software.
I'm faced with the problem of updating firewall rules on an ASA. So I fire up ASDM to do so. And it fails, because its been a couple of weeks since I did it last, and Java doesn't want to work any more. So I try to upgrade Java, and am faced with the decision of installing the Yahoo toolbar in my browser or not. Really? Are you fucking kidding me?
Personally, I don't really care if the ASA OS is written in 6502 ASM, or in VB on an embedded 386. And I especially don't care if the fancy management tool is written in GWT (which actually does "just work", unlike JWS stuff), Java, or for that matter, even Flash. In this example, what I *want* to do is write a firewall rule. In dealing with this minor problem, I'm forced to deal with the insanity that is desktop Java - which is neither provided by SMS or a zypper repository, due to Suns apparent desire to annoy me.
Unsatisfied with just making me think of Java and Sun when I just click on some link somewhere and upgrade, I'm force to go through a barrage of links and licenses before I can download the software. On Linux, I'm forced to agree to the license *again* before I'm allowed to create a symlink by-hand to get it to work. Under Windows I'm forced to uncheck someones desire to force the Yahoo toolbar on me.
Again: Are you fucking kidding me? Faaaaahk! I don't have to jump through this many hoops to get MSDN software. Or trials from Novell, let alone shareware or OSS stuff.
Has no one at Sun ever tried installing software from anywhere? Is installing Java easier then it was in 1994? Sure. What is the hardest desktop software to install in 2010? Java.
Is building a JWS cheaper then paying for an Installshield license? I suppose. Is building a JWS easier then writing a
Java may (or may not, I'm not really willing to grant that point) make life easier for developers. But Java makes everyone else life harder. And does so with pleasure.
Of course, this is entirely beside the larger issue of "Java Web Start" that it not running in a browser (and this includes Flash), by definition, makes it not web based.
The major problem with checked exceptions is that the variance rules for the "throws" clause are at odds with how subclassing and method overrides work (for sort-of-good reasons, mind.).
When you override a method you typically expand the set of things it can do, and thereby also the set of things that can go wrong. Unfortunately you can only restrict (or just plainly keep) the set of declared exceptions. There are some ways around this using generic exception types, but I've yet to see a practical and moderately satisfying solution. (More advanced type systems/languages have things like "effect types" to handle these things in safer ways, but I don't see any of those languages becoming mainstream any time soon, unfortunately.)
HAND.
I'm faced with the problem of updating firewall rules on an ASA. So I fire up ASDM to do so. And it fails, because its been a couple of weeks since I did it last,
Honestly, I've heard horror stories about SDM. It's the only Java app that I've heard about that behaves like this (Don't take me wrong, I understand one of the parents' argument about Java web apps, but I don't use them a whole lot), so I believe you on that.
I've always used the command-line to configure Cisco devices for that particular reason.
Java in the browser has a lot of strong competitors now. Many modern apps are Javascript or Flash on the front end. Or HTML 5 if you want to live on the bleeding edge.
But Java is still an excellent language for large server-side apps and is well supported by tools and a huge variety of open source apps and libraries. Leveraging this existing source base can cut a lot of time and effort out of app development.
And, yes, it is still being used for new development. Oracle just for example were big internal users of Java before the acquisition and are still relying on Java for the bulk of their app development.
The Java software platform is a piece of software licensed as GPL. Anyone can take it, modify it and give it away to someone else.
Not quite; there is a separate non-GPL version. That happens to be the version that people actually use.
More importantly, Sun also had dozens of important patents related to Java that are now owned by Oracle. It is doubtful whether you can create a compliant Java implementation without infringing some of them.
While the phenomenon known as Java may in theory be owned by Oracle it is in practive decoupled enough to be independent.
I wouldn't be so sure about that.
Besides Apple no one cares about consistency on the Desktop anymore. Have you looked at Microsoft apps lately?
The main problem isn't with looks, it's functional incompatibilities: keyboards not being mapped properly, drag-and-drop not working, preferences not getting stored properly, etc.
An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.
Well, the modern way of writing that is wit a mix of JavaScript and HTML; you can use the same tricks as you do in Java for incremental rendering, but it doesn't require the Java runtime.
what 'tricks' do you do in Java?
what tricks? The above code (I didn't include code for a ListSelectionListener) is all it takes to create a table in Java Swing that is immediately rendered, populated with all the data, you can immediately scroll to any part of the table, to the bottom, to the top, whatever, it all exists immediately.
In HTML/CSS/Javascript you can't do that, you can't have the table created immediately that you can scroll around right away with no matter how you do it.
In fact you are completely missing the point of BulkTableRenderer, which does exactly the opposite of what you are suggesting because the fastest way of creating a table in a browser is not with a javascript but with HTML text that only has pure HTML and by setting that as innerHTML to an element. That's the fastest way of doing that, go ahead, try making something work better or faster than the Google team could (and they have direct access to people working on WebKit engine.)
Do it, put your money where your mouth is, talk is cheap.
You can't handle the truth.
The fact of the matter is that JITs do not, in practice, make the JVM as fast as C/C++. The tests that have actually been performed show that it can reach that level in artificial microbenchmarks, but in real-world applications it rarely gets close, and it requires much more memory in the process.
Actually I agree with you to some degree here. In most benchmarks that I've seen, Java does, at best, approach C++ but rarely surpasses it. But benchmarks are not real-world examples. In the real world developers are rarely given the opportunity to spend much time refining and optimizing their code (be it C++ or Java) and so once most programs are written and successfully pass unit/integration testing, they are thrown into production and not touched again except when additional functionality is desired (the "if it ain't broke don't fix it" mentality). This leads to a codebase that is naturally suboptimal.
With C++, the native executable code is fixed and will continue to execute exactly the same instructions indefinitely until the code is recompiled.
The same is not true of Java bytecode. With each interation of improvements in the JVM (especially the improvements in JIT in the last couple of years), the same bytecode will continue to improve in performance without the developers even having to touch it. With continued advances in garbage collection and JIT optimization, one can expect at some point, the bytecode (with the JIT's ability to optimize at runtime and make adjustments based on current conditions) that JVMs will surpass C++ performance for most real world examples.
I know from my own anecdotal experience, whenever I've migrated a C++ application to Java, the results have been an order of magnitude higher performing and far more stable. Granted, many times this is due to my taking advantage of the built-in APIs in Java (such as collections), whereas the old C++ code might use simple sequential searches through arrays. But I guess that's my point. In general, expertly written C++ code will probably outperform Java for some time to come, but from my experience, a lot of C++ code is written by "less than expert" C++ programmers who do not write optimal code and no matter how good the C++ compiler's optimization capability is, it doesn't have the ability to rewrite a poorly conceived algorithm. While the same could be said for Java, the comprehensive APIs available are a lot more "in your face" when learning Java so they tend to be used more (at least that's been my experience, YMMV).
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
for real, you are asking me 'so what' and that's your argument?
I'm sorry, I could've been more specific:
- Why is it important not to call the server as often, especially when HTTP caches will do the work for you?
- Why are you comparing a complex Java app (or applet) with a "simple" HTML design?
- What does "large" amounts of data have to do with it?
Some of my users think that their 'computer is broken' when somebody re-sizes a window on their desktop,
If your argument is that Java is a better environment for dealing with this particular class of users, I guess you win. That sounds like the same class of users who got bent out of shape when I attempted to migrate them from Outlook to Thunderbird, and Thunderbird didn't have their emails colored the way Outlook did. Seriously, they categorized emails by color.
Those users are a lost cause for doing anything really interesting. There's a pervasive attitude in the non-IT world that even people who sit in front of a computer their entire day, whose entire job entails working with a computer, should somehow not have to be computer-literate, that it should be someone else's job to install antivirus, update their computer, keep it clean, and filter their Internet so they can't screw it up.
I think the Web can do this, if not now, then soon. But I also think that recreating an existing app for such users isn't really an example of "new development" that the AC was talking about.
Rendering done by the Java applet is completely different from what a browser does.
I'm sure it is.
Browser needs to parse HTML out, it needs to create some form of a document (DOM) it needs to prepare for quirks...
So if you've got a fully compliant page (thus, you don't trigger quirksmode), you don't use InnerHTML, and you do create and update the table with JavaScript, you're not always triggering every stage of that, or even most of those stages. You can even avoid reflows.
Java applet has none of those issues, it does not need to parse out any documents,
Other than the document containing the Java applet, and you'll need to parse something to get at the data.
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...
...if you rendered it as a simple HTML table. I'm fairly confident I can match what you've just described.
Now, you're claiming that you can just render a 20k row table in Java, but what is that "rendering" actually doing? Do you have a pixmap of the entire table in memory? Or are you loading it into some Java library's concept of a "table", which draws only the relevant bits on the screen?
But that's exactly the point -- I can draw only the relevant bits on the screen with a Javascript app. It may take a library to do it, but it takes a library for you to do the same thing.
- 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.
Define "compiled language" -- that's an implementation detail. Lisp is a compiled language.
you have no idea what you are talking about. GWT is not a library.
Why is this important?
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
It may be an issue with the architecture of GWT, but I don't see how it's at all related to any particular badness in HTML.
You were the one who brought up GWT, to say that
Don't thank God, thank a doctor!
You have several options:
(1) Render the table data in a canvas element. That's the direct equivalent of what Java does.
(2) Use a small HTML table and change the content dynamically in response to moving a slider. This is simple but won't look that good.
(3) Use a full HTML table but fill it in with empty, fixed size rows, then fill in the rows as they become visible. This is the least likely to work well on all browsers, but then Java isn't guaranteed to work well across browsers either.
So Gosling does not have confidence in Oracle's stewardship of java, and they part ways. So now the Java crowd feels unease.
Where the HELL was Gosling when Java was under Sun's stewardship!??!?!?!? I sure as heck did NOT see a glowing future for Java a year ago!
Oracle has owned Sun for barely a few months, and NOW they're supposed to have a magical future planned out for Java?!?!?!? HOW MUCH MONEY does Java produce for Oracle RIGHT NOW?
The ONLY people who should be scrambling and thinking WTF? are people who have commercial Java product offerings. So, if you're IBM, or some Java tools vendor, you have a world of worry on your plate.
But everyone else? I don't know. If you are INCAPABLE of learning another programming language besides Java, then I'd say you're screwed. But for the rest of the programmer industry (all 95% of it), it just means they will be implementing solutions in java for as long as it makes sense, THEN EVERYONE will move onto "THE NEXT NEW THING". Which, btw, has been the history of the programming industry. From assembler to FORTRAN to COBOL to C to DBASE to SQL to HTML to XML to ruby, etc. etc. etc. etc.
Either Oracle gets it right or it doesn't. No one with a brain should give a damn. If you do, then you're some kind of retard who thinks java is the Alpha and Omega of programming languages. Its not. And even if it was, its extremely unlikely to be relevant in twenty years.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon