Let’s poke at Tomcat!

Silver Tabby Cat Lying on Brown Wooden Surface
Very loosely related image from to make this post look nicer in social media shares.

A while ago I mentioned that every Java project has to have a main method somewhere. I started thinking it would be interesting to dig into a larger project and show how even a whole servlet container starts with a main method, just like the smallest hello world program. So let’s poke at Tomcat!

Why tomcat? Because it’s open source, I’ve used it before, and honestly it was the first thing that came to mind :) Oh, and for anyone reading this who hasn’t spent a ton of time writing Java webapps, a servlet container is a kind of webserver that provides a nice little home for your servlets, which are little Java programs that take http requests and give back http responses.

Tomcat does indeed have a main method, it starts on line 457 in There’s even a helpful comment that says “Main method and entry point when starting Tomcat via the provided scripts.”

Which is all well and good, but that makes for a pretty boring blog post :) So let’s talk about how I hunted down that main method. I could have just searched for “static void main” in the Tomcat github repo, but a) I just tried that and it wasn’t actually super helpful, and b) what I really wanted to know was what happens when you start Tomcat.

It’s been a while since I used Tomcat so I looked at the docs first. In the readme on the github project there’s a link to RUNNING.txt, which looks promising.

So I skim through that (there’s a bunch of stuff about installing tomcat and setting up environment variables that I don’t care about right now, I just want to know what the startup script is called) and eventually find the section about starting tomcat. In there it says that the startup script for linux users like me is $CATALINA_HOME/bin/ (there’s a .bat file for windows users too if you’re curious).

Okay great what’s in (also thankyou github for having a file finder!) It turns out there’s not a ton in there and I don’t understand most of it, but at the end of that file is “exec $PRGDIR/$EXECUTABLE start $@“”, which I think I can assume executes a thing :) Also a little earlier in the file is

Given that, it looks like does some pre-setup setup and then actually starts the server (if there’s a 3rd level of startup scripts I’m going to be really sad). There’s a lot more going on in that I skimmed through, but I eventually started seeing a lot of eval exec \”$_RUNJAVA\”  [many more vars] org.apache.catalina.startup.Bootstrap $@ start. That $_RUNJAVA thing sounds like it might, you know, run Java :) That probably means that the startup class is org.apache.catalina.startup.Bootstrap, let’s go see if there’s anything interesting in there. And what do you know there’s a main method. It took some scrolling to get there but we made it eventually!

You may or may not care about how Tomcat (or any other given application) works, but what I hope is interesting is that everything an application does is understandable. Nothing the computer does is magic, it’s all knowable.

OnePlus 5 review

The OnePlus 5 in slate gray, from the OnePlus press photos page.

Because you definitely all care about my opinions on phones :)

The very short version is I really like this phone and recommend it for anyone who likes the Google Pixel but is put off by the price. Now for the details!

The hardware is really nice, it feels solid and well put-together. Fair warning, it is a phablet and the formfactor is very large – without a case the phone is 154.2 x 74.1 x 7.25 mm. As a bit of an aside, if you’re a woman and have any wild ideas about putting your phone in your pocket I highly recommend eShakti jeans with the deep pockets option.

I also highly recommend a case, the phone feels kind of naked without one, plus it’s expensive and smashing it would suck a lot. The Otterbox case is what I went with because I want my phone to be as well-protected as possible. That case also gives the phone a more satisfying heft in your hand, it’s almost too light without a case.

Performance wise it’s great, which is maybe not great for getting my tab habit under control. Yes, I have a problem even on mobile :) It opens demanding apps (like Tap Tap Fish, which I have a terrible obsession with) faster than my last phone, the Nexus 5x and it performs the same with one app or a dozen open. Often the only way I figure out how many apps I left open is when I hit the recent apps button looking for one of them and ending up scrolling, and scrolling, and scrolling, to find it.

The screen is really nice too, it’s huge (you know, like you would expect from a phablet) and sharp and bright. Reading on it is a much nicer experience than it was on the Nexus 5x if only because it’s bigger, but I think the colours are brighter too.

Battery life on this phone is fantastic, I’m guessing the bigger form factor allows a much bigger battery. Even running that huge bright screen for hours (say if you’re extremely bored in an airport) won’t kill the battery. And even if it does, dash charging really does charge your phone back up incredibly quickly.

I can’t condone actually taking calls on speakerphone, but if you want to use the speaker for more civilized pursuits like listening to podcasts while you get ready in the morning, it’s pretty decent. I mean, it’s a smartphone speaker, you can only expect so much, but I can hear it from across the room without turning it up as loud as it will go, so that’s handy.

All I can tell you about the camera is that it exists, I don’t take a lot of pictures so I don’t have anything useful to say about it.

Updates have come steadily since getting the phone, and even if OnePlus stops supporting the phone it’s popular enough that there’s a good chance of finding a custom ROM to put on it.

Now for the cons:

Getting the phone was seriously painful. I ordered mine about 10 minutes after a coworker and got it days after he did. The OnePlus site just doesn’t like some credit cards for no particular reason, you may want to make sure your PayPal is setup to charge directly to your credit card so you still have some protection and use that to pay for the phone.

If you order anything from OnePlus, you need to resign yourself to the fact that they will ship your order when they damn well feel like it and not a second before. If you have a workable phone then the wait isn’t so bad, but if your primary phone died weeks ago and you’re using a ~5 year old phone it’s really painful to wait and wait and wait for your phone to finally show up. In other words, don’t order from OnePlus if you’re in a hurry to get your phone, especially if they’re running a launch event.

This is probably the meanest thing I will ever say on this blog, so brace yourself :) OnePlus support is LESS USEFUL THAN DHL SUPPORT. LESS USEFUL. To be worse than DHL at delivering packages, you would have to open the package and defile it before throwing it in the garbage, and yet somehow DHL support was able to tell me what was happening with my package and where to put my tracking number when OnePlus support had absolutely no idea what was going on. If you’re going to sell a phone comparable to the Pixel for around $250 less you’re going to have to cut corners somewhere, but seriously, OnePlus support is amazingly terrible. As in, so terrible I feel perfectly safe sassing them like this because it’s not going to make them noticeably less useful.

All that said, if you can stand to wait and wait and wait for it to show up, the phone really is excellent.

Back to basics: Classes

a macbook sits on a desk surrounded by black and white plans for a house
Loosely related image from to make this post look nicer in social media shares.

Let’s talk about classes! Classes in Java are super weird (okay they’re weird in any language), and I really struggled with them when I was learning Java, so don’t feel bad if classes/objects are hard for you.

When you write simple code where everything is in main and runs immediately, it’s way easier. With classes you can’t just write it and call it, you have to create an instance first. What’s even going on there?

A class in Java is just a blueprint, it doesn’t do anything until you create an object using the blueprint (there are exceptions but let’s go with that for now). That’s a big part of the weirdness, you write all this code and it just kinda sits there until you write even more code, and here’s the kicker: that code has to be somewhere else.

In a small project your probably have a Main class somewhere that has a main() method, that’s where you need to call your other class from. Why? Because Java says so, that’s why :) Or more precisely, when you run a Java project you have to tell the JVM where to start. Something, somewhere, has to have a main method no matter how you run your project. Even if you create an archive that you drop into a servlet container like Tomcat or Jetty, that servlet container has a main method somewhere that gets called when you start it up. It may be very stealthily called by a script that calls a script that starts a service, but there’s definitely a main method in there somewhere. No matter how complicated an application seems, it’s really just a much larger version of the tiny little projects you do in school. Programs get larger and larger but the basic principles always stay the same.

Back at basic principles, you create actual objects you can interact with using the class/blueprint. In Java you do that with the new keyword. new YourClassName() creates an object using the blueprint, you can assign that to a variable like any other value and then do what you like with it. Once you create an object it’s separate from any other object you create even if you use the same blueprint (class) again. Again, there are exceptions, but I’m trying to keep this simple.

It’s like building two houses from the same set of plans, they’re separate houses even if they start out the same. You can put completely different furniture in each of them, paint them different colours, make a bedroom into a home office, but whatever you do to one house doesn’t affect the other one. And you can put objects inside other objects, like a house object could contain a fridge object or a couch object or a CNC router object if you have an especially interesting garage.

You could also have an array of house objects – pretend you’re keeping track of one of those subdivisions where all the houses are the same :) Those houses could have a method like closeWindows (pretend it’s an automated house), so you could loop through your array of suspiciously similar houses and close all the windows if the weather report said it was likely to rain. But you would need to call the closeWindows method on every single house, if you close the windows of one house it doesn’t affect the others.

This gets much more complicated when you start thinking about multithreading, static methods, and static fields, but those are another blog post. For now all I want to get at is that Java needs you to spell out exactly where to start and that programs all work pretty much the same way no matter how complicated they are. Frameworks like Spring or Struts and containers like Tomcat and Jetty will hide details from you, but no matter how many other programs or libraries you use, the computer always needs to know where to start.

Code smell: feature envy

A large rock or very small island with a few green shrubs growing on it surrounded by greeny blue water and white surf.
Unrelated image from to make this post look nicer in social media shares.

Today’s code smell is feature envy. Feature envy is when one class uses the methods of another class to excess. It’s called feature envy because classes that use methods from another class excessively look envious of that class’s features.

The problem with that, as usual, is the way your logic gets spread around between multiple classes. If you have one method that’s using another class so much that it’s hardly even separate from it, you’ll probably have to change things in both places when you need to fix a bug or add a new feature, but the compiler can’t tell you that you need to do that so you risk creating a shiny new bug by missing a spot.

Feature envy probably makes more sense with an example. Let’s say you have an address class and a customer class, and when you call customer.getMailingLabel() your customer class calls address.getStreetNumber(), address.getStreetName(), address.getCity() and so on to build a complete address string for printing a mailing label. Let’s imagine that policy changed and you’re now able to ship to rural mailboxes, so you need to add route and box numbers to your address and to use those instead of street number and street name if they’re present. If your code has feature envy, you have to change both the address object and the getMailingLabel method to support rural mailboxes. If you moved the getMailingLabel method into the address class, then you would only have to change one class when you wanted to change how you build mailing labels.

As with just about all code smells, feature envy isn’t always a sign there’s a problem. Sometimes you want to separate your data from operations on it, especially if you’re using a strategy or visitor design pattern. If, for example, you want addresses formatted differently for different reports, the formatting is probably more the job of the reporting code than the address object. In that case it would make more sense for a visitor to contain the formatting code so the address object doesn’t have to care about all the different reports.

Code smell: switch statements

a frying pan full of brightly coloured vegetables cut into small pieces
Unrelated image from to make this post look nicer in social media shares.

Today’s code smell is switch statements. Long switch statements or complicated if statements often (but not always!) mean that something has gone wrong with your design. Objected oriented languages give you a lot of tools to avoid big complicated switches, if you aren’t using one of those there needs to be a good reason for it. If you’re not using an object oriented language, on the other hand, I’m honestly not sure if switch statements are a sign of a potential issue. If any of my readers could weigh in on that, that would be really helpful.

But why are switch statements a problem? Because you’re spreading around logic that should probably be in one place, and if you add a value to one switch statement you’re likely to need to hunt down all the other ones and change them too.

If, for example, you have a switch statement that does different calculations based on the type of the object passed in, that logic for how to do the calculation probably belongs inside the object passed in to the switch. If you change that object, you’ll have to hunt down every place it’s used and make sure nothing else needs to be changed, which is obviously asking for trouble :) If you give each object a doCalculation method and replace the switch statement with a simple call to doCalculation, then all of the logic for that object stays inside the object. With all your logic in one place, you don’t have to search for every thing you need to change and risk missing a spot, and your design just makes more sense when logic for one thing isn’t smeared across multiple objects.

Polymorphism isn’t the only way to fix a switchy smell, if your method switches on a parameter that’s passed in, you may want to change it to separate named methods to more directly do the thing. If you have a setProperty(String name, String value) method, you could replace it with named methods like setType, setModel, setYear, etc. You might end up with a lot of little methods, but it’s still clearer than one setProperty method with a giant switch. If you end up with a truly excessive number of methods, that’s another code smell that points to your object doing too much.

Just because switch statements are sometimes a problem doesn’t mean they always are. Sometimes what you’re doing is so simple that an interface and a set of objects that implement it (or changes to your existing interface and objects) makes your code more complicated rather than less. And sometimes there just isn’t a better way to do it: factory methods and abstract factories rely on switches or a series of ifs to figure out which implementation to return.

Lastpass tip of the day

LastPass tries to be helpful by filling in form fields for you, but sometimes it gets it wrong. If you see it fill in the wrong data or if you just mysteriously struggle to sign into services that use 2FA (for me LastPass was helpfully inserting an old 2FA code when I tried to sign into AWS, which meant AWS thought my authenticator app was wildly out of sync and would make me resync it every time I tried to log in), follow these steps and see if it helps.

In case that link ever stops working, you’ve got to find the problem site in your vault, click the little wrench icon to edit that site, then click the little wrench icon again in the edit popup to edit form fields, then delete all the fields with bad values. There may be quite a few of these.

Credit where it’s due, one of my coworkers told me about this. Thanks Logan, I don’t know if I ever would have found that on my own!

JUnit tip of the day

Fun fact about JUnit tests: if something throws an exception that prevents your test from completing normally, it can’t clean up after itself. Normally this isn’t a big deal but if, for example, your setup method adds any test data to your database or creates a whole new database, you’re going to need to clean that up manually. Turns out extra databases eat up a lot of hard drive space if you don’t tidy them up for, uh, months. Just fyi :)

Link of the day

Conveniently enough, I’m not the only blogger on a “be a better programmer while still having a life” kick. If you’re interested in more tips about becoming a better programmer, check out Itamar Turner-Trauring‘s excellent post about learning more tools and techniques while you’re at work.

While you’re at it you should check out Itamar’s Software Clown newsletter, it’s full of great mistakes you can learn from and maybe even avoid running into yourself :)