Oracle coughs up Java 7 release candidate Oracle has published the first release candidate for JDK 7, the long-awaited next version of Java set to officially debut on July 28. On Thursday, during a webcast from the Oracle bunker in Redwood City, California, Java chief architect Mark Reinhold said that the most significant thing about the new release is that "we're …
FFS, they finally get the file and fork support C had in the 1970's? What's the point? What have they been doing? Why is a new library more important than fixing the bloody language?
The core language is still horribly crippled, riddled with short sighted decisions made long ago. Often simply to make the compiler easier to write, now frozen under layer after layer of bad kludges.
Just shoot the beast and start again. Get it right this time.
(And yes, I did waste most of yesterday realising that Java generics really are crippled and hardly better than cut&paste. All the pain, very little work from the compiler or even type safety and half the stuff I do in C++ won't work because they cant have statics in an interface)
It's the JVM's long-standing ambition to grow beyond the Java language, and become a platform over which multiple languages (particularly scripting languages) would be implemented and interact with each other. Of course, years of mismanagement on Sun's part have held this dream back, leaving it to Microsoft – of all companies! – to realize that vision with the CLR.
But the JVM remains a fine virtual machine, even if its security record has been somewhat tainted by a recent history of multiple buffer overrun bugs; projects such as Clojure and JPython attest to that. Oracle's new release further provides the kind of support that makes the JVM not only a viable, but a convenient target for such projects.
And as for Java, for all the ill will generated by generics and other poor decisions, I'd say it remains a largely straightforward language, leagues ahead of C++ in terms of convenience and productivity.
Perhaps you forget that Java is an abstracted runtime and language that tries to allow code to be written once and ran on multiple platforms?
Such native IO was hard to do in a way they would work on Unix style systems as well as Windows. Both are worlds apart underneath the hood.
Naturally it is easy to create code in C++ that stands a chance of compiling and running on multiple platforms. You're linking against libraries supplied by the OS or compiler vendor. But you can't take the executable from one platform and run it on another platform.
I'm sorry you have so much difficulty coping with a different language from the C++ you're familiar with. Clearly the slightly different behaviour has crippled Java and no-one uses it.
Of course you could always use Scala, Groovy, Clojure or one of the many other languages that run on the JVM, with the support of a vast class library that works across many platforms (and has supported sophisticated distributed and concurrent processing for years).
JSR-292 means that we are likely to see a host of other new dynamic languages running with all the benefits of a efficient runtime, garbage collector, profiling and debug tools, class library and deployment from mobile devices right up through to the cloud without having to change your tool chain.
Agreed, it's a long time to wait for less than earth shaking additions, but we're already seeing work on Java 8, and I'm hoping this shows Oracle can regain the focus that was lost in previous years. Java is far from lost, but it wouldn't hurt to be more visible on the bleeding edge.
Personally I'd like to see some more development of the various presentation frameworks both on the desktop and web, which have historically suffered from Sun's slightly academic approach to user-facing libraries. It's probably the weakest area for Java as Sun conceded ground to more recent entrants to the market.
Please elaborate on what is so bad about Java? Are you one of those few that come from languages like Ruby, Python, Groovy, Smalltalk and complain about how bad Java got it wrong? Most of the server side world is built on Java and JEE6 is about as easy as anything else out there. I can build robust front to back scalable enterprise class web applications in hours with JEE6 (and one extra.. Wicket). It's not a "prototype" either like many use Ruby or Python for. It's a fully scalable robust performance capable application that can scale to handle increasing loads without any issues at all.
I never understand the java bashers.. if you don't like it, go away. Use the language you find so much better and stick to it.
I am also confused because so many major companies have built their entire products around Java technology and continue to do so.. if other languages and their supportive libraries were so good, why don't more companies switch to them or begin with it? Having worked at startups that "tried" to use ruby because developers say it's so fast to build with.. only to find it sucks at scaling to large capacities without a ridiculous amount of resources, then switching to Java and seeing how much more support there is, how much more performance they can get, and how much of a magnitude larger talent pool they can select from to support it.. there is just no contest. Besides that, the language is fine. I find that the majority of developers that complain about it are too absorbed in "if it only had this capability..it would be so much better/easier". Get over it, or move on and don't look back.
The Java language is becoming increasingly irrelevant. I am really not that bothered by Java (the language) 7.
The VM, however, is the best in the world. Its robust, quick and portable. Java 7 has a load of improvements to the VM that I am very interested in, like invokedynamic that will give a nice speed boost to alternate languages.
Worth pointing out, that although java 6 has been around for 5 years, it was a pretty good release at the start, and the VM had several major overhauls through its time that improved performance all over the place.
Library wise, we've had the apache commons, lots of google libaries, spring, and others for years, so development has moved on apace without sun/ oracles involvement.
In languages, we've got several mature languages to choose from, Java, Scala, Ruby, Groovy, Clojure. They are good for different things, and implement all of what is proposed for java 7 and more.
Concurrency wise, the jvm has always been pretty good. It has concurrency primitives, and a tightly specified memory model. Java 6 gave a bunch of nice libraries in .concurrent.*
Jsr166y is an improvement over whats in the concurrent package, absolutely, and an excellent one at that, however most of the ideas have been available for a while in the alternate libraries, languages etc. As far as I can tell, they are all in the process of rebasing these over jsr166y, yes, but there were already multiple implementations of parallel collections (for example) well in use on the JVM and have been for years. (see Scala actors and gpars as examples)
Why am I saying this? It goes back to my point, Java the language deserves all the criticism above, its dated, extremely verbose and slow moving. (Its also quick, very well known and understood.)
The Java VM is whats important now, and I for one am certain that its the best general purpose VM environment in the world right now.
I went to take a look at JSR-203 to see if there were any goodies in the brain-dead file management Java classes. To wit, I would have liked something like the Python os.path and shutil modules' capabilities : file copy, file move, decent non-OS specific path functions without having to lookup if "/" or "\" is required...
Perhaps even a simple File.open text reader/writer, without need to assemble opener/handler classes for trivial cases.
Not exactly rocket science, but 5 yrs wasn't enough.
Nor was it enough time for those folks to figure out how HMTL works apparently. I had to edit their index.html from their "Proposed Final Draft " to close the <title> tag because it was malformed HTML otherwise and neither FF nor IE would display it. Shows how much everyone cares.
Brilliant.
Perhaps you should take a closer look at the new API before moaning.
http://download.java.net/jdk7/docs/api/java/nio/file/Files.html
Files API has all and even more than what you've asked for. Path constructors use varargs syntax, hence the ability to avoid OS dependent file seperators. The "List<String> Files.readAllLines(Path path, Charset cs)" method is available. It does exactly what it says on the tin and it doesn't get much easier in my view!
This combined with the try with resource project makes jdk7 a very productive language on the IO front.
Good catch. I didn't look at the actual API doc, just at the high level release notes. Files is indeed looks much more reasonable than before. The biggest issue I have with Java itself is the requirement to catch/throw many exceptions instead of letting them "bubble up". Unexpected exceptions are often not easily recoverable from and pretending otherwise is futile, unless a lot of effort goes into testing and cleaning recovery attempts.
For the rest, my annoyances with the language often have more to do with the API design, where things are more complicated than they need to be. The absence of a built-in basic file copy was understandable in anorexic bare metal languages like C. But it is not, IMHO, appropriate in a language with Java's ambitions (and API size). Ditto file path management which Python was so much better at.
This has to do with programmer productivity and robustness (roll-your-owns are fragile), nothing to do with the compiled vs. scripting languages debate.
I would love to see Java make things simple, rather than treating complexity as a badge of honor. These Files changes are a big step in the right direction.
How much will it cost? Given the recent direction of Oracle, it can only be a matter of time before you will need to buy a licence for the Java VM. Maybe that's why version 7 is almost indistinguishable from version 6. If version 8 contains some must-haves...
I'm fairly confident OpenOffice will remain free, though. Who would pay for it?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
