Charts: Was The Next Great Thing: An Application Framework

[Jeff McDonald]

Charts .. I love them!

Daniel nails the list of concerns, but on some of his points I come to
different conclusions.

1. Resources - I agree, there are higher priorities on my list too
(deployment would be one, and image processing APis another), but I gotta
say ... the charts stuff Rocks!

2. Bloat - always a concern. I think charts are more common than one might
think. Charts are something that I will use a lot more now that they will
be a part of JavaFX so for me .. they aren't bloat. Considering that Oracle
is funding all of the development and they are an enterprise customer that
uses lots of charts ... I can see why they would have been important to
include. Remembering that mobile platforms may be supported in the future
size becomes more important. Java 8 change the landscape a bit because
there will be greater flexibility to eliminate un-needed modules.

3. Change management - this is the real issue. Charts are off to a good
start, but it they need to evolve and mature more first. I'd like to see
them evolve on a different schedule than JavaFX and especially the JDK.
Perhaps Java 8 will help out here too as mentioned before. The sweet spot
would be to use Java 8 to allow inclusion or exclusion of charts in a app
(deployment), and to have an updater service (like Sparkle) to let
developers release updates when it seems best for them and their users.


On Sun, Feb 12, 2012 at 12:18 AM, Tom Eugelink <tbee at tbee.org> wrote:

>
> To add my €0.02 on the chart topic; Dan here does hit the nail on the
> head. I started an email yesterday trying to explain exactly this, but I
> did not succeed (may have something to do with this fever thing I've got
> going on), so I'm gladly stealing Dan's points here. To me it most
> definitely is something of a higher abstraction level than controls. I can
> understand Richard's point of view though, but then a lot of stuff (like
> Dan's examples) are at the same level. Why only charts?
>
> Naturally this is of absolutely no practical consequence, because it is
> great that JFX has charts, no discussion there. But it may be interesting
> in light of how end-users look at charts and indeed on how OpenJFX is
> organized into modules or separate projects.
>
> Tom
>
>
>
> On 2012-02-12 07:38, Daniel Zwolenski wrote:
>
>> Hi Richard,
>>
>> It's not that I don't like having charts available when I want them and
>> although I haven't looked at them in depth yet, it looks like it is a very
>> powerful toolkit. It's just that I feel only a sub-set of applications
>> (specifically business/data apps) will actually use charts, whereas things
>> like buttons, labels, textfields are fairly ubiquitous building blocks for
>> everything. Charts feel more like a higher-level feature to me, on par
>> with
>> things like 'mapping', file editing, PDF browsing, a 'game engine', or a
>> statistics package, etc.
>>
>> It is definitely possible that I may not fully understand the chart API as
>> yet though and my comments may be premature. I haven't had call to use
>> them
>> yet in my applications, perhaps when I do I will change my viewpoint. With
>> that caveat in mind, the main drawbacks I see to charts being in the core
>> platform are these:
>>
>> 1. Resourcing - I have a gut feel that building/maintaining something like
>> this was and will be something of a hassle that will draw all-important
>> JavaFX resources away from more fundamental features. The community would
>> probably pick charts up if it was left out, so it feels like Oracle is
>> blowing 'coin' I'd rather see spent on stuff that can't (easily) be done
>> by
>> the community because it is more 'core' (like video playback, true 3D
>> support, mobile phone support, etc).  If Oracle's got resources to burn on
>> this then this is not such an issue, but I'd personally rather get a media
>> capture API, or a mobile version in there over charts, because charts I
>> can
>> build myself, whereas media capture and/or mobile requires nasty native
>> libraries and weird non-java magic.
>>
>> 2. Bloat - it's good to keep the base platform as small and light as
>> possible so when we look at supporting platforms (like mobile, set top
>> boxes, etc) we only have to move the core features on to these and not be
>> moving a massive codebase across (and also downloading a massive jar).
>> It's
>> easier to keep the platform stable too, less code means less bugs. If we
>> didn't have charts when we go 'mobile' then the move would be easier (i.e.
>> catering for touch screens, smaller screens, etc). Modularisation may help
>> with this, but I think the additional code in the core platform will still
>> result in more work.
>>
>> 3. Change management - my gut feel is something like charts will have a
>> more rapid change/fix cycle than the core platform. I don't particularly
>> want my end user to have to download a new JFX RT every other week
>> (especially if there are more annoying popups) because there has been a
>> fix
>> in the way 'ticks' are rendered on a chart if I'm not using charts
>> (whereas
>> HBox probably isn't going to change too often). Again maybe modularisation
>> will help with this, but it is still a way off and the deployment battle
>> may well be fought and lost before Java8 gets on it's horse and makes a
>> charge.
>>
>> As per my previous email, all of the above is not to say I wouldn't love
>> to
>> see a separate ChartsFX library published by Oracle that had the exact
>> features in the core jfx charts module at the moment (deployed into Maven
>> would be even better :) ).
>>
>> As always, I'm definitely not putting down any of the effort put in by the
>> JFX team. I'm an unashamed platform zealot and a fan. JFX is the
>> development environment I've been dreaming about for years and I love it.
>> I'm more concerned about providing (hopefully) constructive feedback on
>> making it better and making sure the platform is sustainable so it can
>> become the standard and every new job I look at uses it. As we get stuck
>> into nutting out features and working through problems, it's easy to
>> forget
>> to say it, so for the record: very nice work guys.
>>
>> Cheers,
>> Dan
>>
>>
>>
>> On Sat, Feb 11, 2012 at 6:49 AM, Sven Reimers<sven.reimers at gmail.com**
>> >wrote:
>>
>>  There are some ideas sitzung in Jira that would be good for msking Charts
>>> even more successful, e.g. logarithmic axis and multiple y-axis..
>>>
>>> Hope OpenJFX will be the place to make those things happen.
>>>
>>> Sven
>>> Am 10.02.2012 19:39 schrieb "Richard Bair"<richard.bair at oracle.com>**:
>>>
>>>
>>>  - Charts: seems like an add-on that will become something of a hassle
>>>>>
>>>> for the JFX team to maintain, grow, support at the rate it will need, as
>>>> well as adding complexity for mobile platforms (should a pie chart look
>>>> the
>>>> same on a mobile app with touch screen, no mouse over, etc).
>>>>
>>>> Different topic, but I thought this comment was interesting. Why are
>>>> charts any different than controls? We see them as the same thing
>>>> really.
>>>> Charts are extensible -- folks can add new charts, or use the built in
>>>> ones, exactly like controls. Both are intended to be drop-in use for
>>>> applications. Charts are actually much more powerful than we've gotten
>>>> credit for so far (I suspect this is because nobody has dug into them
>>>> deeply and we've not documented a lot of the capabilities on
>>>> fxexperience
>>>> or javafx.com yet).
>>>>
>>>> Richard
>>>>
>>>
>>>
>
>