我们的软件目前有很多功能。我被要求制作一个免费试用版，其中包含完整软件的轻量级版本。试用版中只有少数特定功能可用。而且由于 jar 文件没有加密，我不愿意发布带有硬编码限制的完整版本。我希望能够拥有 2 个罐子：1 个包含基本功能，1 个包含高级功能。
这些功能位于不同的菜单中。当非付费用户选择高级菜单时，如果代码会尝试在启动时加载具有额外功能的 jar 并显示一条消息（例如：此功能在试用版中不可用），那就太好了。另一方面，有权访问高级功能 jar 的付费用户不会知道其中的区别（我说的是现在 1 个 jar 和新方法 2 个单独的 jar 之间的区别）。
编辑：到目前为止最好的建议描述了如何做我的 crippleware，但也警告我不要做 crippleware。那我该怎么办？
正如您所提到的，您可能会有 2 个罐子：
1 具有基本功能和用于高级功能的存根。1 具有实际的高级功能。
您可以使用带有配置设置的工厂类来确定是创建存根类还是真正的类——例如“FancyFeatureClass”或“FancyFeatureClassStub”。“FancyFeatureClassStub”将包含在“lite”发行版中，但“FancyFeatureClass”只会在高级功能 jar 中。
如果他们试图更改配置设置以创建真正的类，而没有真正的类的 jar，他们最终会得到 class not found 错误。
升级时，将高级功能 jar 添加到类路径并更改配置设置以告诉工厂类创建真正的类而不是存根。假设您的应用程序可以这样拆分，它应该可以正常工作。
至于常见的错误——我想你已经犯了一个——不过可能不是你的错:)
“Crippleware”是评估产品的不好方法。最好发布一个带有过期或唠叨屏幕的全功能版本，而不是发布一个残缺的产品。没有这些高级功能可能会使某人难以真正评估产品。
使用一个单独的 Jar 来实现付费功能（以及一个单独的 lite 前端，如果它得到一个 ClassNotFoundException，它会显示一个合适的消息，如“不可用”）将是最简单的方法。
有许多框架，包括 Eclipse RCP，用于以模块化形式分发 UI 应用程序 - 但这对于您的需求来说太过分了。
事实上，您甚至不需要两个 Jar，只要您的构建过程可以选择编译/打包 Jar 中作为分发过程的一部分构建的 Java 类的子集。只是不包括付费功能。
许多技术允许插入功能（通常称为插件或插件）。
这个想法是您的核心代码（或框架）声明了一些接口（一个经过深思熟虑的 API 是理想的）。插件可以提供接口的新实现，并将其注册到框架中。
在其启动序列中，您的框架将查看（通过一些约定，例如在文件中）是否有插件，并让它们有机会执行自己的启动序列，包括注册。
在启动阶段之后，一个运行时示例（用于菜单）：框架在他存储菜单的注册表中查找它。注册表包含框架自己声明的菜单，以及插件提供的任何附加内容......它显示了所有这些。
如果您特别想要您要求的行为，我将按如下方式实现：
这样，您的付费用户将拥有所有正常功能，试用版会显示警告。
存在许多技术来实现这一点，最佳选择取决于您已经知道/使用/感觉舒适的内容：