Monday Apr 16, 2012

Best Practices for JavaFX 2.0 Enterprise Applications

A new article, up on otn/java, by Java Champion, Oracle Java Evangelist, and JavaFX expert Jim Weaver, titled "Best Practices for JavaFX 2.0 Enterprise Applications (Part One),” explores best practices for developing enterprise applications in JavaFX 2.0.

Weaver illustrates his points by examining a sample application named TweetBrowser which contains the following:

* “A Toolbar containing a TextField and a couple of Button controls for searching and navigating tweets obtained from the Twitter REST API.
* A ListView whose cells contain representations of the tweets. Each tweet is represented by a subclass of ListCell that contains an ImageView for the profile picture and Hyperlink controls that enable the user to navigate to screen names, hashtags, and Web links.
* A ProgressIndicator that spins when a search is performed and a WebView that displays the Web page associated with a Web link in a tweet.”

The TweetBrowser project, which Weaver invites the reader to download, contains the code for the application, portions of which he highlights throughout the article. Techniques and best practices used in the TweetBrowser application include:

    “Invoking an application via Java Web Start from the application’s home page
    Ensuring only one instance of the application is started
    Binding the UI to the model”

Weaver concludes the article by observing that, “Implementing techniques such as invoking an application via Java Web Start from the application’s home page, ensuring only one instance of the application is started, and binding the UI to the model make life easier for both the user and the developer."

Please stay tuned for Part Two of this series where Jim will explore more techniques and best practices used in the TweetBrowser example application.

You'll find Part One here.

Tuesday Oct 18, 2011

Java Champion Michael Hüttermann on Best Agile ALM Practices

Michael HüttermannJavaOne 2011 - Java Champion and Agile ALM expert Michael Hüttermann gave a session, "Agile Application Lifecycle Management (18180)" on Tues., Oct. 4, designed to help Java developers integrate flexible agile practices and lightweight tools into software development phases. Hüttermann is the author of Agile ALM and CEO of Systemtechnologie Hüttermann. 

He covered:

* Task-based development for aligning activities with tasks, resulting in traceable artifacts

* Advanced continuous integration, which involves frequently and systematically integrating, building, and testing applications

* Agile approaches to release, configuration, deployment, and requirements management

* State-of-the-art-tool chains

The standard criticism of ALM is that it causes vendor lock-in, which increases the overall cost of an application, leaving developers with the challenge of balancing the pluses and minuses of Agile ALM. While Hüttermann admits that this has traditionally been true, his conception of Agile ALM results in flexible, high-quality processes and tool chains that are sufficiently open to change to avoid lock-in. By relying on lightweight tool chains, developers can improve flexibility because they can readily replace small units of the overall infrastructure without touching other parts. One of the main purposes of Agile ALM is to minimize accidental complexity.

Among the take-aways from the session:

* Continuous integration (CI) refers to the automation of the build, test, and release process with the goal of integrating the activities of colleagues and the work items others produce. This can result in a build ecosystem in which a new-code commit directly triggers a continuous build.

* Agile ALM defines task-based activities that are aligned with requirements, which means the activities are linked to requirements and all changes are traceable to their requirements.

* Agile ALM Tools are no longer cumbersome, monolithic vehicles that can restrict development. They need no longer cover all facets of the ALM ecosystem. Mashups of lightweight, focused, service-oriented, customizable tools are gaining momentum. Developers should feel free to switch from one tool to another.

Agile ALM aficionados should check out the forthcoming Java Magazine article by Hüttermann, set for publication in the November/December issue. If you haven't registered for the magazine, run, don't walk. It's free!

And be on the look out for a forthcoming otn/java interview with Hüttermann as well.

Finally, this JavaOne 2011 presentation can also be viewed @ http://parleys.com/d/2666.

Monday Oct 17, 2011

OpenJDK Development Best Practices

At JavaOne 2011, Oracle Principal Member of Technical Staff, Kelly O’Hair, had a session on “OpenJDK Development Best Practices” that offered a lot of useful practical advice. He discussed current OpenJDK development procedures such as building, testing, code review, and creating a changeset, and integrating that changeset into a team repository.  In addition he covered "OpenJDK Developers' Guide" topics and looked at the challenges of integrating a change.

So what are the best practices when working on the JDK?
● When in doubt, ask
● When something does not work, report it
● Always be careful, rushing in changes is dangerous
● Do no harm, have a backup or backout plan
● Stay calm, nervous people make mistakes
● Be prepared for anything, because it will happen

When editing sources:
● No TABS
● Never edit the legal notices
● Respect the existing formatting
● Small surgical changes are best, easiest to review
● Well written comments are critical
● Do not assume anything about the compilers

Testcases are critical and not optional:
● Create a new one or modify an existing testcase
● Must be solid and work on all supported systems
● Must not be a resource hog (open 20,000 files)
● Must work in a shared VM mode (like a JUnit test)
● Assume someone else might be running the same test at the same time, and that someone might be you
● Continuous Build & Test
● Test gates or baseline testing
● But before you even get started making changes you must be able to completely build it and test it on your own system, this is a fundamental
● Linux builds are the easiest, so let's see what needs to happen

He suggested best practices short cuts for building:
● Always use local disk space
● Use /tmp if it has the space
● Try export HOTSPOT_BUILD_JOBS=4
● Try export ALT_PARALLEL_COMPILE_JOBS=4
● Use export NO_DOCS=true to avoid running javadoc
● Use ALT_JDK_IMPORT_PATH=${HOME}/jdk1.8.0

Kelly offered detailed principles related to testing, testing prep, editing, code review, changeset creation, why a push fails, and the team repository model.

His core ideas:
● Pick your environment, Linux is easiest
● Pick a stable state of repos, promoted build, oldest best
● Learn to build and test it, over and over, know what to expect, create a jdk to use as your import
● Editing working set files, read the Mercurial book
● Problemlist, changeset creation

About

Insider News from the Java Team at Oracle!

duke
javeone logo
Links


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
5
6
7
12
13
17
18
19
20
22
24
25
26
27
28
29
30
   
       
Today