The Struggle To Keep Java Relevant
snydeq writes "Fatal Exception's Neil McAllister questions Oracle's ability to revive interest in Java in the wake of Oracle VP Jeet Kaul's announcement at EclipseCon that he would 'like to see people with piercings doing Java programming.' 'If Kaul is hoping Java will once again attract youthful, cutting-edge developers, as it did when it debuted in 1995, [Kaul] may be in for a long wait,' McAllister writes. 'Java has evolved from a groundbreaking, revolutionary language platform to something closer to a modern-day version of Cobol.' And, as McAllister sees it, 'Nothing screams "get off my lawn" like a language controlled by Oracle, the world's largest enterprise software vendor. The chances that Java can attract the mohawks-and-tattoos set today seem slimmer than ever.'"
um google app engine? spring? android? gwt? groovy?
Please it's evolving and even finding new uses.
All those "java is going to die" people are silly and not grounded in reality. Plenty of talented developers see its power and use it.
piercings and mohawks somehow make someone 'cutting edge' or a better coder? i think not.
good developers will follow the jobs.
i'll save you the trip to monster.com, here are some search results from there:
search results
------ -------
java 5000+
.net 4581
c++ 3706
c# 3369
perl 2569
python 1035
ruby 547
cobol 286
- 5000 is apparently the limit for the number of results a query can provide at monster.com (weak) so there are most likely far more that 5000 java jobs in their database
- couldn't figure out how to search for C reliably, but it's probably up over 5000 as well.
I remember taking a long, hard look at the state of various VMs awhile back, and here's what I came up with: .NET isn't a bad design, but it's entirely controlled by Microsoft.
Rotor doesn't change that at all.
Mono changes it a little, but Mono (at least back then) wasn't really a great platform in its own right -- not enough tools, not enough reason to use it, always playing catch-up. Plus, there's the whole patent issue.
On top of all of that, it was never really designed to be cross-platform, and instead seems to be primarily aimed at creating native apps.
The various "scripting" languages have been moving towards VM architectures, and some are quite good, but none that I know of actually feature any kind of ahead-of-time compilation, even to bytecode. That includes Perl, Python, Ruby, JavaScript, and plenty of others.
Lisps are better, but they generally don't compile to an intermediate form -- if they compile at all, it's to something platform-specific, likely machine code.
Smalltalk is interesting, but is even more closed off than Java, and basically requires an entirely different set of tools for working with. It's not really designed to work as a text-based language.
The closest would seem to be Erlang, but it's radically different. While I know of at least one other language trying to target the Erlang VM, it's something that's really designed to work with Erlang. I'm also not entirely sure if the performance is there.
LLVM looks very, very good, but very few languages actually target it, beyond, say, C. It seems to be targeting runtime optimizations, not portability.
I probably looked at a few others I'm forgetting now...
Basically, the top two are still Java and .NET. Both present a VM that supports multiple real languages. In Java, this is by accident, it's hackish, but there are plenty of robust, mature languages other than Java which target it -- Scala, Groovy, Clojure, JRuby... In .NET, this is by design, but the more interesting other languages targeting it seem to be in an alpha state.
So Java is pretty much it. And it means we can take our fun, dynamic languages, and (eventually) compile them to Java bytecode, and create entirely cross-platform apps with no local dependencies other than Java. It means we get much of the work that's been put into optimizing Java for free -- for example, the Java garbage collector. It also means that even when designing a native app, well, Ruby just got threads in 1.9, and there's still a GIL, so no support for multicore. Python has and probably will always have a GIL. JRuby has had real, native Java threads almost as long as it's existed. Ruby has plenty of options for concurrency, but if you want to take advantage of multicore, your options are either JRuby or a unix fork(), and Ruby's GC is not COW-friendly, so fork() is potentially much more expensive than in other languages.
I don't know if Java is the way forward. I hope someone builds something cool on top of LLVM. I certainly hope Java the language dies. But the JVM is about the best we have in terms of open-source, cross-platform, compile-once-run-anywhere VMs.
Don't thank God, thank a doctor!
Oh - bonus points if you store the Calendar instance in a static variable, and never require the getInstance() call again.
This would introduce a bug in your application, since Calendar.getInstance() always returns a new instance, containing the current time at the moment it is created. Storing it in a static variable and reusing it would return the same time forever.
Moreover, Calendar is not thread-safe and is mutable, so storing it in a shared static variable is a really bad idea.
import static java.lang.System.out;
class Test {
public static void main(String[] args) {
out.println("Hey");
}
}