I figured I’d see what happened if I added all the JPA Entity classes to the persistence.xml file and didn’t update the database. Since none of the existing JPA Entity classes was changed, the application appears to work fine without the tables in the database.

This is good news for me as it allows me to ship new versions of the application without any fear of breaking customers who don’t update their database. This is true only if that customer doesn’t use any of the new features that access the new tables.

    "attach: task_for_pid(59980) failed (5)"

I was also getting errors inside VisualVM and from the command like using jmap that went like this:

Attaching to process ID 61218, please wait...
sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "heapOopSize" in any of the known library names (-)
	at sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:399)
	at sun.jvm.hotspot.HotSpotTypeDataBase.readVMIntConstants(HotSpotTypeDataBase.java:319)
	at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:88)
	at sun.jvm.hotspot.MacOSXTypeDataBase.<init>(MacOSXTypeDataBase.java:36)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:578)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:499)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:337)
	at sun.jvm.hotspot.tools.Tool.start(Tool.java:163)
	at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:77)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at sun.tools.jmap.JMap.runTool(JMap.java:179)
	at sun.tools.jmap.JMap.main(JMap.java:110)
Debugger attached successfully.
sun.jvm.hotspot.tools.HeapDumper requires a java VM process/core!

And I also got some other strange errors from jmap like this one:

61218: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

I opened an issue with the VisualVM team and they tested things out on Snow Leopard and said it all worked fine. I figured they were smokin’ something and decided to try a Sun product and see if it worked. I fired up NetBeans and sure enough, VisualVM and jmap worked great. This indicated it was definitely a VM configuration issue.

Here’s the what you need to do to get your Java applications working with the VM tools on Snow Leopard. Add the following parameters to the java command and everything will start working fine:

java -Xverify:none -Xshare:off -Xcom.sun.management.jmxremote

The -Xverify:none is the setting that allows VisualVM and jmap to capture thread dumps. Without this setting, you’ll get strange errors like those above. The -Xshare:off gets VisualVM working without any startup errors or random failures. The last setting is really just for JConsole and other JMX tools.

Enjoy!

When assigning a reference return value to a variable, a copy is made. Here is an example:

class References {
private:
    std::string name;

public:
    References(const std::string& name) : name(name) {
    };

    virtual ~References() {
    };

    const std::string& getName() const {
        return name;
    };
};

References r("foo");
std::string n = r.getName();

This code makes a copy of the name member variable from the References class and puts the copy into the variable n.

Assigning reference return value to a reference variable

When assigning a reference return value to a reference variable, no copy is made. Here is an example:

class References {
private:
    std::string name;

public:
    References(const std::string& name) : name(name) {
    };

    virtual ~References() {
    };

    const std::string& getName() const {
        return name;
    };
};

References r("foo");
const std::string& n = r.getName();

This code does not make a copy of the name member variable. Instead, the reference variable is now a reference directly to the member variable inside the class.

Passing a reference return value to a method that takes a reference

When you pass the return value from a method that returns a reference directly into a method that takes a reference, no copy is made. Here is an example:

class References {
private:
    std::string name;

public:
    References(const std::string& name) : name(name) {
    };

    virtual ~References() {
    };

    const std::string& getName() const {
        return name;
    };
};

void print(const std::string& s) {
    ...;
}

References r("foo");
print(r.getName());

This passes the reference returned directly into the method as a reference. Therefore, no copy is made.

Using a reference method in a comparison operator

This is the same as the method invocation example above because all operators take references.

1. Open up Terminal (Google it if you’ve never done it)
2. Type in ‘cd /var/vm’
3. Type in ‘rm sleepimage’

It looks like this:

$ cd /var/vm
$ rm sleepimage

This should fix any issues with sleeping and waking up. The root cause is that if you move the machine to fast, have any static electricity and shock the machine, or otherwise jostle it too much when it is going into sleep mode (just after you close the lid), the sleep image will become corrupt and you’ll start having issues.

FooBuilder builder = new FooBuilder();
Foo foo = builder.add(...).divide(...).multiple(...).builder();

The issue that arises is that I want to store a bunch of methods in a base class that various builders can use. In order to do this correctly, I have to really hack up my classes with some strange generics and unchecked casts like this:

public class BaseBuilder<T extends BaseBuilder> {
  public T add(...) {
    ...
    return (T) this;
  }
  public T divide(...) {
    ...
    return (T) this;
  }
  public T multiply(...) {
    ...
    return (T) this;
  }
}

public class FooBuilder extends BaseBuilder<FooBuilder> {
  public Foo build() {
    ...
  }
}

This is really annoying. I think every class should have a generic type variable that references the current type and let the compiler figure it out. Just name the variable ME or something. It would make the code look like this instead:

public class BaseBuilder{
  public ME add(...) {
    ...
    return this;
  }
  public ME divide(...) {
    ...
    return this;
  }
  public ME multiply(...) {
    ...
    return this;
  }
}

public class FooBuilder extends BaseBuilder{
  public Foo build() {
    ...
  }
}

Now that’s much nicer looking.

Let’s say we have this:

public void callSomeMethod(Object obj) {
  obj.methodCall();
}

In static languages this fails because Object doesn’t contain the method methodCall. However, what if we told the compiler to create a new interface based on the content of the method? This code would then look like this:

public void callSomeMethod(autotype obj) {
  obj.methodCall();
}

The autotype keyword would cause the compiler to actually create this code:

public interface MethodCallInterface {
  void methodCall();
}

public void callSomeMethod(MethodCallInterface obj) {
  obj.methodCall();
}

This would now compile. Next, a caller to this method could pass in any object whose type the compiler could add this interface to. If you called it like this:

public class MyClass {
  public void methodCall() {
    System.out.println("Here I am");
  }
}

// Some other code somewhere
MyClass mc = new MyClass();
callSomeMethod(mc);

The compiler could take the interface it created for this method call and then see if the type passed in could implement that interface. If MyClass has already been compiled, it could do one of two things:

• If MyClass is accesible as part of the current compilation unit, it could update the compiled Class to implement the interface
• If it isn’t part of the current compilation unit and isn’t final, it could create a proxy for the call that implements the interface and delegates the call

Not sure yet how #2 really works or if it even makes sense to do it that way, but it seems to be the only way to make it work if the Class is in a JAR or DLL or something like that.

The only issue would be reflection. How could you reflection on the method and then pass an Object to it so that it would not completely blow chunks at runtime? Perhaps the reflective method invocation could determine if the object being passed could be proxied to the dynamic interface and then create a proxy on the fly.

Anyways, just pondering type systems in general today….

1. The std::sort function really only works with vector
2. If you want to sort a set of pointers, you’ll need to create a comparator function or object and use it as a type parameter (uglier than hell)
3. If you want to sort a list, you MUST call the sort method on the list

#2 looks like this and really sucks to look at:

set<string*,StringPointerComparator> myset;

And if you want to pass that thing around, you have to either pass it like that (nasty) or typedef it. Since I hate all typedefs, macrodefs, etc, I generally pass that nasty full type around.

The phones

Keyboard

The winner: G1

The G1’s keyboard is awesome. I like it so much better than the iPhones mainly because I can see the whole screen while typing, but also because it has numbers and I don’t have to hit something to switch between numbers and letters. I’m a keyboard freak, so hands down the G1 wins.

Screen

The winner: iPhone

I think this is close to a tie, but the iPhone screen is bigger. The resolution is the same for both phones, which means that the G1 can display as much information as the iPhone, but it is smaller.

Battery

The winner: iPhone

The iPhone’s battery is 2-3 times better than the G1’s. I’ve heard word of T-Mobile shipping out batteries that add 30% more life, but even still, I play around with my G1 very little and it still needs to be charged daily. My iPhone needs charging every 2-3 days with the same use.

Form factor/Design

The winner: iPhone

This isn’t much of a battle. The iPhone is sleek, light and really nice to look at. The G1 is thicker, heavier and an eye-sore comparatively. However, I can understand the extra size given the full keyboard. One thing the G1 does nicely is it figured out the exact size required for anyone to hold it in one hand and use any feature of the phone. This is the only thing nice about the G1’s size and shape.

Buttons

The winner: G1

I like the buttons and track ball with the G1. The iPhone is sometimes a bit cumbersome to use given that everything is on the screen. Sometimes it is nice to just hit a button.

Accelerometer

The winner: iPhone

The iPhone has a really good accelerometer that seems to be level and responsive. The G1’s is a little rough around the edges and you can’t calibrate it or tweak it at all.

The operating systems and software

Structure

The winner: Android

Android has a lot of advanced features that are pretty nice overall. Each application has a menu, which is great for adding loads of functionality. There are keyboard shortcuts in applications which makes using features fast. Android has intents which are nice. It also allows applications to leverage other applications and common libraries. By far, Android wins when it comes to a modern platform.

At the same time though, Android has many bugs and issues that also make it difficult to actually use.

Homepage/Application Chooser

The winner: Tie

The iPhone home page doesn’t have the cool backgrounds or the lame analog clock or the drag and drop application display, but it is simple, orderable (you can move apps around), and looks really nice. Androids has a cool homepage that allows ordering and an alphabetized app chooser. So, they are different, but equally as usable and cool.

Androids icons definitely have that Linux look, which I grew tired of a decade ago while iPhone’s icons are sleek and nice and I haven’t gotten tired of yet (only 1 year as a Mac user). It seems like Apple is more in tune with style and each OS release keeps things fresh. We’ll see how 10.6 goes. Linux on the other hand just plain sucks the life out of you.

Voicemail

The winner: OS X

T-Mobile and Android’s voicemail integration is horrible. It is exactly the same as every other phone for T-Mobile because you have to dial into voicemail and manage it via T-Mobile’s phone system. There is an 3rd party application that adds visual voicemail to Android phones, but it is in beta and it is a hack that appears to actually dial up your voicemail and record the voicemails to an MP3. I’m not positive on that, but this is what it seems like. Regardless of how this application works, it is a 3rd party application and T-Mobile and Android should really be offering a tightly integrated feature of the phone.

The iPhone completely integrates with AT&T’s voicemail such that you can view all your voicemails on the phone, listen to them on the phone, and even setup and switch your voicemail greeting on the phone.

Calendar

The winner: Android

The Android Google calendar integration is great. However, it doesn’t support multiple calendars very well (you can only view calendars in the associated GMail account and not other GMail accounts or an Exchange calendar) and that’s a real pain point for most. Since I use a single calendar for everything, I don’t mind too much. On the other hand, if you have a Mac and only use Calendar.app, integration with the iPhone is great. This combined with Mobile Me would be ideal for real-time updates and syncing. For now though, Android wins in this department.

I’d imagine that Google will soon offer syncing with the iPhone as it does with the BlackBerry. If not, NuevaSync will work once it is finished and out of Beta.

Likewise, I would put money that Android will start supporting multiple calendars shortly.

Maps

The winner: OS X

Multi-touch, double-click and good integration/features wins this battle. Since you are already touching the screen to move around, multi-touch is nice. The G1’s map interface is nice and it does allow single handed use, but iPhone’s bigger screen and multi-touch prevail in this category.

Email

The winner: OS X

First, the GMail application really should be combined with the Email application. The fact that they are separate is really painful and annoying. Email should just be email like the iPhone does. Second, Android’s email application is one of the worst applications ever written. Here are a few of the pain points:

• Can’t view first few lines of emails in the inbox view
• The folder and email view are combined making for a very cluttered interface
• Email fails regularly even when connected to a WiFi
• Deleting emails does nothing for GMail accounts via IMAP.
• Can’t setup what happens on delete for IMAP accounts. For example, with GMail IMAP it should move the message to [Gmail]/Trash

The worst thing is probably that the Email application doesn’t instantly work with GMail IMAP accounts. This should just work considering that the entire platform and stock applications are written by Google. I mean come on guys, take a cue from Apple and just make stuff work, especially with your own systems. Plus, Email constantly crashes and has so many issues that it is rendered useless in most situations.

The iPhone email isn’t perfect, but it handles all of these things much better and also makes setting up GMail accounts a snap.

Document Viewer

The winner: OS X

The iPhone has a built in PDF viewer that works really well. It also displays Word documents and other formats decently well. In gets a little bit freaked out by complex Word documents in the new DOCX format, but otherwise it is great. It also allows you to zoom in and out using multi-touch and double-click.

The G1 looks like it uses Google Docs online viewer or some type of hacky internal viewer. Not really sure about which one, but it does a very poor job of displaying documents and files, including PDF (I mean really? PDF? It should perfectly display all PDFs). Images are also displayed poorly and some don’t render correctly, such as JPGs. Plus, no zoom (ouch!).

Apps

The winner: OS X

This is based purely on the most fundamental of all applications, solitaire. There are a number of choices on both phones, but overall the solitaire on the iPhone is much nicely in terms of design, features, etc.

App stores

The winner: OS X

Apple’s store has a much cleaner interface and includes pictures, better details, better commenting system and more interactivity. The Android market looks pretty shabby comparatively.

Accelerometer/Orientation

The winner: OS X

The iPhone uses the accelerometer all over the place and it does it really well. Orientation of the phone is really helpful in most applications as it makes the phone easy to use.

Android’s support for orientation and the G1’s accelerometer is just garbage. Even the browser requires 3-4 clicks before you can change the orientation without opening the keyboard. I mean come on guys, just use the tools you have and make people’s lives simple. Plus, HTC seems like they added a pretty low end accelerometer and it isn’t calibrated very well. Plus, you can’t really calibrate it.

Development

The winner: Android

I’ve talked at length about how I think Objective-C is really keeping Apple back, but here’s another way to look at it. If you take the years that technologies were introduced and line them up so that you have language, RAM, and CPU (based on speed), here are the results:

iPhone: 1986 1989 2000
G1: 1995 1996 2000

I definitely like the G1 and Android numbers much better.

The Final Score

If we add all these up, it looks like this:

G1/Android: 5

iPhone/OS X: 11

The final winner? iPhone/OS X

Mac OS X

#include <sys/time.h>
timeval time;
gettimeofday(&time, NULL);
long millis = (time.tv_sec * 1000) + (time.tv_usec / 1000);

This actually returns a struct that has microsecond precision.

Windows

#include "windows.h"
SYSTEMTIME time;
GetSystemTime(&time);
WORD millis = (time.wSeconds * 1000) + time.wMilliseconds;

This code gives the milliseconds within the last minute. If you want milliseconds since epoch or some other fixed point in time it will require a bit more math on the SYSTEMTIME struct.

class Base {
public:
  virtual ~Base() {};
};

class Derived : public Base {
private:
  set someSet;
public:
  virtual ~Derived() {};
  set getSomeSet() { return someSet; };
};

You might find this necessary if you have some code like this:

class Base {
};

class Derived : public Base {
private:
  set someSet;
public:
  set getSomeSet() { return someSet; };
}

void main() {
  map objects;
  Base base;
  if (objects.find("foo") != objects.end()) {
    base = objects.find("foo")->second; // This is actually a Derived
  }
}

void useBase(Base& base) {
  Derived* derived = (Derived*) &base;
  set someSet = derived->getSomeSet();
  ...
}

This code will toss strange errors such as EXC_BAD_ACCESS and other kernel alarms. I’m not certain way this happens, but I think it is because Derived in the second example isn’t actually an instance of Base since the compiler doesn’t understand that Base is polymorphic. If you try to apply a dynamic_cast operator rather than the pointer cast (as used in example #2) the compiler will complain. What is probably happening is that at runtime the memory for the Derived is not correct because it was cast to a Base, and the kernel freaks out when you attempt to access something in Derived.

Another classic example of C++’s power causing major issues at runtime. These types of problems are not only tricky to figure out, but really only make sense to the kernel and compiler and aren’t obvious from a OO perspective.

Most modern OO languages would have absolutely no issues with the above code, and all dynamic OO languages wouldn’t even need the casts at all and would duck type the invocations via dynamic method invocation.