Java 软件的 Lite 版本
我们的软件目前有很多功能。 我被要求制作一个免费试用版，其中包含完整软件的轻量级版本。 试用版中仅提供一些特定功能。 由于 jar 文件没有加密，我不愿意发布带有硬编码限制的完整版本。 我希望能够拥有 2 个 jar：1 个包含基本功能，1 个包含高级功能。
这些功能位于不同的菜单中。 如果代码能够在启动时尝试加载具有额外功能的 jar，并在非付费用户选择高级菜单时显示一条消息（例如：此功能在试用版中不可用），那就太好了。 另一方面，有权访问高级功能 jar 的付费用户不会知道其中的区别（我说的是现在 1 个 jar 和新方法 2 个单独的 jar 之间的区别）。
- 关于如何进行的任何提示？
- 有关于要避免的常见错误的警告吗？
- 还有比单独的罐子更好的策略吗？
编辑：迄今为止最好的建议描述了如何制作我的残件，但也警告我不要制作残件。 那么我应该做什么呢？
Our software currently has many features. I've been asked to make a free trial version which consist of a lightweight version of the full software. Only a few specific features would be available in the trial. And since a jar file isn't encrypted, I was relunctant to release a full version with hardcoded restrictions. I want to be able to have 2 jars : 1 containing the basic features and 1 with the advanced features.
The features are in different menus. It would be nice it the code would try to load the jar with the extra features at start up and display a message (like : this feature is unvailable in the trial) when the non-paying user selects an advanced menu. On the other hand, a paying user with access to the advanced features jar wouldn't know the difference (I'm talking about the difference between now, 1 jar, and the new method, 2 separate jars).
- Any tip on how to proceed ?
- Any warning on common mistakes to avoid ?
- Any better strategy than the separate jars ?
Edit : The best suggestion so far describes how to do my crippleware, but also warns me not to do a crippleware. So what do should I do ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正如您所提到的，您可能有 2 个 jar：
1 个包含基本功能，第一个包含高级功能的存根。
1.具有实际的高级功能。
您可以使用带有配置设置的工厂类来确定是创建存根类还是实际类 - 例如“FancyFeatureClass”或“FancyFeatureClassStub”。 “FancyFeatureClassStub”将包含在“lite”发行版中，但“FancyFeatureClass”只会包含在高级功能 jar 中。
如果他们尝试更改配置设置来创建真实的类，而没有包含真实类的 jar，那么他们最终只会得到类未找到的错误。
升级时，将高级功能 jar 添加到类路径并更改配置设置以告诉工厂类创建真正的类而不是存根。 假设您的应用程序可以以这种方式拆分，它应该可以正常工作。
至于常见的错误——我想你已经犯过一个——不过可能不是你的错:)
“Crippleware”是评估产品的一种糟糕方法。 发布一个带有过期或导航屏幕的全功能版本比发布一个有缺陷的产品更好。 没有这些高级功能可能会让人们很难真正评估该产品。
As you mentioned, you would probably have 2 jars:
1 with the basic features and stubs for the advanced features.
1 with the actual advanced features.
You could use a factory class with a config setting to determine whether to create the stub classes or the real classes - e.g. "FancyFeatureClass" or "FancyFeatureClassStub". "FancyFeatureClassStub" would be included in the "lite" distribution, but "FancyFeatureClass" would only be in the advanced features jar.
If they tried to change the config setting to create the real class without having the jar with the real classes, they would just end up getting class not found errors.
When upgrading, add advanced features jar to the classpath and change the config setting to tell the factory class to create the real classes instead of the stubs. Assuming your app could be split up that way, it should work fine.
As for common mistakes - I think you've already made one - probably not your fault though :)
"Crippleware" is a bad way to evaluate a product. Better to release a full featured version with an expiration or a nag screen than to release a crippled product. Not having those advanced features would probably make it difficult for someone to really evaluate the product.
许多技术允许可插入功能（通常称为插件或附加组件）。
这个想法是你的核心代码（或框架）声明一些接口（一个经过深思熟虑的 API 是理想的）。 插件可以提供接口的新实现，并将其注册到框架。
在其引导序列中，您的框架将查找（通过某种约定，例如在文件中）是否有插件，并让它们有机会执行自己的引导序列，包括注册。
启动阶段之后，是一个运行时示例（针对菜单）：框架在存储菜单的注册表中查找。 注册表包含框架自己声明的菜单，以及插件提供的任何附加功能......它显示所有这些。
如果您特别想要您要求的行为，我将按如下方式实现：
（例如：此功能在试用版中不可用
这样，付费用户就可以通过试用版获得所有正常功能版本显示了警告。
存在许多技术来实现这一点，最好的选择取决于您已经知道/使用/感觉舒服的技术：
Many technologies allow pluggable features (called plugins or addons usually).
The idea is that your core code (or framework) declares some interfaces (a well-thought API is ideal). Plugins can provide new implementations of an interface, and register it to the framework.
In its boot sequence, your framework will look (through some convention, in a file for example) if there are plugins, and give them a chance to execute their own boot sequence, consisting of the registration.
After the boot phase, a runtime example (for menus) : The framework looks it the registry where he stores the menus. The registry contains the menus the framework himself declared, plus any additionals provided by plugins... It displays all of them.
If you want specifically the behavior you asked for, I would implement this as follow :
(like : this feature is unvailable in the trial
That way, you paying users have all normal functionality, with the trial version shows the warnings.
Many technologies exist to implement this, the best choice depends on what you already know/use/feel confortable with :
使用一个单独的 Jar 来实现付费功能（以及一个单独的精简版前端，如果收到 ClassNotFoundException 则显示合适的消息，例如“不可用”）将是最简单的方法。
有许多框架，包括 Eclipse RCP，用于以模块化形式分发 UI 应用程序 - 但这对于您的需求来说有点过分了。
事实上，您甚至不需要两个 Jars，只要您的构建过程可以选择编译/打包您在分发过程中构建的 Jar 中的 Java 类的子集即可。 只是不包括付费功能。
Using a separate Jar which implements the paid for features (and a separate lite front end that displays a suitable message like 'not available' if it gets a ClassNotFoundException) would be the simplest way to do it.
There are many frameworks, up to and including Eclipse RCP for distributing UI applications in a modular form - but this will be overkill for your needs.
In fact, you don't even need two Jars, as long as your build process has the option to compile/package a sub-set of the Java classes in the Jar that you build as part of the distribution process. Just don't include the paid for features.