From Java to PHP

Several months ago I accepted a new position, moving from an Application Developer to a Quality Assurance Supervisor. Prior to this move, I would never have considered moving over to QA, but thankfully, I still get to write code and writing code is really what I prefer to do.

One other big change is the switch from using Java for the past six years to using PHP. Most of the applications in my new position utilize PHP, and I had seen most of the jokes on Reddit regarding how bad it was, so I was skeptical. Now, I’m not fully convinced it’s something I would choose to use, given the option, but it’s not really as bad as portrayed. I like to think of it as a mix between Java and Perl, with a few of its own quirks thrown in for good measure.

I decided to write this blog post to help anyone who might be moving from using Java to needing to use PHP, to cover some of the basics of how to transition. This list is in no particular order, though I did try to cover the basics before diving into more nuanced topics.

With no further falderal, let’s get to the list!

IDE

I expect a lot from my IDE – code completion, class linkage, build tools, etc. For Java, I normally use IntelliJ IDE Community Edition. JetBrains (the makers of IntelliJ) do make a PHP IDE (PHPStorm), but unfortunately, it’s not free. If you can’t get your hands on PHPStorm, Visual Studio Code is a decent, albeit flawed choice. I haven’t yet found a good way to perform refactoring across classes, for instance.

Classpaths and packages

PHP has the concept of classpaths just as Java does, though it handles them differently and calls them namespaces. The easiest way I’ve found of handling this is to use composer. This requires just a single package.json in your main directory that lists both your source folders and namespaces as well as the external packages you want to include.

Classes

Class construction is fairly similar between Java and PHP with the same modifier concepts (public, protected, private) and use of methods. It also allows static member variables and methods, inheritance, interfaces, and abstract classes.

Member Variables

Member variables exist in PHP as they do in Java, with a caveat: you can’t declare a default that isn’t constant.

// valid
private string $whatever = "this';

// invalid
private string $whatever = aClass::staticMethod(); 

You also don’t need to set the type of the variable as you do in Java – PHP is not strictly typed.

private $whatever = "this"; // also valid

You don’t even need to declare a member variable to use it, though I wouldn’t recommend this approach as it can cause confusion and won’t be traceable by the IDE.

Functions/Methods

While the way functions and methods are used in PHP are similar to how Java uses them, their construction is somewhat different.

Declaration
// Java
private void doThings(String $whatever) { 
}

// PHP
private function doThings(string $whatever) : void {
}

As above, the types of the parameters as well as the return types are not strictly required. Methods can even return different types. This will affect your IDE autocompletion, though, so use at your own risk

// We don't have to declare the parameter type
// or even the return type

private function doThings($whatever) {
  // We can return different types!
  return $whatever === "this" ? "Yes" : false;
}

And just a small change in how we actually call these functions:

// Java
MyObject o = new MyObject();
o.doThings();        // instance method
MyObject.doThings(); // static method 

// PHP
$o = new MyObject();
$o->doThings();       // instance method
MyObject::doThings(); // static method

PHP also has two other ways to call static methods when called from the same class:

class MyObject {
  public static function doThings() { }
  public function otherThings() {
    self::doThings();
    static::doThings();
  }
}

The difference in the two comes up when inheritance is involved.

class MyObject {
  public static function doThings() { 
    echo "I am MyObject"
  }

  public function otherThingsSelf() {
    self::doThings();
  }

  public function otherThingsStatic() {
    static::doThings();
  }
}

If we then define a child class…

class MyChildObject extends MyObject {
  public static function doThings() {
    echo "I am MyChildObject"
  }
}

and then call the two functions on the MyChildObject, we see static introduces a concept of late static binding.

// Prints "I am MyObject"
MyChildObject::otherThingsSelf();

// Prints "I am MyChildObject"
MyChildObject::otherThingsStatic();

Conclusion

Other differences do exist in PHP, but the list above should be enough to grasp most of the concepts around OOP. If there are other things that you would like to see, please feel free to leave a comment!

Elwood – 2003(?) – 12/18/2020

Just wanted to reserve a spot in cyberspace for this excellent, loyal boy and overall Good Buddy. He apparently had cancer that metastasized into his liver. Nicknamed “Billy Elwood” or “Buddy Idol” for his signature Billy Idol sneer after getting one of his fangs removed, he always just wanted to be around you.

I’ll never forget you, Buddy.

Migrating from C# to Java

For some time now, I’ve been working to turn some C# code into a Minecraft mod. This is a short post about some hurdles I encountered having only using C# minimally. Unintentionally, I have also become quite jealous of some of the additional features C# offers that Java does not have, or does not do very well.

Generics

First and foremost: C# does Generics right – or at least better than Java. While Java simply utilizes Generics as type erasure, C# allows greater flexibility and introduces additional capabilities like instantiation of the generic parameters.

For example, this is not legal in Java, but the similar C# code would be:

public List<T> makeNewListWithOneItem( ) {
  List<T> myList = new ArrayList<T>();
  myList.add( new T() );
}

So much of what you encounter when trying to migrate code may be a tad more difficult to compensate for, should that code utilize these features. The way I personally worked around it was to include the actual class as the first argument.

public List<T> makeNewListWithOneItem (Class clazz) {
  List<T> myList = new ArrayList<T>();
  try {
    myList.add( clazz.newInstance() );
  } catch ( InstantiationException | IllegalAccessException e ) {
    // blah blah blah
  }
}

It’s not quite as nice, but it should work for those cases where ‘generic parameter instantiation’ is required.

Refs

C# has the concepts of ref, in and out. A nice summary of the differences is:

  • ref is used to state that the parameter passed may be modified by the method.
  • in is used to state that the parameter passed cannot be modified by the method.
  • out is used to state that the parameter passed must be modified by the method.

As Java is pass-by-value, this introduces a problem in how to get it to pass by reference when the code calls for it. While any called function that modifies the internals of the object will work as expected, wholesale reassignment will not be reflected outside of the method call.

abstract class Animal {
    public String name;

    Animal(String name) {
        this.name = name;
    }
}

class Dog extends Animal {
    public Dog() {
        super("Dog");
    }
}

class Cat extends Animal {
    public Cat() {
        super("Cat");
    }
}

public class RefTest {
    public static void main(String[] args) {
        Cat cat = new Cat();
        reassign(cat, "NotACat");
        System.out.println("Reassigning cat name = " + cat.name);

        cat = new Cat();
        reassign(cat, new Dog());
        System.out.println("Reassigning cat to dog = " + cat.name);
    }

    public static void reassign(Animal animal, String toName) {
        animal.name = toName;
    }

    public static void reassign(Animal animal, Animal otherAnimal) {
        animal = otherAnimal;
    }
}

Outputs:

Reassigning cat name = NotACat
Reassigning cat to dog = Cat

A good IDE will even warn about this in the secondary reassign by graying out the assignment, since it will have no effect.

There are several ways to work around this, but the one I’ve chosen would be the use of a encapsulation

class Ref<T> {
    private T innerObj;
    
    public Ref(T obj) {
        this.innerObj = obj;
    }
    
    public T get() {
        return innerObj;
    }
    
    public void set( T obj ) {
        this.innerObj = obj;
    }
}

In this way, any place a ref is needed, the object can be passed as the encapsulated Ref object

public class RefTest {
    public static void main(String[] args) {
        Ref<Animal> cat = new Ref<>(new Cat());
        reassign(cat, "NotACat");
        System.out.println("Reassigning cat name = " + cat.get().name);

        cat = new Ref<>(new Cat());
        reassign(cat, new Dog());
        System.out.println("Reassigning cat to dog = " + cat.get().name);
    }

    public static void reassign(Ref<Animal> animal, String toName) {
        animal.get().name = toName;
    }

    public static void reassign(Ref<Animal> animal, Animal otherAnimal) {
        animal.set(otherAnimal);
    }
}

Note that we’ve change the type to Animal to allow the reassignment.

Now this outputs:

Reassigning cat name = NotACat
Reassigning cat to dog = Dog

By doing this, we are able to effectively pass by reference by taking advantage of the ability to modify the internals of the object, though not the object itself. We’ve simply changed the value we are passing from Cat to Ref<>

Slow performance with CXF and Jetty

I am, quite admittedly, far from an expert with CXF. When I was tasked with upgrading an old CXF 2.x / Jetty 8.x service to CXF 3/Jetty 9, I hoped it would be a fairly simply task of modifying a pom and perhaps a few configuration points and being done. Unfortunately, I found myself needing to upgrade quite a few pieces, dependencies and customized connectors. But even that wasn’t the biggest problem.

Once all the dependencies, security and customized pieces were completed and all the tests were passed, we were ready to place the service into a non-production environment. This environment is far from isolated, as it receives on average 150+ TPS for a single instance. But, all the tests were completed so no problem, right? Unfortunately, from the moment it was started, there were issues.

CPU usage skyrocketed, calls that took milliseconds now took (literally) minutes and the log was filled with Broken Pipes. Thread dumps showed a plethora of stacktraces leading back to XMLStreamWriterImpl and java.lang.String.toCharArray. It seems something was getting stuck outputting the XML responses, but all of the elements in the stack trace were third party – none of it really had anything to do with our application code.

Searches on StackOverflow and other places turned up nothing. At first, we couldn’t replicate in a standalone environment until finally – we could. Turns out that after checking nearly everything, the classpath was the issue. After more searching, we had transitive dependencies pulling in the jaxp-ri library, which appears to have been taking precedence over what did actually work properly, which was StAX. So if you happen to ever find yourself in a similar situation, make sure to check those transitive dependencies for rogue elements!

As a side note, I’m still not 100% clear on exactly why this performed so abysmally with the jaxp-ri library. If anyone happens to have any insight into that, as my time for such endeavors is often lacking, feel free to drop in a comment or two.

DME

DME – What is it?

AT&T’s DME (which stands for Direct Messaging Engine) is a Java-based open source library for performing service lookups with built-in support for a file-based service directory, AT&T’s GRM (open source version GRM-Edge which is slightly different and will be explained in another post), or hooks for custom service directories.

Ok… so?

DME provides client or server location-based (or custom) endpoint ordering with customizable failover support that provides minimal overhead for HTTP, JMS (over HTTP) or JDBC communications. Basically, this allows for accessing redundant systems in a fault-tolerant capacity whether the system is focused on transactions, data retrieval or fire-and-forget data insertion.

Aren’t there already tools that do this?

Probably! I’m not aware of them (and quite honestly I haven’t searched very hard for them), but please leave some info in the comments if you’re aware of similar tools and I can get some comparisons/contrast. I’m only providing this information because DME is something I’m quite familiar with, having worked on it directly.

 

This is a basic overview of the flow of how DME works:

1) Client requests communication via DME, which talks to a service registry

2) Service Registry returns relevant information about the services (host, port, path, etc.)

3) DME selects the closest endpoint(s) and attempts to contact them

4) If failure occurs talking to the closest set, DME can talk to those farther away as a back up. For instance, in the image, if DC A goes down, it will failover to DC B.

 

Simple SSL for Developers

Overview

There are many (good) resources out there for SSL and its underpinnings. There are detailed forays into the dark underbelly of handshake, encryption, certificates, keystores and the like. But how much do you really need to know? Surely, pursuit of absolute knowledge is a noble task, but when you’re on the company dime, just short on time, or … something else that ends in -ime, maybe you just need to know enough to get past your problem and move on to other things.

First thing to know is that SSL (as a protocol) is essentially dead, although perhaps obsolete is the better term here. The latest craze is TLS 1.2 with 1.3 on its way as of this writing. Why TLS? Because it’s more secure, of course! People still generally refer to secure communications over http as SSL, but the protocol of choice is TLS due to vulnerabilities in the original SSL, SSLv2 and SSLv3 protocols. We’ll continue to refer to the process of securing communication as “SSL” throughout this page, but bear in mind that we’re talking about the process, not the protocol.

Second, we need to differentiate between One-way SSL and Two-way SSL. The difference between them is really as plain as it seems. One-way SSL is when the client needs to validate the server, but not vice versa. Two-way SSL is, as you might expect, when both the client and server need to validate each other. We’ll get into how that happens later, but for now just know that those are two are the basic varieties of “who needs to trust who”. One-way SSL is by far the most common, and is what you most often encounter when banking or using any secure website.

Third, we need to understand the parts of how SSL works. I’ll try not to get into too much detail here (as I mentioned, there are plenty of good sites for that), but as a broad overview the important pieces (from a developer standpoint) are the handshake and the certificate exchanges.

The handshake consists of agreeing on a protocol (e.g. SSLv2, SSLv3, TLSv1.1, TLSv1.2), agreeing on a cipher (the mechanism for encryption) and performing the actual certificate exchange and verification. When you encounter an issue, this is one big place where things can go wrong.

The certificate exchange itself involves the server providing its certificate to the client, which the client verifies. In Two-way SSL, the client will also send its own certificate to the server to be verified. The respective certificates are stored in a key store (one on the client, one on the server) and are verified by using a trust store (again, one on the client, one on the server).

Where can things go wrong?

Lots of things can interfere with valid communication between two services via SSL. We’ll work our way through the handshake to highlight some examples. Note that these examples all will reference the use of Java, but these issues themselves are not necessarily language related.

Handshake Protocol Selection

In order to be able to handshake, the client and server must be able to agree on how to talk. Beyond that, they must also agree on how to handshake. There is a somewhat problematic protocol called SSLv2Hello that can cause issues when the server is more restrictive on which protocols it accepts. SSLv2Hello (like all the SSL protocols) is considered vulnerable to attack and so, rightly, it should not be used. But upgrades take time and can be forgotten and adoption by end users can be slow. So sometimes these protocols hang around longer than they really should.

SSLv2Hello is not a normal SSL protocol in that it’s not used for sending any actual messages. It’s a ‘pseudo-protocol’ that’s used to perform the handshake. So how can you perform a handshake with a protocol that is known to have vulnerabilities when connecting to a server that is restricted to TLS? Easy – you can’t.

Sometimes this manifests itself plainly by stating that SSLv2Hello failed. Other times it’s more cryptic, like “Early EOF Exception”. Debugging these can be a bit trickier – you’ll often need to know the protocols the server supports beforehand or be able to debug the SSL connection. In Java, adding -Djava.net.debug=ssl should help.

So how do we disable SSLv2Hello from ever being used in the first place? In Java we can utilize the -https.protocols and jdk.tls.client.protocols flags to “TLSv1.1,TLSv1.2” (for example) to include only TLS protocols v1.1 and 1.2.

Invalid Cipher Selection

Just like protocols, ciphers can be compromised as well. It can be more difficult to diagnose these situations when dealing with a simple generic Java exception. Again, adding -Djavax.net.debug=ssl can help pinpoint the issue.

Additionally, there are legal restrictions on the strength of ciphers that can be exported from the United States (outside of the United States, you’ll have to consult the applicable laws). In the event that you are inside the United States, you may simply need to allow other ciphers to be used. For Java, those are found here.

Certificates

Certificates can be thought of as ID cards that two entities might show to each other to prove they are who they say they are. When you contact your bank and enter your password, you want to make sure that they are who they say they are! So imagine when you go to the bank, the teller shows you identification that verifies the teller’s identity. But we can’t just trust the teller, or even the ID. We also must trust whoever issued that ID. In this case, the ID itself is analogous to the certificate, while the issuer is analogous to the Root Certificate Authority (Root CA’s).

Windows and Java come pre-installed with a list of Trusted Root CA’s that are generally recognized as, well, trustworthy. If they issue a certificate to a server, then that server (according to the powers that be) can be trusted as well. This is all well and good, but ID’s (and certificates) don’t get issued for free! (Well, sometimes they do)

Often times during development, it’s too costly or time-consuming to procure valid certificates signed by recognized Root CA’s, so a self-signed certificate is used. Since it’s development, this in and of itself usually isn’t a problem, but it can be if your client isn’t set up to trust that certificate. (In Java, this usually manifests itself with a “PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target” or similar message) Many people recommend what amounts to turning your SSL Certificate Validation off (AKA trusting all certificates). This gets you past the issue and lets you proceed but is not recommended because often times this slips past into production and then things can really get compromised!

So another possibility is to simply add the server’s certificate to the client’s trust store. This takes a few more steps, but it is easier once you’ve done it a few times. A walk-through for that is coming but the steps involve using the browser to download the certificate. Once that is done, I’d recommend copying over the default java cacerts and adding the certificate to the new truststore using Java’s keytool command. Then you’ll have to tell your client to use the new truststore instead of Java’s default by using -Djavax.net.ssl.trustStore and -Djavax.net.ssl.trustStorePassword.

For Two-way SSL, the reverse has to take place as well. While you may have to type in your banking password to get into your account, another option would be to prove to the bank that you are who you say you are via certificate as well. This generally isn’t the case for current websites, as it would be too cumbersome for each and every customer to go and procure valid certificates that the bank trusts, but it is an option in environments where a smaller number of unique hosts communicate.

And those are the major points of general issues faced by developers when using SSL. Certainly there is more (much more!) to cover, but most of the time the issue falls into one of those categories. As time permits I’ll add diagrams and walk-throughs, but if you’d like to see additional details or examples, feel free to leave some comments and I’ll try to prioritize those. Thanks for reading!

Greetings and Salutations

This is just an opening post to place some semblance of an introduction to what will undoubtedly be a forgotten collection of ne’er before (or after) seen posts. Supposedly, at some point, I’ll add some random words and sentence fragments regarding my coding experience and perhaps logical musings in general. In the event that someone actually discovers this by an unfortunate turn of events, let it be known that all risks associated with the use of this site are borne by the user. Thanks, and enjoy the show.