JavaFX for the Enterprise - Working Group

[Roman Kennke]

And 'we' in this context means (should mean... that's the goal we need
to strive for) 'we the JavaFX community', not 'we Oracle' or 'we
non-Oracle'.

Roman

Am Donnerstag, den 18.10.2012, 09:05 -0700 schrieb Richard Bair:
> Dan's email deserves more than a flippant response, for which I apologize. That's what I get for trying to respond while on the train (and having only a phone as an input device). I quickly mentioned, in essence "hey, we're on it". I'm sorry for the misunderstanding, I know passions are running high at this time, and I don't want to be misunderstood.
> 
> > 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?
> 
> This is true. Oracle is a big company, and sometimes the way things are phrased in a press release are not to the liking of each constituency. That is to be expected. It goes without saying that the Java Team (not just the JavaFX Team) wants to see Java client be successful. It also goes without saying that an "official Oracle spokesperson" (I would be one of those) should be very careful about making any public statement regarding strategy or position that hasn't been previously vetted by one's senior management. We just had a JavaOne conference, in which we clearly stated that JavaFX for enterprise application client development, and for embedded consumer device development, are areas that we think we can compete and win in, and which also offer a lot of value to developers above and beyond current options.
> 
> >   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.
> 
> A working group is neither needed nor would it be productive. The reality is, the JavaFX team is devoted to producing the best platform that exists. It is the sole reason that Jasper and I work on this project. We are not in this for money (banking is much more lucrative), neither are we in it for job security (Android would have been a better bet, and we've had numerous opportunities to work for Google). We're doing this because we believe that all other client application development options stink, and we want to create the very best platform available.
> 
> Creating a working group would be pointless. That group already exists, and it is this mailing list. I see no value is creating a separate group to go off and brainstorm solutions. We know the problems, we (like any other development project in the history of the world) have multiple competing constraints and resourcing limitations (or limitations on the ability to manage large numbers of production teams). Jasper and I have complete influence within the JavaFX team. But within a company like Oracle (or Sun, or IBM, or HP, Microsoft, or any other large company), certain functions (like Legal, Security, etc) are housed in cross-cutting branches at Oracle, not under the direction of this, or any other team. As such, there are limitations in what we can do. People have asked for legal assurance that this usage or that usage of JavaFX with Maven isn't going to run afoul of Oracle legal. It is not in the power of this team to answer that question. Does that cause us difficulties -- yes of course it does, but such things are a fact of life in a large organization.
> 
> >   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").
> 
> You will not find anybody who has a higher sense of urgency than I do, either inside or outside Oracle. The problem is, the list of things that any one individual feels is P1 priority is going to be different. I also have the benefit of knowing a number of commercial operations that are using JavaFX and what their needs are, along with the existing set of Swing / SWT customers and what their needs are for JavaFX to be useful for them. It is not possible to have everything be a P1. I undoubtedly have, and will continue to, make decisions and priority calls that people don't agree with. That is the nature of the job, I cannot please everybody.
> 
> >   - Continuously identify improvements to the JavaFX platform that are
> >   needed to ensure adoption by enterprise; drive the inclusion of these into
> >   the JavaFX platform.
> 
> We do this all the time. In fact, we have an entire team paid to do nothing but "inbound marketing", where they engage customers and help develop the roadmap. In addition, we have this list where anybody can express their needs, and many of these are incorporated into our plans. There is also my own oracle email address, through which many contacts are made (and as a result, my ability to parse and respond to everything is very difficult). Jasper and I are both enterprise app developers (although it has been nigh unto 7 years since we were doing other than toolkit development, a fact we both are keenly aware of). And let me reiterate -- we have this list. We have twitter. There's no lack of input from all across the spectrum.
> 
> I am opposed to having a working group of exclusive membership. I believe in keeping this open for everybody's input. As a result, we're going to have a lot of choices to make, some you will like, some you won't.
> 
> >   - 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.
> 
> We do this on a daily basis. We look at a heck of a lot more than just HTML5 and .NET. We're aware of all the latest fads in development on the EE side, we've even built prototypes to compare how this works relative to FX.
> 
> >   - Provide best practices, community/forum support, documentation,
> >   examples, tool add-ons, frameworks and other aids for integrating JavaFX
> >   into popular enterprise technology stacks
> 
> We have a documentation team devoted to writing documentation. Is there specific documentation you want that isn't provided? I can hook you up with the doc writers and you can work with them. We'll link to your blogs (which we've done!) or anything else.
> 
> >   - Provide advocacy, publicity and drive general engagement and outreach
> >   programs for the adoption of JavaFX in the enterprise.
> 
> Here again, we have a whole "outbound marketing" and evangelism group who is devoted to this. Stephen Chin and Jim Weaver among them. Stephen is now on a motor-bike across Europe tour hitting ever JUG and gathering of Java developers he can find. Like I said, we're doing all this stuff, with paid people, who's full time job it is to do these things. And they're good at it.
> 
> >    - 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
> 
> We could (and should) have a whole thread on this subject.
> 
> >   - 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).
> 
> We've already had threads on validation, but again, the right way to do this is to have such conversations in a thread on this mailing list, it is not required that we have a separate working group to identify these things. The issue that I think sometimes we run into, is that although all these things are good and perhaps even critical, there are other things that are also good and critical that we are working on, such as accessibility and internationalization. So sometimes threads on a mailing list don't end in concrete work being done, when that thread is not related to one of the things we're signed up to deliver on. This is natural and to be expected. The way to move forward when it isn't on our list for the next release, is to have the discussion; produce the APIs, tests, and implementation; sign the contributor agreement and attach to JIRA.
> 
> >   - Create a demonstration enterprise application (along the lines of
> >   PetClinic) demonstrating best practice for integrating JavaFX in a full,
> >   end-to-end JEE stack.
> 
> In fact, we released the "DataApp" also known as "Henley Car Sales" with JavaFX 2.0 for exactly this reason. It uses EE 6 on the backend, Jersey Client on the backend and frontend, and JavaFX on the front end. There is a lot of scope to extend and work on this. In fact, it is BSD.
> 
> As I mentioned in my poorly worded and perhaps flippant response, we're already engaged in each of these areas, and forming a new working group is neither necessary nor would it actually help move the ball forward. The best things to do are to discuss issues on this mailing list, add issues to JIRA and lobby other developers to support those items, and if possible contribute complete solutions for things that we don't have on our deliverable list.
> 
> Richard