Invert Your Mind

For some of the Inversoft products I’ve been adding new tables for new features into our standard schema. The tricky part with updating the database is also giving customers all the update scripts that they need to run and instructions on how to run them correctly.

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.

I was attempting to work with VisualVM and Tomcat over the past few days on Snow Leopard and it was constantly failing. I was getting errors like this:

    "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!

Assigning reference return value to a variable

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.

One of the family Apple notebooks (a Macbook) was having some issues waking up from sleep periodically. It was also having issues when the lid was closed the fan would constantly spin as though the machine was overheating. I took the machine into the only Apple store I trust (the main tech there is pretty solid, although he still doesn’t use Terminal). The fix was pretty simple:

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.

I just noticed that I’ve been using the Builder pattern with method chaining a lot. Looks like this:

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.