Posted tagged ‘Java’

Learning notes from a C++ n00b – Part 1

August 25, 2010

I am primarily a Java developer. My college decided in my sophomore  year to switch from C/C++ to Java for most of the classes. While it did give me a very good foundation in Java development, it created a bit of a gap in my education. While I’ve done work in C in the past, I haven’t had the opportunity to work on a serious project in C or C++. Since my goal is always to learn a language a year, starting now C++ will be that language. It should be exciting.

Get excited by vintage letterpress

I'm excited. Are you excited? You're probably not. You're probably thinking "Why don't you already know C++? What sort of developer are you?" Well to find out, you should keep reading!

This post is the beginning of a series describing my process of exploration and discovery into the wonderful world of C++ from the perspective of a Java programmer. I imagine that some people who know C++ and Java are getting out popcorn waiting for the inevitable meltdown with dealing with things like memory leaks, makefiles, platform differences, and probably a bunch of other common issues I know nothing about. While that may eventually be the case, I’m not there yet.

Immediately, one of the biggest departures between Java development and C++ development is the change in IDE. For Java development I’m a big fan of IntelliJ IDEA. Java has a lot of import statements that involve very long package names and an IDE like IDEA tends to take care of that for you. Refactoring, like changing method or class names, is easy since I don’t need to manually find all usages and change them. Autocomplete and click jumping to method or class definitions is also very handy. The integrated debugger is useful when needed, and I like that it can easily import maven pom files as projects. While I’m definitely a proponent of being able to program in your language without an IDE (you shouldn’t let your IDE program for you), it still can be a useful tool at times.

My new IDE for C++ is vim. Ok, I don’t know if I’d really call it an ‘IDE’ exactly, but it’s my editor. I like vim overall, and I’ve been an avid user of it for about 7 years, so I can maneuver my way around. After reading about ctags, I wrote a script to generate them so that I can use it to jump between functions and methods. I’m pretty sure I’m not using it correctly however, as I have a tags file in each directory and I think the editor doesn’t always pick up all of the tags files I want. I have no idea how to use a debugger, and dealing with import statements is still a pain. Overall though vim is very fast and never hiccups unlike IDEA, so that’s a plus.

Another large departure from Java development is going from maven to makefiles. In Java I can create a maven pom.xml file to list all of my dependencies and plugins. Maven supplies a natural file structure that I can use to arrange my files into packages and place external resources in a place where the classpath will pick it up. There are tools to automatically create stub maven projects that I can just jump into and start coding. I can have any tests in my test directory automatically run just by calling mvn test. I can compile my project using mvn compile, and I can package it all up into a nice jar or war file by using mvn package. These are all default things that come with maven. It takes care of running the javac command to compile my code. It also sets up a testing environment for running tests. A very handy tool.

So makefiles. Makefiles sort of remind me of ant. I never really got into ant because it’s fairly verbose. It requires you to be more explicit in telling the system what to do and how to do it. Really though, makefiles are a bit less useful than ant, as they seem to be more like elaborate shell scripts that use the make utility to run. I still have to put in all of the g++ commands, along with lines of what libraries and other sources to give to the linker. Dependencies have to be accounted for manually. Tasks like clean or test have to be defined along with instructions for what those things actually do. There is no standard setup with clean interfaces for running tests or setting up your file structure. The main positive aspect that makefiles have over maven pom files is that a single makefile can generate several different deliverables (pom files only create a single jar).

I know that there are tools such as autoconf and automake that is supposed to make makefiles more portable to deal with library issues, but they’re not very easy to use. The GNU tool chain has a fairly extensive manual, but it feels like one needs to read the entire thing before even getting started. I haven’t had the time, so the GNU tool chain hasn’t entered my arsenal yet. I’m still not sure how to deal with the library distribution issue, but I’m sure that will come with time.

This is the book I'm currently learning C++ from. It doesn't get into the surrounding tool chain like make or the compiler much, but it's still useful for the language itself.

I’ve only been really looking deeply into C++ for a week or two now, and there are a lot of questions that pop into my mind. I have certain philosophies dealing with programming that I’ve gained over the years. A lot of those practices have been fueled by ideas from the Pragmatic Programmers. Others I have developed on my own. I’m still uncertain as to how to incorporate some of these ideas in my C++ development.

The first and most important of these is unit testing. Java has some very standard unit testing frameworks with JUnit and TestNG. Boost has a library for unit testing C++, and so does Google Test, but I have yet to delve into either of these deeply. Also I’m not sure if there’s a standard way of running tests like you can find with Java. Making sure that each test is in its own section in a makefile doesn’t seem very appealing. Hopefully I’ll find a nice way to easily unit test code (including using mocks), I’m just not there yet.

Also, how do you profile C++ code? I’ve used a tool called yourkit for Java which works very well. I know that there must be profilers for C++, but I don’t know what they are or how to use them. Similarly, debugging is an area that is still very grey. I know that there’s gdb, but I haven’t found a good tutorial on how to use it or how to integrate it into vim or some other editor to set breakpoints and see variable values.

And honestly, while I understand the basic concepts of pointers, I’m still unsure as to when to use them and how to fully utilize their functionality. In Java everything is done by reference (except primitives) and there’s a garbage collector when items go out of scope. When passing any object to a method, it can be modified by that method. I still need to learn a bit more about how scope effects both objects created on the heap and other objects in C++.

Overall there has been a lot of learning in the short time that I’ve been playing around with C++. While I’ve used Objective-C in the past for some iPhone programming, I haven’t really seriously taken on any projects in C++. The learning experience has been great, and quite a bit of fun. While most people would probably argue that makefiles are really annoying to set up, I’ve been enjoying the learning process of figuring out how to use them and creating working builds. My tests have all been small at this point, but they’re sure to grow in size. That said, I know I still have a lot to learn. I shall be delving deeper into the Boost libraries and doing multi-threaded programming with some asynchronous socket connections. I’ll be sure to update again after having gained a bit more experience.

20 second builds

June 11, 2010

Back in May of 2007, Linus Torvolds did a talk at Google about git. Specifically he tended to reiterate the point on how your workflow changes dramatically when you can perform a merge or get new code from other people in under a second. Merging multiple branches into your own branch without remembering revision numbers and knowing that your history is in tact, being able to view the entire history of a project without an internet connection, and just being able to work with your version control system in sub-second time can change how you work with your code. You become willing to make branches because it’s so cheap and easy. You can try out new things quickly and have an easy way to toss them if it doesn’t work out, or merge back parts if it does. I think that the philosophy of really fast version control and its effects on your productivity are quite real, and very important. I also think that the same mentality can and should be applied to your build process.

An example of how development might work via a revision control system such as git. I just needed a picture. Image provided by wikimedia commons.

Of course the first thing you might think is “There is no way I’m going to get my build down to under a second.” And for anything non-trivial, you’d be right. However, I think having a goal of a build plus unit tests in under 20 seconds is not an unreasonable demand. Even better if it’s under 10 seconds. But projects can get really large and involve thousands of files and a similar set of thousands of unit tests. How can you build all of that in under 20 seconds? The answer is: you don’t. Do I sound contradictory? I’m not, but you might have to change how you think about your project.

The main idea behind getting a build under 20 seconds is that it will allow you to compile what you’re working on and run all of your unit tests so that you can test your changes and see if anything breaks. If your build takes several minutes you’re not going to want to build and run your unit tests until your done. This makes doing Test Driven Development a lot more difficult because if you don’t run your tests constantly, you’re probably not designing around your tests passing. You might write less tests, have a less elegant design, and ultimately produce poorer quality code. But still, a large project with hundreds of thousands of lines of code isn’t going to even compile, much less run all of the unit tests in under 20 seconds, so what do you do?

As with any development problem, you break it down into a smaller and more manageable chunk. Instead of writing a giant application with thousands of different files and unit tests, you write more small libraries and services that hold maybe a few dozen or hundred files and tests that contain decoupled and independent structures. These smaller libraries and services can have their own separate build process as they are all separate small projects in and of themselves. That way you can write just the unit tests relating to those small projects and cut your build times down to under 20 seconds.

Now granted that’s only the build time for one module, but all of them together can still take several minutes. But that’s ok. Most bugs and development that you’re working on will only touch one or maybe two modules at a time, causing you to run the build process for just those modules to fix the problem or add the feature. There’s no need to compile and run unit tests for a lot of other systems that are completely unrelated to what you’re working on. As for if your change will break things in other packages, that’s what integration tests are for.

Besides, if you separate your code into smaller libraries and services, you’ll be providing a natural way of decoupling systems and making them no longer become dependent on each other. If you write good strong unit tests that mock any external entities that are called or would call your service or library, those tests enforce the contract that your other systems will require. This will ensure that changes you make will not break other systems. If the changes you make do break the systems, you just create or modify your unit tests to fail due to this breakage so that you know why your system should output what it does or call who it does.

By driving down your build times by having sections be in separate projects, you will have faster turnaround and feedback on the work that you are doing right now. You can run a build right after changing a single line of code just to make sure, and 20 seconds isn’t too long of a wait to get a response. It’s almost like a small break, but no quite long enough that you start trolling slashdot and forget you’re building something.

I feel this post needs another picture, so here's my cat Mischief playing with some rope.

Java’s flaws: Why Primitives Are Bad

February 23, 2010

I use Java every day for the majority of my work. This isn’t that uncommon, as Java is one of the most used languages in businesses today. While the language has improved greatly from it’s 1.0 release, some of the legacy features still make working with the language very painful.

Primary I’m talking about Java primitives. Primitives in Java were one of the features taken from languages such as C and C++ that really should have been left out. If it weren’t for those 8 primitive types, Java would be a real Object Oriented Language. Because of those primitives, we can’t really call it that, which can cause some problems when using some OO methodologies.

The reason why primitives are bad is that they are not Objects. A primitive is not extended from the Object class like every other Object in Java. This reduces a primitives ability to participate in polymorphism by casting to the Object class. If a data type cannot be cast as an Object, it is unable to participate in generic methods that accept Objects as their argument.

Of course the first argument someone will bring to me is the availability of Autoboxing that came with Java 1.5. Autoboxing will automatically convert a primitive to its Object counterpart and visa versa on the fly with no additional programming thought. Problem solved right? Well not exactly.

You see while base primitives can be converted automagically to Objects via autoboxing, primitive arrays cannot. Ok well sure they can be created and cast to an object, but the resulting object cannot be initiated via reflection. This is because the ‘class’ of a primitive array has no constructor since it’s not a real Object.

So why would anyone want to create a primitive array, cast it to an object, just to create a similar one again via reflection? Who messes with reflection anyway?


If you’re mocking an interface where one of the methods utilizes a primitive array as a parameter, JMock cannot create an expectation for that method being called by passing it in the class of the parameter because the parameter cannot be initiated via reflection. The best you can do is use an expectation that ignores all calls to that mocked object, but then you can’t verify that a method gets called or called a certain number of times.

Why would you even have an interface that used a primitive array rather than an array of the Object wrapper? Well Java has several built in such as String.getBytes(). There are 3rd party transmission libraries that send byte arrays over the wire to a receiver which cannot be tested due to the method signature having a primitive array.

It’s possible that I haven’t dived far enough into the language to find a work around for this language flaw yet. Perhaps it is possible to utilize primitive arrays as objects for mocking that I haven’t discovered. Unfortunately, forums don’t yield much else of interest on the topic either.

If anyone knows of a way to create a JMock Expectations object with a primitive array parameter in one of the mocked method calls, let me know. I’m at a loss and not very fond of the language at this point.