Classes
Java, like Xojo, is very OOP oriented and classes form the backbone of that OO orientation.
Bot java and Xojo share a lot of characteristics in how this works.
Both only support single inheritance - a class cannot inherit from two parents like in C++.
Both support Interfaces and use them in very similar ways.
The biggest differences are :
-
in java classes can be arranged into packages and easily used & imported. Xojo name spaces are about as close as you get but they cant be external if they contain deep hierarchies of modules & classes which makes them harder to manage
-
in java you can probably find an add on package or classes for just about anything. They range from tiny ones to entire much larger ones like Jasper Reports, and to full blown IDE’s. You name it you can probably find it. Xojo’s biggest add ons come in the form of plugins from a small set of plugin authors.
In Java the main program is a class. In Xojo its an instance of a particular class ( Application ConsoleApplication WebApplication) Its a subtle difference but its there.
When Jave starts your app it finds that main class, creates an instance of it and calls its main entry point ( named main !) So eve hello world is a class
class HelloWorld {
public static void main(String[] args)
{
System.out.println("Hello World" ) ;
}
}
One thing to be aware of is that in Java, because it IS case sensitive, that there can be types that are all lower case (something like double and Double)
Usually the lower case one is an intrinsic, like Xojo’s built in intrinsic types, and the Upper case one is a CLASS based version that can hold the value OR be null. This is a Nullable Type -m and there are many in Java by default.
Nullable types are handy in places - for instance you can tell if ANY value has been assigned and not have to rely on some other flag variable or sentinel value.
In Xojo, you really cant tell because simply defining a variable of type double sets it to one of the legal values - 0. (same for integers, booleans, and so on)
This can lead to trouble since, if you want to permit the use the entire range of values, there is NO value in their range you can use that tells you no value was ever assigned.
So you need some kind of mechanism to track when a value is assigned that sets a boolean saying that a value has been assigned
With nullable types you can just check if the variable is null or not.
This has a price though. You can end up with confusing code situations like
double a = 1.0;
double b = 1.0;
Double c = 1.0;
Double d = 1.0;
System.out.println(a == b); // true
System.out.println(c == d); // false
But whats going on here ?
double a = 1.0;
double b = 1.0;
defines to primitve, intrinsic, doubles and assigns values. So when you get to
System.out.println(a == b); // true
what is being compared is their CONTENTS ( 1.0 to 1.0 which is equal)
In the following code we create two instances of the Double CLASS, each holding a value of 1.0
Double c = 1.0;
Double d = 1.0;
And when we get to
System.out.println(c == d); // false
we’re still comparing CONTENTS but in this cases the contents are two references to instances.
For comparison in Xojo if we did something like
var d1 as new Folderitem
var d2 as new Folderitem
if d1 = d2 then
break
end if
In Xojo the = between the folderitems compares REFERENCES, same as in Java, not the CONTENTS
Java forces you to think more about whether you used double vs Double only because they have many of these nullable types with names that are the same.
Other than that classes are very similar.
You can write the code that says you class inherits from another as follows
class Classes {
static class Vehicle {
protected String brand = "Ford"; // Vehicle attribute
public void honk() { // Vehicle method
System.out.println("Tuut, tuut!");
}
}
static class Car extends Vehicle {
private String modelName = "Mustang"; // Car attribute
}
public static void main(String[] args)
{
// Create a myCar object
Car myCar = new Car();
// Call the honk() method (from the Vehicle class) on the myCar object
myCar.honk();
// Display the value of the brand attribute (from the Vehicle class) and the value of the modelName from the Car class
System.out.println(myCar.brand + " " + myCar.modelName);
}
}
Car extends Vehicle is how Java writes that Car inherits from Vehicle.
Car is a subclass of Vehicle.
We declare one and create one using very familiar syntax (except the ; at the end of line but then in Java you dont need _ to make a line span multiple lines 
)
So far most of our examples have been really simple.
A single class all in one file.
But thats not _usually- how java code is organized.
Usually you would split each class and probably even subclasses, into separate files.
For our example above that might be organized like
Classes.Java
class Classes {
public static void main(String[] args)
{
// Create a myCar object
Car myCar = new Car();
// Call the honk() method (from the Vehicle class) on the myCar object
myCar.honk();
// Display the value of the brand attribute (from the Vehicle class) and the value of the modelName from the Car class
System.out.println(myCar.brand + " " + myCar.modelName);
}
}
Vehicle.java
class Vehicle {
protected String brand = "Ford"; // Vehicle attribute
public void honk() { // Vehicle method
System.out.println("Tuut, tuut!");
}
}
Car.java
class Car extends Vehicle {
private String modelName = "Mustang"; // Car attribute
}
but , when you compile (using something like javac *.java) you fget a warning that did not appear before
But it is one that makes sense
Classes.java:14: error: modelName has private access in Car
System.out.println(myCar.brand + " " + myCar.modelName);
^
1 error
This error makes perfect sense. Brand and modelName are not publicly accessible and so, like in Xojo, you need to care about what scope you assign ( we didnt earlier when it was all in one file for kind of special reasons that I really dont think I want to try & explain as “normal” java code organization makes those rules kind of not important)
If we expose those both by making them public then everything works as expected.
Public, private and protected act almost exactly the same as you’re used to in Xojo
With one exception. Since java has a notion of “packages”, which is a lot like a Xojo module with contents that are other modules & classes, its protected can make things only accessible within the package. Xojo really doesnt have a scope level like that.
Next time we’ll write more code since we have covered most of the basics and moving actual code will be more instructive.