Slashdot Mirror
Oracle's Plans for Java Unveiled at JavaOne
msmoriarty writes "Oracle had lots of Java announcements at this year's JavaOne. So far the plans include: 'The availability of an early access version of JDK 7 for the Mac OS, plans to "bridge the gap" between Java ME and Java SE, an approach to modularizing Java SE 8 that will rely on the Jigsaw platform, a new project that aims to use HTML5 to bring Java to Apple's iOS platform, the availability of JavaFX 2.0, a pending proposal to open source that technology, gearing up Java EE for the cloud, and a delay in the release of Java 8.'"
Don't you mean something more like
ReproductiveSystem.getBodyPart(BodyPartFactory.getBodyPartInstance(new BodyPart(BodyPart.GENITALS(BodyTypes.MALE)))...
Thankfully, no.
---- Booth was a patriot ----
What the hell?
Any self respecting Java developer knows you have to have a GenitalsFactory class that can creates both MaleGenitals and FemaleGenitals (and may in future be extended to create HermaphroditeGenitals, which will be a totally different class because multiple-inheritance if Wrong and Bad)
Java + SWT is great for the desktop. The best portable runtime environment with native look and feel. What more do you want on top of that?
Please. The Oracle (formerly Sun) JVM is not "full of holes". And, Oracle does patch them - what do you think all those Update release are for? Oh, you wanted a patch for just that specific fix into a given (random) Update release, did you? Do you have any experience in managing such a project as the JVM? Point patches are a massive headache to manage - so much so, that while I was at Oracle (in the very JVM group you disparage), we couldn't find a reasonable way to manage point patches well on even the paying customers. And, I worked with a bunch of folks far smarter than the average programmer.
I was in the Sun JVM group for over 7 years (2004-2011). In that time, there were only 3 "critical" exploits published for the JVM, and less than a dozen for the entire JDK. There were more than that for "serious" bugs/problems, but those weren't security breaches (which, were, by definition, an exploit). I should know, I was the Gatekeeper for the JVM.
Newer versions (i.e. 4.1.2 -> 5 -> 6 -> 7 ) do certainly break a non-trivial number of older apps, and require fixes. Updates to a given release (i.e. 6u10 -> 6u20) do very occasionally break something if you jump a large number of Update releases; however, most of the cases we found in such breakage of apps was the developer's fault in either using an undocumented "feature", a feature which was marked "obsolete", or one which was marked as "unsupported". If you stuck to the documented API of supported features, well, it wasn't absolutely 100% bug-free upgradable, but then again, nothing is, and the JDK has an outstanding track record in that regard.
That's not to say that there aren't problems in both the JVM and JDK. It's just that you obviously don't know what you're talking about in the real world. Don't take my word for it: Google "Sun JVM security (hole OR flaw)" there are a very few links (maybe 2) to flaws in the past 5 years, a bundle of links to stories around 2004-2005 (which are all about the same set of bugs), and then practically everything else is at least 10 years old. Guess what? ALL of those have been fixed, relatively quickly, too.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
If you want to talk about dead platforms, look no further than Perl.
I love the fact that you're posting this on Slashdot.
Actually, I'd argue that JDK 8 isn't that important right now. People are still adjusting to JDK 7, and fixing the issues with JDK 7 should have a higher priority than doing all new stuff for JDK 8. Especially since there are very few features slated for 8 that are of broad immediate appeal. Honestly, I was never a believer than less than 2 years between major JDK releases was a good idea. It takes at least a couple of years for vendors to move to the new JDK, and stabilization of a release takes awhile (as the user base of the JDK is enormous, and there's no substitute for real-world running of apps to shake out bugs in the JDK).
JDK 7 was released 2 months ago. Focusing on making that a better product, rather than jump right into spending all their effort on a future release is, IMHO, the more responsible use of limited resources.
Of course, nothing is preventing community work on OpenJDK 8.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
It's more subtle than that.
For instance using standard Oracle is pretty cheap... and it's not until you start to say 'gee, if only we had partitioning these performance problems would go away' that you really get stung.
Then you start doing spatial analysis and find the Spatial features easier to use than the crippled Locator.
Or you try a new database for a new project and because it's still a POC everything is free, until you go live...
Or you upgrade from dual core to quad as part of a regular hardware upgrade - only to find you need to buy twice the licences.
Or you discover that sometimes hardware does fail and you need RAC.
By the time those sort of things happen it's too late to say 'well, it would've been free if only we'd used MS SQL, Postgres or any other vendor'. Oracle's sting isn't the initial purchase price.
Also, have you ever tried running a system outside support & maintenance? I know a number of companies that keep extra Oracle licences around because they don't dare repurchase them if they ever do end up needing them.
Well, in hindsight it would have been nice if Sun had adopted SWT and its native widgets instead of pushing Swing on the desktop for years and getting nowhere. Yes, I get it, writing a cross-platform native GUI layer that acts the same on every platform is hard, but they had numerous options. They could have bought or licensed QT. They could have adopted SWT. Or wxJava. Or even GTK (like most Mono LInux desktop apps).
It would have been nice if they had open sourced the JDK a decade earlier instead of waiting until they felt the heat from gcj. Java could have been the dominant platform for writing cross-platform desktop apps, instead Sun was pushing applets, and it took until SWT before I saw the first Java desktop app that didn't suck (Eclipse). Imagine my surprise when I found that the second Java desktop app that didn't suck (Azureus) was also based on SWT.
Applications like Eclipse, Azureus, and Banshee show that Java/Mono style languages can do desktop apps, but for whatever reasons the Sun AWT/Swing combination went nowhere. If it were a true open source project I'm sure they would've adopted another GUI widget layer, but they didn't, probably because Sun wanted exclusive ownership rights.
If you do not understand how to make clean, efficient code in Language X, you should consider learning Language X.
Have you tried running a Microsoft App lately without installing the .NET 3.5, 4, 2.2, 1.1, 1.0, and maybe another couple of .Net runtimes? I have a couple of guys at work that are gung ho .NET developers right out of school. And they hate java because you have to install a runtime and its slow.. I laugh every time...
What are we going to do tonight Brain?
Actually, if you know what you are doing then Swing is second to none (to bad most people don't have enough decent knowledge of Swing to use it effectively). With the Nimbus look-and-feel it is also pretty nice (at least that's what I have heard from the users that are used to fugly Windows apps - that are even more inconsistent than the Java ones).
SWT seems ok until you start to develop it. Then you realise it is awful. Then if you have to develop in SWT off Windows you realise it is even more horrible. Then you have professional projects where you need to extend SWT and you look deep under the covers and realise SWT is really, truly bone-deep-ugly. Then you go back to Swing and life is much, much better - especially ever since Java 1.6u10+ (Nimbus and fully hardware accelerated rendering on multiple platforms).
Looks like you got the wrong memo. Any language that is not used by a hipster is dead.
And the Department of Defense. Java is vetted for TS and higher clearance systems. Most other languages and platforms are not.
Having a JVM - or any kind of virtual machine - is actually a pretty big security issue. For native code, modern OSes are hardened with protections like no-exec flags on data that make it harder to exploit many common classes of security holes, but as soon as you introduce a sufficiently capable virtual machine into your process this hardening becomes worthless. As far as the processor is concerned, the VM bytecode is just data like any other data, and it's fairly easy to use any security holes to trick the VM into executing your own malicious bytecode, bypassing noexec entirely.