The Next Great Thing: An Application Framework

Daniel Zwolenski zonski at googlemail.com
Sat Feb 11 21:59:06 PST 2012


I like all the thinking on this front and the different initiatives (and
the enthusiasm). I think there is a lot of room for us to exchange ideas
(and code!) and either make sure each of the platforms is doing something
unique, or merge efforts if they are not. One of my fundamental goals
however is to not tie a developer into a specific development
toolset/environment as much as possible (as a developer I hate it when I
can't use my tools, so I try to make it so everyone else can use their
weapon of choice too), so the frameworks based around Eclipse (or any
specific IDE) are unfortunately not of direct appeal to me.

Having said that, I'd love to keep abreast of the features being added, how
they are being implemented, architectural patterns and motivations,
etc. Perhaps there is even room for a project like JFXtras to become a spot
for us to put common toolkits that our frameworks can all share, rather
than each of us reinventing wheels. If there is anything in JFX Flow that
people would like to use in their toollkits, let me know and we'll see if
we can section stuff off. Likewise I will look through your frameworks as
much as time allows and see what overlaps (e.g. maybe we could all work on
a form validation framework together that our application frameworks then
share and add to, etc).

Richard, on the topic of what the JFX platform should/shouldn't include,
can I add another way of thinking into the mix for you to mull over:
although there is a strong case for keeping the JFX platform as the 'core'
library, just because other modules/elements are not part of the 'core'
doesn't mean that Oracle can't produce them, sponsor them, contribute to
them, etc. It would be great to see Oracle champion initiatives on each of
the logical extension fronts (full app frameworks, game platforms,
form/wizard frameworks, navigation/event-bus libraries, high-level
animation libraries, PDF/doc browsing/editing, voice/video conferencing,
etc). This approach would achieve the goal of getting all these needed
value-add frameworks built in a consistent, 'official' way, but would
remove the restrictions implied by a core framework (e.g. can't use 3rd
party, tied to core release timeline, legal issues, etc). Also the cost to
Oracle would be massively reduced, allowing them to achieve far more with
limited resources. If Oracle is driving initiatives they can still keep
their brand on it - Google uses a similar approach and it only adds to
their brand and their platform (see http://code.google.com/).

In some (few) cases this could be in the form of Oracle putting together
it's own closed team (like the JFX team is now) on a project if Oracle
feels that area is of critical importance/urgency to the JFX platform. My
preference however would be for Oracle to instead either lead or support
open source community efforts. Perhaps by providing a project lead for it
and getting members of the community to sign up and join in (perhaps even
sponsoring some community developers - like a 'key contributors' model or
something).

Alternatively (or as well) it would be awesome if Oracle had an internal,
dedicated team of 'community supporters' who's full time job it is to
assist community projects that Oracle sees as value add to the platform.
This team would help guide/support projects that look to add value to the
JFX platform, possibly by providing direct development resources, or
otherwise by providing publicity, official 'sanctioning',
infrastructure/hosting support, and communication links to funnel requests
back to the JFX team for core support/enhancements, etc. Additionally this
team could also help identify duplicate efforts and try and foster/guide
collaboration and effort-merging to limit the number of similar initiatives
(for us garage developers working out how to collaborate is a lot harder
than it sounds, and having a trusted third-party assist with this would be
useful).

In a better world, the java.net developers site would be the ideal
infrastructure for these sorts of projects, but unfortunately (in my
opinion at least) it is a dog's breakfast of a system with a horribly
unusable UI, outdated/limited features and poor performance. I've tried to
use it in the past and found it too painful and ended up switching to
google code. If some energy were to be expended on making java.net more
like a modern day collaboration suite (the Atlassian toolset for example)
then this could be the perfect platform for this sort of community effort,
all to the mutual benefit of Oracle and the JavaFX community as a whole.
Win-win.

For what it's worth, I would volunteer what spare time I could find to work
with guys on your end to make something like this a reality.



On Sat, Feb 11, 2012 at 8:55 AM, Tom Schindl <tom.schindl at bestsolution.at>wrote:

> In my thinking is an IDE is simply a large large RCP-Application?
>
> In this sense like you as an die hard Eclipse users I've started
> developing an RCP framework built on top if Eclipse 4 Application
> Platform which provides the completely new runtime layer the Eclipse 4.x
> IDE is built upon.
>
> The key things are:
> * extensibility by using OSGi
> * event bus built on OSGi Event Admin
> * service architectur built on OSGi
> * theming via CSS
> * programming model based upon JSR 330 (javax.inject)
> * DOM like Application Model providing clean seperation between
>  application state and rendered UI
> * commands/handler framework
>
> Kai Tödter is also doing work in this area (he also builds on the
> Eclipse 4 Application Platform) and has published nice screenshots of
> applications [1].
>
> I'm currently working on a demo application which we'll demonstrate at
> Eclipse Con North America in March showing how a collabrative
> application can be built using the Eclipse 4 Application Platform and
> JavaFX (because it's at EclipseCon we'll even mix SWT into the game but
> that's a minor thing) [2].
>
> Coming back to my above assumption that an IDE is nothing more than a
> big RCP application - the RCP the framework built by us - can easily be
> expanded to an IDE e.g. by mixin in other Eclipse technologies like e.g.
> JDT-Core, Xtext for DSLs, ... .
>
> I think the important thing for efx and the e(fx)clipse runtime
> platforms is that they build upon hardened frameworks because other big
> products (Netbeans and Eclipse) are built upon them.
>
> This makes those 2 frameworks share resources with others (e.g.
> e(fx)clipse runtime platform currently has around 20 classes and
> supports all important UI paradigms starting from menus to toolbars to
> tabs) while inheriting all other features from the framework developed
> at Eclipse.
>
> BTW if you are not happy with the UI-Paradigms currently defined in the
> Eclipse 4 Application Platform you are able to expand and mix in your owns.
>
> All our sources are provided under EPL [3].
>
> Tom
>
> [1] http://www.toedter.com/blog/?p=709
> [2]
>
> http://www.eclipsecon.org/2012/sessions/eclipse-4-meets-cdo-now-you-see-it-and-so-do-they
> [3] http://github.com/tomsontom/e-fx-clipse
>
> Am 10.02.12 22:00, schrieb Sven Reimers:
> > Seems there is more than one approach out there for getting a JavaFX RCP
> in
> > shape. As a die hard NetBeans RCP user I started an open source
> > java.netproject called efx, which tries to reuse a lot of the NetBeans
> > RCP pattern
> > while getting rid of the Swing UI.
> >
> > So the focus is more on RCP not on an IDE or something similiar, but with
> > first class support for development of such RCP based applications..
> >
> > Sven
> > Am 10.02.2012 21:35 schrieb "Richard Bair" <richard.bair at oracle.com>:
>
>
> --
> B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
> ------------------------------------------------------------------------
> tom schindl                 geschäftsführer/CEO
> ------------------------------------------------------------------------
> eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
> http://www.BestSolution.at                      phone    ++43 512 935834
>


More information about the openjfx-dev mailing list