JavaFX for the Enterprise - Working Group

[Daniel Zwolenski]

I tried. I'm out. You guys can breathe easy - the 'negative guy' will shut up now and leave you to your own devices.

One last thing before I bow out:

"For goodness sake contribute?"

- I have contributed several 100 hours  writing a blog on how to force JavaFX into working in an enterprise stack. All of this on weekends and in late evenings. 

- I have contributed long, long hours reviewing and discussing JFX on this list. As part of community discussions, many of those things have directly influenced the JFX platform. 

- I have contributed many hours prototyping Auto Updating code which is open source and available for review and contribution. I had no help and little response from JFX or the community on this. I identified a show stopper feature that I needed to make the solution actually work on the current platform, raised it with JFX to which the response was "I'll think about it". This was months ago - there has been silence on the topic since so little point in continuing with this contribution, making the original effort completely pointless. 

- I have contributed many hours working out ways to get Maven integration working - critical for enterprise adoption. I worked with other community members to find work arounds and strategies. We identified a DLL load issue. I offered to contribute the code to make this maven friendly (the response was "not our problem"). We identified a legal hurdle and I identified the line in the contract that was the problem (the response was "too hard to fix"). I wrote half the plugin, hacking around the previous issues, and asked for access to some documentation on the packaging tools or assistance in doing this (the response was silence). 

- I have contributed an open source wrapper around a cross-platform camera capture program that can integrate into jfx while we wait for the jfx platform to include this highly ranked feature in jira

- I have contributed hundreds of hours supporting the JFX forum, fostering community growth and uptake. I am still ranked somewhere in the top 10 helpers even after not answering anything for several months. 

- I have contributed numerous bug submissions and feature enhancements to JIRA and commented on many more. 

- I have contributed to the advocacy of the JFX platform by giving a talk on it at a local JUG at the request of Jonathon Giles. 

- I contributed by responding to a direct request from Richard to discuss and prototype a JFX 'browser' for some conference he was doing. After kicking off the discussion with some initial emails, and starting me working on stuff, he then got distracted, failed to respond to emails and generally didn't bother following up, even just to let me know if it was/wasn't useful for his needs and whether to keep going or stop. 

- I have contributed ways to improve the use of JIRA, including improving the use of the voting mechanism. I contributed a dashboard but jfx couldn't be bothered to enable dashboard sharing. I then contributed the queries needed directly to Richard. (at his request) which was then ignored. 

- I have contributed my own development reputation with my commercial clients by championing the jfx platform to them. The one client I convinced to use the platform has been severely hampered by deployment and build issues and lack of any significant uptake of the platform (so no skilled developers available and no one interested in making the switch) and are currently evaluating a total rewrite in HTML. I look like a chump. 

- I have contributed a proposal to address the fact that Oracle is openly backing a competitor platform and not jfx in the enterprise space - the response was "there is no problem" and "raise a jira issue". 

What exactly is it you want me to "contribute for goodness sake"? Blood? Or do I need to check in to your source tree for it to count? Hot tip: you need to actually provide a clear, well documented way for people to get, build and run your code (preferably in a way that doesn't involve 16 magical steps and putting our local Dev environment at risk of getting munged - we have actual work to do that requires a stable jfx environment) if you want that to happen. 

"Goodness sake" is a good way of putting it since there is little other incentive for contributing. None of these contributions have had any kind of gain for me, monetary, professional or otherwise. The payoff should have been a platform I could use but that investment hasn't panned out. 

This dismissive comment about contributing really rams home how you, Richard, personally feel about contributions so far. Nice. 

Are you feeling like you're not getting enough "contributions"? Maybe you should have a look at how you've responded to the attempts (not just by me) to contribute so far. Do you think you're making it easy or rewarding to contribute? Are you supporting your contributors by clearing obstacles they identify, addressing or even responding to issues they raise (read back through the dozens of maven emails if you really think so). Based on my experiences, I would say your hearts in the right place but this is definitely not translating into anything tangible for contributors. 


On 18/10/2012, at 1:23 AM, Richard Bair <richard.bair at oracle.com> wrote:

> We are already doing everything on your list (which was pretty void of specifics).
> Please list specific work projects, linked to specific JIRA issues, and vote for them and for goodness sake contribute!
> 
> 
> 
> 
> On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski <zonski at gmail.com> wrote:
> 
>> So Oracle as an organization doesn't think JavaFX can be a player in the
>> web/enterprise space and is backing HTML5. I don't agree, JavaFX has the *
>> potential* to be better. But it's a long way behind and gotten off to a
>> rocky start; there's a hell of a lot of work to be done and the current
>> rate, strategy and direction are not going to be nearly enough.
>> 
>> Oracle is a big corporation with many different divisions. The left arm
>> doesn't know what the right is doing. So let's put aside 'oracle' for a
>> moment. I want to know: what does the JavaFX team think? Do you want to go
>> up against HTML5 for the client space, or just settle for a spot on the
>> fringe?
>> 
>> Below is what I propose.
>> 
>> This proposal needs the full backing of the JavaFX team and management.
>> Specifically it needs:
>> 
>>  1. Belief that JavaFX can and should be the *number one* client
>>  development platform for enterprise.
>>  2. Recognition that the current strategy will not make that happen.
>>  3. Resources (aka people) allocated to the working group outlined below.
>>  These people must have enough influence in the JFX platform to legitimately
>>  be able to influence the direction as needed.
>>  4. Commitment to supporting this working group fully and implementing
>>  the strategies and recommendations that come out of it as a high priority
>>  5. A sense of urgency, and a proactive pursuit of achieving these goals
>>  with a well defined timeline (i.e. "resources will be allocated by November
>>  2012" not "we're working on it").
>> 
>> In my opinion, all of these must be met 100%. Otherwise there is no point
>> starting at all and better to let it go and leave the enterprise space to
>> other players like HTML5 as 'Oracle' is suggesting. This is your call.
>> 
>> I believe JavaFX can be the best platform for client-side enterprise
>> application development, capitalising-on, and adding-to Java's dominance in
>> server side enterprise development.
>> 
>> Do you?
>> 
>> 
>> *Proposal to form a working group for JavaFX in the enterprise*
>> 
>> Mission:
>> 
>>  - to position JavaFX as *the* dominant client-side development platform
>>  for enterprise/business applications
>> 
>> 
>> Members:
>> 
>>  - a combination of paid Oracle JavaFX team members, and community
>>  participants. The Oracle members must have the ability to access senior
>>  JavaFX management and technical decision makers, and as such influence the
>>  road map and direction of the JavaFX platform. Community members will be
>>  those with a background and experience in the enterprise space and who are
>>  committed to making JavaFX the platform of choice in this space.
>> 
>> 
>> Responsibilities:
>> 
>>  - Continuously identify improvements to the JavaFX platform that are
>>  needed to ensure adoption by enterprise; drive the inclusion of these into
>>  the JavaFX platform.
>> 
>>  - Continuously identify and monitor trends and developments within the
>>  enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and
>>  ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's
>>  long term viability for their needs.
>> 
>>  - Provide best practices, community/forum support, documentation,
>>  examples, tool add-ons, frameworks and other aids for integrating JavaFX
>>  into popular enterprise technology stacks
>> 
>>  - Provide advocacy, publicity and drive general engagement and outreach
>>  programs for the adoption of JavaFX in the enterprise.
>> 
>> 
>> Objectives:
>> 
>> Objectives will be determined by the working group once formed, however
>> initial objectives will likely include the following:
>> 
>>  - Review the current deployment/distribution options for JavaFX and
>>  determine ways to improve this to make it competitive with other popular
>>  enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise
>>  OS' and platforms
>> 
>>  - Identify the most popular enterprise build and development tools and
>>  determine a strategy for making JavaFX integrate into these
>> 
>>  - Review popular trends and toolkits within competitive platforms and
>>  define the ideal frameworks and add-on tools needed by an enterprise client
>>  (e.g. form validation). Use this list of high-level requirements to
>>  determine the low-level JavaFX enhancements needed (e.g. allow field
>>  markers so that a 3rd party validation framework could leverage these).
>> 
>>  - Create a demonstration enterprise application (along the lines of
>>  PetClinic) demonstrating best practice for integrating JavaFX in a full,
>>  end-to-end JEE stack.
>> 
>> 
>> Longer term objectives may include:
>> 
>>  - Develop (or foster community development of) the high-level frameworks
>>  that have been identified as necessary for JavaFX in the enterprise. These
>>  will likely be developed as third-party modules external to the JavaFX core
>>  framework (i.e. built on top of the features provided by the core JavaFX
>>  team).
>> 
>>  - Provide integration with existing or new Rapid Application Development
>>  (RAD) tools popular within the enterprise Java space (e.g. ROO, etc).