Oracle is moving to drop a major component from its upcoming Java 8 release, in an effort to get the flagging Java development process back on track.
The component, known as Project Jigsaw, was an addition to the language that would have allowed Java developers to write and distribute programs as modules. It would also have …

COMMENTS

One thing i'd like to see in desktop java is something that android and ios have had since day 1 (I think, if not certainly for a very long time) - a WebView of some kind. As it is now, if you want a real web browser you have to use SWT, get an SWT-Swing bridge, and package up OS specific versions of any application, and even then you'll get IE on windows, webkit on osx, etc.

They used to...

Back in the day, Swing's JEditorPane's HTML support was about on a par with the browsers. The problem is that it hasn't been updated. But I'm not sure how sensible it is to compare Java with Android or iOS in this regard, since its cross-platform nature means that it can't rely on external components and would have to bundle the entire browser. (Also note that .Net doesn't have a very good equivalent either - the best it has is a slightly flaky COM wrapper around IE).

WebView implementation

Already there - check out the WebView class in JavaFX. I know there are a lot of legacy Swing based applications around, but any new project should really be looking to use JavaFX for UI work - it's a huge step forward.

JavaFX 2 has a WebView, and before you start laughing, JavaFX 2 actually seems quite nice. It is compatible with Swing - you can embed JavaFX 2 components within a Swing application including the WebView (which is based on WebKit).

Re: 8 already ?

I think it was more like it was very very slow to move to 7. As the article said, there's concern among developers that the language isn't evolving and IIRC the rules say they aren't allowed to change the APIs in an update release. The only way that new things are actually going to happen is if major releases come out on a reasonably regular basis.

Re: 8 already ?

Re: 8 already ?

The really scary fact is Java 6 is going EOL this November!

Meanwhile we still have plenty of customers running Java 1.4 (almost always under Websphere), so all this new stuff is useless to us.

At a Sun conference a while back I suggested they incorporate something like Retrotranslator into their compiler, so devs could use new features (ie java.util.concurrent) but still have their code run on older VMs (which Sun could charge support for). The response was "what's Retrotranslator?". Personally I'd like to see a bit more consolidation and stabilty (particularly wrt the Desktop, which is in the process of being lost, and security) and a bit less focus on new shiny shiny features.

Re: 8 already ?

Re: 8 already ?

"Jul 03, 2012 / Apache Camel 2.10.0 Released / The Camel community announces the immediate availability of a new minor release camel-2.10.0."

from the faq <http://camel.apache.org/faq.html>

"Apache Camel was developed to run on Java 1.5 or later to take advantage of the new language features like generics and annotations together with using the Java 5 concurrency code. Starting with version 2.7.0, only Java 1.6 is supported. / Starting with version 2.10.0, Java 1.7 is supported, but not required."

The long-suffering Java community

"That will likely be a welcome change for the long-suffering Java community, many of whom have grown frustrated with Java's seeming inability to evolve to suit the latest programming features and techniques."

The mind boggles at statements like this. Java has been missing fundamental capabilities since its inception. How long, how many releases before they gracelessly implemented something as simple as a system regular expressions library? How many features common to other languages were finally implemented only out of embarrassment at the absence of them for so so long?

Java chose to emphasize abstractions such as 'purity' and minimalism. It was thereby sterile and barren. A surface so stain-resistant you had to use buckets of ink to write anything usable.

Damn the language and its implementors when the users of the language are not the foremost thought.

(I've been using closures and such 'advanced' features in *two* completely different languages since 1995. But I suppose they're too 'ugly' to consider for enterprises, hmm?)

Re: "You can always use Clojure"

Easy there, tiger. Scala was invented for the sort of person who wanted sexy new version of Java that let them keep objects and braces and other linguistic comfort blankets. Me, I'm looking forward to yet better JVM support for dynamic languages. If the Nashorn project works out nicely, it'll do stuff like Jython and JRuby a world of good.

Java 8 looks like a pretty sound dev platform to me, and its about time too; there was something fundamentally wrong about a language designed to replace C++ lacking a raft of features that C++ has had for a few years, and it'll be nice having decent alternatives to C# 4 which is a pretty impressive piece of work in itself.

Re: The long-suffering Java community

To be honest, if the absence such language features are preventing you from doing your job, you should reconsider your role as a developer. Every programming environment has strengths and weaknesses, and understanding and working around those is core to delivering functionality. At the end of the day, that's what people actually want - a functioning system, not one that's written using specific constructs.

I'll accept that it's nice to have some language features, but it's also nice to have an incredibly efficient run time, hot spot optimisation, immensely fast garbage collection, vast swathes of inbuilt libraries that are robust, well characterised and reliably supported from one release to the next. It's also nice to have complete documentation, support across multiple platforms and a host of tools that handle everything from virtualisation to performance and testing. Oh yes, then there's the interoperability with many other systems, support for different languages on the VM, third party frameworks and the availability of experienced developers who can work with all of the above.

As it is, the long suffering Java community have produced Scala, Groovy, Clojure, JRuby and a host of others, and modularisation is well supported by OSGi. The absence of Jigsaw is not going to stop the use of Java in projects large and small. At the same time, Oracle seem to be consistently wrong-footed in this arena which is, more than anything, a missed opportunity.

Re: "You can always use Clojure"

"Java 8 looks like a pretty sound dev platform to me, and its about time too; there was something fundamentally wrong about a language designed to replace C++ lacking a raft of features that C++ has had for a few years,"

It was only ever Java-only coders who thought it would replace C++. For those of us who use C++, java is simply the rather noisy, show off younger brother who'll might tidy his room up occasionally (usually at an inconvenient time for everyone else) without being explicitly told to do it , but other than that is slow and inadequate at pretty much everything he's given to do.

Not really the end of the world

Considering that Java is now a dull, enterprise back-end kind of language, coded in by boring enterprise guys like myself, who cares that development of the language moves at the speed of tectonic plates? I mean, the application I'm co-developing just moved from Java 5 up to Java 6, and that only as a required platform; half the code has not been updated since Java 1.3. Enterprises sure ain't waiting for rapid development cycles; they want solid, bug-free (asif) software.

I know Java isn't sexy, it isn't what the script kiddies like, and it's not at the bleeding edge of computing either, but by-and-large it gets the job done, and it gets an awful lot of jobs done these days.

"Groovy grab my Code...."

And you can spice it up by injecting Groovy into moderately large subtrees of the codebase. Try it.

You lose a lot of compile time checks and things become slower at runtime (you have to think of objects as mutable bags of methods and properties rather than as instances of nodes in a class hierarchy). But the feeling is the one one gets when one goes from the detailed sigma+index notation to the freewheeling Einstein summation convention in Tensor calculus. YES!

I would like to see that modularization though. That should really have been in there from the beginning. Well, we have OSGi for now.

Re: Not really the end of the world

Apparently Java SE 5 ran out of "public" support in 2009, with Java SE 6 going in November 2012. We'll be upgrading soon ourselves. To 6.

Of course there are other support options, and indeed other incarnations.

Java 8 evidently arrives in 2013 - they hope.

Our manager thinks Java 7 still has too many bugs for us, but I wonder if he understands that a tool like this -always- has -some- bugs, and most of them we won't ever touch. Nobody does. That's why they are still bugs.

Re: Waiting for the next announcement...

Agreed: losing lambda's would make Java 8 not really worth a new release. Lambda's will enable some powerful idioms, reducing a lot of the boring boiler-plate that Java currently makes us jump through.

That said, we're still on Java 6 here, so we're missing out on its goodness.

"no really earth-shattering, ground-breaking kinds of features."

That sums up the entire java language IMO. What exactly is the point of it? Sure there's the - in theory - write once run anywhere - so long as you have the correct JWM at the run site - but most companys only deploy on a single OS platform anyway.

So, Java ... why? What are the advantages over C++ apart from a slightly cleaner syntax? Plenty of disadvantages , the main one being the horrendous CPU and memory sucking nature of every JVM we've ever tried.

Re: "no really earth-shattering, ground-breaking kinds of features."

Actually the write once run anywhere holds to a certain degree, java 6 has been arround for so long that most machines have it installed and since most libraries are Java5 compatible the extent of reusable binaries is massive.

In fact that is java's main strength; the number of third party Open Source API out there have given developers a significant ability to reduce the time taken to write code and thus costs. Its also strongly typed which is a massive aid to the IDE's in alerting the developer to issues early, has an easy to manipulate garbage collector and the JVM provides hooks for full runtime monitoring and management.

Memory footprint is not that much bigger than C++ once you get past the initlal 60mb I would say you probably arn't detaching your objects properly, i.e. a memory leak. As for the CPU modern JVM's are much faster, and for intensive operations you can always use native functions, and for common libraries you are likely to find someone has already created a bridge. For instance most java game engines talk directly to OpenGL/AL/CL via native calls.

Re: "no really earth-shattering, ground-breaking kinds of features."

"Memory footprint is not that much bigger than C++ once you get past the initlal 60mb "

60MB might small small beer on a machine with GBs of memory , but bear in mind that java is mainly used on servers these days and any given server could literally have hundreds if not thousands of processes running on it at any given time. That 60mb quickly adds up.

Re: "no really earth-shattering, ground-breaking kinds of features."

Only if you don't realize that "leaving to the runtime system the task of freeing up memory that can never be used again" and "keeping all the memory reachable, forever" are two totally different things.

Why are we back in the early 90s discussing GCs? It's tiresome. But at least, today there is Jimmy Wales' Big Bag of Trivia. Have a gander:

so unexpected?

Everyone knows that the problem Project Jigsaw was trying to solve is hard.. The work has (more recently) been discussed in an open and transparent way via the developer mailing list. Recently it was obvious that Project Jigsaw wasn't progressing as much as they should have been. This is in stark contrast to the Project Lambda mailing list which suggest a language/platform change pretty much on track.

So my reaction to the announcement was dissapointment but not really any surprise. Was I annoyed at the way it was communicated, well no, the mailing lists were keeping me up to date with how things were progressing and the decision was communicated 18 months before the slated release date of Java 8.

I'm not qualified to answer the 'Just use OSGi/Maven' argument. But my experience with JBoss Modules is that I dearly want modularization rules to be applied at compile time AND runtime so that I don't get runtime errors that are harder to solve than they should be.