Oracle's Java plan trapped in last century Oracle's roadmap for Javas 7 and 8 shows it recognizes the world is pulling away and leaving Java with last-century concepts and ideals. Java 7 is meant to set the foundation for a cloud-friendly platform, but the real cloud-ready features won't make an appearance until Java 8 in 2013 at the earliest. While Larry and company …
I though the article was a bit bleak at first "Java is left behind", but the closing point is key: the Java world is moving beyond Oracle, beyond the enterprise. Big HDFS filestores running Hadoop and HBase: Java based, hosted in Apache. Spring? At SpringSource, and happily staying ahead of the EJB attempts to catch up. OSGi? Have Oracle stopped pretending it doesn't exist yet?
Oracle aren't playing in these worlds, and some of their key concepts "NoSQL, no app server, commodity servers" are the kind of think that Larry must wake up screaming about
Sun and now Oracle have done more harm to Java than any other party of late. It's a laugh to see them sue Google for invigorating Java (the language) and making it relevant for smart phone development when J2ME was so moribund. And the pace of Java 7 is glacial and pretty pathetic given the small iterative number of changes it contains.
What amazes me is that no one has forked the thing yet.
Scala is a completely new language running on the same JVM. It can share Java classes and vice versa but you know when you're in one world or the other. I'm thinking of something akin to Java++, something which is Java + extensions, something which fixes all the crap that Java gets stick for but is never fixed properly. For example being able to write getter / setter annotations on fields, domain specific languages, partial classes, runtime generics, built-in dependency injection etc.
Something that alleviates programmers of a lot of the boiler plate crap in Java while still being backwards compatible. Groovy would be a close contender but it's not a syntactic superset.
I would really like to see that, but i'm wondering if its legally possible?
I remember them forking Open Office on the instant.
Another question is, of course, should we just make something new?
True, a zillion people have experience writing Java code which would be a shame to throw away, but there's a lot of valid complaints about Java shortcomings...
What about rallying around something new, like John Graham's Lisp flavored re-invention of a language, Arc?
I guess to some that would seem too similar to Scala...
Anyway, anything that has the stink of Oracle, I don't want to be near.
I would think it's pretty tough to copyright a language or patent it, and certainly Java has a full GPL'd implementation and there are other clean room / non certified implementations of both the JVM and the language compiler. So I don't see why it can't be extended. But Oracle is litigious and what is legal may require a very long and expensive lawsuit to settle as is the case with Google. Google hasn't used any Oracle code, and doesn't even claim to be Java yet they're being sued for a handful of patents.
No, not literally, of course not. However, it demonstrates what happens when something is used as a starting point, components are taken and other aspects are changed or added. So similar, conceptually, to a fork but not actually involving a Subversion checkout (replace with the name of your favourite SCM tool, as appropriate). That was my point. Apologies for not spelling it out.
This has to be the most incorrect, factually misleading, and utterly unresearched article I've ever read on The Register. The author of this article clearly knows very little about what he is talking about, and it is clear he just has an article and buzz word quota to fill.
Register: this is embarrassing.
Java is a Programming language for an Applications platform. Using a virtual machine for execution.
The "Cloud" is the idea of somehow using remote computing resources via Mobile or Broadband.
No programming Language needs to be "Cloud friendly" or "Cloud Ready" or "Cloud Compatible".
Almost the entire article is hogwash. The redeeming feature is that it points out that "Cloud" has become meaningless as is covers too wide a range of stuff.
one thing I've noticed of late, is that people talk about languages when they're actually talking about the whole shebang (frameworks, libraries, ...). So when a language isn't ready/suitable/..., it's the lack of some add-on that's at fault. This isn't necessarily wrong when the languages themselves are designed to be extensible.
Including frameworks and libraries in regards to the usefulness of any language only makes sense, when you think that you have to deliver product before you run out of money.
Reinventing the wheel is exactly the recipe to fail take-off when you reach the end of your cash-paved runway...
This is EXACTLY what I was thinking!! I don't understand anyone saying a language or JVM is not cloud friendly. It runs within an OS that runs inside of a cloud environment. IS the language and/or JVM supposed to be "cloud" aware.. somehow when it starts up be it a web app or console Java app, does it just look at the network, OS it runs on and from that determine it's part of a cloud and some how it does some new great stuff? This part of the article completely confused me. In most cases that I know of, cloud deployed java apps are running as web apps, inside a JEE container. There could be "agents".. self run console apps that might be services or script started.. but otherwise, they mostly run inside of JEE containers. I don't believe many, if any, java web apps are "aware" they run in a cloud. The container/server won't even know this.. there is no magic "cloud" formula. Cloud is basically physical servers turned into virtual servers on bigger/faster physical servers. That's it. Running in the cloud simply means your app is on some virtualized "pretend" computer. It's the same sort of network setup as a rack full of physical computers with the obvious differences of virtual networks and such.
I never get it when people use the "cloud" acronym for everything. Salesforce.com is a "cloud" deployed app. Well.. it's basically the same deployment, only instead of a single physical server for each JEE container, they use beefier multi-core servers with more memory, along with something like XEN or VMWare dividing up the cores and memory into virtualized machines, each getting their own "sandbox" chunk of processing and memory. That's it..that's the magic.
Let's try to understand what it means to be part of a cloud already and get beyond the use of this word as if it's the holy grail to deployments! It's just a more efficient way of using more powerful computers!
"However, people who prefer a more intuitive approach - namely immutable objects, Actors and messaging" - Java 6 has all these, and they intuitive enough to be useful and usable.
"Why won't someone fork it?" - you're more than able to. JDK7 and 8 are open source. Whether it plays nicely with <your chosen VM flavour here> is another matter, and that's a real issue.
People often bash Java as being behind the times, and that's partly true in some respects, but all languages are "behind the times" when compared to given portions of other languages. It's relative.
Computing isn't all about the cloud, you know.
Thank you.. can't agree more. How is it that everyone bashes Java.. yet C/C++ have barely changed at all in 30+ years. They have some new changes coming up to C++ right now that are finally adding some new things to it, but the language itself has been almost identical since it's inception. Yet.. nobody bashes C or C++ for not evolving?
Sadly, a lot of people bash Java without realizing it's part of a bigger thing.. the JVM. The JVM allows for other languages as well, and they can all play nice together for the most part. So if Java the language is a "wee bit" behind the times..it's still got the biggest developer pool to find talent from in the world, it's got more libraries and open source behind it than any other language in the world, while c/c++ combined are "bigger" overall than Java, Java is used far more on the server side than both c and C++ combined. Since most applications these days are "in the cloud" (e.g. web apps deployed on servers) it stands to reason that Java is a large part of this. I don't see C and C++ being nearly as large on the server side as Java.. so for a language that is behind the times, it sure is amazing how many companies keep on building new libraries with it, using it for robust scalable applications and more. If you include the Android mobile side to things, it's even that much bigger with how fast Android is growing and how many developers are able to actually develop apps with some sort of ease compared to iOS apps.
Java itself is a fine language, easy to pick up and code in (though I will admit its generics implementation is still sorta kludgy). It's just the official 'enterprisey' JSR-promoted frameworks that Sun came up with tend to really suck. Ditch the EJB's and JPA and JMS and JTA and JSF (seriously, does -everything- have to be a TLA?) and use plain old java objects with some neat open-source frameworks like Tapestry and Hibernate and you'll get the efficiency of an type-safe compiled language without all the sludge that the official enterprise stuff brings. No, I guess it's not 'cool' like Ruby et al is, but it's possible with open source frameworks and Maven to be very quick and efficient.
Seriously, go learn JEE6... it's beyond easy, uses POJOs. EJB3.1 is so impressive now, and being able to build everything into a single .war file now is much nicer/easier too.
I have built a few JEE6 apps now, all using Pojos, with my entity beans being my pojos that I pass around. I will admit I don't need to work with transactions as I keep everything stateless all the way through with the "state" being stored in the database. I replaced JMS with REST as it's much easier and almost as robust for most things as JMS.. with the exception being guaranteed delivery.. but even that is not hard to make work right with the new JEE6 timer capabilities and async methods.
Only thing I would add is using Wicket. Wicket is the only framework I've found that truly allows a html/css expert do their work without having to know anything about java and where the html files are deployed.. simply understand the use of <wicket:id> and a couple other things, but can build complete web pages and then the wicket developer can add in all the dynamic code in Java and it's pretty easy to work with. It handles a number of things like state, session replication (or session state stored in database), various "hacks" like SQL hacks, has a large built in support for ajax, html components and more.
I will never get the "Ruby" kick. I tried ruby.. it was a disaster to me. It was more difficult to set up than Java even with classpath issues (which isn't hard if your a mid level Java engineer and actually learn the JVM, not just the language.. thus understand how it all fits together). Ruby the language to me just doesn't make sense. Java, C, Basic, Pascal.. are easy to read for the most part. I guess it's all the symbols and syntax of Ruby that I don't comprehend.
Right now, shipping 7 and 8 together, tomorrow, would have no greater impact on the future of java than doing nothing at all. I've been using Java pretty much exclusively for the last ten years and it has been capable of solving lots of problems very nicely (as long as you didn't want mobile - and Google have the Java Mobile issue solved very elegantly with Android).
Right now I'd just freeze the Java language spec at Java 7 (it seems a shame to waste the effort) and switch my attention to the JVM and functional languages instead. As the article hints, there are now a number of JVM based languages (Scala and Groovy come quickest to mind) that bring much-needed brevity, flexibility and frankly better productivity. As Sun simply didn't keep up in Mobile. Oracle cannot hope to keep Java competitive with the new kids, so why not just embrace them as first class citizens?
Of course from Oracle's point of view the problem here is that they don't have control over Scala, Groovy et as they do with Java so they may never be able to bring themselves to admit this in public.
I can write a web app in Groovy, writing 50% less code than I would in Java to achieve the same end - and still piggy-back on all that good open source Java that's out there - why would I waste my time writing Java? That's the pitch I give to managers when we're talking about greenfield development, and a position I've adopted only in the last few months. Functional languages have proved their worth, Java is dead, long live Java.
This whole article is peppered with technical inaccuracies, it's frankly embarrassing for the register to publish this nonsense. Just to clear up one of them:
Variables changes can be seen by other threads, you just use the volatile and synchronized constructs, this tells the JVM to flush out the cache so other cores can see the update. This is very expensive, that's why it's optional and has to be explicitly stated by the programmer, that's why all other languages will have a similar construct.
Java also has the java memory model, which ensures that multi-threaded code works the same on all processor architectures and types. From ARM to POWER7, be it NUMA or not.
Eh? Which inaccuracy are you clearing up?
He never said you couldn't see changes in other threads, as it would be hard to code anything if that were the case.
He said:
For example, being able to change a variable in one thread and not have its changes be seen in another.
This is something altogether. In what way was he inaccurate?
Sorry you can't see the difference. I've been coding Java for 14 years, so perhaps that's why I can.
Java allows you to write non obvious, random, surprising code. Correct behaviour is optional, not mandatory.
Sure, you might get more performance, but you also get a lot more danger, you cut yourself without even realizing you've done so.
Some more reading on the subject:
http://www.nearinfinity.com/blogs/bryan_weber/jvm_concurrency_with_scala_actors.html
http://www.infoq.com/presentations/goetz-concurrency-past-present
http://stackoverflow.com/questions/4477809/why-scala-good-for-concurrency
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
