Wednesday Jun 26, 2013

Diving into Scala with Cay Horstmann

A new interview with Java Champion Cay Horstmann, now up on otn/java, titled  "Diving into Scala: A Conversation with Java Champion Cay Horstmann," explores Horstmann's ideas about Scala as reflected in his much lauded new book,  Scala for the Impatient.  None other than Martin Odersky, the inventor of Scala, called it "a joy to read" and the "best introduction to Scala". Odersky was so enthused by the book that he asked Horstmann if the first section could be made available as a free download on the Typesafe Website, something Horstmann graciously assented to.

Horstmann acknowledges that some aspects of Scala are very complex, but he encourages developers to simply stay away from those parts of the language. He points to several ways Java developers can benefit from Scala:

"For example," he says, " you can write classes with less boilerplate, file and XML handling is more concise, and you can replace tedious loops over collections with more elegant constructs. Typically, programmers at this level report that they write about half the number of lines of code in Scala that they would in Java, and that's nothing to sneeze at. Another entry point can be if you want to use a Scala-based framework such as Akka or Play; you can use these with Java, but the Scala API is more enjoyable. "

Horstmann observes that developers can do fine with Scala without grasping the theory behind it. He argues that most of us learn best through examples and not through trying to comprehend abstract theories. He also believes that Scala is the most attractive choice for developers who want to move beyond Java and C++.  When asked about other choices, he comments:

"Clojure is pretty nice, but I found its Lisp syntax a bit off-putting, and it seems very focused on software transactional memory, which isn't all that useful to me. And it's not statically typed. I wanted to like Groovy, but it really bothers me that the semantics seems under-defined and in flux. And it's not statically typed. Yes, there is Groovy++, but that's in even sketchier shape.

There are a couple of contenders such as Kotlin and Ceylon, but so far they aren't real.

So, if you want to do work with a statically typed language on the JVM that exists today, Scala is simply the pragmatic choice. It's a good thing that it's such a nice choice."

Learn more about Scala by going to the interview here.

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