Developers vs Designersexpanding the Java platform beyond programmers

1

who is this guy?

Josh Marinacci: joshua.marinacci@sun.com

Co-author: "Swing Hacks" by O'Reilly,

Developer: Swing, NetBeans, and JavaFX teams

http://weblogs.java.net/blog/joshy/

2

Developers vs Designers

3

In the beginning...

there was “the developer”

4

Think back to the dawn of time, the 1960s. This is when software as we think of it today really got out of research and became a part of business. It was written by programmers: dedicated professionals who wrote software to spec under very tight technical constraints of memory and CPU usage. As we developed better computer technology the ambition of software increased, but the balance still remained. Software, or at least user facing software, is often ugly because it matters more what the software can do than how it looks. I really feel this is because software has been in such an experimental phase for so long. We are always trying new things, and the fact that it does this new thing is the valuable part. Not what it looks like. I forget where I heard this expression, but it goes something like this. If you have a talking dog with a lisp, no one cares about lisp. They are amazed that it can talk at all. For a very long time the point of software has been to push the boundaries of what is technically possible, without regard for usability or how it looks.

Software can be beautiful

But it’s hard

5

Software can be beautiful (but it’s hard)And when I say beautiful here I am referring to aesthetic beauty of the interface, not the elegant structure of code. It's really quite hard to make software and looks and acts beautiful. It's a ton of work. Just look at the rising budgets of video games. That artwork and programming is really expensive.

It's also difficult to make beautiful software because it is rare to find a developer who has a good design sense, or a designer who is a good programmer. The disciplines have traditionally been very far apart, and anyone who can bridge the gap was very valuable and rare.

So software has typically be designed and built by programmers.

Let a Thousand Eyesores Bloom

the web

HTML: simple and forgiving

compiler == reload button

designers can build something

6

But then something happened. The Web. The web is built on HTML and simple scripting languages like Javascript and PHP. HTML was easy. Anyone could build a webpage with just notepad and a free browser. It was simple. Basic style and links for navigation. It was forgiving. No compiler to complain at you when you didn't close your tags. Just keep futzing with the tags and hit reload until it looks like what you want. Now this system didn't always result in great software, or even pretty software, but it did allow designers for the first time to build software without developers. Or at least to do the bulk of user facing development and leave the programmers to do the back end work. This was something genuinely new.

Think DifferentOld:

UI Toolkits

platform style guides

New:

anything goes

always custom.

7

Another thing that happened on the web was things could be different. It was the first time the software world accepted the fact that not all software would or should look the same. If you remember the early days of windows, the mac os, or cross platform toolkits like Swing; there was a big emphasis on consistency and UI style guides. Every app must look the same. The same colors, fonts, graphics, icons. Everything. But on the web that simply wasn't the case. It often wasn't possible, and the few people who tried to make web software that looked like consistent desktop software failed miserably. The web became a wild west of design, constantly trying new things. Often failing, but still trying and innovating. Even today when certain metaphors have become commonplace, still no one website looks just like another. In fact, to have your website or webapp look the same as someone else's is considered a bad thing. Now we have established that not all software will look the same, that user interfaces can be different, and people will not only accept it but appreciate it.

The skinning revolution

Winamp, Audion, X11 Window Managers

Shaped windows and opacity

real graphics tools + simple config files

always different, always weird, always new

designers in control

8

Around the same time as the web was taking off there was a revolution in desktop software starting with Winamp. It was called skinning. There was this concept that software, or at least music players, didn't have to look the same. In fact, one copy of that software could have multiple looks, changable at any time, at the whim of the user. And these looks weren't just variations on a theme, but different interfaces that were utterly and completely different. It encouraged people to think outside the box. Round shapes, not square boxes. Alpha channels. Windows themselves could be shaped and have transparency. You could make your player look like something out of a future episode of star trek, or be a minimalist with pixel perfect micro fonts. And you could build all of this without knowing a single thing about MP3 playing software. Skins were typically simple text files which stitched together images created in photoshop. A designer could go from concept to a running and *shipped* skin in a day without the help of a programmer at all. This was the beginning. It started to change the way software was written. Even despite all of the truly hideous skins out there.

Example Skinz

9

Flash, Silverlight, & RIAs

JS Frameworks: GWT, Script.aculo.us, MooTools

Flash/Flex/AIR

Silverlight

10

The final change has been the rise of RIAs. Javascript is surprisingly powerful, but it's hobbled by the speed and limitations of browsers, as well as cross browser difficulties. In recent years we've seen lots of Javascript frameworks and libraries that try to solve this problem including GWT, Scriptactulous, and my personal favorite MooTools. They let you interact with the web browser in a more structured and consistent, but they can only do so much. The browser is what it is. The only way forward is to extend the browser itself via plugins. Either the small plugins like Google Gears which extends the Javascript model, or complete new runtimes like Flash.

Thanks to Flex, Flash has become more than just a player for cartoons. Now it's a platform for building slick applications that look good and can do more than plain HTML and Javascript alone.

Microsoft's Flash competitor, Silverlight, is doing the same thing. A new runtime that works as a browser plugin to extend the browser beyond what is possible with plain HTML and Javascript. Silverlight has just hit their beta of version 2 and we're starting to see some very interesting apps come out of that community.

These new runtimes open up possibilites that were closed by the old HTML and CSS model.

The Shift

the way we build software is changing

innovation is not speed and raw features

innovation is in the feature set choice and aesthetics

designers drive the software, not developers

11

With the groundwork laid by the web and skinning software, combined with the near ubiquity of designer tools like Photoshop, and the new browser plugin runtimes, the way we develop software has started to change.

The software technology itself is good enough that the innovation isn't in the the technical side of how to calculate something faster or push out more pixels. The innovation is in the choice of feature set and ease of use and the asthetics.

No longer are designers simply people who make the software pretty. They are the drivers of user features. They decide what the software should do and how it should look. They do much of the work and hand off certain pieces to dedicated programmers, or in the smaller companies do programming themselves while wearing different hats. In short software, or at least user facing software, is becoming designer driven.

Java: Programmer Platform

Java language unfriendly to designers

Lack of designer tools

Enterprise focused

Not a consumer quality user experience

12

So that's where software has come from and where it is going. But what about Java? Java was the original RIA with applets, so what happened? As it turns out Java is rather unfriendly to designers. Java requires a compiler and full programming knowledge to use. You must understand OO, threads, classpaths, and a very expansive API. These are all features which are great for programmers, and in fact some of the reasons the java platform has been so popular. But they make life difficult for designers. There are no real designer tools targeted at the Java platform. Certainly we have ways of manually slicing up images to use in applications, and if you've read my book Swing Hacks or Filthy Rich Clients from Chet and Romain then you know it's possible to make good looking Java applications, but it still requires a lot of work. Far more than it should. Traditionally the Java platform has focused on the enterprise space. Desktop Java works well on the enterprise desktop where all computers are the same and Java SE has been pre-installed by the IT guys. But in the consumer space desktop Java just hasn't cut it. It's too hard to install. It's slow to start up. It's crashy or unreliable in certain browsers. In short, it's a bad consumer experience.

LayoutManager: Worst Idea Ever?

GUI in Java: inconsistent, redundant, complicated

LayoutManagers: reviled

Backwards compatibility headaches

Horrible experience for designers

13

In particular the GUIs are bad. The GUI APIs in Java are powerful but has several significant issues which pose serious problems for designers. First, it's not consistent. Thanks to the evolution of the Java platform we have AWT, Java2D, and Swing, and even the Swing alternative SWT. They each operate at a different level of the stack. Should you use Frame or JFrame? Should you customize a JButton or make your own with rectangles in Java2D? Combined with threading and network operations this creates a complicated programming system with duplicated classes, missing components, and platform differences. Not good for a budding designer. Layout managers in particular are problematic. They were designed with this idea that layout should be consistent between all applications, and that custom layouts should be written in code. As an example of how to do this we included GridBagLayout. Which is now one of *the* most *reviled* layout managers of all time. It even has it's own parody cartoon. There hasn’t been a good way of visually creating layouts until the advent of Matisse, the gui builder in recent versions of NetBeans. But even then it’s not really a designer tool. You have to understand Java to make use of it. Then we drop in the general problems of maintaining backward compatibility, then we have a system that is decent for enterprise developers who don't care about the look of their apps, but something that's horrible for designers or anyone who needs to build rich applications. There's too many ways to do the same thing, and not enough ways to do the things designers care about.

Why Java Matters

Ubiquity: half a billion

Crossplatform

Fast

Huge ecosystem

Open Source

14

So now that I've finished showing you all of the failings of the Java platform when it comes to consumer applications, let me talk about the strengths and why it's worth investing the time and energy to change things. * Ubiquity. there are over half a billion copies of desktop Java out there. And a whole lot more on mobile devices. * Cross platform. It runs on Mac, Windows, Solaris, Linux, and most other flavors of unix. It's currently being ported to native packages on several linux distros, to phones and set top boxes, and to more esoteric operating systems like Haiku, the modern incarnation of the BeOS. * Fast: years of research and optimization have created a JVM which is very fast. Gone are the days of interpreted Java and hoping for JITs to save us. The modern hotspot JVM does lots of runtime optimization to execute as fast as natively written code and optimize memory usage. * The ecosystem: millions of lines of Java code have been written across the world. Thousands of great open source libraries. No matter what you want to parse or generate, there's probably an open source library already for it. Want to show a PDF? There's a library for it. Want to parse XML? There's about 20 libraries for it. Want to parse XML using only a few K of memory? There's a library for that too. The Java ecosystem is huge and we should be able to leverage that in our next generation apps. * Open Source: When it comes to plugin-based RIA platforms we have three major players. Adobe with Flash. Microsoft with Silverlight. And Java. Only one of these is open source. Java may have had a long and checkered past when it comes to openness, but we threw the doors wide open a year ago and now Java is completely open source. The last encumbered bits have been stripped away, or will be soon in the next few months. Java is free and can never be locked up again. We should never forget the importance of having an open platform.So clearly there is huge value in the Java, but we still have the disadvantages I spoke of. So what do we do. How do we grow the platform beyond programmers to designers without giving up the value we already have. How do we fix it?

We Fix It!

15

We simply fix it. We fix everything. We tackle every single issue I've just mentioned. From deployment to designer tools, we fix it. So let me show you.

Improve User Experience

JavaSE 6 update 10

16

Java SE 6 is the most recent version of Java. We've had a variety of updates that have fixed bugs, but they didn't really add anything new. That's changing. JavaSE 6 update 10 is in public beta now and the final version will be released soon. We are tackling all of the deployment and performance problems head on with this release.

Installation

New Windows installer

Linux distro bundling

Working with Apple

Deployment toolkit

17

Installation * new installerThe new installer is simpler and faster. Fewer buttons. Less scary. That's for windows * Linux package installs. We are working closely with linux distro vendors to get Java included right in the repos, so that the installer becomes a non-issue. We're also working with Apple to improve the MacOSX support. They just released their first version of Java 6 in May and we working closely with them get the next version ready. * deployment toolkit. No longer do you have to write complex browser specific javascript to detect which version of Java is available. Now you can call our simple javascript library, hosted on java.com, do accurately detect the version of Java installed, kick off the right installer if the version you need isn't there, and then generate the applet tag. It's that simple. We are also working on some commandline tools to create the same experience for CD based installers.

New Browser Pluginrewritten from scratch

out of process JVM

more shared code between platforms

javascript works

draggable applets

crossdomain.xml support for mashups

18

* new Java plugin: This is *huge*. I can't overstate this. The number one user experience problem we’ve had has been with applets. They are slow. They lock up the browser when they load for the first time. They crash. The browser and javascript integration doesn’t work well.

Well.. no more. We didn’t just fix bugs. We've rewritten the applet browser plugin from the ground up to be faster, more reliable, and virtually crash proof. Java will now be run out of process so it's almost impossible to crash the browser, even if you 'kill -9' the JVM process the browser will be fine. There’s much less native code to maintain. More shared code between browser and platform versions. The Java to Javascript bridge finally works consistently so that you can have applets which interact with web page it’s embedded in.

It also lets us do a really cool trick: drag a running applet right out of the browser onto your desktop and then close the browser. That's a feature that we pretty much get for free with the new plugin. This really is a game changer. and I’ll have a demonstration of that for you later.

* crossdomain.xml. I hate to speed through this because it really is so important, but we are short on time. We have added crossdomain.xml support to the Applet security model. Now applets can use the same webservices as Flash and Silverlight applications with the same security restrictions. For example, I could create a cool photo viewer app which will be hosted on my server, connect to Flickr to get photos, and then be embedded in my niece’s MySpace homepage. And it will be safe and secure. No warning dialogs. No risk of viruses or downloads. Support for crossdomain.xml files lets us create mashups with the flexibilty of Javascript and the richness of the Java platform.

Speed & Modularity

Graphics hardware acceleration ... by default!

Quickstarter

Java Kernel

Modular JRE in Java 7

19

* HW graphics acceleration. We are fixing a bunch of bugs in the accelerated DirectX and OpenGL graphics pipelines and getting it turned on by default. This will speed up Java's graphics performance tremendously. * Quick starter: on Windows there will be a quick starter daemon which will preload a good portion of Java into the disk cache. This means the first time you see an applet in the webbrowser we won't have to load up and initialize several megabytes of rt.jar. It will already be there. But since it's in the disk cache Windows will still swap it out if necessary when it needs more memory. * Java kernel. The kernel downloader will let you incrementally download just the portions of the JRE that are needed. The rest of the JRE will be downloaded in the background so that you eventually have all of the pieces. This should cut the average JRE download in half. * Modular JRE. Java 7 will have modules support in the language which will help manage dependencies between different libraries, and different parts of the JRE itself. With this infrastructure in place we can finally begin to modularize the JRE. Over time the JRE will get smaller, faster, and more efficient. All good things for consumers and the enterprise desktop.

Media, Graphics, & Effects

Video, not JMF

Shaped and Translucent windows

Pixel Shader effects

20

Graphics, Media, and Effects:

We have great support for image formats, but what about rich media like video? This is something you guys have been asking for for years. Well, now we have it. At JavaOne we announced a partnership with On2 to create a 100% cross platform video solution for low and hi-def video. Additionally we have hooks for native codecs, so you will be able to write Java programs that leverage whatever codecs are installed on your user's computer. On Windows this will be the windows media apis. On Mac it will be core video. The Linux world is a bit more chaotic, but we are working on that too. So finally we will have great video support in Java.

Java SE 6 update 10 also adds shaped and transparent window support. No longer will you have to make custom native calls or hack it with screenshots. This is the real thing built in.

With the hardware accleration turned on we can now start to build libraries that use pixel shaders to accelerate certain graphics features. There is an experimental project on Java.net called Scenario, the scenegraph project. It's part of the infrastructure that supports JavaFX, which I will talk about in a second. Part of Scenario is a new library called Decora which can create pixel shader effects in a cross platform way and then compile them down to hardware specific implementations. If you don’t know what pixel shaders are, they are this microprograms which are uploaded into your graphics card to do certain things really really fast. This will let us do things like bloom effects, drop shadows, full screen gaussian blurs, and all of the other effects we see in libraries like Apple’s Core Image; all executed directly on the GPU. And this is just the beginning. With the way GPUs are going we will be able to do more amazing things in the future, even on mobile devices.

What’s Next?

21

So that's the improvements to the Java platform. It fixes the consumer experience problems, but it doesn't address designers. Just because we have a platform which can do the things that designers need doesn't mean it's easy for them to actually do it. We need a designer friendly API and language.

JavaFXDesigner Platform

22

I won’t say it’s just for designers, because it makes developers far more productive too. And it’s still the early days with alpha code and, let’s face it, developers are more tolerant of alpha stuff than designers. But this will give you an idea of where we are going.

JavaFX Scriptvar x = 0.0;var rect = Rectangle { x: bind x y: bind x fill: Color.BLUE};var anim = Timeline { keyFrames: [ KeyFrame {time: 0s values: x=>5 }, KeyFrame {time: 0s values: rect.fill=>Color.GREEN}, KeyFrame {time: 0.5s values: x=>200, radius=>50 tween EASEIN }, KeyFrame {time: 1s action: function () { System.out.println("time is now"); }} repeatCount: Timeline.INDEFINITE ]}anim.start();

23

New language: JavaFX ScriptThe first thing we've done is create a new language specificially designed for user interfaces. It has binding and animation built into the language itself. It even has time as a core data type. The language is statically typed and compiles directly to JVM bytecode, but it has modern language features like properties, closures, sequences, and variable binding. I can create a user interface in code that is typically half or less the length of equivalent Java code. Here's an example:

[show json style init, binding, animation, simple graphics primitives, and closures, and variable interpolation]

We've designed the language to look familiar to people who know Javascript, HTML, and CSS, but it still lets you call directly to Java code, so you can use all of your existing libraries if you want. It has a nice mixture of declarative structure like HTML, and the procedural code from typical programming languages.

I'm not going to go to in depth with the JavaFX Script language, but if you are interested I can talk about all of the cool features in the Q&A or after my session.

New GUI APIsJFrame f = new JFrame();if(com.awt.sun.util.AWTUtilities.isTranslucentySupported()) { com.awt.sun.util.AWTUtilities.setTranslucency(true);}frame.setUndecorated(true);JPanel panel = new JPanel() { protected void paintComponent(Graphics g) { Graphics2D gfx = (Graphics2D)g.create(); gfx.setRenderingHints(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIASING_ON): gfx.setColor(Color.RED); gfx.drawOval(0,0,100,100); gfx.dispose(); }}frame.getRootPane().setcontent(panel);frame.setVisible(true);

24

Remember how I said that the GUI APIs for Java are confusing because there's so many of them? Even if we had a new version of the Java language with properties and closures built in we still would have this old API that wasn't designed with the new features in mind. Our answer was to create a new API that is consistent, coherent, and cross platform. Let me show you an example. Here's how I would make a shaped window today in Java.

JavaFX code

Frame { stage: Stage { content: Circle { centerX: 50 centerY: 50 radius: 50 fill: Color.RED } fill: null // turn off the background }}

25

Now here it is in JavaFX Script:Notice how both the frame's stage and the circle class use the same name for the background: fill. And if you want to get rid of the window's background you just set fill to null. It's consistent and easy. *that's* the value of creating a new API.

Cross Screen

Single API set for all devices and platforms

Single set of developer tools

Profiles for device specific functionality

26

And most importantly JavaFX is cross platform and cross device, or what we call Cross Screen. No longer will you have one way to doing applets and one way for desktop apps. The PC and mobile APIs won't be different. We will have a single API that works everywhere and is easy to understand. Now of course there are some API features which are specific to certain screens. For example Swing components aren't on phones, and most desktops won't have a location API or accelerometer. For those cases we have profiles. But rather than being entirely separate it's simply a set of classes which are marked as being in that profile. Everything is built together and consistent. But how do you learn about the API? How do you know what's in each profile?

Old Documentation: 1995

27

If you've used Java before you've probably seen this. Javadocs were great in 1995, but today.. Well, lets just say they are less than great.. Here's Javadocs from Java 1.2 in 1997.

Old Documentation: 2000

28

Old Documentation: 2008

29

Now here it is in the latest JDK 7 beta. Hmm. Not much has changed.

Well, we are changing things now. In JavaFX we rewrote the javadoc tool from scratch to let us generate modern documentation using strict valid XHTML and semantic markup. We use CSS and Javascript to style everything and give us usability improvements. Here's what it looks like.

Modern Documentation

30

Now this is just our first version. We are still trying out new ideas and polishing it, but this will give you an idea of where we are going. We wanted something totally different. No more frames. Thanks to the great MooTools Javascript library, the sidebar on the left will expand and collapse to see each package. To switch profiles you just click on the button in the upper right to choose common or all. Then the classes which aren’t in the profile will simply hide themselves. Soon will will have an official desktop profile and when the mobile SDK is released we will add the mobile APIs. And there may be more profiles in the future as JavaFX expands to new environments. But you'll still be able to have just a single set of Javadocs and always know if a given class or function you want is supported on your target profile by using the profile switcher. We are planning ahead by making documentation that will scale in the future.

What about tools?

new language

new runtime

new documenation

new profiles

new tools....?

31

So that's the JavaFX platform.It has a new language, new runtime, new documentation. But by themselves, these things aren't going to make a platform for designers. Designers...

Designer Friendly Tools

32

...need tools. Designer friendly tools. So let’s see what we have.

The Futz Factor

33

NetBeans & The “Futz Factor” First we have started with a tool for the graphics savvy developer. It's a new plugin for NetBeans which does all of the things you expect from a NetBeans language plugin. It supports code completion, syntax highlighting, building and debugging your code. Pretty standard stuff. But it also has a preview mode that lets you interactively build up your user interface. Each time you type a character NetBeans will recompile the code and show you a live preview. This is lets you do something that I call: The Futz Factor. You can build something quick and then futz with everything. Change colors. Move text over by a few pixels. Adjust the drop shadows. All of the things that make a blah UI into a great UI. With a traditional IDE the compile/run cycle is just too long to make this a good experience. With the preview mode I can keep futzing with things until they look pixel perfect.

Designer Workflow

34So there we have it. A new netbeans plugin. Everything a budding designer needs to get started, right? Right? Just a NetBeans plugin. Hmm. Okay perhaps not. Most designers don't use IDEs. They create their interfaces in drawing tools. In particular, they use Photoshop and Illustrator, the world standard drawing programs. When we started the JavaFX initiative we seriously considered writing our own designer tools to compete with Photoshop and Illustrator, just as Microsoft is doing. But we realized that, well, that would be stupid. Even if we created a new program that was just as good as Adobe's tools, the ones they've been perfecting and polishing for 20 years, all we would have is a program that was just as good. It would be an incredible expense and take a long time, for very little gain, and still most designers would stick with their Adobe tools because that's what they like. There's got to be a better way. Well, there is. Why don't we just let designers keep using the tools they already love?!

Project Nile

Photoshop and Illustrator plugins

FXD File Format

FXD Viewer

SVG Converter

Designer / Developer Collaboration

35

So that brings us to Project Nile. It’s which a set of plugins for Photoshop and Illustrator though we have more planned for the future. (Nile is just a codename. Final name will come later after the trademark guys get ahold of it.) These plugins let you do all of your drawing in Photoshop or Illustrator and then export to an FXD file, which is a compact binary format that contains not only the vector artwork but also references to the structure of the Illustrator file.

Photoshop Plugin

36

In the case of Photoshop the layers will be exported as PNGs and the FXD file will contain the structure of the layers.

FXD Viewer

37

This FXD file can be viewed separately with the viewer app, like you see here, or, more importantly, referenced from JavaFX Script code.

Within JavaFX Script

38

Because the structure of the document is preserved a designer can draw all of the graphics in Photoshop and then hand it to a developer who will add behavior using simple scripts or prefab code that references the objects in the graphics file. The graphics are always kept separate from the code, so when the designer updates the graphics you can just export again and the code will still work. The export plugins will generate JavaFX Script stub code which will load up the images and FXD file. Once generated, however, you can modify the code to your hearts content.

The designer can name a photoshop layer ‘foo’ and then the developer can reference the ‘foo’ layer from code and add behavior, animation, or events. This creates a wonderful back and forth collaboration between the developer and designer. And it means that designers can build a mostly working program entirely within their drawing tool and then add simple bits of behavior with just a little bit of programming knowledge.

Plugins

Photoshop and Illustrator CS3 supported today

SVGConverter supported today for other tools

more coming soon

39

Generated Codepublic class JavaFXInvadersUI extends UiStub { public attribute background: Group; public attribute clouds: Group; public attribute enemies: Group[];.... protected function update() { background=getGroup("background"); clouds=getGroup("clouds"); enemies=[getGroup("enemies_0_"),getGroup("enemies_1_")];.... } public static function getURL() : String { return "{__DIR__}JavaFXInvaders.fxd"; }}

40

Designer + Developer!

41

This really changes things. Now designers and developers can work together productively without the programmer reimplementing the work of the designer, often badly, and without giving up the tools that they each know and love. They can work together instead of against each other. This is exciting. This makes better software.

When can you get it?!JavaSE 6 update 10: end of Summer

https://jdk6.dev.java.net/6u10ea.html

JavaFX SDK preview July 31st

javafx.com

openjfx.java.sun.com

Desktop SDK 1.0: this fall, Mobile SDK in 2009

42

Now some demos. Before I get to them let me show you where you can get this stuff.

So what’s what we are doing to expand the platform. So when will this stuff be available? JavaSE 6 update 10 will go final at the end of this summer or early fall, depending on how many last minute bugs we find. This release will cover Windows, Solaris, and Linux and you can get it at the URL I’ve listed here. I don't have a timeframe for a new release for Mac OSX but we are working very closely with Apple to get a lot of the update 10 improvements into their next release. We are scheduled to ship the first public preview release of the JavaFX SDK on July 31st. Which is only a week from now. In fact I think I may have a few more bugs to fix after my session here, so I’ll have to wrap this up soon. :) JavaFX.com will have the links to download the release along with docs, tutorials, samples, and the new tools. Not all features will be available on all platforms in this release, but it can do quite a lot already. We plan to have several more releases in the following months and we are shooting for a final 1.0 release of the desktop SDK in the fall. You can also get public daily builds at openjfx.java.sun.com. These public builds don't include everything that will be in the SDK, and of course they are very alpha and can break every other day with apis changing, but if you really want to be on the cutting edge this is where to go.

The final release of 1.0 for desktop will be this fall and mobile will be in 2009.

Summary and Demos

Shift from developer to designer driven software

Expanding the Java platform

Improving the consumer experience

JavaFX with Designer & Developer tools

Built on the 100% Open Source Java platform

43

Shift from developer to designer driven applications.We are shifting. This is the way the world is going. I'm very excited about it, even though I'm a developer and not a designer, because I want better looking and easier to use software. This is a great development and is going to keep getting better.

The Java platform is adaptingRemember, the Java platform isn't just Java the language. It's the JVM and the ecosystem of Java code and libraries out there. Java is just one of many languages on the platform, each with their own uses. We have Ruby, Python, Javascript, Groovy, and now JavaFX Script. All languages that have first class support on the JVM, and first class support in NetBeans.

The consumer experience is improvingWith the new applet plugin, new deployment tools, and new graphics features it we can create very rich applications.

With JavaFX and the new tools we have a great designer / developer workflow.

And most importantly, it's all built on the 100% open source Java platform.

Demo Time & Q&APhotoFlockr

Magnifying Glass & Widgets

JavaFX Docs

Indus & Photoshop

joshua.marinacci@sun.com

http://weblogs.java.net/blog/joshy/

44

So now that I've told you where the platform is going and what we are doing. Let's see it in action and then have a few questions.

Flickr FlockrThis is one of the apps we built for JavaOne using JavaFX. It connects live to Flickr to find pictures that match the tag you type in. This app was designed by our lead designer and then coded by an engineer. It doesn't just show the photos but the actually groups them together and moves them using a flocking algorithm. To do it properly requires, I believe an order N^5 algorithm, so the speed of the JVM becomes very important here.

Mag GlassHere is a simple draggable applet. It's a magnifying glass that I don't have to install. I just go to the webpage and drag it out. Then I can magnify anything on my desktop. I can even quit the browser and it keeps running.

Indus:Photoshop export. Open in NB. Add behavior. Run it.