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.

The Zepton Class for Core Functionality

For the Zepton programming language, I am trying to develop a "core" class of functionality that is static attributes an methods that are implicitly included with a static import into the generated Java code for a Zepton program. This core class is Zepton.java, and will be a nexus of input, output, utility, and other functionality that is available in multiple Java classes--but is implicit for a Zepton program.

More specifically with an example:

package zepton.demo;

prog helloWorldUserName {
do
  println("Hello World!!!");
  println();

  print("What is your name?->");
  String userName = readln();
  printf("Hello: %s %n", userName);

  exit(0);
}

When transcompiled into Java code the result is the Java class:

package zepton.demo;

import static zepton.lang.Zepton;

public final class helloWorldUserName extends Object {

  private helloWorldUserName(){}

  public final static void main(final String[] args){

    println("Hello World!!!");
    println();

    print("What is your name?->");
    String userName = readln();
    printf("Hello: %s %n", userName);

    exit(0);
  }

}

Users learning to program on the Java platform using Zepton do not need to focus on peripheral details that a full Java class will entail, nor need focus on the details of such classes as java.lang.Runtime, java.lang.System, etc. The implicit static import is "auto-magically" generated by the transcompiler.

So, the problem and issues are around the "core" Zepton class with the implicit functionality. But in writing the core functionality, I'm running into some issues with the Java programming language--going back to the fundamentals has revealed some fundamental glitches or design flaws in Java.

The strength of the Zepton programming language is it is an extension of Java, with a program structure and concept. But this is also the weakness...adding a cool new feature is possible, but it will be Zepton-centric and the user will have to "unlearn" this feature...and the two groups of users are learning Java but don't want to drown in the Java vastness, and a user that wants a quick-and-dirty program without all the Java trimmings and accoutrements.

So for the core Zepton.java class, I am avoiding extending Java with Zeptonic-only features, but still want the core Zepton feature class--competing requirements for something so foundational--more on this as I codify.

Introducing the Zepton Programming Language

The Zepton programming language is a Java syntax compatible programming language that has only a “program” construct. Zepton is from “zepto” the smallest measurable interval of time, so small, and the letter “N” for the Nth programming language--”zepto” + “N” or “Zepton” programming language.

Zepton is designed with only one new keyword: “prog” for a program. Java is object-oriented centric, which means everything is a class and that a class has to offer.

While Java is a very popular programming language, and is used to teach programming and software development, it has become a gargantuan programming language with the many features.

Zepton is intended for learning the syntax, statements, and concepts of Java--while being able to use all existing Java classes, libraries, packages, and frameworks. Also Zepton is useful for quick and dirty programming--without having to create an entire class.

The required, classic example is in Zepton:

package zepton.demo;

prog helloWorld {
do
  println(“Hello World!!!”);
  exit(0);
}

The equivalent Java verbose class is:

package zepton.demo;

import static java.lang.System;

public final class helloWorld extends Object {

  private helloWorld(){}

  public final static void main(final String[] args){
    out.println(“Hello World!!!”);
    exit(0);
  }
}

Zepton allows a program to be written to implement functionality, but without the need for object-oriented features of code re-use. But Java code can be re-used in a Zepton program.

Zepton is not “Yet Another Programming Language” (YAPL) but a conceptual extension of the Java programming language--which has class, thread, enum, now outside an outside programming language that builds on Java with the program concept.