Skip to main content

JavaFX Script as a general purpose language?

Posted by opinali on June 11, 2009 at 11:46 AM PDT

Fabrizio says: "You'd have problems in forcing it to a broader scope than the one it has been designed for." (i.e., GUIs) This may be true, but only because JavaFX Script is still a bit recent in both design and implementation. A few important features are still missing, some only not included due to time/resource constraints because the team's priority is the features to make JavaFX a viable RIA platform. Now that the critical, let's-cross-the-chasm release 1.2 is out, I hope there is more time for enhancements in the "general purpose" area"...

Like this: JFXC-642: Support for maps as a core language construct. One comment even says "We could really do with this for Marina [1.2] release". Unfortunately they didn't, but the bug is now scheduled "After Marina", i.e. the next release; it's one of the top RFEs in my wish list. JavaFX Script's List-like sequences are great, but we really need a Map counterpart, complete with all sorts of high-level syntax sugar (from initialization to powerful comprehensions) and smart javafxc optimizations like flattening, tuning of implementation class choice, sizing, immutable/mutable transitions, conversion from/to compatible Java collections, and other tricks that are already implemented for sequences.

With that and perhaps other few enhancements, JavaFX Script would become just as "complete" as other modern high-level OOPLs. JavaFX Script really could be a very viable candidate to the role of successor or companion to Java as a language for implementation of full Java applications.

Consider this: The Java language has come to a dead-end. The community, apparently, cannot stomach any evolution that would introduce even minimal backwards-compatibility breaking. The full compatibility constraint (both source and binary) makes very hard to introduce any major feature without some big compromise in either functionality, complexity, or interoperability with legacy APIs. Too many people disliked the enhancements of J2SE 5 because of their compatibility compromises (not only generics but also most other features - e.g. the enhanced-for is a timid enhancement compared to JavaFX Script's). Java SE 7 (ok, JDK 7, so far) is turning out another failure at evolution - Project Coin has nice enhancements, but it could also be renamed to Project Alms, because that's what it is: a charity for the poor souls who insist programming in Java but starve for a more modern and productive language.

Scala might be a great successor of Java. It's reasonably Java-like, well integrated to Java and its libraries, "designed for the JVM", static typed. On top of that, it adds an impressive amount of modernization like type inference, generics (without erasure), functional programming, pattern matching, Actors, and more. In a comment from Gilad Bracha, it's a "tour de force of language design". But Scala is also a significant learning curve to most Java hackers. It's a complex language, even though it avoids any legacy tradeoff. And the Scala team is apparently not yet done with new features, now v2.8 will introduce continuations and more cool stuff. I fear very much that Scala may be doomed to the same fate of Haskell - a language that enchants geekdom with a very elegant design and even a great implementation, but ultimately serves only to influence future designs with more pragmatic constraints. In my dreams, Sun would pick a subset of Scala that any competent Java programmer could master over a weekend, rename it to something like Java 3, and be done with it for the next decade (experts could stick with the full Scala, and that would be a superset of Java 3 so the next migration, or Java/Scala interop, would be even easier).

Groovy has become an impressive system (an even more amazing feat after recovering of a difficult start), but just like JRuby, Jython and others, it is a dynamic typed language. Most Java programmers will never trade Java for these languages. I don't mean to open this debate here, but if the advocates of dynamic languages think they can turn the tables once their languages are more mature, with better frameworks, compilers, success cases etc., it's not as simple as that. Many developers with a strong education on programming languages, OO and related subjects, have a firm, well-founded preference for static typing, and can only be convinced to move to languages with even more (or better) of that, like Scala. Speaking for myself, the single feature of dynamic languages that's worth anything IMHO is powerful metaprogramming features (as more superficial features like "less typing for variable declarations" are largely obsolete in modern languages - with a "pure" typesystem, strong generics, and type inference). Well, nothing is perfect, and I'll take the safety/performance/convenience of static typing over a MOP any day. (Optional static typing like Groovy's doesn't cut it, because I don't see how this can go together with some modern features like advanced type inference.) OK, so I didn't resist and I did open that debate just a little; but the point is, most developers prefer static typing; this just won't change next week; and it's not even a Java-specific trait resulting from Sun's designs. Other dominant languages, from C/C++ to C#, SQL, and any decent XML-based language (with a strict schema), are all static typed; C# is also evolving in the same general direction of Scala. Having said all that, the Java platform is welcoming dynamic languages; as an advocate of Java[-the-platform] I am very enthusiastic and supportive of improvements from javax.script to invokedynamic and other enhancements in JDK 7. Some people prefer dynamic languages, we can agree to disagree, to each his own etc. - I even make limited use of those languages in niche needs. And the bottom line is, if these languages run great in the JVM, it's a win-win for the whole ecosystem around Java.

Now let's close this digression and turn back to JavaFX Script. If you're already up to speed with JavaFX programming (and you value higher-level languages even with some small tradeoff in performance or access to legacy APIs), what are your thoughts about using this language as a general replacement of Java? Let's say, to program the persistent entities and business logic, packed in some Java EE EAR, "behind" the GUI? Which features are missing? (Suppose, of course, that somebody will write lightweight and convenient JavaFX Script APIs wrapping all the Java SE/EE APIs you need; or perhaps even better APIs that take full advantage of JavaFX Script, ignoring old cruft.) Beyond a map type, my next obvious pick is Java's Annotations, essential to support most modern SE/EE APIs "“ and that's a pretty small change as javafxc could basically "pass" the annotations to the resulting Java artifacts. Notice that I'm not proposing that JavaFX Script can be a full replacement for Java; just a "higher-level companion" for application-level coding. it's OK to need Java for "system-level" tasks, from stuff that needs low-level typesystem features for performance, to ugly APIs that may be impossible to make much simpler with a thin wrapper like the full extent of Java Reflection APIs.

P.S.: JavaFX Script's binding feature, its biggest claim to fame, is most certainly NOT a DSL-esque construct that's "only good for GUIs". If you think that, it's like thinking that "generics are only good for Collections" or "closures are only good for event handling plus a better foreach" (I've heard/read such opinions from many, many developers who have shallow knowledge of these features). Binding is a very general and powerful construct. It remembers me of my study of Constraint Satisfaction Programming while doing my MSc ten years ago. Binding is more limited than CSP, it just implements the facility of automatic propagation of dependent assignments (but it's very good at that, including minimal reevaluation: e.g., x = bind y + f(z) doesn't invoke f(z) again when only y changed; with sequence binding, only affected slices are recomputed). But this is already very powerful. Just like those pure and famous OO or functional languages that didn't succeed in the real world, CSP didn't enter so far in the mainstream. (To be fair they didn't even try - only academic attempts were made, like Kaleidoscope - now completely forgotten). But this research influenced more traditional systems, like JavaFX Script, to make a more pragmatic "baby step" that is still extremely useful.


Important fix, Groovy doesn't have static typing as I mention in this blog: It seems Groovy just fakes this: you can declare variable types, but actual checking is performed at runtime as always. That sucks.

@felipegaucho: Java is indeed very strong in the back-end, but it's surely facing competition from higher-level productive languages/frameworks like Ruby and its Rails, etc. I don't "buy" these languages, but it's mostly they are dynamic typed and I don't believe in that paradigm for code that should be robust before everything. But options like Scala, and even an improved JavaFX Script, can surely attract me as a valid option for back-end, or even for web applications (scripting dynamic pages), at least of course if these langs get all support they need with good libraries and tooling. I am not proposing that we migrate from Java to JavaFX Script for all development. I'm just proposing that we could have this possibility _as an option_. If JavaFX Script already has 90% of the features that it would need to be a good choice, why not investing in those 10% missing enhancements? Notice that the result would not compete directly with Java (languages with different abstraction level), it would compete with the likes of JRuby, Jython, Groovy, Scala, etc. People needing the maximum performance and best access to a mountain of APIs would always prefer straight Java than any of those competitors.

@nopjn: I never said that Java is dying, I said it is on a dead-end, i.e. it can't move forward. Now if you think that Java is already perfect and you'll feel comfortable with it until your retirement, that's ok... JavaFX's concurrent library (javafx.async) was never meant to compete with java.util.concurrent. This is not possible anyway because JavaFX aims to keep as much ME/SE portability as possible, and we won't have JSR166 in Java ME any time soon. The purpose of javafx.async is just to make the most commons needs of GUI apps - running some tasks outside the EDT - easy and portable. If you want the full power of Java SE concurrency, you can just import java.util.concurrent in your JavaFX program (desktop profile) and use it. The same holds for any other advanced SE or even EE or third-party library, if you don't mind mobile portability. It's also very easy to write lightweight wrappers for those libs, e.g. to benefit from binding.

The problem with the Java language is that it's stagnating. Java was cutting-edge 15 years ago but is now starting to show its age. What's more, silly compromises were made in order to gain mindshare among C++ programs, like leaving out closures (which James Gosling said he wanted to include in the Java language). It's clumsy and overly verbose at times, especially the Generics syntax. Primitives were also another silly compromise, necessitating the awkwardness of boxing and unboxing, which Java 5 didn't completely fix. Meanwhile, languages like C# are evolving at a much faster clip because they don't have the same legacy baggage that the Java language does. In order not to fall behind in the future when competing programming languages become really advanced, Java will need a new language.

@felipe I agree, I don't feel any strong feeling about replacing Java *in general*. I'm living happy with Java ;-) and, for what I can see, with Swing too. JavaFX is to me very good for mobile and for some kind of fancy, user-oriented applets. For all the rest, Swing / SwingX / NetBeans Platform are ok. Still, there are some ideas in JavaFX that could be useful in Java (such as its functional binding). I'm not asking to change Java, I'm one of those who advocate keeping it as is, with only minor changes; those ideas could be implemented in a library to make things easier. This is the way I'm going.

Java options for the presentation layer aren't much competitive at all.. so, if JavaFX can bring us a chance to compete it is a great thing, a very welcome and most wanted feature from the Java portfolio. From the other side, the backend technology provided by Java is already wonderful and higly competitive.. So, why force JavaFX to do something we don't need ? bring us a powerful presentation technology, do what JSF failed to do and we will adopt it :)

only good for GUIs I mean :) I need to replace my fingers or my keyboard anyway :)

Question: why we need to replace Java ? and why people waste so much energy looking for the next language ? :) JavaFX is today only good for guys.. and I can't imagine how many years it will take to see JavaFX candidate to replace anything available today, including java.. but let's see....

The Java language is dying ? Wrong !! Add closures and properties/binding and that 's enough for the vast majority of us. I wish I had time to look closely at scala... JavaFX Script need a few more years, just to get nice libraries like we have in Swing (eg: a powerful windowing toolkit). And it's was never meant to replace Java. Just look at the concurrency update. It doesn't come close to Doug Lea's. It's not its goal. Are the new components written in JavaFX Script ? Olivier Allouch

Interestingly, one of the key issues with Java FX Script as a langauge is the name - surely its just a 'scripting' language. Not that I can claim my favouite, the Fan language, , has a better name, but it is another Java NG language that feels much more Java developer friendly than Scala.

Yes, but I'd rather say that the problem is that in JavaFX you get a fixed implementation of the thing that does periodic work, and you can't fully customize it. But in th end, yes, these are DSL stuff, so IMO the discussion should be that JavaFX is a DSL for UIs, eventually some of its constructs could be inspirational for another language.

@fabriziogiudici: Hmmm... I'd rather have those at/tween keywords removed from the language. With JavaFX Script's object initialization syntax and Duration type, declaration of keyframes would be 99% as clean and easy without these keywords (which are definitely DSL). The problem with more general usage of tween / interpolators is that these features assume some runtime that works continuously, setting up and consuming timers and/or doing periodic work (like JavaFX's animation engine). You don't want even an indirect dependency of that, if you're writing server-side stuff.

"well there is a couple of syntax sugar like at() and the tween operator, just don't use that;" Yes, but I don't like the idea that a language has got specific features for a different domain than yours, and that you just don't use... recalls me of fat classes. Indeed, one could say that interpolators (with a different implementation, not EDT bound, but same syntax) could be used on servers too. Just imagine a server component that generates signals to drive a device. Thinking of more software oriented servers, I bet that game engines could use an interpolator to update the model of an object in a virtual world, etc...

@fabriziogiudici: Yep, binding is a very interesting area of investigation now. Perhaps this discussion is more mature in the Beans Binding effort that you are involved in; obvious use cases include binding entities (in "detached" mode) to GUI components. The major limitation of JavaFX's binding, for a really general-purpose use, is being a static construct, we could use some APIs to dynamically bind and unbind things... but that's relatively small peanuts compared to the functionality already in place.

@massimoh: The set of primitive types was minimal for 1.0 but they fixed it at 1.1 with all missing numeric types. Notice that javafx compiles your code (with JavaFX's Float, Integer etc. objects) into unboxed primitive types whenever possible (it's similar to Java 5 with autoboxing but smarter - more comparable to C# which also has a "pure" typesystem that still contains primitives but with these masquerading as objects). Now, JavaFX is only missing full support for primitive arrays; but you just can't declare/instantiate them, so if you really need arrays this only takes an extremely small snippet of Java code, the JavaFX Script can access the arrays.

@wordwarrior: Checking your soapbox: 1) Agree; 2) Agree but it's not a JavaFX problem, it's a tooling problem (enhance NetBeans plugins or create extensions of JUnit and other tools); 3) I didn't understand, I see no such coupling. Of course you won't create something like a Scene in a server module, but the language itself is not coupled to GUI stuff... well there is a couple of syntax sugar like at() and the tween operator, just don't use that; 4) JavaFX seems to be a lot better, they basically dumped the old async packaged and created a new one with task/future APIs, but I didn't test it yet; 5) JavaFX can use the same tools, I already did that. Of course the tools can be customized to better understand JavaFX (show a cleaner call stack, provide a higher-level performance breakdown by understanding resource usage from the scenegraph and media APIs); 6) No need of "native" anything (if you mean native code), but yes it nees at very minimum, something like JPA-FX.

Also, the Java language syntax may be old and stagnant, but it really does everything most projects need very well. Most of the features it's missing seem to be of questionable use or for very narrow purposes. The reified generics issue, closures, and Project Coin type things are not even close to big game-changing issues.

My FX experience is limited to casual experimentation with 1.0. I really liked the core FX language design and it's phenomenal for GUI apps, which is the obvious purpose. But it's has some omissions for background processing type projects: the big one is that it has really limited primitive data types. Also in 1.0, the immutable sequences didn't look a good substitution for high-performance, large size, traditional arrays. It seemed like these were intentional design choices as FX really isn't intended for this type of development. My FX experience is limited, so maybe I'm wrong? love the blog btw.

Yes, I think that Sun is heading in this direction. FWIW, somebody (prime21) posted this prediction a while ago: I haven't done much JavaFX programming beyond "Hello, world", but I did read the language tutorial, and I like the language syntax and features. What needs to be added? Well: 1) Open source. JavaFX can become the RIA framework of choice for the open source community, and this would give it an unmistakable advantage over Flash and Silverlight. What's more, it would allow for better debugging, since it would be possible to step into JavaFX classes (which I can't do now). 2) Junit or unit testing functionality. Chalk this one to Fabrizio Giudici. This is absolutely essential for any serious programming. 3) Decoupling of GUI logic constructs from any server-side implementation. Otherwise, it would be weird to instantiate any of the GUI objects in the server VM. 4) Robust native support for multithreading. Right now, this is a bit of kludge: 5) Profiling tools. Java has lots of these. 6) Some kind of native plugs into a more sophisticated database/ORM/JPA framework. That's just off the top of my head. JavaFX's biggest problem will be compensating for approximately 15 years of maturity in Java tooling.

Well, after all, maybe it can be a serious competitor. Scala is a little bit hard to learn in current days (tutorials are not too user friendly, and it's a functional language). Groovy is too slow to be more than a simple toy.

In my opinion, JavaFX is great for what is was porpoused: a RIA application. A replacement for Java2D (or an upgrade?). But people are so hungry for the "next Java" that JavaFX is the new "hot thing" in general programming area.

@allenhalsey: Thanks for pointing that error. Unfortunately I only looked at Scala some time ago and briefly, and the generics support looked cleaner that I just assumed that it didn't rely on erasure. P.S.: I don't consider full reification (with dynamic type information, reflection support...) essential to categorize a "good" generic typesystem. In C++ templates there are no generic types at runtime either (unless they improved it - I did serious C++ 10 years ago), but the templates are still a much strongly typed than Java5 as the compiler "expands" template instantiations by inlining the type parameter. So, it's still possible that Scala's generics are much better than Java, if Scala avoids Java5's fiascos like not being able to create arrays of generic types - I think this is true, but again this is based on my limited and old examination of Scala... need to find some time for a second look :( At least I'm sure of one fiasco that Scala doesn't suffer, the inability of using certain types as generic parameters (since Scala has no primitive types).

"[Scala] adds an impressive amount of modernization like ... generics (without erasure)" I think Scala's generics does use erasure. "Scala uses the erasure model of generics, just like Java, so we don't see the type parameters anymore when programs are run. We have to do erasure because we need to interoperate with Java." Source: Martin Odersky in interview published 2009-05-18

@mikeazzi: The new async API yet seems fine for the purpose of running things outside the EDT... except that it's odd to require a Java class to write a RunnableFuture. I would expect a "Pure JavaFX" option. I wonder if this reveals some limitation of Java->JavaFX interop. You can easily write a JavaFX wrapper for common scenarios, but that shouldn't be necessary. Perhaps Sun is prepping something more complex or working on the interop. Having said that, JavaFX lacks even the basic synchronization features of Java. Binding can be used as a thread-safe communication channel, but that's not sufficient. You can resort to Java code to create and synchronize threads, but then again, that wouldn't be JavaFX. Advanced concurrency, like java.util.concurrent, makes no sense because (a) it can' be decently supported on JavaFX Mobile, (b) little demand - how many Java GUI apps do ANY concurrency beyond the minimum necessary to deal with the EDT? The answer may be that it doesn't pay to make JavaFX more complex, and less portable from SE to ME; the small number of apps that need real concurrency can obtain it easily with the fall-back to Java, and JavaFX libraries that benefit from some concurrency can do that under the covers and expose a pure JavaFX API. Looking forward, if JavaFX is to adopt more concurrency features, I agree that it shouldn't mimic the [now] low level approach of Java, it should go for a higher-level paradigm, and Actors are a very good candidate. In the SE runtime we could implement actors (or something else) on top of the full power of JSR166; on the ME runtime, we'd have a much simpler and lighter implementation.

Excellent thought provoking post Ovaldo! I too share your opinion that JavaFX Script can play a much larger role in the programming space than simply being a nice GUI DSL. Some here suggested that the killer feature of JavaFX Script is its functional binding, and if we could provide similar support in Java then we will be just as productive. While functional binding is indeed a killer feature of JFX Script, it is not the only one that makes the language so unique, and so powerful. It is rather its declarative syntax that sets apart from the rest, and gives it such an expressive power. Case in point, when EJBs, and Java programming in general got so complicated, and so overwhelming, what did they do to address the complexity issue? They introduced annotations. Annotations are nothing but poor man's Java version of declarative programming. Annotations allowed the developer to tell the system what to do, not how to do it. Through declarative programming you express your intent through higher level abstractions, and you let the system figure out how to carry out these intents. In JavaFX case you get the real deal. One need only to look at Simon Morris's post on Thinking Declaratively in JavaFX to get a taste of its declarative power. It is this declarative syntax with its higher level of abstractions that enabled the language to blend multiple programming paradigms (functional, procedural, binding) so effectively, and lowered the barrier of entry to mainstream developers to such otherwise intimidating paradigms. I would like to conclude these comments with a question to you Osvaldo. We all seem to agree that one of the major areas where JavaFX Script seems to be lacking is the concurrency support. How do you think this should be addressed? Do you think actors is an appropriate concurrency model for JavaFX, or a task based one is better? It's interesting to note that most of the newer functional language out there are favoring the actors model. I also think it might be a better fit with the data flow programming style that JavaFX supports.

@aehrenr: First, you seem to be confused about dynamic[-typed] languages. I generally abhor such languages. JavaFX is not one of them. Properties have nothing to do with dynamic langs, and properties don't break encapsulation. FACT: Properties actually improve encapsulation, if you unserstand the feature and use it properly (and if it's properly implemented in a given language, of course). You are even more confused in the subject of closures. Closures are not a "functional" feature, in the sense that it's something specific to the functional paradigm. Look for example at the Smalltalk language, a pure-OOPL that noboby will accuse of "functional", but it's one of the languages that use closures more aggressively (some would even say abusively - you need two closures for a if-then-else statement). FACT: Closures are essential in any modern OOPL, with or without functional traits. I never proposed/supported any change for the sake of change. I support these changes due to 13 years (and counting) feeling the pain of using Java without features that are necessary. Some are necessary since v1.0 (if you know your Java History you'll remember that closures were in Oak's draft plans), Others have become necessary once the language becomes heavily used for some kind of development, e.g. properties. I agree that adding major features late in the game may complicate the language, but there are often great solutions that would only cost some tradeoff in source-level compatibility... (notice I'm not talking about binary compatibility...) but the Java community is not willing to accept even the slightest backwards compatibility compromises. BTW, one of the reasons why I support improving the Java language is precisely the fact that, as a veteran developer, I have tons of legacy code. Over the years, I've been able to "refresh" some of these projects (those with active development) to benefit from the latest APIs like java.util.concurrency, and new syntax like generics and annotations - and the result was overwhelmingly positive, even with admittedly compromised features like Java5 generics. If Java7 had closures and properties, I would once again review all that legacy to use those features wherever they make sense; yeah that would take some work, but my track record say that the ROI would be very good for future maintenance. OTOH, I just don't have the resources to completely rewrite those large, old apps in a new language like Scala, as the efort would be immensely higher even for such Java-like languages. (Groovy would probebly be the less effort, but I wouldn't move to a dynamic-typed language; and even if I would, a "light port" that doesn't fully explore the new language wouldn't make sense - I remember years ago when people used to write C++ in C style, usually resulting in the worst of both worlds.) DSLs layered in mainstream languages may be good in theory... but show me the money. I want to see, for example, an advanced GUI DSL that's as good as JavaFX, written on top of Scala or some other extensible language. (P.S.: statically typed, of course - including all new features of the constructed DSL.) There are scene graph animation runtimes for JVM languages, and new ones being written as we talk (e.g. Trident), so somebody just needs to wrap them in a layer of DSL. I'm waiting...

@opinali "Programming languages must evolve because the work we must do with these languages evolve" Java has been good for at least the great majority of projects and for much larger projects than can be handled with any "dynamic" scripting language. If you modify Java with goofy scripting language features (e.g.. properties) you only risk, that it gets worse in handling large projects (you loose encapsulation). If you extend Java in order to become a functional language (e.g.. BGGA) you risk to overcomplicate a language that was not made for this (like the exaggerated generics definition) and you alienate many, many developers. It is like modifying dads Pick-up with the latest experimental hydrogen powered engine while it is in duty on the farm that nourish us all. No good idea, really. This is the reason (in short) why we should modify Java only for practical reasons (like project Coin) and no features should be added that change the character of the language. You surely think now that I am a luddite, I think I am not, but only very few new things that are purposed make really sense. Change for the sake of change is no progress! There must be a reasonable new concept and a good design behind a new idea not some imitation potpourri. Of course there must be progress in the Java world in order to handle the more complicated projects. This progress is in my eyes very well represented by Scala. It is the hydrogen engine of the future but in a new car. We can still use dads Pick-up if something doesn't work as expected (if Scala should be too complicated to be adopted as mainstream language and needs to be simplified). "More and better APIs/frameworks often compensate for an aging language, but this trick works better for languages designed to be seamlessly extended by libraries, which is certainly NOT the case of Java" There is no language with so many libraries available like Java. So it can't be that bad. Java had hit by chance exactly the Thats good for many years to come, no need to fix something overhasty that is not broken. And new languages (like Scala) will represent the future. "If you like the idea of DSLs, I don't understand your dislike for JavaFX Script, which was created as a GUI DSL (although some people like me want to see JavaFX Script growing outside that box) . You seem to imply that a "DSL" is not a self-contained language, but rather a layer over some "base" mainstream language, e.g. like Groovy's Builders, or LINQ for .NET languages, or something else built o top of Scala." If you build a DSL by a special language, than it is hard to change or evolve the API (many API changes need a language change, thats really no good idea). This is the reason why in my eyes only general purpose languages make sense. For very few special applications DSLs can be build on top of them for special cases like data retrieve or GUI. If you have a fundamental new language for every version of many APIs this would greatly hamper developers and hinder evolution of APIs. So there is Java for the mainstream, Scala for advanced projects and if you want to try something new and Groovy for the quick and dirty "dynamic" programming. Thats enough and it is quite good to live in the Java world. The new scene graph APIs should be done in a way to use them from Scala and Groovy. It is no good idea to introduce yet another language (JavaFX). Computer languages are tools to solve problems. I am more interested in my problems than in remembering many unproductive and redundant details of different computer languages.

@aehrenr: Programming languages must evolve because the work we must do with these languages evolve. Software development, in general, is much different in 2009 than it was back in 1996. We (at least I) are now building applications that are, sometimes, orders of magnitude more complex than a decade-and-half ago. A programming languages is like wine: if you let it mature a few years it may become a better, "aged" wine; but if you wait many years, it often becomes vinegar. Java is not yet vinegar, but it's surely making progress in that direction and I don't see much action to stop that progress (Project Coin has many nice features but they are too little - I'd rather pick a single critical feature, like closures, over the entire batch of Coin's proposals). More and better APIs/frameworks often compensate for an aging language, but this trick works better for languages designed to be seamlessly extended by libraries, which is certainly NOT the case of Java. Dynamic languages can be extended with MOPs. Even modern static-typed languages w/o a MOP, like Scala, can have good extensibility mechanisms, as you agree when you mention Scala as a base for building DSLs. But Java has no good extension mechanism (somethig that allows creating/faking new syntax, not just new features... please don't mention "fluent APIs", it's a bad joke). If you like the idea of DSLs, I don't understand your dislike for JavaFX Script, which was created as a GUI DSL (although some people like me want to see JavaFX Script growing outside that box) . You seem to imply that a "DSL" is not a self-contained language, but rather a layer over some "base" mainstream language, e.g. like Groovy's Builders, or LINQ for .NET languages, or somethuing else built o top of Scala. This is certainly not the standard defintion of DSL ( Now I agree that there are advantages in building DSLs on top of general-purpose, extensible languages like Ruby, Groovy or Scala; but these advantages are only easy implementation (don't have to create a full compiler) and easy integration with a more mainstream language. But these advantages are not without tradeoffs. The flip side of easy implementation is MUCH less freedom; you can't build an arbitrary syntax with facilities like MOPs (at least, not with full static checking). And integration can be achieved by other means; JavaFX is seamlessly integrated to Java, or at least as seamlessly as possible.

What I do not get is why one comes to the conclusion that a language can not be used for productive work when it is not changed every year. Java can be used for years to come as it is, while Scala represents the fresh and innovative future and can be increasingly used in real world projects. And it has a consistent and elegant design, not like a Java with a variety of cobbled features that looks like a botoxed old lady. I do not like the whole concept of JavaFX. Why should one use a special language only for GUI progamming when a elegant API would be the solution. I prefer general purpose languages. The use of Scala would have been much more intelligent for producing an elegant DSL for GUI programming.

@felipegaucho: We may agree that JavaFX, even at v1.2, is not yet perfect, but "not even 10%"? I'm sorry, but this goes straight to my "trolling" trash can, unless you have extremely strong arguments. I agree however with your comment on Scala... yep, without some serious backing, it's not going anywhere, regardless of isolated success cases like Twitter or some good frameworks like Lift.

@opinali: As I see today, JavaFX has not even 10% of what we need in the frontend, that's why my reaction against trying to thing about wnother uses before to have its core features working fine.. @Scala: Scala language has no strong sponsor, what means it is dead.. perhaps one day a big corporation get interested in buying Scala, including all its very small team of creators.. but until (if) then Scala will continue to be the most beautiful pet project out there :) .. There no point in to discuss the quality of a language that simply don't have market powers.. no legal responsible, no vendor, no support, no commercial meaning at all.. but, yes, Scala is probably the academic choice of the last few years :)

@opinali "the DSL syntax certainly looks cool, but it fails in my prereq of static typing" Sure dynamic typing is only good for quick and dirty but GraphicsBuilder demonstrates that Sun should have implemented the scene graph in Java so that every JVM language can use it. In Scala or Groovy the declarative "JavaFX feeling" could have been easily achieved. My main point was that I think that the implementation of the scene graph for the exclusive use by JavaFX is a very bad concept. Sun should have provided a Java API (so everyone can use it) and bindings for Groovy and Scala (to have this declarative thing). The additional GUI language Java FX is completely expendable. I hope you now understand why I think this. "But this only gives me a fraction of the benefit I'd have with a evolution of Java; that would let me make 100% of my old code up-to-date with a very small effort" If your old code runs fine, why force the usage of properties and closures in it? You only introduce bugs, never fix something that aint broken :-). It is better to implement new things in a more flexible language like Scala and use new elegant idioms and patterns that would not be possible with a patched up Java. Java is today and in the foreseeable future used very effectively by many, many people, most of them are no computer scientists and the majority of them has not even heard of the closure debate. Why spoil this effective tool with new features (that are only needed by very few) that are far better placed in a language well designed around them as Scala, Groovy (and maybe Fan). If you have a programming platform that is as widely used as Java you need a simpler entrance language for the rest of us anyway and for the committed people something advanced like Scala. Just as M$ does with VB and C#. But Java is the better VB I think and Scala for sure the better C#. Yes and we have Groovy for the scripting things as a counterpart to the new shell of Windows. This implies that we keep Java simple, therefore for closures I strongly advocate the proposal of Josh Bloch. I hope you now understand why I think this. regards

@aehrnr: I checked the GraphicsBuilder, the DSL syntax certainly looks cool, but it fails in my prereq of static typing. Call me a bigot, but I just won't use a language that allows me to write utterly broken code, compiles it without even a warning, and forces me to depend on unit tests with extremely high coverage to make sure that embarrassing "method not found" or similar errors won't bomb in production. (I've seen this in production systems, like IBM VisualAge for Java [implemented in Smalltalk] which I used for years.) I tested a GraphicsBuilder example, introducing a simple error; it compiled perfectly and then failed at runtime with "java.lang.IllegalArgumentException: Transforms are not allowed outside a 'transformations' node". So I'll reject your attempt to provide a good gfx DSL - I would only use one that catches this kind of error at compile time (as well as enabling other static type goodies, like perfect code completion and safe automatic refactoring). Lots of people missed closures in Java, speak for yourself. Java had success in great part because it was a good balance between tradition (C/C++ like syntax - easy to pick up) and innovation (GC, better OO model, etc. - good step forward in power and EoD). This doesn't mean that it could be even better... FACT: missing closures was such an obvious mistake that Sun was forced to hack something similar in the first major update (inner classes in JDK 1.1). Unfortunately, at that time the APIs were already designed without closures, so inner classes are a bastard child of closures with interfaces. Rails has nothing to do with this, I specifically remember that it was a hot debate back in 1999 when I was doing a MSc in OO. At that time the "reference languages" were Smalltalk, Scheme, CLOS, etc. ;-) On your comment that JG "supposedly wished", check Bill Joy was the strongest advocate of having closures, generics and even continuations in Java 1.0, and the rest of the Oak team (including JG) agreed in principle, but they voted to focus on a timely release. This is all History, not supposition. There are other evidences if you know where to find (in blogs from involved people and even in some old Bug Database comments, written by some of the "fathers of Java" although Sun censors names/emails in bug Evaluations.) Finally, I agree that a new language like Scala can be used to extend existing apps, writing new modules or perhaps just rewriting critical components that benefit the most from the new language. But this only gives me a fraction of the benefit I'd have with a evolution of Java; that would let me make 100% of my old code up-to-date with a very small effort. Notice that this efort is even smaller if you rely on good tools; e.g. the Eclipse IDE can automagically convert classic for loops to enhanced-fors, and also infer generic type arguments, so it helps a lot in the transition to Java 5.

@opinali "DSLs layered in mainstream languages may be good in theory... but show me the money. I want to see, for example, an advanced GUI DSL that's as good as JavaFX, written on top of Scala or some other extensible language." Of course the scene graph and many details are missing but demonstrate the basics. "You are even more confused in the subject of closures..." I did not discuss closures but when we are at it, I think a language has to be designed around them. No one missed them in Java until Ruby got some attention (because of Rails). Java had its success as it was, no matter how James Gosling supposedly wished it could have been. I am for my part relatively sure a Java that would have had generics (as they are now) and BGGA from the start, would not have had a comparable success because Java hit (by chance) exactly the right combination of simplicity and power. "I just don't have the resources to completely rewrite those large, old apps in a new language like Scala" Who mentioned rewriting in Scala? Just extending functionality in Scala by calling in your old Java code. It is the same thing when you use JavaFX as a new language just for GUIs or more. There is no reason why usage of JavaFX in combination with Java is easier than usage of Scala or Groovy in combination with Java.

@aehrenr: Now you have much better arguments (or expressed them more clearly). The scene graph is actually not tied to JavaFX; in principle, it's just another library implemented in Java (and native code), with Java interfaces that you may call directly from a Java app if you want. The major "catch" is that this API is fully internal: proprietary and undocumented. We can say the same about all the powerful media codecs inside the JavaFX runtime (even for Linux/Solaris, where the Java layer is just a wrapper over GStreamer, that Java layer is neither open source, nor documented). And yes that pisses me off. But even if/when Sun finally decides to open source JavaFX, they won't probably maintain a supported, documented, stable API for the scene graph and codecs, because that would mean additional work and difficulty to evolve future releases. So, perhaps the Java community - specifically people not "sold" on JavaFX and JavaFX Script, who still prefer Java and Swing/J2D - could write a stable, supported API that wraps around Sun's internal stuff, so apps could use all features from the JavaFX runtime more safely: if Sun makes incompatible changes in the next version, just fix the wrapper API. Bindings for Grooby and Scala wouldn't cut it, at least not for me. I wouldn't adopt Groovy because it's a dynamic language. Most Java developers wouldn't move to Scala because of its complexity. Neither language has any impressive adoption numbers. Of course, creating a completely new language is also a risk because it starts with an adoption count of zero, but Sun decided to bet in that risk in the basis that they are Sun, they "own" the platform, and many Java developers will use anything that comes from Sun; and it's not a bad bet, considering that even f**k-ups like Entity Beans had reasonably good adoption when introduced just due to their status of being official APIs or supported by Sun and other big players. Now on my legacy code... yeah it runs fine, but i have to maintain it, i'm talking about products which are still actively developed, not just receiving minor bugfixes. From time to time there's new feature developent and I have to massage that old code, usually adding increasingly complex new features, so the old cranky technology is a pain. It always pays to migrate things, e.g. I've moved several projects from a very old old in-house ORM to Hibernate, and later from Hibernate's classic, proprietary API to JPA. Like I said before, the ROI was always very good. It might be even better to dump all old code and rewrite the apps from scratch with a next-gen tech like Scala; but this is something I cannot justify to paying customers. But I can do small, incremental improvements of the legacy code, by sneaking these improvements in minor releases or maintenance tasks. I agree that Java should be kept as simple as possible, but not simpler, like Einstein would say. ;-) Major features like closures could be added with very small cost of complexity (if any!) if we are willing to drop some source-level backwards compatibility. The complexity issues of things like closures and generics are always 90% due to the desire of full compatibility with legacy language syntax and APIs. Notice once again that I'm proposing to only break source compatibility, and it's possible to do that while keeping full binary backwards compatibility (i.e., the new JRE will run all old .class files). People who don't want the effort of migrating legacy codebases just don't use the new features, "javac -source" is your friend...