Copy Link
Add to Bookmark
Report

Java Newsletter by Glen McCluskey - Issue 7

eZine's profile picture
Published in 
Java Newsletter
 · 2 years ago

Issue #007
July, 1996

Contents

  • Invoking Subprograms in Java
  • Comparing C/C++ to Java Part 7 - Destructors vs. Finalize
  • Free Java Library
  • Enums and Java
  • Introduction to Applet Programming Part 3 - Events

INVOKING SUBPROGRAMS IN JAVA

It's often the case that when writing programs, you'd like to invoke another program from within the first and send it input and get output from it. How might this be done in Java? A simple example that runs the UNIX program "ls" to retrieve a listing of files in the current directory looks like this:

        import java.io.*; 

public class test1 {

public static void main(String args[])
{
try {
Process cp = Runtime.getRuntime().exec("ls");
DataInputStream d =
new DataInputStream(cp.getInputStream());
String line = null;
while ((line = d.readLine()) != null)
System.out.println(line);
}
catch (Throwable e) {
}
}

}


The call to exec() starts the process running, and returns a Process object. Then we query the Process object to get a buffered input stream that is connected to the output of the child process. We then can simply iterate over this stream, reading lines in turn, that are the output of ls. In a similar way, it's possible to send input to the child process or capture its error output.

The Process class has several additional methods available for controlling processes:

        waitFor()       wait for the child process to complete 

exitValue() return the exit value for the process

destroy() kill the process


There is also a variant of exec() that supports passing of environment variables to the child process.


COMPARING C/C++ TO JAVA PART 7 - DESTRUCTORS VS. FINALIZE

In C++ there is the notion of a destructor, a function called when a class object instance goes out of scope. For example:

        class A { 
public:
A();
~A();
};

void f()
{
A a;
}


When the function f() is entered, the constructor A::A() is called for the local object a, and when f() is exited, the destructor A::~A() is called in turn.

Java class objects do not behave in a similar way. They are dynamically allocated, at which point a constructor is run on the object instance, and later garbage collected.

Java does not have any notion of a destructor method that is run when an object instance is no longer valid. But it does have a finalize() method:

        protected void finalize() {}


that can be added to any class. finalize() is called for an object instance after that instance has been identified by the garbage collector as no longer a valid object, that is, there are no remaining references to it. For example:

        public class test1 { 

public test1()
{
System.out.println("call ctor");
}

protected void finalize()
{
System.err.println("call finalize");
}

public static void f()
{
test1 p = new test1();
}

public static void main(String args[])
{
f();
System.gc();
System.runFinalization();
}
}


After the return from the f() call, there is an object instance that can be garbage collected; there is no reference to the object we created while inside of f().

System.gc() frees up objects and marks them as pending for finalization to be done. Actual finalization processing proceeds asynchronously with the garbage collector, so to force finalization we can call System.runFinalization().

Because of the way that finalize() methods work, you should use caution in assuming that they can be used to reclaim valuable resources such as UNIX file descriptors. Also, you should insert a line like:

        super.finalize(); 


at the end of a finalize() method, to call the corresponding method of the superclass.

FREE JAVA LIBRARY


I have developed a Java library for managing collections of objects, such as lists, stacks, sets, bitmaps, and trees. If you are interested in this library, please see the Web page:

        http://rmi.net/~glenm/javalib/index.html


ENUMS AND JAVA

In C++ there is a facility known as enumerations or enumerated types that can be used to represent a set of integral values:

        enum Color {CO_R = 1, CO_G = 2, CO_B = 3};


After this declaration, Color can be used as a type (including for function overloading purposes), and values like CO_R can be used wherever integral constants would be used. Type checking is done, so that for example:

        Color c = CO_R; 

c = 37;


is invalid.

Java does not have enumerations. One way to simulate them is simply by defining constants in a class:

        public class Color { 
public static final byte CO_R = 1;
public static final byte CO_G = 2;
public static final byte CO_B = 3;
};


public means that these values are accessible to all, static means that they're shared across all object instances, final means that they're immutable once set, and byte means that they're represented in bytes in the virtual Java machine.

Once a class like this is set up, you can say things like:

        byte b = Color.CO_G;


But notice that this simulation is only a simulation. There's nothing to stop me from saying:

        byte b = Color.CO_R; 
b = 29;


and thereby introduce an invalid color value. A solution to this problem would be to define Color as a "real" class, that represents the actual current value of an enumeration:

        public class Color { 
private byte value = 0;
public static final byte CO_R = 1;
public static final byte CO_G = 2;
public static final byte CO_B = 3;
public Color(byte b)
{
if (b == CO_R || b == CO_G || b == CO_B)
value = b;
else
throw new IllegalArgumentException();
}
public byte getvalue()
{
return value;
}
}


This approach works, but can be cumbersome to use. However, enums, like other language features, add to the total complexity and implementation cost of a language, and leaving them out of Java is a reasonable design tradeoff to make.

INTRODUCTION TO APPLET PROGRAMMING PART 3 - EVENTS

In previous issues we've talked about the basic protocols underlying an applet and how graphical and text output is done. With this issue we'll start a discussion of input handling, and begin by talking about events just a little bit.

Here is an applet that allows a user to do free drawing with the mouse. That is, whenever the mouse button is held down and the mouse moved, a line will be drawn:

        import java.applet.*; 
import java.awt.*;

public class Draw extends Applet {

int prev_x = 0;
int prev_y = 0;
int color = 0;

public boolean mouseDown(Event e, int x, int y)
{
prev_x = x;
prev_y = y;
return true;
}

public boolean mouseDrag(Event e, int x, int y)
{
Graphics g = getGraphics();

switch (color) {
case 0:
g.setColor(Color.red);
break;
case 1:
g.setColor(Color.green);
break;
case 2:
g.setColor(Color.blue);
break;
}
if (++color > 2)
color = 0;

g.drawLine(prev_x, prev_y, x, y);
prev_x = x;
prev_y = y;
return true;
}
}


This applet can be invoked via the HTML code:

        <html> 
<head>
<title>Interface to Draw Applet</title>
</head>

<body>

<applet code="Draw.class" width=400 height=400></applet>

</body>
</html>


using the JDK AppletViewer program.

We've alternated the output color of the drawn line, as a means of tying together some of the ideas from the last issue, and to better illustrate what is happening.

mouseDown() is an applet method called by the system when the user presses a mouse button. It's passed a description of the event along with an X,Y pair, and returns true if it handled the event, so that the event will not be further processed. In our example we simply record the X,Y location where the event occurred.

mouseDrag() is a method called when the user drags the mouse with the button down. When this occurs, we switch colors and then draw a line between the old position and the new one. getGraphics() is a method that returns a java.awt.Graphics object, that is used for line drawing, image painting, and so on.

If you run the above applet, the colors will alternate very rapidly if you move the mouse slowly, and alternate more slowly if you move the mouse rapidly. Why is this? It has to do with polling of the mouse. That is, the mouse's status is checked at regular intervals. If the mouse has moved a long ways in the poll interval, then the single-color line segment will be longer than if the mouse had been moved slowly.

We will be discussing events and input further in upcoming issues.


ACKNOWLEDGEMENTS

Thanks to Thierry Ciot, Irv Kanode, Mike Paluka, and Alan Saldanha for help with proofreading.


SUBSCRIPTION INFORMATION / BACK ISSUES

To subscribe to the newsletter, send mail to majordomo@world.std.com with this line as its message body:

subscribe java_letter

Back issues are available via FTP from:

rmii.com /pub2/glenm/javalett

or on the Web at:

http://www.rmii.com/~glenm

There is also a C++ newsletter. To subscribe to it, say:

subscribe c_plus_plus

using the same majordomo@world.std.com address.

-------------------------

Copyright (c) 1996 Glen McCluskey. All Rights Reserved.

This newsletter may be further distributed provided that it is copied in its entirety, including the newsletter number at the top and the copyright and contact information at the bottom.

Glen McCluskey & Associates
Professional Computer Consulting
Internet: glenm@glenmccl.com
Phone: (800) 722-1613 or (970) 490-2462
Fax: (970) 490-2463
FTP: rmii.com /pub2/glenm/javalett (for back issues)
Web: http://www.rmii.com/~glenm

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT