那么通过接口调用是不是就行了呢？我们可以定义一个IFoo接口，其中声名sayHello方法，Foo实现该接口。也就是这样：IFoofoo=(IFoo)cls.newInstance();本来该方法也会有同样的问题的，因为外部声名和转型部分的IFoo是由run方法所属的类加载器加载的，而Foo类定义中implementsIFoo中的IFoo是由HotswapCL加载的，因此属于不同的类型转型还是会抛出异常的，但是由于我们在实例化HotswapCL时是这样的：
23.HowswapCLcl=newHowswapCL("../swap",newString[]{"Foo"})；
其中仅仅指定Foo类由HotswapCL加载，而其实现的IFoo接口文件会委托给系统类加载器加载，因此转型成功，采用接口调用的代码如下：
24.public void run(){
25. try {
26. HowswapCL cl = new HowswapCL("../swap", new String[]{"Foo"});
27. Class clcls = cl.loadClass("Foo");
28. IFoo foo = (IFoo)cls.newInstance();
29. foo.sayHello();
30. } catch(Exception ex) {
31. ex.printStackTrace();
32. }
33.}
确实，简洁明了了很多，在我们的实验中，每当定时器调度到run方法时，我们都会创建一个新的HotswapCL实例，在产品代码中，无需如此，仅当需要升级替换时才去创建一个新的类加载器实例。
在线升级系统的设计原则
在上小节中，我们给出了一个Java类热替换的实例，掌握了这项技术，就具备了实现在线升级系统的基础。但是，对于一个真正的产品系统来说，升级本省就是一项非常复杂的工程，如果要在线升级，就会更加复杂。其中，实现类的热替换只是最后一步操作，在线升级的要求会对系统的整体设计带来深远的影响。下面我们来谈谈在线升级系统设计方面的一些原则：
◆在系统设计一开始，就要考虑系统的哪些部分是需要以后在线升级的，哪些部分是稳定的
虽然我们可以把系统设计成任何一部分都是可以在线升级的，但是其成本是非常高昂的，也没有必要。因此，明确地界定出系统以后需要在线升级的部分是明智之举。这些部分常常是系统业务逻辑规则、算法等等。
◆设计出规范一致的系统状态转换方法
替换一个类仅仅是在线升级系统所要做的工作中的一个步骤，为了使系统能够在升级后正常运行，就必须保持升级前后系统状态的一致性。因此，在设计时要考虑需要在线升级的部分所涉及的系统状态有哪些，把这些状态设计成便于获取、设置和转换的，并用一致的方式来进行。
◆明确出系统的升级控制协议
这个原则是关于系统在线升级的时机和流程控制的，不考虑系统的当前运行状态就贸然进行升级是一项非常危险的活动。因此在系统设计中，就要考虑并预留出系统在线升级的控制点，并定义清晰、明确的升级协议来协调、控制多个升级实体的升级次序，以确保系统在升级的任何时刻都处在一个确定的状态下。
◆考虑到升级失败时的回退机制
即使我们做了非常缜密细致的设计，还是难以从根本上保证系统升级一定是成功的，对于大型分布式系统来说尤其如此。因此在系统设计时，要考虑升级失败后的回退机制。
