Archive for the ‘Java’ Category
Managing Multiple Build Environments
Last updated: 3 March, 2010
One of the challenges of Web development is managing multiple build environments. Most applications pass through several environments before they are released. These environments include: A local development environment, a shared development environment, a system integration environment, a user acceptance environment and a production environment.
Automated Builds
Automated builds provide a consistent method for building applications and are used to give other developers feedback about whether the code was successfully integrated or not. There are different types of builds: Continuous builds, Integration builds, Release builds and Patch builds.
A source control system is the main point of integration for source code. When your team works on separate parts of the code base, you have to ensure that your checked in code doesn’t break the Integration build. That’s why it is important that you run your unit tests locally before checking in code.
Here is a recommended process for checking code into source control:
- Get the latest code from source control before running your tests
- Verify that your local build is building and passing all the unit tests before checking in code
- Use hooks to run a build after a transaction has been committed
- If the Integration build fails, fix the issue because you are now blocking other developers from integrating their code
Hudson can help you automate these tasks. It’s extremely easy to install and can be configured entirely from a Web UI. Also, it can be extended via plug-ins and can execute Phing, Ant, Gant, NAnt and Maven build scripts.
Build File
We need to create a master build file that contains the actions we want to perform. This script should make it possible to build the entire project with a single command line.
First we need to separate the source from the generated files, so our source files will be in the “src” directory and all the generated files in the “build” directory. By default Ant uses build.xml as the name for a build file, this file is usually located in the project root directory.
Then, you have to define whatever environments you want:
project/
build/
files/
local/
development/
integration/
production/
packages/
development/
project-development-0.1-RC.noarch.rpm
integration/
production/
default.properties
local.properties
development.properties
production.properties
src/
application/
config/
controllers/
domain/
services/
views/
library/
public/
tests/
build.xml
Build files tend to contain the same actions:
- Delete the previous build directory
- Copy files
- Manage dependencies
- Run unit tests
- Generate HTML and XML reports
- Package files
The target element is used as a wrapper for a sequences of actions. A target has a name, so that it can be referenced from elsewhere, either externally from the command line or internally via the “depends” or “antcall” keyword. Here’s a basic build.xml example:
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="project" basedir="." default="main">
<target name="init"></target>
<target name="test"></target>
<target name="test-selenium"></target>
<target name="profile"></target>
<target name="clean"></target>
<target name="build" depends="init, test, profile, clean"></target>
<target name="package"></target>
</project>
The property element allows the declaration of properties which are like user-definable variables available for use within an Ant build file. Properties can be defined either inside the buildfile or in a standalone properties file. For example:
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="project" basedir="." default="main">
<property file="${basedir}/build/default.properties" />
<property file="${basedir}/build/${build.env}.properties" />
...
</project>
The core idea is using property files which name accords to the environment name. Then simply use the custom build-in property build.env. For better use you should also provide a file with default values. The following example intends to describe a typical Ant build file, of course, it can be easily modified to suit your personal needs.
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="project" basedir="." default="main">
<property file="${basedir}/build/default.properties" />
<condition property="build.env" value="${build.env}" else="local">
<isset property="build.env" />
</condition>
<property file="${basedir}/build/${build.env}.properties" />
<property environment="env" />
<condition property="env.BUILD_ID" value="${env.BUILD_ID}" else="">
<isset property="env.BUILD_ID" />
</condition>
<target name="init">
<echo message="Environment: ${build.env}"/>
<echo message="Hudson build ID: ${env.BUILD_ID}"/>
<echo message="Hudson build number: ${env.BUILD_NUMBER}"/>
<echo message="SVN revision: ${env.SVN_REVISION}"/>
<tstamp>
<format property="build.datetime" pattern="dd-MMM-yy HH:mm:ss"/>
</tstamp>
<echo message="Build started at ${build.datetime}"/>
</target>
<target name="test">
...
</target>
<target name="clean">
<delete dir="${build.dir}/files/${build.env}"/>
<delete dir="${build.dir}/packages/${build.env}"/>
<mkdir dir="${build.dir}/files/${build.env}"/>
<mkdir dir="${build.dir}/packages/${build.env}"/>
</target>
<target name="build" depends="init, test, profile, clean">
...
</target>
...
</project>
Using ant -Dname=value lets you define values for properties on the Ant command line. These properties can then be used within your build file as any normal property: ${name} will put in value.
$ ant build -Dbuild.env=development
There are different ways to target multiple environments. I hope I have covered enough of the basic functionality to get you started.
Java, C, Python and nested loops
Java has no goto statement, to break or continue multiple-nested loop or switch constructs, Java programmers place labels on loop and switch constructs, and then break out of or continue to the block named by the label. The following example shows how to use java break statement to terminate the labeled loop:
public class BreakLabel
{
public static void main(String[] args)
{
int[][] array = new int[][]{{1,2,3,4},{10,20,30,40}};
boolean found = false;
System.out.println("Searching 30 in two dimensional int array");
Outer:
for (int intOuter = 0; intOuter < array.length ; intOuter++) {
Inner:
for (int intInner = 0; intInner < array[intOuter].length; intInner++) {
if (array[intOuter][intInner] == 30) {
found = true;
break Outer;
}
}
}
if (found == true) {
System.out.println("30 found in the array");
} else {
System.out.println("30 not found in the array");
}
}
}
Use of labeled blocks in Java leads to considerable simplification in programming effort and a major reduction in maintenance.
On the other hand, the C continue statement can only continue the immediately enclosing block; to continue or exit outer blocks, programmers have traditionally either used auxiliary Boolean variables whose only purpose is to determine if the outer block is to be continued or exited; alternatively, programmers have misused the goto statement to exit out of nested blocks.
What’s interesting is that Python rejected the labeled break and continue proposal a while ago. And here’s why:
Guido van Rossum wrote:
I’m rejecting it on the basis that code so complicated to require this feature is very rare. While I’m sure there are some (rare) real cases where clarity of the code would suffer from a refactoring that makes it possible to use return, this is offset by two issues:
1. The complexity added to the language, permanently.
2. My expectation that the feature will be abused more than it will be used right, leading to a net decrease in code clarity (measured across all Python code written henceforth). Lazy programmers are everywhere, and before you know it you have an incredible mess on your hands of unintelligible code.
But what’s more interesting is that the idea of adding a goto statement was never mentioned. Common sense perhaps?
Is Groovy the next programming language in your toolbox?
Groovy offers the flexibility of PHP and the power and capabilities of Java. Groovy meets all the requirements: optional static typing, familiar syntax, runs on a VM, performs as well as Java and supports lots of hot buzzwords like closures and builders. If you are a PHP and/or Ruby developer, I’m sure you are going to love Groovy.
If you are interested in learning more about Groovy and Grails and what it has to offer to your developer toolbox, keep an eye on my blog for some groovy posts :)
10 reasons to switch from CruiseControl to Hudson
Ten things no one ever told you about Hudson:
- It’s extremely easy to install (unzip the file and that’s it)
- It can be configured entirely from its friendly Web UI (no XML required)
- It has an attractive dashboard with colourful and meaningful icons
- It’s extremely flexible
- It can be extended via plug-ins
- It offers a much better UI than CruiseControl
- It can execute Phing, Ant, Gant, NAnt and Maven build scripts
- It gives you clean readable URLs for most of its pages
- It has RSS, e-mail and IM integration
- It can distribute build/test loads to multiple computers
This tutorial guides you step-by-step through the fundamental concepts of Continuous Integration and Hudson. When you are done with this one-hour tutorial, you will understand the benefits of Continuous Integration as well as how to set up your environment.
Links
Get groovy for better shell scripts
Eric Wendelin wrote:
I often use shell scripts to automate mundane, repeatable tasks on my computer. Since I’ve found Groovy, though, I have discovered a great way to make writing those scripts easier and more enjoyable. This is especially true if I have anything complex to do, and it saves me a LOT of time.
I couldn’t agree more. Also, I’m quite impressed how easy is to operate on an XML document with Groovy.
Essential Java Resources
The Java platform will be celebrating its 14th birthday soon and one side-effect when a successful and ubiquitous language reaches this kind of milestone is the widespread proliferation of libraries, tools and ideas. In this article, Ted Neward tacks through the vast tides and presents a list of the key resources any up-and-coming Java developer should have.
Running Quercus in Jetty Web Server
Jetty Web server can be invoked and installed as a stand alone application server. It has a flexible component based architecture that allows it to be easily deployed and integrated in a diverse range of instances. The project is supported by a growing community and a team with a history of being responsive to innovations and changing requirements. More info here.
Installing Jetty
First you need to download Jetty. It’s distributed as a platform independent zip file containing source, javadocs and binaries. The most recent distro can be downloaded from Codehaus:
$ wget http://dist.codehaus.org/jetty/jetty-6.1.14/jetty-6.1.14.zip $ unzip jetty-6.1.14.zip $ cp -R jetty-6.1.14 /opt/ $ cd /opt $ ln -s /opt/jetty-6.1.14 jetty
Problems installing Jetty? More info here.
Running Jetty
Running jetty is as simple as going to your jetty installation directory and typing:
$ cd /opt/jetty $ java -jar start.jar etc/jetty.xml
This will start jetty and deploy a demo application available at:
http://localhost:8080/test
That’s it. Now stop Jetty with cntrl-c in the same terminal window as you started it.
Installing Quercus
Quercus is a complete implementation of the PHP language and libraries in Java. It gives both Java and PHP developers a fast, safe, and powerful alternative to the standard PHP interpreter. Quercus is available for download as a WAR file which can be easily deployed on Jetty:
$ wget -P ~/quercus http://quercus.caucho.com/download/quercus-3.2.1.war $ jar xf ~/quercus/quercus-3.2.1.war
Unpack the WAR file and copy all the jars to Jetty’s global library directory:
$ cp ~/quercus/WEB-INF/lib/* /opt/jetty/lib
Configuring Jetty
Edit the web.xml file:
$ vi /opt/jetty/webapps/test/WEB-INF/web.xml
Add the following between the web-app tags:
<servlet>
<servlet-name>Quercus Servlet</servlet-name>
<servlet-class>com.caucho.quercus.servlet.QuercusServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Quercus Servlet</servlet-name>
<url-pattern>*.php</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.php</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
Create a PHP file inside the test application:
$ cat /opt/jetty/webapps/test/index.php <?php phpinfo(); ?>
This file will be available at:
http://localhost:8080/index.php
It works! You are now ready to:
Instantiate objects by class name
<?php
$a = new Java("java.util.Date", 123);
print $a->time;
Import classes
<?php import java.util.Date; $a = new Date(123); print $a->time;
Call Java methods
<?php import java.util.Date; $a = new Date(123); print $a->getTime(); print $a->setTime(456); print $a->time; $a->time = 456;
And much, much more.
PHP implemented in 100% Java
Quercus allows developers to incorporate Java code into PHP web applications and gives both Java and PHP developers a fast, safe, and powerful alternative to the standard PHP interpreter.
Quercus natively supports Unicode and the new Unicode syntax of the up-and-coming PHP 6, and implements a growing list of PHP extensions (i.e. APC, iconv, GD, gettext, JSON, MySQL, Oracle, PDF, Postgres, etc.). Many popular PHP applications will run as well as, if not better, than the standard PHP interpreter straight out of the box.
Quercus PHP libraries are written entirely in Java, thereby taking the advantages of Java applications and infusing them into PHP.
Benefits
Although PHP users and Java users can take advantage of Quercus immediately without modifying their application, the real benefits come from developing mixed Java/PHP applications:
- PHP libraries written in Java are fast, safe, and relatively easy to develop, compared with C libraries. Since Java is the library language, developers won’t need to be paranoid about third-party libraries having C-memory problems or segvs.
- PHP applications can take advantage of Java libraries and capabilities like JMS, SOA frameworks, Hibernate, or Spring. (Or EJB if you really wanted.)
- Java application can move presentation code to PHP, leaving behind templating systems, or languages with small libraries, and taking advantage of PHP flexibility and capability.
Links
Programming Jobs: Dynamic and Static Languages
I’ve built large systems in dynamic and static languages. Neither is necessarily better or worse than the other in terms of maintainability, if you know what you are doing. Ted Neward said that at the end of the day, the whole static vs dynamic thing doesn’t matter. One should simply chose the languages that can:
1. Provide the ability to express the concept in your head, and
2. Provide the ability to evolve as the concepts in your head evolve
Programming Language Demand
With ITJobsWatch you can compare the frequency of job titles, companies, skills and industries in the UK employment market. The following charts provide the number of permanent jobs per language, based on job ads, across the UK over the last 3 months.
Timeline of Programming Languages
- 1983: C++
- 1987: Perl
- 1991: Python
- 1995: Java (highest demand)
- 1995: Javascript
- 1995: PHP
- 1995: Ruby (lowest demand)
- 2001: C#
Source ITJobsWatch.com


