Hamlet D'Arcy has been writing software for over a decade, and has spent considerable time coding in C++, Java, and Groovy. He's passionate about learning new languages and different ways to think about problems, and recently he's been discovering the joys of both F# and Scheme. He's an active member of the Groovy Users of Minnesota and the Object Technology User Group, is a committer on the Groovy project, and is a contributor on a few open source projects (including JConch and the IDEA Groovy Plugin). He blogs regularly at http://hamletdarcy.blogspot.com and can be found on Twitter as HamletDRC (http://twitter.com/hamletdrc). Hamlet is a DZone MVB and is not an employee of DZone and has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Java 7 Update from Mark Reinhold at Devoxx

12.12.2008
| 17208 views |
  • submit to reddit

This is a summary of Mark Reinhold's Java 7 update given at Devoxx, with a few comments from myself. Mark described his presentation as a provisional plan and not binding.

The changes in Java 7 will come from Sun and others.

Among the "Big" changes from Sun (with what looks like a prioritized ordering):

  • Modularization - 294 and project Jigsaw
  • 292 - JVM Support for dynamic languages
  • JSR 203 - More New I/O APIs which are nearly finished, includes true asynchronous I/O (not just non blocking I/O) and finally a real file system API
  • JSR TBD: Small language changes (following)
  • Safe rethrow - Allows a broad catch clause, with the compiler being smarter on what you're allowed to rethrow based on what is thrown from the try block. (I had not seen this before but it looks nice)
  • Null dereference expressions - Null checks with '?' syntax similar to Groovy... lettign developers avoid a nest of null checks.
  • Better type inference - Example around generics instantiations, but it was not clear how far the inference would be taken (the more the better in my opinion).
  • Multi-catch - (yes!) allows a comma seperated list of disjunctive exception types in catch clause.
  • Joe Darcy is leading effort in Open JDK and his blog was referenced: http://blogs.sun.com/darcy
  • JSR 296 - Swing application framework - It still needs to be easier to create Swing apps.
  • A forward port of 6u10 features (Java Kernal, QUickstarter, New Plug-in, etc.)
The "Small" Sun changes are:
  • SCTP (Stream Control Transmission Protocol) - Driven by big customers, probably proprietary
  • SDP (Sockets Direct Protocol) - Again, customer driven
  • Upgrade class loader architecture - Work started in Java 5 and continues to evolve. There are some deadlock issues today in classloader delegation that will be addressed.
  • Method to close a URLClassLoader - seems simple but actually tricky to implement.
  • Unicode 5.0 support - "just got to do it"
  • XRender pipeline for Java 2D - This was an Open JDK Integrators Challenge project,and is an analog to the OpenGL pipeline but much more portable across x11.
  • Swing Updates - JXLayer, DatePicker, CSS styling (maybe) that Ethan Nicholaus (sp?) has been working on
The "Fast" changes from Sun (apparently, this means performance improvements):
Hotspot run-time compiler enhancements
  • G1 Garbage collector (available in 6 experimentally soon) - Leads to much smaller pause times and hopes to replace CMS (Concurrent mark sweep) GC
  • Compressed pointer 64 bit VM
  • MVM-lite maybe - Multiple Virtual Machines will help you run isolated applications and allow a kill -9 on a Java application. Mark said it is not clear what problem would be solved, and original project was extremely ambitious, but desire to drag apps out of browser plugin presents a good usage and need for MVM.

Other's Features:
  • JSR 308 - Annotations on Java Types - Driven by Prof. Michael Ernst and Mahmood Ali. Encode more compile time assertions in code (like the @NotNull annotation), which is checked by the static checker. (yes!)
  • Concurrency and Collections Updated (JSR 166 continues). All the features announced on the concurrency interest mailing list by Doug Lea yesterday: Fork/Join, Phasers, LinkedTransferQueue, ConcurrentReferenceHashMap, and Fences
The featues not in 7 (some of them, anyway the list is actually infinite)
  • Closures - No consensus around single proposal
  • Reified generics
  • 1st class properties
  • Operator overloading
  • BigDecimal syntax
  • JSR 295 - Beans Binding

And finally the big news... a release date! "Java 7 in Early 2010" - Mark Reinhold

From http://hamletdarcy.blogspot.com

Published at DZone with permission of Hamlet D'Arcy, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Osvaldo Doederlein replied on Fri, 2008/12/12 - 7:05am

Compressed 64->32bit pointers are already available in the JDK 6u6p (Performance Release). G1 is already available in the latest JDK 7 builds, it's just not enabled by default and not very reliable (crashed on the first stress test I ran - I filed Bug 6775807).

JSR-296 and the other Swing Updates is a good item to calm down the Swing coders who are very worried about JavaFX meaning an abandonment of Swing (remember Sun keeps doing a great job with NetBeans RCP, etc.). But if JSR-295 is dropped, I can't help but think that FX may be part of the reason, as FX includes its own, different binding mechanism. Perhaps JSR-295 needs time to be redesigned so the platform as a whole doesn't end with two completely incompatible binding runtimes. At least it would be important that both share a low-level core that enables interoperability, e.g. standard Swing code binding to data from FX classes, and FX components receiving notifications from data defined from Java code and bound through JSR-295 APIs.

Java7 will be the best release in many years infrastructure-wise: 294/Jigsaw; Concurrent classloading - I think that could speed up the boot time of large apps, especially microkernel-based ones like JavaEE servers and IDEs; XRender - will finally make Java a first-class citizen for Linux desktop apps; G1; Full 64 bit support (will actually debut in 6u12, get the beta); ForkJoin.

So much good stuff, I can almost forget the sadness of probably not having Closures. I guess it's time to move to Scala, JavaFX or some other modern JVM language (just not dynamically typed crap like Ruby or Python). I think that five years from now, I'll only be writing 'standard' Java code if I'm writing a low-level runtime of some sort (middlewares etc). Thanks to the conservadorism of the community, the Java language is slowing moving into legacy and low-level roles.

Jacek Furmankiewicz replied on Fri, 2008/12/12 - 8:08am in response to: Osvaldo Doederlein

The Java community is not all all conservative, far from it. Just one major player is.:-)

But yes, the closures is a disaster...I mean you have 3 working prototypes and you still cannot add it?

 

Richard Osbaldeston replied on Fri, 2008/12/12 - 10:44am in response to: Osvaldo Doederlein

Not sure how 296 is going to calm down developers with articles like JavaFX==Swing 2.0 http://www.dzone.com/links/javafx_swing_20.html doing the rounds. JSR296 1.0 has been around for a year already only receiving one minor commit in that time. Are they just bundling the existing 1.0 jar here? development has been at a standstill for some time. Same deal with the SwingX classes all it'll take is a package change. The Painter interface has already been added in 6u10. JXLayer? did someone just trawl java.net for relatively mature projects to include? Not so much fresh development but more a bundling exercise, which is possibly at odds with the modularized view of the world.

Appframework is only really useful for new greenfield Swing projects, JavaFX seems to be vying for that position now. Swing developers would probably prefer the FileChooser fixing and any Laf enhancements required for Windows 7.0 (released next year - the year before JDK 7.0).

Given 6.0 was released in 2006 I'm left somewhat under-whelmed by the changes on offer here small syntax changes and JavaFX seems to sum it up.. how does that stack up against 4 years of .Net, Ruby or Flex development.

Osvaldo Doederlein replied on Fri, 2008/12/12 - 11:26am in response to: Richard Osbaldeston

[quote=osbald]

Not sure how 296 is going to calm down developers with articles like JavaFX==Swing 2.0[/quote]

I wouldn't see that as a problem if I was a Swing developer, beause the Swing API has no hope of being reworked into a modern GUI/RIA framework, without massive compatibility-breaking that no one wants. Extra layers like JSRs 295/296, or RCP projects and tools, can improve productivity and save some keystrokes, but can't fix an aging architecture. BTW there is already a Swing 2.0 API, it is called SWT and it solves two of Swing's major defects: performance (speed, memory footprint, loading time, resource usage - SWT destroys Swing in all these aspects), and LAF fidelity (Swing has improved a lot, but it's still a Sysiphus job for each big release of any OS, while SWT only needs very minor updates to catch up). SWT's multiplatform story is also reaching a very serious level. OTOH, SWT is not a modern RIA framework, even its 2D gfx subsystem is not yet competition to Java2D, I think. So, perhaps we could regard JavaFX as Swing 3.0.

Anonymous Coward replied on Fri, 2008/12/12 - 12:16pm

[quote] Given 6.0 was released in 2006 I'm left somewhat under-whelmed by the changes on offer here small syntax changes and JavaFX seems to sum it up.. how does that stack up against 4 years of .Net, Ruby or Flex development.[/quote]

I'd say it stacks up rather well. Java FX is a big deal – a new language, and six new products shipped or shipping next year (desktop, devceloper plugins for Netbeans/Eclipse, the project Nile stuff, mobile, TV and the RAD development tool.)

Then there’s two versions of EE shipped – 5 was the same year as Java SE 6, 6 is expected next year – and both of these are big deals when you think about what is in them - EJB3, JSF1 and 2, JPA 1 and 2 and WebBeans.

There’s all the work around dynamic languages – JRuby, Jython, the Da Vinci Machine Project. Not to mention Fortress.

And there’s lot of interesting stuff outside of Sun – GWT, Android, Cliff Clicks work on scalable non-blocking code style (see http://www.infoq.com/news/2008/05/click_non_blocking) not to mention Groovy, Scala etc.

Plus Java 7. I'll admit to be quite relieved about closures myself – I don’t like any of the existing proposals very much and I can’t say I miss the full closures syntax when working with Java. That said a combination of ARM and C3S looks interesting and given how well anonymous inner classes work with the parallel control structures this is the route I’d like to see Java go in – I’m in no hurry though.

It’s a pretty exciting time to be involved in Java I reckon.

 

Richard Osbaldeston replied on Fri, 2008/12/12 - 1:09pm in response to: Osvaldo Doederlein

Swing API has no hope of being reworked into a modern GUI/RIA framework

So the solution is to replace it with completely new compatibility-breaking GUI/RIA framework that isn't even in the same language? How is that any less disruptive? Until we see JavaFX show some enterprise support chops it isn't even Swing 0.1 for me. Could you migrate Netbeans into JavaFX? (why would you even try?) One of the hallmarks of a updated version of an API is that your skills and knowledge from the previous incarnation are transferable. The code is migratable. It's not start over from first principals. Embedding Swing components in JavaFX gives you what exactly? especially if they're not going to be enhanced.. You can't call JavaFX Swing 3.0 when all it's doing is embedding Swing 1.0 components..?

SWT is AWT2 in my book, not Swing2. It had its chance and didn't get the traction. Pure JavaFX components seem to do away with Look and Feels and OS fidelity. It's not practical to be ubiquitous on all devices and offer platform fidelity at the same time. So that would make Swings replacement less functional that it's predecessor?

Richard Osbaldeston replied on Fri, 2008/12/12 - 1:06pm in response to: Anonymous Coward

Then there’s two versions of EE shipped – 5 was the same year as Java SE 6, 6 is expected next year – and both of these are big deals when you think about what is in them - EJB3, JSF1 and 2, JPA 1 and 2 and WebBeans. There’s all the work around dynamic languages – JRuby, Jython, the Da Vinci Machine Project. Not to mention Fortress. And there’s lot of interesting stuff outside of Sun – GWT, Android, Cliff Clicks work on scalable non-blocking code style (see http://www.infoq.com/news/2008/05/click_non_blocking) not to mention Groovy, Scala etc.

None of which are actually in the JDK last time I checked? Actually as I Swing developer I find it annoying that EJBs got several code-breaking revisions while poor old Swing didn't even get a second chance.

J Szy replied on Fri, 2008/12/12 - 2:08pm in response to: Anonymous Coward

[quote=chhum]I'd say it stacks up rather well. Java FX is a big deal - a new language[/quote]

I'd rather say it's a big mistake. I believe programmers generally are not language people, a new language is not "a new tool in the toolbox", it's simply another technology one must take time to learn and the time is not billable.

[quote]and both of these are big deals when you think about what is in them - EJB3,JSF1 and 2, JPA 1 and 2 and WebBeans.[/quote]

Now that's a really big deal and big advance. I wish they put more time to framework development. Even if the frameworks included in EE are somewhat less powerful than their open source counterparts, they are really important for the enterprise.

[quote]There’sall the work around dynamic languages – JRuby, Jython, the Da Vinci MachineProject. Not to mention Fortress.[/quote]

Now this is an utter waste of time and money. Blog weenies aside, hardly anyone uses those "dynamic languages" in the real world. I'd rather they added some new useful frameworks instead.

 

Osvaldo Doederlein replied on Fri, 2008/12/12 - 2:41pm in response to: Richard Osbaldeston

[quote=osbald]
Swing API has no hope of being reworked into a modern GUI/RIA framework

So the solution is to replace it with completely new compatibility-breaking GUI/RIA framework that isn't even in the same language? How is that any less disruptive?[/quote]

It's less disruptive because FX is not "Swing 2.0" in a strict sense (evolution of the same API); it's a next generation toolkit that's supposed to replace Swing, and there are no conflicts between the old and the new toolkit. A real Swing 2.0 would have to use the same package, class and method names, so you'd lose the backwards-compatible API in order to use the next-gen version (unless Sun came with some side-by-side solution, but any solution would have big tradeoffs, like significantly larger JRE to host two separated javax.swing packages and "DLL Hell" with dependencies on third-party components etc.).

Because JavaFX is completely isolated (especially the API - different packages), Swing can actually continue to be maintained and enhanced independently; and that's exactly what is happening, although perhaps in a slower pace than it would if Swing continued to be Java's single choice for RIA.

Swing coders are just being jealous of all man-power Sun is investing in FX and not on Swing. But the hard fact is, even an investment as high as the US debt couldn't make Swing a much better toolkit without major breaking changes. Get over it. If you want some cool evolutionary stuff that Sun is not sponsoring anymore, like SwingX, well it's all open source, so if the Swing community is big enough there won't be lack of people to finish it.

BTW, you will be able to call a lot of FX's goodness - SceneGraph, new codecs - from normal Java/Swing code. It would be very good if the FX team could write some demos and tutorials for that. This could calm down Swing fans big time.

Jeroen Wenting replied on Mon, 2008/12/15 - 2:20am in response to: Jacek Furmankiewicz

[quote=Jacek]

The Java community is not all all conservative, far from it. Just one major player is.:-)

[/quote]

About time they became a bit more conservative after the disaster of Java 6 and the near disaster of 1.5.

[quote=Jacek]  

But yes, the closures is a disaster...I mean you have 3 working prototypes and you still cannot add it?

[/quote]

Closures would be a disaster if added. Not adding them is a good thing. It's about time Sun stopped stuffing Java with all kinds of Me2! features, things added/proposed (like closures, like properties, like embedded SOAP stacks and http servers, etc. etc.) for no other real reason than that some other language has them.

Osvaldo Doederlein replied on Mon, 2008/12/15 - 6:23am in response to: Jeroen Wenting

[quote=jwenting]

About time they became a bit more conservative after the disaster of Java 6 and the near disaster of 1.5.

[/quote]

I understand the criticism for Java5 (non-reified generics), but what do you mean by "Java6 disaster"? Please substantiate that. Java6 is a huge success in my experience, and I don't remember hearing major compains about that release. (Personally, I'd just complain that all the good stuff in 6u10 could have shipped in JDK 6 FCS; Sun should have awaked for the desktop/RIA problem years before.)

[quote=jwenting]

things added/proposed (like closures, like properties, like embedded SOAP stacks and http servers, etc. etc.) for no other real reason than that some other language has them.[/quote]

This kind of argument is getting very old. Everybody and his dog knows that features like closures and generics are wanted (by part of the community at least) because they should have been in Java since JDK 1.0, and that's the opinion of the "Java fathers" themselves; it's just that they didn't have time to do these things for the 1.0 deadline (I won't post yet again the historical links for this; they're not hard to google.) I agree though that some heavyweight libraries, like the full JAX-WS, are harder to justify in the JRE - at least in JavaFX they did the right thing and opted for a very light REST web services support, let those who need SOAP import it from JavaSE or an extension lib. But after the JavaKernel, the download time of APIs like WS, CORBA etc. is not a big deal anymore... except for a few issues that I hope the Java7 modularization effort (esp. project Jigsaw) will address.

Jeroen Wenting replied on Mon, 2008/12/15 - 7:09am

Java6 is unstable, too unstable to run a serious server on (or used to be, update 7 seems to be getting close to being useful).

It's also got (as I said) a massive amount of Me2! features (which IS a real problem).

And oh, James Gosling didn't want function pointers (aka closures) in Java. He only blogged that he wanted them sometime this year and said he had always wanted them, a publication that was quickly debunked when someone pulled out an older post in which he said he deliberately had not included them because he considered them a bad idea.
Marketing must have told him to change his mind...

Function pointers (call them closures if you like) have no place in an object oriented language, certainly not in one that was designed from the outset to not have them and instead features perfectly fine alternatives (like anonymous inner classes) if you do require similar functionality.
I've been programming professionally in Java for over a decade (and in a wide variety of settings, ranging from small utilities to large enterprise systems and everything in between) and never had the need for them, never missed having them. That's enough of a litmus test for me.

Modularised JVMs are another disaster waiting to happen. People install the minimal version from some disk, later install from another disk software that requires more and expects to download it, but the machine has no internet connection (or a very slow or tightly firewalled one) and blame the software manufacturer for the errors they're getting.
While less of a problem these days in the west where DSL and cable internet are commonplace (but nowhere near universal) in the third world (and in many government agencies and larger corporations) such restrictions are the norm rather than the exception.

Jacek Furmankiewicz replied on Mon, 2008/12/15 - 8:10am in response to: Jeroen Wenting

Java 5 and 6 a disaster? Are we in the same universe?

We may argue about the need for closures, but you are 100% wrong about properties.

Java desperately needs properties, real properties...i.e. not just a replacement for getters/setters but something that automatically takes care of firePropertyChange() as well, which is needed for data binding.

Data binding in Java is way behind other languages, even with libraries such as beans Binding (JSR 295) because of the insane amount of code that needs to be added to every POJO to enable data binding.

 Real properties would fix that. Sun was able to give proper databinding to JavaFX within 12 months, but is leaving Java developers (99.9% of its target market) out in the cold by not giving the same offerring to core Java.

We need Properties now (if you are a UI developer, I can understand for server-side guys it's not so important).

Due to lack of properties, folks are developing major hacks such as this or this in order to make databinding bearable in Java.

 

 

Osvaldo Doederlein replied on Mon, 2008/12/15 - 8:38am in response to: Jeroen Wenting

[quote=jwenting]

Java6 is unstable, too unstable to run a serious server on (or used to be, update 7 seems to be getting close to being useful).

[/quote]

Perhaps I was just lucky, I've put at least one "serious production" app on Java6 since FCS. Of course it wasn't a bug-free release, YMMV, and so on. Individual anecdotes (either yours or mine) are not evidence that any particular release was very good or very bad.

[quote=jwenting]

And oh, James Gosling didn't want function pointers (aka closures) in Java.

[/quote]

I know the Gosling blogging/unblogging stuff... but we can't know for sure if he was lying now, or in the past when he had to defense against to pure-OO crowd thatreceived Java with a lot of negative comments because ithad primitive types, didn't have closures, and other "sins". I don't envy James, he was forced to wear both the engineer and marketoid hats since the first release of Java, and up to current days when he doesn't seem very interested in playing a big role on the language evolution (btw that's a good thing, no language should be strongly tied to a single guy's mindset as both mature). OTOH, the fact that Bill Joy was strongly for closures and generics is sufficient for me. ;-)

[quote=jwenting]

Function pointers (call them closures if you like)

[/quote]

Now that's quite a significantway of assuming that you don't know jack about closures. ;-) Based on my memory of long history of good postings, I don't really believe that you are so uninformed about OO, so I guess you're just trolling. There is a HUGE distance from a simple function pointe to a closure. With definitions as relaxed as that, I think ANSI C would almost be considered a modern OO language. ;-)

[quote=jwenting]

have no place in an object oriented language, certainly not in one that was designed from the outset to not have them and instead features perfectly fine alternatives (like anonymous inner classes) if you do require similar functionality.

[/quote]

That's the funniest trolling ever... "no place in OO", say like the first true, gold-standard OO languages (Smalltalk family)? And Java WAS designed from the outset with closure, they actually had closures in early Oak prototypes but dropped it to "not scare users" with issues like the cost of hidden heap allocations. Inner classes are not "perfectly fine", they beloing the Trash Can, to the Hall of Shame of language design(*). That's IMO and I am nobody, but I've heard the same from many world-class OO experts that I respect.

(*) Although I'm happy that we've got inner classes in JDK 1.1, as a pragmatic solution for the ENORMOUS PAIN that was Java 1.0 without any kind of closure-like syntax. At that time they had to deprecate the initial AWT event model, so it was already bad enough, backwards-compatibility wise, that I think it wouldn't hurt to walk the last mile andadding full closures (in both functionality and short syntax)... if this happened in JDK 1.1, subsequent APIs like Java2 Collections would have been designed around closures since the beginning, and Java would be in much better shape today.

[quote=jwenting]

I've been programming professionally in Java for over a decade (and in a wide variety of settings, ranging from small utilities to large enterprise systems and everything in between) and never had the need for them, never missed having them. That's enough of a litmus test for me.

[/quote]

That's not a logically valid argumentation. You just learned and got comfortable with the tools that you have, so you don't think that anything different is "necessary". Some C/C++ programmers are saying, even to this day, that Garbage Collection is a useless feature because "I have 20 years experience, programmed in dozens of domains, and never needed it." Absence of evidence of a need != evidence of absense of that need.

[quote=jwenting]

Modularised JVMs are another disaster waiting to happen. People install the minimal version from some disk, later install from another disk software that requires more and expects to download it, but the machine has no internet connection (or a very slow or tightly firewalled one) and blame the software manufacturer for the errors they're getting. [/quote]

You didn't understand this particular proposal. No "minimal JRE" will be made available anywhere (not from Sun, not from any JavaSE-certified source). The JavaSE will not adopt profiles a la JavaME or JavaEE 6. Modularization is just an internal refactoring - a logical split of the numerous APIs so they don' have unnecessary dependencies; this can be accomplished by some lazy initialization code here, some lightweight structural design patterns there, etc. This refactoring will have benefits like faster application loading time (less unnecessary classloading), easier QA (ability to test bugfixes and new features in isolation without needing large regressionall the time), smaller patches (no need to patch the massive rt.jar all the time), etc. The currently bulky JARs and DLLs will be split in many smaller files - the IBM JDK already does that in some extent: their Java6 rt.jar file is just 17Mb, because there are another jars for XML, CORBA, crypto, security, JDBC etc. (although this doesn't necessarily mean osser-coupling among APIs fro mdifferent jars; it may be just different packaging). With real modularisation, simpler apps should load less stuff than before, and there should be other subtle benefits like a better bootclasspath override machanism and extension API installation, better interaction with OSGi runtimes, etc.

Richard Osbaldeston replied on Mon, 2008/12/15 - 9:54am in response to: Jacek Furmankiewicz

Not forgetting JavaFX may well benefit from properties too. Currently JavaFX can only bind to other JavaFX objects, pretty limiting if you're going to be calling out to remote Java services or beans. (arguably the single EDT thread is even more limiting). Doubt remote beans will return JavaFX objects nor readily take JavaFX objects as inputs as I also assume JavaFX libs not normally in servers classpath? are they serializable? (gawd knows beansbindings aren't) if not heavier than needed for domain objects?. JavaFX Script to/from Java integration story yet to be told.

Even then assuming all domain objects will be POJOs is often flawed in the real world as most frameworks will be using proxies or bytecode manipulation of some sort these days: http://tinyurl.com/6neuht

Richard Osbaldeston replied on Mon, 2008/12/15 - 11:44am in response to: Osvaldo Doederlein

Because JavaFX is completely isolated (especially the API - different packages), Swing can actually continue to be maintained and enhanced independently; and that's exactly what is happening

Is it? don't see any signs of swing being maintained in the sense of getting bindings or properties nay time soon. All I see is the odd bits developed for JavaFX but happen to be accessible by Java too and a bunch of bundled java.net projects I've already been using (SwingX, JXLayer). Strikes me as a Swing developer Sun are trying to pull the wool over my eyes over this maintainace issue - only I'm not buying it.

The issue is why bother maintaining Swing if you're eventually replacing it as you say? Indeed why should anyone continue to put effort into their Swing based projects when it's effectively a dead-end, a code branch with no future and no migration path. Maybe Kirill could do a "party of one" article on maintaining the passion while the language sponsor is actively trying to pull the rug from under your feet? Why bother continuing with JGoodies, JIDE, Flamingo, MigLayout, Substance et al? JavafX has no need for LayoutManagers nor Look&Feel..?

> Swing coders are just being jealous of all man-power Sun is investing in FX and not on Swing.

Is that not fair enough? is it logical to abandon your existing customers to possibly chase some new ones? If not just jealously - its a fear we're being abandoned much like Microsoft did to it's visual basic 6 developers. Arguments like it's open source, you can maintain it yourself aren't of any comfort, nor should JavaFX developers get too comfatable if this is what happens (you'll be next - eventually).

Osvaldo Doederlein replied on Mon, 2008/12/15 - 10:58am in response to: Richard Osbaldeston

[quote=osbald]

Currently JavaFX can only bind to other JavaFX objects, pretty limiting if you're going to be calling out to remote Java services or beans.

[/quote]

You can probably bind FX objects to Java data and have Java objects listen to FX's binding notifications (which runtime uses a standard Listener mechanism), but this can be ugly, e.g. using types such as com.sun.javafx.runtime.location.IntVariable from the Java side as a int property container. Not recommended as these are internal classes, not public APIs, and their explicit use would also break the POJO model. But a official Java package for JavaFX interoperability - perhaps even a next-generation, FX-friendly successor of JSR-295 - could use those types internally, rewriting POJO bytecodes if necessary.

[quote=osbald]

(arguably the single EDT thread is even more limiting).

[/quote]

I didn't understand if you refer to Java or to JavaFX here. FX seems to be much better on concurrency, as the entire GUI rendering is performed by the runtime (I assume it uses dedicated thread[s] for that); JavaFX event handlers will usually just update bound variables and all the propagation of effects to the scene is performed indirectly by the binding system, which supposedly uses queuing or synchronization as necessary. It looks like JavaFX, with its declarative and binding features, relieves the programmer of a big burden; no need of things like SwingWorker... and that's good news in this era of multicore.

Richard Osbaldeston replied on Mon, 2008/12/15 - 11:42am in response to: Osvaldo Doederlein

FX seems to be much better on concurrency, as the entire GUI rendering is performed by the runtime

Nope, as I understand it JavaFX 1.0 is single-threaded, everything is run on the EDT and therefore very much worse than what's on offer in Swing. They do plan to expose SwingWorker in some FX / AppFramework Task manner, but it won't be automatic.

Don't think JavaFX script bindings offer any more protection from property changes occurring on non-EDT thread than beansbindings does (i.e. None). As such binding anything remote or multi-threaded becomes an issue, possibly pushing client concerns into the server domain? rubbish.

Osvaldo Doederlein replied on Mon, 2008/12/15 - 12:01pm in response to: Richard Osbaldeston

[quote=osbald]

Nope, as I understand it JavaFX 1.0 is single-threaded, everything is run on the EDT and therefore very much worse than what's on offer in Swing. They do plan to expose SwingWorker in some FX / AppFramework Task manner, but it won't be automatic. [/quote]

I did some investigation, it seems you are right. Event handlers are executed in the EDT (which is to be expected) but I thought the rendering wouldn't be. Setting a breakpoint in some code triggered by the bindings, e.g. PhotoFlip demo's getPT() function, allows me to see the stack trace when FX hits that function, and we are indeed in the EDT again.

On the other hand, the binding system is deferred and does not interfere with rendering as I expected - it's just not through multithreading. When your even handler updates a bound variable, it seems the variable is just set "dirty". Only after all event handling finishes and the animation engine preps for the next frame, the binding cycle happens and user code is invoked again where necessary (in this case, to create a transform object).

This actually isn't a bad architecture to get started, it resembles typical animation/game engines, with the advantage of immediate transition between event handling and rendering without any thread-switching delay or contention costs. And just like in a game engine, if your code (event handling or rendering helpers) is very slow, the only penalty is a drop in FPS as the next frame will take longer to finish.

OTOH, it's bad to not benefit from multicore systems, and we need some mechanism for asynchronous long-running tasks like reading a file. There is a javafx.scync package for that, I don't know if it fills the need reasonably (just learning FX). I wonder if Sun plans to move the rendering into a separate thread, this should be possible to do without any impact on public APIs - perhaps it could be an optional feature, controlled by a startup option. Would be great at least for the desktop profile, but not necessary for JavaFX mobile, here I think the single-threaded engine is really the best tradeoff (provided, once again, that we can have good async mechanisms when necessary).

Osvaldo Doederlein replied on Mon, 2008/12/15 - 12:30pm in response to: Richard Osbaldeston

[quote=osbald]

The issue is why bother maintaining Swing if you're eventually replacing it as you say? Indeed why should anyone continue to put effort into their Swing based projects when it's effectively a dead-end, a code branch with no future and no migration path. Maybe Kirill could do a "party of one" article on maintaining the passion while the language sponsor is actively trying to pull the rug from under your feet? Why bother continuing with JGoodies, JIDE, Flamingo, MigLayout, Substance et al? JavafX has no need for LayoutManagers nor Look&Feel..?

[/quote]

You have some very good points, but notice that JavaFX is not (by far) a complete Swing replacement. For one thing, it doesn't have any components (buttons, etc.), it doesn't support a "conventional" GUI with windows decorations like scroolbars, navigation like menus and toolbars, internal frames, docking, grids - and not too many FX coders will want to build those with raw scene graph objects (rectangles etc.); that is possible and good just for VERY custom needs.

So, the FX programmer who wants to code the next payroll front-end will have to import javafx.ext.swing (or similar package in FX Mobile), or even the raw Swing/CLDC/LWUIT packages. Or perhaps just write the GUI "skeleton" in the standard Java language and toolkit, and hook on Swing just to render some particular frame that contains super-duper graphics, media or animation. And this means that Swing is going to be maintained and enhanced. Of course, you may be right that Swing is not going to receive revolutionary enhancements at least in the areas that are a better fit for JavaFX; if this is the only restriction to Swing's future, I think it's a reasonable compromise.

Richard Osbaldeston replied on Tue, 2008/12/16 - 7:33am in response to: Osvaldo Doederlein

but notice that JavaFX is not (by far) a complete Swing replacement.

Clearly but that appears to be a matter of time. I'm two years into a major swing product and foresee several more years ahead of us, so I have to have one eye on the future in terms of planning. Clearly the plan for JavaFX is to have it's own scenegraph based widget set, it's been mentioned a couple of times in passing, but no solid details yet http://java.dzone.com/articles/javafx-reintroduce-swing-jtabl it's needed as much as anything to allow widgets in the mobile profile rather than the desktop profiles stop-gap (and incomplete) Swing embedding. Now add the promised enterprise support http://weblogs.java.net/blog/rbair/archive/2008/11/javafx_enterpri.html which is also obviously falling on the JavaFX side of the fence not Swing. One of thing things I find compelling about Flex is the built-in binding, buffering, validation story which is more the kind of thing you want for enterprise dev. Reading between the lines I'm expecting the widgets and enterprise support in with jfx 2.0 beta expected around this time next year. i.e. too late for JDK7

How I feel at the moment is JavaFX is shaping up to be the Swing 2.0 Elect, so to speak. Client side developers are entering a difficult transition period. Which is why the lack of communication on the plans and whooly JavaFX->Java integration is so frustrating. If this was clearer I could at least plan for the changes in some form, minimise my risk, focus less on custom Swing components and more on the framework & models that should be view-agnostic. Although with the properties/bindings JDK issues it's looking like this kind of parity is long way off http://tinyurl.com/56wf7u. JDK8 at the earliest? 4 years between 6.0 & 7.0 so JDK 8.0 in 2014? how relevant will Swing still be by that time? given the kind of exclusive development being lavished on JavaFX and it's continued encroachment onto Swing turf..?

So it's about trends, planning and communication as much as anything. Do wonder how much more I'd take to JavaFX if it was all Java or had the integration issues in place rather than 'on some unpublished roadmap' http://tinyurl.com/6bn9uw Would also feel more comfortable if JavaFX was being sold more to web designers then Java developers. Don't have a problem with converting new developers, but the exiting client Java community is relatively small and has little to benefit from being split down the middle.

When Josh says "Swing has a long future ahead of it" you could read that as "..much like AWT had ahead of it when Swing was released back in 1998"?

Osvaldo Doederlein replied on Tue, 2008/12/16 - 9:02am in response to: Richard Osbaldeston

[quote=osbald] When Josh says "Swing has a long future ahead of it" you could read that as "..much like AWT had ahead of it when Swing was released back in 1998"? [/quote]

This is a very good comparison, because AWT had a hopeless design, impossible to fix and evolve even for the standards of a peer-based ("heavyweight", in Swing's NewSpeak) toolkit. If you want that kind of toolkit today, you use Eclipse's SWT that is AWT done right - so right in fact, that it's reasonably competitive with Swing in features and API design (although Swing still tops), and humiliates Swing in all performance aspects.

Swing survived 10 years but it didn't age very well, even with massive effort from Sun (Merlin, continued LAF enhancements, HW acceleration, Java 6u10, Matisse and other superb NetBans features, etc.) and the community (tons of third-party libs). But Swing will not survive another 10 years. A Swing product being developed today will be well supported for many years, in terms of bug fixes and small enhancements, perhaps even a few major enhancements like the app framework in Java 7 and perhaps a new bindings spec later (not to mention that you don't really depend on core libs for these things, you can install third-party libs). Heck, even JavaFX's official API includes javafx.ext.swing so Sun will have to support that until hell freezes over even after they introduce a brand-new, JavaFX-centric component package.

Michael Azzi replied on Tue, 2008/12/16 - 11:15am in response to: Osvaldo Doederlein

Hi Osvaldo,

Regarding the JavaFX threading model, below is what Richard Bair had to say about this on the mailing list. In short, expect to see rendering taking place in its own separate thread:

> ** Concurrency and Scene Graph **
>
> The downfall of every current Java scene graph and UI model is the failure to recognize that the _rendering model_ must be fully concurrent and separate from the display model (scene graph). Any display/rendering model that locks everything else out is doomed to chunky, stuttering behavior. We can construct a display model in jfx, then link a rendering model (with implicit animation) to it through binds, but the single-threaded nature of the whole thing prevents it from functioning correctly.

Hi Ross,

We've been talking about this a lot recently, and have in fact discussed it even before fx. Expect to see this in the hopefully not to distant future. The demos we've been working on ha e made it clear that we need to separate the event thread from the render thread.

>
>
> There doesn't appear to be any prohibition in the current jfx release on creating clusters if a custom runtime is used. Such a runtime can probably deliver some concurrency between fx behavior clusters. I anticipate some interesting experimentation in this direction.
>
> Finally, thanks to Weiqi Gao for his very interesting article.
>
> Ross Judson
>
>

Johan Compagner replied on Tue, 2008/12/16 - 11:24am

so we dont get Reified generics but the big question for me is do we get better generics support at all?

 because we really need it, it is to verbose and it should do way better  type interference...

Osvaldo Doederlein replied on Tue, 2008/12/16 - 12:58pm in response to: Michael Azzi

[quote=ma111828] Regarding the JavaFX threading model, below is what Richard Bair had to say about this on the mailing list. In short, expect to see rendering taking place in its own separate thread [/quote]

Thanks for that, but where are these archives? I only found the openjfx-compiler lists where I failed to find this thread.

Now, I think a concurrent rendering model wouldn't hit a "lock everything" problem because JavaFX's binding mechanism is lazy and high-level, the runtime can do all sorts of tricks without impacting the current framework and language semantics. For the JavaSE profile there is the benefit of java.util.concurrent.

But perhaps the current model (everything runnig on the EDT) should be kept as an option. It's more lightweight (very important especially for FX Mobile), and you can always spawn an async task for long-running jobs (I'd like to have back something like the old do / do later syntax).

Michael Azzi replied on Tue, 2008/12/16 - 1:22pm in response to: Osvaldo Doederlein

[quote=opinali]

[quote=ma111828] Regarding the JavaFX threading model, below is what Richard Bair had to say about this on the mailing list. In short, expect to see rendering taking place in its own separate thread [/quote]

Thanks for that, but where are these archives? I only found the openjfx-compiler lists where I failed to find this thread.

[/quote]

Are you sure you looked in the right place? because I can find it threre under this link:

https://openjfx-compiler.dev.java.net/servlets/ReadMsg?list=dev&msgNo=6583

Now out of curiosity, what is the Swing's threading model? I thought it's single threaded too,  where all the rendering logic runs on the event thread, no?

Osvaldo Doederlein replied on Tue, 2008/12/16 - 1:59pm in response to: Michael Azzi

[quote=ma111828]

Are you sure you looked in the right place? because I can find it threre under this link:

https://openjfx-compiler.dev.java.net/servlets/ReadMsg?list=dev&msgNo=6583

[/quote]

Thanks for the link. I did a search by author "Richard Blair" in this list, but the top returned messages had old dates and I didn't notice that messages were sorted in ascending date order...

[quote=ma111828]

Now out of curiosity, what is the Swing's threading model? I thought it's single threaded too,  where all the rendering logic runs on the event thread, no?

[/quote]

Check here. It is just like you say, and additionally it's not thread-safe, so to update the state of components from other threads you must use the invokeLater() API which schedules your state-changing code to be executed in the EDT.Conversely, an event handler that needs to trigger a long-running task should use the SwingWorker API to run it outside the EDT but consume the results in the EDT to update GUI state (this is performed by a simple producer/consumer mechanism).

Michael Azzi replied on Tue, 2008/12/16 - 2:13pm in response to: Osvaldo Doederlein

[quote=opinali]

[quote=ma111828]

Now out of curiosity, what is the Swing's threading model? I thought it's single threaded too,  where all the rendering logic runs on the event thread, no?

[/quote]

Check here. It is just like you say, and additionally it's not thread-safe, so to update the state of components from other threads you must use the invokeLater() API which schedules your state-changing code to be executed in the EDT.Conversely, an event handler that needs to trigger a long-running task should use the SwingWorker API to run it outside the EDT but consume the results in the EDT to update GUI state (this is performed by a simple producer/consumer mechanism).

[/quote]

That's what i thought. The only reason I brought it up is to highlight the irony, and the double standard in some of Swing fans comments, bashing Javafx, particularly regarding threading. All the while forgetting, just as you pointed it out, that the javafx architecture, and abstraction layers enables it to take advantage of some really interesting multi-threading capabilities. Something that's never possible with Swing.

Johan Compagner replied on Wed, 2008/12/17 - 4:21am in response to: Michael Azzi

[quote=ma111828]

That's what i thought. The only reason I brought it up is to highlight the irony, and the double standard in some of Swing fans comments, bashing Javafx, particularly regarding threading. All the while forgetting, just as you pointed it out, that the javafx architecture, and abstraction layers enables it to take advantage of some really interesting multi-threading capabilities. Something that's never possible with Swing.

[/quote]

 

what? not possible in swing? in swing everything is possible.. why wouldnt it be? Yes you have to program it our your self maybe a bit more, but i am writing fully multi threaded swing programs for a long time now. 

 All user interfaces i know are single threaded. So i would be really suprised if javafx wasnt that way. Because the lower level, the operating systems, also have single threaded ui.

Osvaldo Doederlein replied on Wed, 2008/12/17 - 6:46am in response to: Johan Compagner

[quote=joco]what? not possible in swing? in swing everything is possible.. why wouldnt it be? Yes you have to program it our your self maybe a bit more, but i am writing fully multi threaded swing programs for a long time now. [/quote]

I think Michael was referring to the toolkit's renderer - the engine that repaints all components. For Swing, multithreaded repainting would hardly deliver any benefit because 99% of all Swing GUIs are a composition of components which painting is very simple (antialiased text and gradient fills being among the most sophisticated operations). But there are exceptions, e.g. if you have a 2D CAD app with several views that must be painted by massive amounts of Java2D operations, Swing is not able to invoke your paint(Graphics) methods on several components in parallel, so you can't benefit from a multicore system. You can of course, circumvent this limitation by doing all repainting in threads that you manage, with offscreeen images, and just copy the latest frame to the screen when Swing invokes paint()... but this technique has limitations: hard to benefit standard / third-party components, may introduce extra latency due to thread scheduling, may increase memory usage with extra buffers.

Now, JavaFX's GUIs will typically be much more sophisticated with all sorts of effects, media, etc. and in a future release (2.0?) Sun will add full 3D capability (I guess by integrating some OpenGL bridge, like JOGL or similar, to the scene graph). That's why a multithreaded renderer would be very interesting, remarkably for low-end consumer machines. (A "low-end consumer machine" at early 2010 may still suffer from a crappy integrated Intel GPU; but it will have at least a quad-core CPU, so a multithreaded software renderer could deliver a massive performance benefit.)

[quote=joco]

 

All user interfaces i know are single threaded. So i would be really suprised if javafx wasnt that way. Because the lower level, the operating systems, also have single threaded ui. [/quote]

The problem is just the native 3D pipelines that used to be single-threaded (the OGL and D3D drivers). I say "used to be" because now with SLI and dual-core GPUs, these drivers are already forced to do parallel rendering at least in the GPU side. Those pipelines involve both the GPU and CPU, I don't know if mainstream drivers are already becoming capable of exploring multicore CPUs. But if you track the whole story of GPGPU, CUDA etc., you know that it's just a matter of time.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.