As fate would have it, I have had the good fortune to have extensive experience with both C# and Java. While many articles will list things a programmer misses from C# while coding in Java (properties, LINQ, reified generics, type inference, named and optional parameters, closures, continuations), this post intends to look at things a Java programmer might miss while coding in C#.

1. Method return type covariance

Covariant method return types are one of the lesser known Java features (see Section 8.4.5 in the JLS). Basically, Java allows you to narrow the return type of a method when overriding it in a sub-class. For example:

public class Foo {
}
 
public class SubFoo extends Foo {
}
 
public class Bar {
    final Foo foo = new Foo();
    public Foo getFoo() {
        return foo;
    }
}
 
public class SubBar extends Bar {
    final SubFoo subFoo = new SubFoo();
 
    @Override
    public SubFoo getFoo() {
        return subFoo;
    }
}

Although situations where this is needed are seldom, it is a nice feature to have when you need it. An good example of its usage is in the Apache Wicket framework. All pages in Wicket typically derive from the WebPage class. Thus, when you want to access information from a custom Wicket session you need to do something like this:

public class UserInfoPage extends WebPage {
    public UserInfoPage() {
        FooSession session = (FooSession) getSession();
        String userName = session.getUserName();
        ...
    }
}

However, if you add a class above UserInfoPage called FooPage, you can use a covariant return type to eliminate the unsightly cast:

public class FooPage extends WebPage {
    @Override
    public FooSession getSession() {
        return (FooSession) super.getSession();
    }
}
 
public class UserInfoPage extends FooPage {
    public UserInfoPage() {
        FooSession session = getSession();
        String userName = session.getUserName();
        ...
    }
}

To me this is preferable to adding another method called getFooSession(). Having two methods can be confusing to a future maintainer (do I want getFooSession() or getSession()? What’s the difference?) and needlessly clutters your IDE’s code completion.

There is no equivalent in C#, short of adding a method. Will C# ever support such a feature? It’s hard to say, but probably not anytime soon. There has been a request for covariant method return types since 2004. Microsoft response then was:

We hear this request a lot. We’ll consider it for the next release.

After seven years and three major C# releases, it looks like they’re still considering it.

2. Class-like enums

This one is not a big surprise, as it is typically mentioned as one of the few things that Java has done better that C#. In C#, enums are basically glorified integral types. As such, they can’t contain any extra data without using attributes. While attributes are nice, accessing them requires quite a bit of boilerplate.

public enum MotionType {
    Stationary,
    Walking,
    Running,
    [Description("Time Travelling")],
    TimeTravelling
}
 
...
 
MotionType type = MotionType.TimeTravelling;
var description = type
    .GetType()
    .GetField(type.ToString())
    .GetCustomAttributes(typeof(DescriptionAttribute), false)
    .Cast<DescriptionAttribute>()
    .First()
    .Description;
Console.WriteLine(description);

A further restriction of C# enums if that they can’t be used as a generic constraint. For example, the following code would not compile:

public class Monster<TMotionType> where TMotionType : enum {
}

According to C# MVP Jon Skeet, this is not a restriction of the CLR, but is actually a restriction of the Microsoft C# compiler. The best you can do to work around this is to use the broader constraint where : struct, or the Unconstrained Melody library.

Java enums, on the other hand, are specialized classes. Like C# enums, Java enums can be used with switch statements and be converted to integral types. However, Java enums go far beyond these simple uses. Java enums can have instance fields, instance methods and even per-constant methods. Java generics can also be constrained to take only enums.

Here’s how the MotionType enum could be written in Java (notice how easy it is to get the description in this case):

public enum MotionType {
    STATIONARY("Stationary"),
    WALKING("Walking"),
    RUNNING("Running"),
    TIME_TRAVELLING("Time Travelling");
 
    public final String description;
    MotionType(String description) {
        this.description = description;
    }
}
 
...
 
MotionType type = MotionType.TIME_TRAVELLING;
System.out.println(type.description);

This is just scratching the surface of Java enum capabilities. I highly recommend reading Chapter 6 of Effective Java or the Oracle enum documentation.

3. Anonymous inner classes

This is another it’s-useful-when-you-need-it feature of Java that C# mostly addresses with events and delegates. The most common situation for anonymous inner classes in Java is for listeners:

Widget widget = new Widget() {
    public void onInteraction(WidgetState state) {
        ...
    }
};

In C#, this is handled using events and delegates:

Widget widget = new Widget();
widget.Interaction += state => {
    ...
};

The C# approach is superior in most cases. There’s far less clutter and it’s a lot easier to add listener support to a class in C#. Furthermore, since it’s a language feature, you can count on it being more or less the same everywhere. However, it’s not without drawbacks. You’ll notice in the previous Java example, we can guarantee that there is only one listener. Furthermore, if we declare onInteraction as abstract, we can also ensure that all concrete implementations of Widget have an onInteraction handler. The event/delegate approach as written cannot make the same guarantees.

Since C# does not support anonymous inner classes, the best we can do to emulate them is something like this:

Widget widget = new Widget(state => {
    ...
});

…or, if we wanted to make it a little more clear, we could use named parameters:

Widget widget = new Widget(onInteraction: state => {
    ...
});

Locally scoped final/readonly variables

In the book Code Complete 2, Steve McConnell recommends that you use final keyword whenever possible. The justification for this being that less mutable code is easier to keep track of mentally and less likely to be accidentally modified. Although the practice of making everything final can be weird at first, you eventually become so used to using final that you start to feel a little bit exposed whenever a variable isn’t marked final.

C# has a nearly equivalent keyword to final: readonly. However, for some reason, readonly is only usable on the field level. In the local scope, there is no direct equivalent to final in C#. The best you can do is use const, but this only works with compile-time constants, so

const string foo = Foo.getString();

…won’t work.

Conclusion

In this article we looked at four features of Java that lack direct C# equivalents: covariant method return types, class-like enums, anonymous inner classes and locally-scoped final/readonly keywords. C# is often thought of as a “better Java”. However, as this article has shown, this is not true. Java may not have as many bells and whistles as its newer cousin, but it still offers some compelling features that may never find their way into C#.

History lesson: Anders was lured away from Borland by Microsoft with a hefty offer of a $1.5 million signing bonus, a base salary of up to $200,000, and options to buy 75,000 shares of Microsoft stock.

Looks like it was worth it, as each C# release has added many interesting and powerful features, while maintaining a fine balance between complexity and simplicity.

First stop: parsers!

Furthermore, after some thought, I’ve decided to split up Fep arrays. In PHP arrays aren’t really arrays in the traditional sense, but more like array/associate array hybrids (JavaScript uses a similar concept). This can be confusing, error-prone and I don’t think that the benefits of having an hybrid array system outweighs the complexity.

Thus, in Fep, there will be two main collection types: lists and dictionaries. Here’s how a Fep list will look like:

// Fep
fep = [ "foo", 1, 2, "bar" ];
fep.count(); // == 4
fep.add( "baz" );
fep.find( x => x > 1 ); // == 2
 
// Will compile into this PHP
$fep = new FepList("foo", 1, 2, "bar");
$fep->count();
$fep->add( "baz" );
$fep->find( function( $x ) { return x > 1 } );

And here’s how a Fep dictionary will look:

// Fep
fep = { blah: "blah", foo: "bar", 0: "zero" };
fep.keys(); // == [ "blah", "foo", 0 ]
fep.containsKey( "foo" ); // == true
fep.remove( "foo" ); // == true
 
// PHP
$fep = new FepDict(array("blah" => "blah", "foo" => "bar", 
         0 => "zero"));
$fep->keys();
$fep->containsKey( "foo" );
$fep->remove( "foo" );

In this article, I’ll write a bit about how I think Fep arrays will look. Keep in mind this a work in progress and is by no means comprehensive. Without further ado…

In PHP, you define an array using the array() construct. Fep will follow the lead of languages like JavaScript, Python, Ruby and Groovy and use the square bracket [] notation.

Initialization

For example, a simple array in PHP is creating like this:

$arr = array(1, 2, 3);

In Fep, this would be done like this:

arr = [1, 2, 3]

There are actually three things to notice here. First, Fep uses square brackets. Second, Fep has optional semicolons (similar to JavaScript and Scala). Third, Fep doesn't prefix all variables with $. This should give your pinky finger a bit of rest and de-noise-ify your Fep code.

How about associative arrays? In this case, I don't want to deviate too much from PHP, so I'm going to go with the same syntax:

// PHP
$fruits = array(
  "fruits"  => array("a" => "orange", "b" => "banana", 
                     "c" => "apple"),
  "numbers" => array(1, 2, 3, 4, 5, 6),
  "holes"   => array("first", 5 => "second", "third")
);
 
// Fep
fruits = 
[
  "fruits"  => ["a" => "orange", "b" => "banana", 
                "c" => "apple"],
  "numbers" => [1, 2, 3, 4, 5, 6],
  "holes"   => ["first", 5 => "second", "third")
]

Decomposition

What about that convenient list construct? In Fep, we'll try again to reduce the typing and improve readability by introducing this syntax:

// PHP
list($a, $b, $c) = array("a", "b", "c");
 
// Fep
a, b, c = ["a", "b", "c"]

Accessors

To fetch a value from a Fep array, the regular PHP-style accessors will be used, with the main difference being that Fep will support negative indexing. That is, $array[-1] == $array[$array.length - 1].

arr = [1, 2, 3]
println $arr[0]    // 1
println [4, 5, 6][1] // 5
println $arr[-1]   // 3
 
mixed = ["a" => "b", "foo"]
println arr["a"] // b
println arr[0]   // foo

API

All arrays in Fep will be Array objects. As such, they'll have access to all the PHP array functions in an object-oriented way. Here's a few examples:

// PHP
$arr = array(1, 2, "x");
$len = count($arr);
array_push($arr, "y", "z");
in_array(1, $arr);
$merged = array_merge($arr, array("a", "b", "c"));
 
// Fep
arr = [1, 2, "x"]
len = arr.length
arr.push("y", "z")
arr.contains(1)
merged = arr + ["a", "b", "c"]

Fep has the following goals:

• Eliminate many of the inconsistencies of PHP while maintaining the core feel of the language. For example, why is there print and echo? Answer: it’s complicated. But it doesn’t have to be! isset() is a language construct that requires brackets but require doesn’t. These are the types of things I’d like to fix.
• PHP has a ton of string functions that are just screaming to be separated into classes. Fep will do this. This will be also done to groups of functions in a similar state.
• PHP isn’t the nicest language, but it’s easy and familiar. It also has a ton of support. Fep will be a sort of meta-language. Fep code will be converted to PHP code before it is run in order to maintain compatibility with the PHP ecosystem.
• PHP’s OO model is a bit strange. Why is the constructor called __construct? To me that’s ugly as shit. I’m also not a big fan of using -> to access methods and attributes. I’d much rather use ., but in order to do that, we’ll probably need to stop using . for concatenation. I’m ok with doing that.

That’s just a few of the things of the top of my head. The development process will follow this pattern:

1. write a series of articles to map out the language (maybe even write a language reference like Python),
2. write a compiler that’ll convert Fep code into PHP code,
3. write a module for Apache that’ll convert .fep files to .php files and then feed them to the PHP module.