Java In and Out Parameter Passing

The Zepton programming language implicit uses a core language class Zepton.java to provide auto-magically to software developers. My original goal was to implement a method readln() that takes various primitives--Boolean, Integer, Long, Double, Float, String, char--and return the value read on a line into the parameter variable.

But a glitch--the way Java handles parameters. Primitives, even the object wrappers (from int to Integer, double to Double, etc.) are passed as parameter for output, not for input and output.

In doing some more research, I found that in the Java Language Specification, Java uses a simple parameter passing method called “pass by value.”

The Java Language Specification (Section 4.3) declares that the passing of all datum, both object and primitive data, is defined by the following rule: “All data is passed by value.”

For a primitive--int, Boolean, Integer, Double, is passed by value--the value of the primitive. For an object like ArrayList, HashMap, int[] (yes, arrays are an object, even arrays of primitives), the reference--the address to the pointer, is passed by value--the address of the object in memory.

So a general-purpose readln (or readLine) method that takes an object and can return a value through the parameter is...difficult to implement, and would require some “extensions” to Java. I have done so with a programming language I created--Boz that was transcompiled to both Java and C#.

A great online article  “Passing by Value vs. Passing by Reference in Java” by Justin Albano examines these issues.

But, Zepton is designed to only add “prog” or a program structure to the Java language, not modify or extend it into a new programming language. The strength (and in this case a weakness) is to be fully syntax and conceptually compatible with Java.

A Zepton developer moving to Java will experience a cognitive shock--or cognitive dissonance if the readln() method takes a parameter and returns it as output--vanilla Java does not--so a “bump” in the conceptual road.

Thus Zepton must be compatible, no surprises. The core language class Zepton.java will use the same method signatures from Runtime.java, System.java, PrintStream.java, and DataInputStream.java.

For input and output the methods in Zepton are:

class Zepton {

  public static printf(Locale, String, Object...);

  public static println(String);

  public static println(Integer);
  public static println(int);

  public static println(Double);
  public static println(double);

  //...println methods for the various primitives and object wrappers

  //...read line methods for various primities and object wrappers
  public static String readLine();
  public static int readInt();
  public static double readDouble();
  public static boolean readBoolean();

  //...other methods used by Runtime, System
  public static void gc();

  public static void exit(int);

}//end class Zepton

As a software developer, compiler writer, programming language designer, I want to add and improve methods. For example I want to modify the gc() method to return a long--the amount of bytes of memory after running garbage collection on the Java runtime environment.

But Zepton is about Java likeness...so modifying a commonly used method like gc() would create cognitive dissonance.

One possibility is to rename and create a method that does the garbage collection with the feature of returning the long amount of bytes of memory recovered--but then when a user moves to Java, well “shiver my timbers” the equivalent method in Java doesn’t have that feature.

Thus Zepton is so simple--Java compatible, adding the program construct, removing features (a program does not have a constructor or destructor...) but remaining conceptually and syntactically similar to Java. The core language Zepton.java simply is the intersection of methods and constants from the various classes in Java for the Zepton programming environment.

So the Zepton program:

package zepton.demo;

prog helloWorld {
do

  println(“Hello world!!!%n”);

  exit(0);

}//end prog helloWorld

If the same program used the Java environment explicitly:

package zepton.demo;

import java.lang.Runtime; //or import java.lang.*; which is implicitly included
import java.lang.System;

prog helloWorld {
do

  System.out.println(“Hello world!!!%n”);

  Runtime.getRuntime().exit(0); //or System.exit(0);

}//end prog helloWorld

But, Zepton is meant for learning to program in the Java environment, or for quick programming...so all the explicit overhead is overwhelming and overloading.

Thus keep it simple...silly, and for parameter passing, extending or adding methods that are enhanced...keep it simple...so this too shall pass...and not as a parameter.