Home arrow Java arrow Page 3 - Understanding Deployment Frameworks

Understanding Deployment Frameworks

Java games can be deployed using various types of deployment frameworks. This article helps you understand the three different kinds of deployment frameworks, and shows you how to deploy your games to all three types without having to recompile your code. It is excerpted from chapter two of Advanced Java Game Programming, written by David Wallace Croft (Apress; ISBN: 1590591232).

Author Info:
By: Apress Publishing
Rating: 4 stars4 stars4 stars4 stars4 stars / 6
April 10, 2008
  1. · Understanding Deployment Frameworks
  2. · Managing the Applet Animation Thread
  3. · Reading from a JAR File
  4. · Upgrading Clients with the Plug-In

print this article

Understanding Deployment Frameworks - Reading from a JAR File
(Page 3 of 4 )


A Java archive (JAR) file is simply a compressed zip file containing all the code and multimedia files that you need for your game. It greatly reduces the amount of time that is required to launch your applet because players can download the game in a single HTTP request.

Before JAR files, one of the techniques developers used to reduce applet download times was to copy all the images to a single file. As shown in Figure 2-1, the individual smaller images would be located at different positions in the larger combined image in the form of a grid or a strip. Coordinate data and custom code was then used to cut out rectangles of image data from the different positions within the combined image once downloaded. Fortunately with JAR files today, such additional code is no longer necessary. You can access the individual images simply by opening them by their unique file names and directory paths relative to the archive root. If you have a sprite set that comes to you as a single image, you probably want to crop it into smaller images using an image editor before deployment. If for some reason you do need to crop smaller images from a larger image during run time, you can use the static methodcrop()in classImageLibof packagecom.croftsoft.core.awt.imagefor that purpose.

Figure 2-1.   Ari Feldman’s “1945” Sprite set. Artwork copyright 2002, 2003 by Ari Feldman.

Another pre-JAR complication Java applet developers used to have to deal with was writing code to delay using an image until it was completely downloaded. In the early days of the Web, Internet connections were so slow that browsers would display incomplete image data as it was downloading so users could get a sense of what was coming and decide whether it was worth the wait. Applet developers that did not want to use an image until it was entirely loaded used the classjava.awt.MediaTrackerto track the progress of the download. This was especially important as HTTP requests were less reliable back then and sometimes requests to download images would fail completely. If game programmers did not track this, game players would occasionally be frustrated by playing shoot-em-up against enemy sprites that had the unfair advantage of invisibility due to a bad Internet connection.

Fortunately the necessity to program all that tracking, stalling, and download request reattempt logic goes away when you simply include your multimedia files in the same JAR file as your code. When you take this approach, you know your game code is guaranteed to load your images reliably and quickly without needing to resort to special precautions. If by chance your images do fail to download successfully, you cannot do much about it, as your code probably did not download either because it was in the same package.

One of the catches to placing all your image and other resource files within a JAR file is that you need to access these files using the java.lang.ClassLoader getResource()method. TheClassLoader reference that you use for this purpose must come from a class that is in the same JAR file as the resource file you are trying to access. This is because classes loaded from different JAR files are assigned their own
ClassLoaders. The path and file name argument to thegetResource()method is then relative to the root of the JAR file that is associated with that instance of theClassLoader.

  URL  imageURL
    = getClass ( ).getClassLoader ( ).getResource ( imageFilename );

  Image  image = ImageIO.read ( imageURL );

Note that the object returned fromgetResource()is an instance of the classURLinstead ofFile. Here is another example that uses aURLto access the data:

  URL  bangAudioURL = getClass ( ).getClassLoader ()
    .getResource ( BANG_AUDIO_FILENAME );

  AudioClip  bangAudioClip = Applet.newAudioClip ( bangAudioURL );

Another trick to this is that your path and file name argument to thegetResource()method, although relative to the root of the JAR archive, must not be preceded by a leading forward slash (/) to indicate the root directory. For example,media/dodger/bang.wavwould work but/media/dodger/bang.wavwould not. This is different from using thegetResource()method to pull files from the hard drive outside of the JAR file.

blog comments powered by Disqus

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials