1、快速上手，降低学习曲线
对于刚刚接触J-Hi的人来说，它上手很容易，我们为每一个功能点都提供了悬浮帮助功能，即使没有任何资料（当然我们已提供了视频与开发文档），您也可以通过向导与帮助在十分钟之内就可以创建出您自己的项目原型。
其次J-Hi平台采用的大都是大家耳熟能详的主流框架与技术，如果您对主流的框架有所了解，那么对J-Hi的学习就没有任何阻力了。
2、快速搭建开发环境
也许您因为项目或自身开发团队的不同会采用不同的框架技术，例如您团队中对struts2熟悉的人远远要比掌握webwork的工程师要多，或者在您的项目中统计分析的功能很多，您要考虑ORM的效率问题，而不得不放弃hibernate而采用ibatis或springJDBC，也许您还要考虑数据库问题等等。在搭建开发环境您一定会考虑很多因素，尽管搭建开发环境并不复杂，但还是不够自动化，还要手动的配置，费时费力。J-Hi为快速搭建开发环境提供合理的解决方案，您可以按需求动态的搭建开发环境。
在此您可以选择不同的ORM框架
在此您可以选择不同的表现层框架
在此您可以选择不同的页面框架，并且我们提供了“预览”让您在搭建开发环境之前就可以看到搭建后的页面显示效果
在此您可以选择不同的数据库。
3、快速生成所有代码
通过建立或导入模式，您可以快速的生成所有代码与文件，并且在生成时会根据您选择的框架技术与数据库的不同而自动适配。
当然您还可以有选择的生成部分代码文件，例如只生成JSP页面，或只生成java代码。生成的java代码结构如下（因为我选择的框架是ibatis3+struts2，所以平台会自动匹配只生成与这两个框架相关的类文件，而不会生成无用的其它框架的东西）：
4、快速解决在业务需求中的技术难点
一般我们在做项目开发时，总是要等到项目开发的中、后期才能去解决业务核心问题，因此很造成无法合理估计项目的技术风险。原因是复杂的业务总是要等到基础模块建好后才能进入到开发阶段，从而使解决核心的技术问题置后。我们以一个报销为例来做个简单说明，比如报销在审核后的业务逻辑很复杂并且有可能还要涉及到与其它的系统对接。一般来说我们总是要等到这个报销单建好，起码要有最基本的增删查改功能（即使没有页面也要有后台的代码）后才能进入到核心业务的开发，这就加大的技术风险，因为我们会很早的发现问题，但解决这些问题却远远的落后于发现这个问题，甚至到了开发的中、后期因为技术问题在底层上还要一改再改。而使用J-Hi可以很快的进入到业务核心的技术上，因为只要生成，基础功能就已经提供，甚至平台还为您提供了单元测试用例类，从而使您可以直指业务核心，将项目风险控制在最低。
5、通过提供通用的组件
平台提供了很多通用业务组件，例如组织机构、角色权限、报表、定时任务、菜单管理、日志管理、系统配置、附件上传等等，除此之外平台还提供了一些纯技术组件，例如树型结构、java脚本工具、编码生成器、可选择性的返回JSON对象等等。这些通用的业务组件与技术组件可以为您在开发过程节省很多时间，随需使用，从而大大降低开发速度。
6、通过服务的复用性提高开发速度
在介绍平台的服务复用性之前，让我们来举个例子。比如您做了一个OA项目其中有一个模块是报销管理这个模块很成熟，您已经在OA系统中应用了很久。现在又有一个ERP系统，您想把这个成熟的报销管理复制到ERP系统中，这样这个功能就不用在ERP系统中再做开发了。对于平台来说这就是服务的复用性，我们提供了一整套对服务复用性的解决方案，并且有自己的可视化工具。
我们叫它J-Hi整合工具，是用C#做的。它的作用：
1）可视化导入/导出数据库，并同时实现跨数据库，例如您可以在mysql上开发（导出），开发完将所有的数据迁移到oracle上（导入）。
2）发布器，可视化将您开发的模块或系统自动发布成一个发布包（包括数据库、jar、文件[jsp、js、图片、配置文件等]还包括文件的片段[例如修改web.xml文件中的一部分内容]）
3）部署器，将发布包部署到开发的工程中，部署的内容见发布器的描述
4）实施器，对应的生产系统，我们通过FTP，将相应的文件与数据库自动部署到生产系统中
7、快速的部署与迁移
也许您正在为客户要求从SQLServer数据库改为Oracle而感到苦恼，因为这要做大量的数据迁移工作，或许您反复的将修改后的bug部署到生产环境中而郁闷，我想J-Hi通过它的整合工具为您提供了便捷的方式。具体的实现方式请参见上一节的介绍
8、开发人员可以快速的接手别人的工作
因为使用J-Hi开发，生成的代码与文件的风格都是相同的，在哪里写业务逻辑应该怎么写？在哪里要改页面应该怎么做？想要到哪张数据库表或表与类的对应关系？包括生成的类、JSP文件、配置文件的命名规则都是统一的。因此一个新人加入团队会很容易的上手并进入工作状态，即使是修改别人写过的代码，也会很快速的定位到相应要修改的位置。
9、快速解决需求变更
对于项目开发来说，项目的需求变更是很正常的事情，对于有经验的项目经理来说，如果一个项目从未发生过需求变更过反而是不正常了:)一但需求变更大多都要改数据库表，如果是已运行很稳定的系统，这种变更真是要命。J-Hi为此也提供了自己的解决方案，对于简单表变更，平台只要对单个实体生成就可以了。如果是复杂的变更，我们还提供继承实体的解决方案，也就是说原来的所有代码与表结构都不变，通过实体继承J-Hi会从数据库表到java类再到JSP页面形成一整套继承关系，从而保证以前功能的稳定性。这个说来好象很玄妙，让我们举例说明。比如你有一个部门表，N多信息都与它有联系，而且做了很多的业务处理，现在客户要求在部门表中加另一些信息。对你来说可能会为部门表中加字段，由此而带来所有类的变化与页面的变化，而这套系统已经很稳定已经用了一、两年了，开发人员都已经离开了公司，这样接手的人要读懂全部代码才有可能改，这样就造成开发速度的大大降低。平台提供了另一种解决方案：不动以前的任何东西，相关于在原有的基础上打上一块补丁。再做一张表，让这张表与部门表形成one to one的关系，而类无论是POJO、DAO、Service都继承自部门相应类作为父类，同时在JSP页面上也会继承所有部门的所有元素，这样就形成了实体继承关系，这就好比设计模式中最基本的“开闭原则”，对于所有的新生功能是开放的，而对于已有的老功能是关闭的，可以完全把老的功能视为一个黑箱。这样即能保证已有功能的稳定性，又能加入新的功能做为补充。