The LoadType opcode is used to push a Type instance onto the stack. But unlike other "literals" such as Int, Real, Str, and Duration - there are lots of boundary conditions associated with LoadType.

The way I approached the implementation of LoadType in Java was to model it after how Java class literals used to be generated before the JVM allowed use of the LDC opcode with a CpClass index in 1.4:

Class f() { return String.class; }

Got translated into something like:

static Class class$String;

Class f() 
{ 
  if (class$String == null) 
    class$String = $class("java.lang.String");
  return class$String;
}

static Class $class(String name)
{  
  try 
  { 
    return Class.forName(name); 
  } 
  catch(ClassNotFoundException) 
  { 
    throw NoClassDefError 
  }
}

I do something similar for Fan:

Type f()
{
  if (type$sys$Str == null) 
    type$sys$Str = Sys.type("sys::Str", true);
  return type$sys$Str;
}

private static Type type$sys$Str;

Plus since I have a field in Sys for every sys type, I shortcut to those fields if the podname is sys.

What is important that you should note is that if the type cannot be found it will throw UnknownTypeErr (or UnknownPodErr) only when the actual code is executed. This means the an invalid type used in LoadType should never prevent the pod or the type from loading (unless used unchecked in a static initializer).