Next JavaFX release delayed?
Karsten Silz
remember hearing at JavaOne and on the podcast that it was to be out
at the end of 2009 (see this thread as an example:
http://forums.sun.com/thread.jspa?threadID=5415628). Now Oracle said
that a _beta_ of the next release will be out before June (http://
www.theregister.co.uk/2010/01/29/oracle_sun_java_open_source/page3.html),
so the final version may not be out until August or later.
Why is JavaFX so late? Maybe the scope changed - Oracle talked about
combining JavaFX with HTML, Javascript and Oracle's ADF framework.
The one area where I think this delay can hurt JavaFX is in enterprise
development - the 1.2 component library doesn't include a data grid or
a tree AFAIK, and reports are a key feature of most enterprise apps
(there's probably some open source data grid out there, but I would
have rather delayed the charts from 1.2 to include data grid and
tree).
To, JavaFX 1.3 seems to be the first "real JavaFX release" - a
complete set of components, a visual UI designer, maybe even the
designer tool, (more) mature IDE support and hopefully the most
important Java Web Start / applet issues ironed out by then (see here
for Java Web Start talk: http://java.dzone.com/news/when-will-java-web-start-be).
Oracle should also clear up the licensing situation (which parts of
JavaFX will be open sourced, changing the Scenegraph library license
from GPL to Apache or so).
opinali
were a bit confusing on this subject -- you can even see "Java F/X"
written in many slides, they are clearly still digesting this. I think
the "beta before June" concerns with other pieces like the Design
Tool, not the next release of JavaFX Desktop (1.2). Which was already
broken into two releases, it seems the next one (containing the Prism
render - 1.3?) would be scheduled for the JavaOne timeframe (I mean,
the original JavaOne schedule - usually June).
Looking at http://javafx-jira.kenai.com/secure/Dashboard.jspa, you can
have a good estimation of whether 1.2 is in the track. The javafxc
subproject certainly is, with the first SoMa milestone (compiled-bind-
alpha) at 100%, the second (compiled-bind-2) very close at 53/63, the
third (compiled-bind-3) at 24/41 and the last (SoMa) at 205/218; so,
the total remaining number of bugs seem small enough for the expected
release in late February. But for the Desktop Runtime, it's harder to
tell; the bug status is at only 309/588 which seems a hard call for a
single month, but if 1.2 was any indication, the progress of the
Runtime's bugtrack is almost worthless as an indicator of how close
they are to shipping.
A+
Osvaldo
Karsten Silz
> I don't see any signs of a new delay (yet).
Wasn't it supposed to be out by the end of 2009?
Steven Herod
ish with release at end of Jan, but then I heard of more delays/
changes.
Not sure of the reasons exactly, maybe organisational issues?
Hopefully the Oracle resolution will give everything clarity.
Interestingly Eric Klein (Marketing manager for Java and primary guy
in the "This ain't your Dad's Java" podcast) left Sun last week.
Not sure how much of the JavaFX strategy that effects, I also heard
the marketing guys were behind the JavaFX reqts.
Mohamed Bana
—Mohamed
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Steven Herod
But JFXtra's has such a thing, although I'm not sure of its
completeness/maturity right now.
On Feb 1, 11:23 am, Mohamed Bana <moha...@bana.org.uk> wrote:
> I heard JavaFX doesn't have a DataGrid control. If that's true, it makes
> little sense for them to release anything without a DataGrid that also
> supports virtualization *.
>
> *http://bea.stollnitz.com/blog/?p=338
>
> —Mohamed
>
> On 1 February 2010 00:14, Steven Herod <steven.he...@gmail.com> wrote:
>
>
>
> > Yes, it was, I think at first, then I heard of a code freeze November-
> > ish with release at end of Jan, but then I heard of more delays/
> > changes.
>
> > Not sure of the reasons exactly, maybe organisational issues?
>
> > Hopefully the Oracle resolution will give everything clarity.
>
> > Interestingly Eric Klein (Marketing manager for Java and primary guy
> > in the "This ain't your Dad's Java" podcast) left Sun last week.
>
> > Not sure how much of the JavaFX strategy that effects, I also heard
> > the marketing guys were behind the JavaFX reqts.
>
> > On Feb 1, 7:54 am, Karsten Silz <karsten.s...@gmail.com> wrote:
> > > On Jan 31, 4:40 pm, opinali <opin...@gmail.com> wrote:
>
> > > > I don't see any signs of a new delay (yet).
>
> > > Wasn't it supposed to be out by the end of 2009?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to java...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
opinali
Yep, I said "new" delay :)
opinali
notice), which begs the question: is 1.3 late, perhaps that's the
reason for this new minor update?
Checking the JIRA again: For javafx, compiled-bind-2 is notw complete
(53/53 so they just lifted 10 bugs), compiled-bind-3 is just around
the corner with 12/15 (again thanks, at least partially, to some
rescheduling), and there's a flurry of new SoMa-bXX milestones
(probably containing thhose rescheduled bugs) of which b23 is complete
(26/6), b24 is 12/42, b25-27 empty, and the final SoMa is very close
at 204/217. Overall it seems they entered in the engame run. But
javafxc must go stable before the runtime project, because it's a
dependency, and once javafxc 1.3 is RC quality they must recompile
everything else (including other projects like Composer, Design Tool,
and god knows what else Sun is cooking) and zero in any regressions.
The Runtime project now shows 343/591, so the fix rate looks good (and
as I expected/predicted they've been closing some groups of related
bugs in batches, e.g. tons of "implement CSS" stuff closed in a single
day). With ~250 bugs to go it's still a hard call for less than one
month, unless most of these bugs are simple or already in final stages
of development/testing (e.g. I'd expect the whole new batch of
controls to be already implemented but just needing final touches).
A+
Osvaldo
On Jan 31, 1:40 pm, opinali <opin...@gmail.com> wrote:
> Looking athttp://javafx-jira.kenai.com/secure/Dashboard.jspa, you can
> have a good estimation of whether 1.2 is in the track. The javafxc
> subproject certainly is, with the first SoMa milestone (compiled-bind-
> alpha) at 100%, the second (compiled-bind-2) very close at 53/63, the
> third (compiled-bind-3) at 24/41 and the last (SoMa) at 205/218; so,
> the total remaining number of bugs seem small enough for the expected
> release in late February. But for the Desktop Runtime, it's harder to
> tell; the bug status is at only 309/588 which seems a hard call for a
> single month, but if 1.2 was any indication, the progress of the
> Runtime's bugtrack is almost worthless as an indicator of how close
> they are to shipping.
>
> A+
> Osvaldo
>
> On 29 jan, 13:57, Karsten Silz <karsten.s...@gmail.com> wrote:
>
> > I was wondering when the next version of JavaFX (1.3?) will be out. I
> > remember hearing at JavaOne and on the podcast that it was to be out
> > at the end of 2009 (see this thread as an example:http://forums.sun.com/thread.jspa?threadID=5415628). Now Oracle said
> > that a _beta_ of the next release will be out before June (http://www.theregister.co.uk/2010/01/29/oracle_sun_java_open_source/p...),
Mohamed Bana
I haven't read anything to suggest that a new language for write UIs is needed. Just look at Silverlight which uses XAML (XML) to declare a UI, it's doing fairly well.
Perhaps, Josh Marinacci also left because he saw a lost cause.
* http://bea.stollnitz.com/blog/?p=338
—Mohamed
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
Fabrizio Giudici
> I don't see myself using JavaFX to implement any line of business
> apps. A DataGrid control with virtualization* is vital in places such
> as, say, front-office where data needs to be presented in tabular format.
even with JavaFX.
>
> I haven't read anything to suggest that a new language for write UIs
> is needed. Just look at Silverlight which uses XAML (XML) to declare
> a UI, it's doing fairly well.
this is not a relevant detail and I'd learn either way in function of
the technology that I pick.
>
> Perhaps, Josh Marinacci also left because he saw a lost cause.
>
about other people's intentions (also because it's easy to
counter-speculate: Josh is a guy who like challenges and the PalmOS
choice he's done is not less challenging than JavaFX).
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
Mohamed Bana
On 2/8/10 12:57 , Mohamed Bana wrote:Right. But what's the point about JavaFX? You can do data virtualization even with JavaFX.
I don't see myself using JavaFX to implement any line of business apps. A DataGrid control with virtualization* is vital in places such as, say, front-office where data needs to be presented in tabular format.
That's great to hear, but it's still lacking the DataGrid control. I presume Oracle are going to do something about it given they're being used heavily in enterprise.
This is fairly subjective - there are also people that hate XML. For me this is not a relevant detail and I'd learn either way in function of the technology that I pick.
I haven't read anything to suggest that a new language for write UIs is needed. Just look at Silverlight which uses XAML (XML) to declare a UI, it's doing fairly well.
You can use Expression Blend so there's no need to touch the XML - I over generalize of course.
And what about others that are still there? I'd not make speculations about other people's intentions (also because it's easy to counter-speculate: Josh is a guy who like challenges and the PalmOS choice he's done is not less challenging than JavaFX).
Perhaps, Josh Marinacci also left because he saw a lost cause.
Sorry. I shouldn't have said that.
—Mohamed
Fabrizio Giudici
On 8 February 2010 12:06, Fabrizio Giudici <fabrizio...@tidalwave.it> wrote:
On 2/8/10 12:57 , Mohamed Bana wrote:
I don't see myself using JavaFX to implement any line of business apps. �A DataGrid control with virtualization* is vital in places such as, say, front-office where data needs to be presented in tabular format.
Right. But what's the point about JavaFX? You can do data virtualization even with JavaFX.
Yes. We know that JavaFX lack components - I bet (but above all I hope) that the current silence about JavaFX releases is due to Oracle replanning it, also adding more developers as they announced. I think it's fair for them to take some time to complete the planning, then they should communicate as soon as possible.
That's great to hear, but it's still lacking the DataGrid control.� I presume Oracle are going to do something about it given they're being used heavily in enterprise.
opinali
> On 8 February 2010 12:06, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>wrote:
>
> > On 2/8/10 12:57 , Mohamed Bana wrote:
>
> >> I don't see myself using JavaFX to implement any line of business apps. A
> >> DataGrid control with virtualization* is vital in places such as, say,
> >> front-office where data needs to be presented in tabular format.
>
> > Right. But what's the point about JavaFX? You can do data virtualization
> > even with JavaFX.
>
> That's great to hear, but it's still lacking the DataGrid control. I
> presume Oracle are going to do something about it given they're being used
> heavily in enterprise.
This is planned, but it won't make it in 1.3 because the controls
backlog was big. 1.3 is finally closing in all the basics (tree, list,
menus, scrollview, multiline textbox etc.) except the table/grid -
that should come in the next release. Seems like a good plan for me
exactly because the table/grid is the most complex and important
control, it should be especially well designed, remarkably to allow
great binding to diverse data sources (the JavaFX Composer beta shows
that Sun plans to invest here - drag&drop building of business apps
that navigate data from databases, XML and others sources). And if
Swing teaches any lesson, we are better off waiting for a careful
design than to hurry up and then live forever with the result. Oracle
doesn't need to change the route, unless they can throw sufficient new
resources in the project so they can deliver the Grid in 1.3's
schedule (but then, our friend Fred Brooks says this doesn't usually
works...).
> >> I haven't read anything to suggest that a new language for write UIs is
> >> needed. Just look at Silverlight which uses XAML (XML) to declare a UI,
> >> it's doing fairly well.
> > This is fairly subjective - there are also people that hate XML. For me
> > this is not a relevant detail and I'd learn either way in function of the
> > technology that I pick.
Count me as "people that hate XML". ;-)
> You can use Expression Blend so there's no need to touch the XML - I over
> generalize of course.
JavaFX will also have visual design tools that will hide the code from
you. JavaFX Composer already does this, the Design Tool should be
closer to higher-end tools for Silverlight and Flash. But it will be
nice that these tools will output plain JavaFX Script code that will
be easy to hand-tune if necessary. The fact that JavaFX Script
seamlessly unifies programming, GUI/design resources (layouts/forms),
and vector graphic resources (it's a pretty good SVG replacement),
will only be fully appreciated when people start working with complex
projects, several integrated (or not!) tools, third-party frameworks,
etc.
Oh, and at least one major competitor - Flash - proposes a new
language for writing UIs, ActionScript. Of course Flash is already
quite old, and ActionScript (even with Adobe's enhancements) is
familiar to ECMAScript programmers, so nobody considers it a new
language. But it is definitely a GUI DSL; it's just one that everybody
is already used to.
> >> Perhaps, Josh Marinacci also left because he saw a lost cause.
> >> And what about others that are still there? I'd not make speculations
> > about other people's intentions (also because it's easy to
> > counter-speculate: Josh is a guy who like challenges and the PalmOS choice
> > he's done is not less challenging than JavaFX).
Yes... Perhaps Josh didn't want to be part of Oracle. Perhaps Palm was
making great bids for top developers of that specialty. Perhaps a lot
of things. We will never know, because whatever information Josh gives
to us know, will be biased by his already-current position as a Palm/
WebOS developer and also as an evangelist (his blog "The iPhone, Open
Systems, and Leaving Sun" makes very clear the point about evangelism,
btw Josh is very good on this too). Not a criticism, I would probably
do the same.
A+
Osvaldo
Fabrizio Giudici
>
> This is planned, but it won't make it in 1.3 because the controls
> backlog was big. 1.3 is finally closing in all the basics (tree, list,
> menus, scrollview, multiline textbox etc.) except the table/grid -
> that should come in the next release. Seems like a good plan for me
> exactly because the table/grid is the most complex and important
> control, it should be especially well designed, remarkably to allow
> great binding to diverse data sources (the JavaFX Composer beta shows
> that Sun plans to invest here - drag&drop building of business apps
> that navigate data from databases, XML and others sources). And if
> Swing teaches any lesson, we are better off waiting for a careful
> design than to hurry up and then live forever with the result. Oracle
> doesn't need to change the route, unless they can throw sufficient new
> resources in the project so they can deliver the Grid in 1.3's
> schedule (but then, our friend Fred Brooks says this doesn't usually
> works...).
>
JavaFX can anyway mix with Swing components where there's a native
component lack, thus using JTable or JXTable - of course, not the best
option, but doable.
Jess Holle
> Let's also recall that one wanting to develop business apps now with
> JavaFX can anyway mix with Swing components where there's a native
> component lack, thus using JTable or JXTable - of course, not the best
> option, but doable.
installations of JavaFX and not on mobile, TV, etc.
--
Jess Holle
s
This is a great thread. Having been manic on JavaFX coding for the
past year myself, I must say that the language is a major game
changer, which I feel is only realized after extensive development.
It is a paradigm shifter especially in terms of design, and contrary
to categorization, it only minimally seems to be a "scripting"
language in my usage. I find my projects and style have taken on the
unique characteristics of self-organization and emergence, because
trying to apply many of the old design and architecture rules do not
apply to this unique phenomenon, which I call a phenomenon because it
is too liquid to detail (yet). I probably couldn't explain it even if
I tried because at this point, you adapt to JavaFX, not the other way
around. This language is a God send. I've given up all else. Java
is nothing but an interface language to me, now. I may be shooting
myself by doing this, but I'm all in. As for Swing, no need to touch
it, even now without 1.3; the alternatives combined with creativity
are too precipitous.
Steve Sobczak
Fabrizio Giudici
mobile etc... and as a temporary solution.
Jess Holle
> On 2/8/10 16:49 , Jess Holle wrote:
>> On 2/8/2010 8:56 AM, Fabrizio Giudici wrote:
>>> Let's also recall that one wanting to develop business apps now with
>>> JavaFX can anyway mix with Swing components where there's a native
>>> component lack, thus using JTable or JXTable - of course, not the
>>> best option, but doable.
>> Of course long term that will cause one's app to run only on Java SE
>> installations of JavaFX and not on mobile, TV, etc.
>>
> Of course - but we were talking of business apps, that mostly won't
> need mobile etc... and as a temporary solution.
Yes, but....
One of the reasons JavaFX could be compelling is as a rich and rapid
application toolkit that actually covers mobile and SE at once.
If you don't care about things being quite so rich and rapid, then just
go with DHTML. If you don't care about mobile, then one could arguably
just use Swing, though one could argue it's not as rapid or rich as JavaFX.
In any case, JavaFX's story is watered down whenever one has to add
Swing to fill in the gaps. This is actually true whenever one has to
fill in JavaFX's gaps with Java -- it works fine if one only cares about
Java SE environments. Java ME has only a subset of Java and that subset
is also back in pre-Java-5 days and thus even the subset is a technology
backwater that erodes the entire notion of WORA (as you can't write code
that uses Java 5+ features or libraries that use such features and then
have it work on Java ME).
Perhaps the best solution here is for Java ME to simply die at this
point -- as it is quite clear that Sun has no will to update it, no one
else in the mobile community has the will/power to make Sun do so,
mobile devices are ever more powerful, and Java 7's modularity may help
Java SE squish into places it hasn't been before.
[ME has been a cash cow for Sun -- one which it seems they've been
milking without really investing in at least in terms of updating the
base JVM technology. It also seems that Sun's been pretty uninterested
in making SE actually replace ME in the near term -- lest they endanger
that revenue. It's thus unsurprising that Google jumped to Harmony and
essentially created their own Java mobile edition given the alternative
of paying Sun for antiquated technology which Sun is clearly not keeping
up to date.]
--
Jess Holle
Fabrizio Giudici
First, filling the gaps with Swing would make sense for any application
whose expected life is a few years (let's say 3/5 which in my experience
is typical). Using a JTable would mean to make it out for the first
year, and then you'll probably be able to replace it with a native
JavaFX component. It's also likely that you have to mix Java and JavaFX
if you're evolving any existing application.
For the mobile, tell me which existing technology allows real WORA
encompassing both the desktop and the mobile(s). Yes, the fact that JME
is still Java 1.3 is a shame, of course, and the fact that Android is
nearly Java 5 is a plus. BTW, the complicated scenario you described is
real, but doesn't justify the fact that Google actually departed from
true compatibility with Java 5, even though they base on it. Which means
that the technical explanation is only a part of the reality, and Google
indeed wanted to cut their own, different than Java solution. That's a
pity and a bad decision for the community of developers, since it's
increasing fragmentation.
Of course, I do hope that JME will be away soon, and by this I mean a
fast evolution towards a realisting subset of Java 5. If I'm not wrong,
it's what Oracle described in their plans.
Stephen Chin
I have been working with the JavaFX team to include a version of the JFXtras Grid layout (not to be confused with a DataGrid) for JavaFX 1.3. It is based on the open-source JFXtras XGrid layout that is available today, but is much better integrated with the new layout engine in JavaFX 1.3. Amy Fowler talked about this in her SvJugFx presentation last month:
http://steveonjava.com/2010/01/19/javafx-layout-secrets-with-amy-fowler/
To my knowledge, the JavaFX team is not rushing a DataGrid/Table control for the reasons Osvaldo mentioned below. They want to make sure that they have a very robust API, and it is not a simple task to get it right.
That said, I am working on an XTableView control for the JFXtras project, which is available in the 0.6 preview release (which can be downloaded here: http://code.google.com/p/jfxtras/downloads/list), and will be officially released very, very soon. The main goal is to get something high performance and stable out there for folks who need a Table/DataGrid today, while providing a reference control that the JavaFX team can get feedback from and improve on when they do their own implementation.
Speaking of mixing Swing with JavaFX, we also have a very convenient JTable wrapper called XSwingTable in the JFXtras project. John Freeman did an outstanding job on this code (well unit tested!), which is also included in the 0.6 preview release.
I hope this helps. Big disclaimer about not working for Oracle and their releases/features being subject to change.
opinali wrote:
This is planned, but it won't make it in 1.3 because the controls backlog was big. 1.3 is finally closing in all the basics (tree, list, menus, scrollview, multiline textbox etc.) except the table/grid - that should come in the next release. Seems like a good plan for me exactly because the table/grid is the most complex and important control, it should be especially well designed, remarkably to allow great binding to diverse data sources (the JavaFX Composer beta shows that Sun plans to invest here - drag&drop building of business apps that navigate data from databases, XML and others sources). And if Swing teaches any lesson, we are better off waiting for a careful design than to hurry up and then live forever with the result. Oracle doesn't need to change the route, unless they can throw sufficient new resources in the project so they can deliver the Grid in 1.3's schedule (but then, our friend Fred Brooks says this doesn't usually works...).
JamesJ
JavaFX?
This is a great thread. Having been manic on JavaFX coding for the
past year myself, I must say that the language is a major game
changer, which I feel is only realized after extensive development.
It is a paradigm shifter especially in terms of design, and contrary
to categorization, it only minimally seems to be a "scripting"
language in my usage. I find my projects and style have taken on the
unique characteristics of self-organization and emergence, because
trying to apply many of the old design and architecture rules do not
apply to this unique phenomenon, which I call a phenomenon because it
is too liquid to detail (yet). I probably couldn't explain it even if
I tried because at this point, you adapt to JavaFX, not the other way
around.
This language is a God send. I've given up all else. Java
is nothing but an interface language to me, now. I may be shooting
myself by doing this, but I'm all in. As for Swing, no need to touch
it, even now without 1.3; the alternatives combined with creativity
are too precipitous.
Steve Sobczak
opinali
On Feb 9, 5:21 am, JamesJ <ja...@kybios.com> wrote:
> However. If you are trying to write an interface to existing code, the lack
> of generics is painful. The lack of arrays or easy access to Java arrays is
> also painful in some situations. Sequences are interesting, but they just
> don't do it all. It just doesn't feel like a "heavy lifting" language yet.
> It feels hard to write robust solutions to more complex problems. (I
> understand that it is still evolving, but I feel it still has a ways to go.)
IMO, the biggest problem in this are is that JavaFX Script doesn't yet
have a native Map-like data type - something similar to the sequences
in spirit and features (powerful syntax, immutability, interaction
with other language features like generator (for), binding/triggers,
etc.). Many so-called dynamic/scripting languages can get away with
just list and map as fundamental constructed types (some langs, e.g.
JavaScript and perl, don't even have real classes - everything is maps/
dictionaries); so it's a good model, at least for the bulk / higher-
level work. When things get tough, it's lovely to just be able to use
any of the hundreds of available collections from JavaSE and third-
party Java libs - but there's some cost in convenience and portability
to mobile. Augmenting sequences with a map would arguably be an
excellent balance; the map would also help in better interop with Java
methods that have map parameters/returns, which are very common. The
support for native (Java-style) arrays should also be improved with
the ability to instantiate the array, then I'd be happy enough.
Yep, this whole paragraph was another plug for http://javafx-jira.kenai.com/browse/JFXC-642,
please go there and vote ;-) That bug is very old for JavaFX standards
(June 2008 - before 1.0FCS...), I have blogged about it in June 2009
(link in the bug), and it's unfortunately scheduled for "After SoMa",
I would love to see this confirmed to the next major release. I
understand that the javafxc team has been spending massive effort in
the compiled-bind feature (that turned out to be ~100X more elaborate
than I initially thought), but once this settles down, perhaps we
should aim once again to ideas like JFXC-642. JavaFX Script must
indeed become a more "heavy lifting" language.
> Also, I'm not a fan of the distribution model. It seems that the
> tools/licence won't let you make an executable jar and just send it out.
The JavaFX runtime contains native code. LOTS of it. And it resorts to
other tricks, part of the runtime is (or will soon in a future
release) be put in the bootclasspath instead of the classpath. So, you
won't be able to just stuff that runtime in a single jar, any time
soon. Unless you use some packaging tool that supports native code.
Then, at the very least you wouldn't get a portable package (but
that's usually ok for internal apps).
The license OTOH sucks indeed; Sun has officially promised that JavaFX
would eventually be full open source - Rich Green from Sun was clear
about this years ago in the first JavaOnes that hyped JavaFX, so I
will continue to quote this to remember everybody that Sun either lied
or broke a promise to developers, until they (now Oracle) open source
at least the desktop runtime. (javafxc is already open source, but
that's clearly insufficient. There are some encumbered pieces like
codecs but missing these would be ok, the FOSS community could replace
them.)
BTW, if JavaFX starts building real momentum and market share, then
its proprietary runtime will lose 80% of all the goodwill and
mindshare that OpenJDK gained among developers in general and FOSS
enthusiasts in particular. I fully understand the benefits of keeping
the runtime project private and even the Apple-esque secrecy in the
initial build-up of the platform; but this stage is close to the end
now, I think Prism will be the last release that Sun|Oracle will have
any excuse of strategy. After that, each year without the open source
release will be a major mistake, the history of the JDK repeating
itself (potentially with a "too little too late" release far in the
future).
> I would love to see how long it would take a some without any JavaFX or JNLP
> experience to download the tools, build hello world and publish it. For a
> product that is supposedly targeted at a larger audience than core
> developers, I was surprised at the steepness of the learning curve.
The tooling sucks too, the NetBeans plugin has a long way to go, for
one thing it should support project dependencies (JavaFX libraries /
subprojects) and have a superb JNLP editor and package generation /
deployment / publishing features.
A+
Osvaldo
Karsten Silz
> The license OTOH sucks indeed; Sun has officially promised that JavaFX
> would eventually be full open source - Rich Green from Sun was clear
> about this years ago in the first JavaOnes that hyped JavaFX, so I
> will continue to quote this to remember everybody that Sun either lied
> or broke a promise to developers, until they (now Oracle) open source
> at least the desktop runtime. (javafxc is already open source, but
> that's clearly insufficient. There are some encumbered pieces like
> codecs but missing these would be ok, the FOSS community could replace
> them.)
"just open source" for licenses isn't enough - if Oracle wants
commercial JavaFX applications, then they need to change the
Scenegraph license from GPL to a more liberal license (e.g., Apache /
BSD style).
Codecs are a different matter: Oracle can't open source them because
they license them from other companies and pay for that. Now you
could use open source codecs for audio/video, but the main problem is
two-fold:
- On Netbooks and mobile devices you need hardware acceleration at
least for video to get decent playback. H.264 has that now (e.g.,
iPhone) or soon (e.g., Flash Player 10.1).
- With Flash, Silverlight, the iPhone and Blu-Ray all supporting H.
264, it has become the de-facto video codec. It will be hard to
convince content owners otherwise.
This battle over H.264 (comes with patents and royalties for certain
uses) has already stalled the HTML 5 <video> / <audio> tags - no
mandatory format is defined (http://arstechnica.com/open-source/news/
2009/07/decoding-the-html-5-video-codec-debate.ars). But just a
couple of days ago, H.264 declared to be royalty-free for internet
video streaming until the end of 2016 (http://www.theregister.co.uk/
2010/02/04/mpeg_la_h_264_codec_licence/), so I think it will remain
the dominant codec.
Karsten Silz
> To my knowledge, the JavaFX team is not rushing a DataGrid/Table control
> for the reasons Osvaldo mentioned below. They want to make sure that
> they have a very robust API, and it is not a simple task to get it right.
On the hand, shipping yet another major JavaFX release (the third one)
without a data grid is a bad decision IMHO. Most applications have
report / tables, and not having a standard JavaFX component for that
sucks a lot. Sun/Oracle has worked on JavaFX for around three years
when the next JavaFX release shipped, and it had the resources to
build charting components and to rewrite whole the "2D/3D drawing
stack" for the upcoming release, if I'm not mistaken), but you
couldn't find the engineers to build a table component?!
On the other hand, I can see where you need to take your time to do
this right: In Flex, you've had the regular data grid since the very
beginning and - since Flex 3.0 - the advanced data grid (can show
trees, multi-column sorting) and the OLAP grid (http://www.adobe.com/
devnet/flex/tourdeflex/web/, "Flex Core Components - UI Controls -
Tree and Grid Controls"). These two new grids are totally different
from the regular data grid (and kinda buggy from what I heard). This
sucks, too.
Jess Holle
On Feb 9, 12:57 pm, opinali <opin...@gmail.com> wrote:The license OTOH sucks indeed; Sun has officially promised that JavaFX would eventually be full open source - Rich Green from Sun was clear about this years ago in the first JavaOnes that hyped JavaFX, so I will continue to quote this to remember everybody that Sun either lied or broke a promise to developers, until they (now Oracle) open source at least the desktop runtime. (javafxc is already open source, but that's clearly insufficient. There are some encumbered pieces like codecs but missing these would be ok, the FOSS community could replace them.)"just open source" for licenses isn't enough - if Oracle wants commercial JavaFX applications, then they need to change the Scenegraph license from GPL to a more liberal license (e.g., Apache / BSD style).
Personally I'm fine with that -- as long as they move to LGPL / GPL+Classpath Exception. GPL itself is viral, potentially impacting one's entire product, whereas LGPL just forces changes to the library itself back to the community, which is a good thing.
--
Jess Holle
opinali
likes the GPL-family licenses, and this is enough reason to pick such
licenses. OpenJDK builds are already finding their way as standard
packages of Linux distros; companies like RedHat are investing in Java
(JBoss product line, IcedTea / OpenJDK contribs) so I think Java's
future is great at least in the "Enterprise Linux" niche, if not yet
for broader Linux usage.
A+
Osvaldo
opinali
> On Feb 9, 4:20 am, Stephen Chin <st...@widgetfx.org> wrote:
>
> > To my knowledge, the JavaFX team is not rushing a DataGrid/Table control
> > for the reasons Osvaldo mentioned below. They want to make sure that
> > they have a very robust API, and it is not a simple task to get it right.
>
> On the hand, shipping yet another major JavaFX release (the third one)
> without a data grid is a bad decision IMHO. Most applications have
> report / tables, and not having a standard JavaFX component for that
> sucks a lot. Sun/Oracle has worked on JavaFX for around three years
> when the next JavaFX release shipped, and it had the resources to
> build charting components and to rewrite whole the "2D/3D drawing
> stack" for the upcoming release, if I'm not mistaken), but you
> couldn't find the engineers to build a table component?!
It's probably not just a matter of resources (charting before Grid
surely looks like bad priority!), but dependencies. The new control
package seems to depend on some significant enhancements/changes in
core features like layout, latest animation improvs, etc., all being
delivered in 1.3.
Improvement of the 2D/3D stack, OTOH, is not wrong priority. JavaFX
depends on these things very heavily, it's not a straight Swing
replacement. It's a toolkit that allows a Button to be rendered with a
[fake-]3D transform, with motion blur, AND playing some streaming
movie inside it, if your designer wants that. If they had jumped to
the controls library as Job #1, they would later have to rewrite 90%
of it after massive changes in the graphics stack. That would be
stupid, and take more time and resources to deliver the full platform
that is envisioned.
> On the other hand, I can see where you need to take your time to do
> this right: In Flex, you've had the regular data grid since the very
> beginning and - since Flex 3.0 - the advanced data grid (can show
> trees, multi-column sorting) and the OLAP grid (http://www.adobe.com/
> devnet/flex/tourdeflex/web/, "Flex Core Components - UI Controls -
> Tree and Grid Controls"). These two new grids are totally different
> from the regular data grid (and kinda buggy from what I heard). This
> sucks, too.
Flex (and AIR) came after long years of Flash platform. And the
Silverlight platform didn't have any control package in its first
version. So I don't see any difference in the roadmaps (other than, of
course, JavaFX is still behind in some features because it entered
later in the game, and because Sun didn't have Microsoft-level
resources to grow the platform in blitzkrieg speed - it's been fast
evolution nevertheless).
A+
Osvaldo
opinali
> Codecs are a different matter: Oracle can't open source them because
> they license them from other companies and pay for that. Now you
> could use open source codecs for audio/video, but the main problem is
> two-fold:
BTW Sun's biggest blunder in 2008-2009 was NOT acquiring On2, before
Google did. Even the cash-strapped Sun could have paid $100M for On2
(owners of the needed codecs), probably a better ROI than the $1B paid
for MySQL (that almost made Sun bankrupt by blocking thre acquisition
from Oracle)...
The video codec issue does indeed suck. But it's not that critical for
JavaFX. If Sun|Oracle offers a good (proprietary) build of FX for all
major desktop and mobile platforms, and if they release as much stuff
as possible under a free license, people who prefer to run a "purely
free" platform (a small minority - can't even have a decent video
driver for Linux) will miss the fun of some video-centric FX apps; but
they would run without any problem >90% of the apps I expect to be
written in JavaFX: "common" desktop apps (using FX as a replacement
for Swing), games, etc.
A+
Osvaldo
s
> Have you had any problems with these issues?
I've experienced many if not all the development issues you and others
mention, and plenty more. My personal problems with convoluted
cognitive slippage keep me from getting into it, for I could go on and
on without any common-sense:-)
One thing I'd like to add, though, is that Inkscape has provided all
the vector-based graphical-design-to-JavaFX-code functionality I've
needed and wanted since I think Spring 2009, simply as a SaveAs
option. The two together are outstanding. Files with the .fx file
extension are all I need.
To share my biggest conceptual issue that is still emerging, I'd say
making decisions on how to handle large-scale OO JavaFX coding in the
new looser polymorphic model, combined with habits of old-world Java
interfaces, and finally--"bind"ing (exponentially deep)--is my biggest
obsession and compulsion.
JavaFX is the best Kool-Aid I've ever drank. And in no form or way do
I receive any benefits for saying this (I wish I did).
Steve Sobczak