the duke is back, or i find i can’t do without java

1000px-wave-svgBack on 14 July I wrote a post titled “no more java“, in which I swore off the use of Java for everything new and to “walk away from any Java programming opportunity.”

It turns out that there is, practically speaking, no way for me to do that. As much as I despise Oracle, the use of the language throughout the last 21+ years of my software engineering career (Java officially turned 20 in 2015) isn’t something I can just blithely walk away from. As I came to discover over the last 60 days, while there are a lot of very good programming languages besides Java, there are some things for which Java is the better fit, warts and all.

That’s not to say I didn’t find the other languages I looked at as less than Java. I found them all quite compelling in their own rights. The languages I did go back and look into included Python, C-Ruby, JavaScript (via node.js), the latest stable version of C++ (C++14 via gcc and clang), Google Go (up to 1.7) , and Rust (up to 1.11). Notable by its absence is Swift. I chose not to dive into Swift because it’s still only on one platform (OS X, soon to be called macOS) and because it’s still in a state of flux as it transitions to Swift 3.

All those languages I did look deeply into were quite compelling in their own rights and offered powerful solutions for different classes of problems. And while they tended to overlap some features and capabilities of Java, they could never replace Java for the types of software problems I like to work on. And please note, when I speak of the languages I also speak of the development, build, test, and deployment tools that wrap a language and help make it a powerful problem solver.

I don’t consider my two months looking elsewhere a waste of time; far from it. It was an eye-opening trek into languages I would have never taken otherwise, as well as a deeper dive into some languages I’d had considerable experience with before, such as Python and Ruby (in fact, working with Python 3.5 was almost like re-learning the language, as the last version I’d touched was 2.4). With Java I’d grown a bit stale in my thinking, which is never a good thing. Looking at other programming languages fosters opportunities to expand perspectives and offers alternative solutions to tough problems for which Java might not be the best fit. It also illustrate ways to weave these “new-ish” solutions back into new and existing Java solutions.

And finally, by taking two months away from my Java work, I discovered when I came back that tough problems I couldn’t quite solve before were suddenly solvable, some of them quite easily so. I really needed a break away from Java.

So it’s back to Java, or more precisely, the Java Virtual Machine (JVM). For with the JVM I also have Scala, Groovy, Gradle, and JRuby, not just Java 8. I’m using the Actor pattern¬†Futures and Promises and the Parallel Collections Library supported by Scala for modeling and simulation, while using Groovy and JRuby to solve unique problems while calling down into the Java libraries, especially for UI bits. And finally I’m getting the hang of using Gradle as my primary build, test, and deployment framework. I am so tired of Ant and I’m no fan of Maven either.

I need to do this again, at least once/year, to maintain a clear mindset and fresh perspective. I look forward to my next walk-about through the programming language landscape.

wordpress code rendering bug 

I share code on my blog from time to time in order to illustrate key points. In order to display code I use the code tag provided by WordPress. Most of the time I have no problems with displaying code, especially on any of the desktop browsers across the Mac, Linux or Windows operating systems. The only time I have a problem displaying code is on any iOS-hosted browser such as Safari, Chrome, or Opera. But before I show you the problem on iOS let me show you how successfully it renders under Android Chrome (Android 6.0.1 on a 2013 Nexus 7).

This is the prior blog entry with a Makefile and a C++ source file. The Makefile is being displayed properly. Note in particular how the text is of the proper size and alines correctly with the line numbers to the left. Now look at Chrome on iOS 9.3.1, the current release, on an iPad Air 2.

The source code file for the Makefile is grossly oversized. This poor source file display shows like this on any iOS browser, not just Chrome. And that’s because Apple forces all browsers to use the same Apple-provided rendering engine. Thus, it’s not just a problem with Chrome on iOS, but with every browser on iOS, because it’s an Apple problem. I should note that all browsers on Android render source code on my WordPress blog correctly. They each have their own rendering engines, and they all handle this correctly.

writing safe code

What with the all the hoopla these days about the Internet of Things and the simply horrible (horrible, I tell you!) lack of security in many of these devices, I thought I’d throw my two cents into the discussion about simple but effective things you can do to help make such devices more secure. No, really. I’ll start my pontificating off by doing what I do best, writing a small, sloppy C++ program to illustrate a point.

#include <cstring>
#include <iostream>

int main() {
	char *inputBuffer = new char[10];
	char *inputBuffer2 = new char[10];

	std::cout << "Type something: ";
	gets(inputBuffer2);
	std::cout << "You typed 1st: " << inputBuffer2 << " : " << std::strlen(inputBuffer2) << std::endl;

	std::cout << "Type something: ";
	gets(inputBuffer);
	std::cout << "You typed 2nd: " << inputBuffer << " : " << std::strlen(inputBuffer) << std::endl;
	std::cout << "You typed 1st: " << inputBuffer2 << " : " << std::strlen(inputBuffer2) << std::endl;

	return 0;
}

The program throws out prompts asking you to enter strings of text. It places the string input into two character arrays, inputBuffer and inputBuffer2, using standard C’s gets(), one of the most unsafe ways to do this. As a consequence this program is Unsafe; if compiled with gcc/g++, the resultant compiled application will actually issue a “warning: this program uses gets(), which is unsafe.” warning when executed. Programmers who use standard C’s gets() are just begging to get mugged on dark streets in the big city.

The single biggest problem with this program is it’s using standard C’s gets() to read data and to place it into the two arrays. Why is that a problem you innocently ask? Both arrays are limited to 10 characters each. Standard C’s gets() doesn’t care one wit how many you enter. You can blow right past that limit by typing any string greater than 10 characters and gets() will happily put all that input into memory, starting with the zeroeth character location of both arrays. Absolutely no attempt is made to limit input. Now watch what happens when my small sloppy example’s run.

Type something: first input string
You typed 1st: first input string : 18
Type something: SECOND INPUT STRING
You typed 2nd: SECOND INPUT STRING : 19
You typed 1st: ING : 3

Oh my goodness, what happened? Because of the way I allocated those character buffers, and then the way I used them, my second input string overwrote my first. In other words my second input string data corrupted my first input string. Thus printing my first input string actually printed the last three characters of the second inputed string. And that’s because both character arrays were allocated with only ten characters each. How should it look if it were safe? Let’s look at the same code, but written not nearly as sloppily. I’ll replace the bare allocated character arrays with instances of C++’s std::string and use C++’s getline() standard library call.

#include <iostream>

int main() {
	std::string inputBuffer;
	std::string inputBuffer2;

	std::cout << "Type something: ";
	getline(std::cin, inputBuffer2);
	std::cout << "You typed 1st: " << inputBuffer2 << " : " << inputBuffer2.length() << std::endl;

	std::cout << "Type something: ";
	getline(std::cin, inputBuffer);
	std::cout << "You typed 2nd: " << inputBuffer << " : " << inputBuffer.length() << std::endl;
	std::cout << "You typed 1st: " << inputBuffer2 << " : " << inputBuffer2.length() << std::endl;

	return 0;
}

Now let’s run that code and see what happens:

Type something: first input string
You typed 1st: first input string : 18
Type something: SECOND INPUT STRING
You typed 2nd: SECOND INPUT STRING : 19
You typed 1st: first input string : 18

Now the strings are behaving the way you’d expect them to. Both are read in and neither one overwrites the other. The key to this is reasonable resource management. I used the C++ string class to provide simple but effective character resource management. No matter how many characters I typed in at the prompts, both string instances would have provided the necessary space internal to each instance to hold those characters, without having to worry that one would corrupt the other. So remember folks, in spite of what Linus says about C++, it’s actually better to use C++ than bare-bones C, even if fgets() is better than gets() in standard C.

I’m writing about this specific kind of programming because a lot of security exploits occur when resources aren’t properly managed and buffer overflows occur. Buffer overflows can result in everything from data corruption to the execution of arbitrary code, leading to permission escalation and all sorts of mean nasty things.

Good resource management can take you a long way in programming. Now if you can just remember not to hard code back doors into the code…

haiku

Haiku running in VMware Player on Windows 8.1 host

Haiku running in VMware Player on Windows 8.1 host

So I’m sitting in my hotel room late one evening here in Tokyo, and for whatever reason I got a wild hair to try out Haiku in VMware Player (version 6.0.5 build-2443746, the latest). Maybe it was this recent article about it on OSNews that got me curious. Installation is certainly simple enough. And once installed it came up and allowed me to play with it a bit. It’s the first time in years I’ve tried Haiku, and from my experience with BeOS, it’s as close as I remember BeOS 4 and BeOS 5 running on one of my very ancient boxes around early 2000 (oh my, fifteen years ago…).

In this case I fired up the old GL Teapot demo and then brought up Windows 8.1’s resource monitor. 360 frames/second isn’t too shabby, especially for a VM. If I did decide to contribute or otherwise fool around with this OS, running it on the VM would certainly be quite doable. The only problem (so far) is moving files back and forth between the VM and the local host. I can’t install the VMware Tools on this VM.

Considering just how light-weight (i.e. resource usage wise) that Haiku is, it makes me wonder how hard it would be to port this to ARM and something like the Raspberry Pi 2 with its quad-core ARM v7 chip. There seems to have been some interest in cross-compiling to the earlier RPi back around 2012, and there’s a page on the Haiku wiki about compiling Haiku for ARM. Not that I have a lot of cycles these days. I guess we’ll just have to wait and see. I would certainly use it as an alternative to Linux on those boards.

Certainly something to think about.

adding library dependencies in android studio beta 0.8.9

In creating a new Android 5/Lollipop app that uses the latest Material Design, I created a new project and selected Android 5 (API 21) (NOT API 20+: Android L (Preview)!). In the process of bringing up the application, Android Studio threw exceptions that it couldn’t find Java class android.support.v4.view.View, among others. To solve this problem I had to add a support library (also known as a library dependency) to the project. This is accomplished via File > Project Structure (Ctrl + Alt + Shift + S) to bring up the Project Structure window.

To add a library dependency, select the Dependencies tab at the top right, click on the plus symbol on the far upper right (see big red arrow above) and then click “1 Library dependency.”

This brings up the “Choose Library Dependency” dialog. I’ve stretched it out to show all that are available to me. You selection will be dependent on the all the APIs you’ve chosen to support. I’ve highlighted the v4 support library. Once you’ve selected the dependency library you need click “OK” all the way back. Once that’s done the project will resync itself, and if you’ve found all the dependencies that project says it needs, Gradle will complete successfully.

Editorial Comment

I realize this is beta code. But this was a new project and all dependencies should have been automatically settled during the creation process. The way Android Studio is behaving right now it’s as if it were still late stage alpha code.

This is also one of the worst UI examples I’ve ever come across, bordering on disastrous. None of this is intuitive, all the way from digging out the main dialog. I know that Google didn’t write the IDE, but they selected it, and they now share responsibility for how bad it is. And this is very bad indeed.