JFinal 3.5 发布,将能上的菜先上了

JFinal
 JFinal
发布于 2018年10月08日
收藏 27

    jfinal 新功能经过 6 个月的酝酿、开发,在大幅度的创新来临之前,jfinal 3.5 这一版先稳一稳,趁着国庆长假,将能上的菜先上了。

    jfinal 3.5 这一版针对这 6 个月以来用户反馈最强烈、最频繁的需求进行了开发,同时对原有代码进行了极其精致的优化与打磨。

    jfinal 3.5 诸多内部优化值得升级使用,诸多基础性调整为下一步进化做好准备。

1、Controller 依赖注入

    jfinal 3.5 添加了 Controller 依赖注入功能,使用前需要配置启用该功能:

public void configConstant(Constants me) {
    me.setInjectDependency(true);
}

    然后在 Controller 中只需对属性使用 @Inject 注解即可:

public class MyController extends Controller {

    @Inject
    Service service;

    public void index() {
        service.justDoIt();
    }
}

    添加该功能主要目标是为了自动化触发业务层 AOP 与进一步减少代码量,如上代码中的 Service 中使用的 @Before 配置的拦截器会自动生效,而老版本需要手动 enhance 一次。

2、Interceptor 依赖注入

    @Inject 还可以向拦截器属性注入依赖对象,用法与 Controller 之中完全一样:

public class MyInterceptor implements Interceptor {

    @Inject
    Service service;

    public void intercept(Invocation inv) {
        service.justDoIt();
    }
}

    jfinal 依赖注入功能与 spring 有着本质的不同,jfinal 依赖注入的核心目标是为了实现 AOP 自动化与节省代码量,而且与 IOC 毫无关系,更不需要 IOC 容器。极简设计,实现该功能只用了 243 行代码。

3、Aop 任意时空支持 AOP 及 Inject

    jfinal 3.5 添加了 Aop 工具类用来全面取代老版本中的 Enhancer,可在任意地方通过 Aop.get(…) 方法创建 AOP 代理对象,实现 AOP 功能的同时进行依赖注入:

Service service = Aop.get(Service.class);

    以上代码会创建 Service 对象,如果 Service 中使用了 @Before 配置过拦截器将会自动生效,如果 Service 中的属性使用了 @Inject,则会被注入依赖对象。还可通过  Aop.inject(...) 方法来注入依赖对象:

Service service = new Service();
service = Aop.inject(service);

    以上代码会为 service 中的 @Inject 属性注入依赖对象 ,Aop.inject(...) 方法相对于 Aop.get(...) 少一个对象创建过程。Aop 可以在 Controller、Interceptor 之外快捷使用 AOP、Inject 功能。

4、主干版本加入 action 参数注入功能

    由于老版本照顾了 java 1.6、1.7 用户编译级别为 1.6,action 参数注入功能做到了 jfinal-java8 分支版本之中。 jfinal 3.5 最低要求 JDK 1.8,  action 参数注入功能自然也就做到了主干之中:

public class LoginController extends Controller {
    public void index(String userName, String password) {
        Ret ret = service.login(userName, password);
        renderJson(ret);
    }
}

    以上 index() 这个 action 被注入了 userName、password 形参,省去了对 getPara、getFile 系列方法的调用代码,将进一步提升开发效率。该功能还支持 File、Model、RawData、Date 等常用类型,还可以通过扩展 IParaGetter 接口实现注入任意类型的数据。本功能由 @玛雅牛 大神贡献,再次感谢 @玛雅牛。

5、jetty server 模块升级为 2018.11 版本

    jetty server 模块升级到 jetty 最新版 9.4.12.v20180830, 由于是 java 8 起步,用户可自由升级 jetty 到未来的更高版本。升级后的 jetty server 支持所有版本的 eclipse,支持 IDEA 热加载,并且统一 eclipse、IDEA 启动参数:

JFinal.start("src/main/webapp", 80, "/", 5);

    老版本 jetty server 无法在部分高版本 eclipse 中使用,无法在 IDEA 下支持热加载,jetty server 最新版 maven 坐标如下:

<dependency>
    <groupId>com.jfinal</groupId>
    <artifactId>jetty-server</artifactId>
    <version>2018.11</version>
</dependency>

6、NotAction 注解

    NotAction 注解用于 Controller 上原本为 action 的方法之上,可以强制该方法不成为 action:

public abstract class BaseController extends Controller
    
    @NotAction
    public void getLoginUser() {
        ......
    }
}

    以上代码中的 getLoginUser() 将不会成为 action,不会生成访问路由,老版本中的 @Before(NotAction.class) 可改用 @NotAction 注解实现。

7、Controller 添加 getRawData()

    getRawData() 便于接收客户端发送过来的 json 或者 xml 数据:

public void index() {
    String jsonStr = getRawData();
    User user = FastJson.getJson().parse(jsonStr, User.class);
}

    getRawData() 有助于提升 API 型项目的开发体验,在减少代码的同时进一步提升开发效率。

8、Controller 添加 getKv()

    getKv() 将表单参数封装成 Kv/HashMap 对象,方便使用其中的一些工具方法:

public void index() {
    renderJson(getKv());
}

9、enjoy 模板支持自定义 Field表达式

    如下代码将支持 object.field 表达式访问  isField() 方法:

Engine.addFieldGetterToLast(new FieldGetters.IsMethodFieldGetter());

    通过扩展 IFieldGetter 接口,可以自由定制 object.field 表达式的获取方式。

10、改进 ClassPathSource

     解决 URL.openConnection() 在 linux 下打开文件句柄不能及时关闭的问题。

    上述是一些看得到、感知得到的增强与改进,此外还有超过 50 项的内部优化、打磨是看不到的,后续会在 changelog 中整理出来。精益求精的 jfinal 3.5 版本,值得你升级。

     One More Thing:
     近几天俱乐部将会在线直播讲解 jfinal 3.5 与 club 1.6 的新功能与新用法。与 jfinal 3.5 一同发布的还有俱乐部专享项目 jfinal club 1.6,该项目提供一套极简的权限管理以及内容管理后台,截图与功能介绍猛击 传送门,现在就加入俱乐部获取专享福利:http://www.jfinal.com/club 

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:JFinal 3.5 发布,将能上的菜先上了
加载中

精彩评论

理工男海哥
理工男海哥
国内还有很多开源的作者,但是真正像波总这样沉淀下来,通过元思维的方式去思考开发者的需求的太少太少了,使用JFinal的这几年里,从来没有因为JFinal的设计问题影响到产品。因为JFinal灵活的设计和国内强大的口碑,使我的个人作品 #Jboot# 也因此收获了不少的用户,使我个人也得到了认可。在此呼吁大家也参与到JFinal的生态贡献中来。
kut
kut

引用来自“陳建勳”的评论

請問,這個是不是已經默默超越spring了呀?

引用来自“JFinal”的评论

在学习成本、开发效率、代码量这三个 jfinal 的核心目标上远远胜于 spring
哈哈哈……笑话。
凌凌凌凌
凌凌凌凌
说超越spring就过分了。springboot 笑笑不说话:expressionless:
JFinal
JFinal

引用来自“陳建勳”的评论

請問,這個是不是已經默默超越spring了呀?
在学习成本、开发效率、代码量这三个 jfinal 的核心目标上远远胜于 spring
TerryZ
TerryZ
前排支持波总,idea 和 eclipse 都支持热加载太棒了

最新评论(133

badouyuren
badouyuren
憨憨电影已升级
Role
Role

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“JFinal”的评论

用 Interceptor 、Enhancer 实现 Aop 是 jfinal 七年前第一个版本就有的东西,jfinal 3.5 添加的这个 Aop.java、AopFactory 与 IOC 完全无关,更不需要 IOC 容器,根本谈不上是回到 Ioc & aop 这条路上来,更谈不上饶了好大一圈,143 行代码而已


其一,jfinal 的 Aop 七年前就有了,其二 Ioc 根本不需要,所以你说的 “终于回归到 ioc & aop” 这个是纯属不粘边

jfinal 3.5 对 aop 仅增加了 143 行代码,只是为了省代码引入依赖注入,而且设计目标与设计方式与 spring 截然不同

jfinal 最擅长的事情是消解、消灭一些不必要的概念,让事情变得简单舒适。这个从 jfinal 3.0 发布的模板引擎会有更切实的体会:https://www.oschina.net/news/81225/jfinal-3-0-released

引用来自“哈库纳”的评论

Interceptor 是 aop 的概念、新加的这个 @Inject 实际上就是 ioc 概念。和容器没什么关系的,只不过一些框架没有所谓的容器就没有完整的 meta 信息无法进行 @inject 而已。

但实际上类似 Guice 这样的 IoC 框架,实际使用中已经不需要把 Bean 注册到容器里,一样可以 getInstance 时候自动完成依赖注入。 我的 Hasor 也具备这种特质,所以从这个角度而言,我觉得无论是 Hasor 也好还是 JFinal 也好 既然提供了 Interceptor 和 @Inject 那就是走在 aop & ioc 的道路上。

因此我才说从上面的角度来讲 JFinal 回到了 ioc & aop 这条路上。


至于实现是用了 143 行还是 50W行对于开发者而言不重要, 不过可以肯定的是更少的代码一定是可以带来更少的 Bug 出现概率。

-----

最后我觉得波总,还有其它看到这条评论的同学。ioc & aop 仅仅是概念而已,没必要一看到 ioc & aop 就把 Spring 搬出来。

而且波总也大可不必太敏感。真正的底层技术的更新真的没那么快,就像操作系统原理几十年过去了基本还是那个样子。ioc & aop 这个概念也是 n久了,但是框架不知道换了多少代。 对于代码写的多了的人自然知道只要是 提供了类似 @Inject 这样的功能,原理嘛都是一个样子的。 只是实现可能不一样而已。

底层 其实实现原理就是那么几个换来换去还是这几个。

引用来自“Role”的评论

都是老司机,选轮胎那只能看谁家卖的轮胎耐用跑得快了。:grimacing:

引用来自“yong9981”的评论

IOC有这么复杂吗?何必视其为洪水猛兽。一直很奇怪jFinal只有AOP,没有IOC。现在总算加了个@Inject出来,还忙不叠与IOC划清界线。 实际上IOC没这么复杂, 比较成熟短小且实现了JSR330标准的IOC工具只有几百行代码(Feather),如果将AOP功能加入,也只需要1500行代码就搞定(见拙作jBeanBox)。 IOC不是没有用,在处理复杂对象的构造、单例缓存、隔离对象依赖时可以简化代码。jFinal的优点是整合,但最大的问题也是整合,因为它是一个封闭的整合环境(笔者在替换jFinal3.4版的Dao工具为自写的DAO工具时发现jFinal的Web和Dao层代码有藕合,这是架构上不应该出现的),实际上SpringBoot也是封闭的整合环境,因为它建立在Spring内核不被替换的前提下,但SpringBoot好在除了内核外,其它的功能都可以自由切换包括DAO工具等。 如果把jFinal的IOC/AOP与其它IOC/AOP工具比较,把它的DAO与其它DAO工具比较,实际上并不出彩,而且自成一家,没有考虑流行的JSR/JPA等标准,不利于项目的移植。
IOC与AOP本来就是两个不同的方向,一个是依赖注入一个是切面编程,JFinal WEB和Dao有你说所的有藕合,一个WEB能与dao数据操作存在有藕合,这个还真想了解下。:joy:
用JFinal也照样可能用第三方的DAO工具或ORM的,没有这个限制,官方把ORM整合在一起,并没有限制不能使用第三方的ORM,完全可以。
yong9981
yong9981

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“JFinal”的评论

用 Interceptor 、Enhancer 实现 Aop 是 jfinal 七年前第一个版本就有的东西,jfinal 3.5 添加的这个 Aop.java、AopFactory 与 IOC 完全无关,更不需要 IOC 容器,根本谈不上是回到 Ioc & aop 这条路上来,更谈不上饶了好大一圈,143 行代码而已


其一,jfinal 的 Aop 七年前就有了,其二 Ioc 根本不需要,所以你说的 “终于回归到 ioc & aop” 这个是纯属不粘边

jfinal 3.5 对 aop 仅增加了 143 行代码,只是为了省代码引入依赖注入,而且设计目标与设计方式与 spring 截然不同

jfinal 最擅长的事情是消解、消灭一些不必要的概念,让事情变得简单舒适。这个从 jfinal 3.0 发布的模板引擎会有更切实的体会:https://www.oschina.net/news/81225/jfinal-3-0-released

引用来自“哈库纳”的评论

Interceptor 是 aop 的概念、新加的这个 @Inject 实际上就是 ioc 概念。和容器没什么关系的,只不过一些框架没有所谓的容器就没有完整的 meta 信息无法进行 @inject 而已。

但实际上类似 Guice 这样的 IoC 框架,实际使用中已经不需要把 Bean 注册到容器里,一样可以 getInstance 时候自动完成依赖注入。 我的 Hasor 也具备这种特质,所以从这个角度而言,我觉得无论是 Hasor 也好还是 JFinal 也好 既然提供了 Interceptor 和 @Inject 那就是走在 aop & ioc 的道路上。

因此我才说从上面的角度来讲 JFinal 回到了 ioc & aop 这条路上。


至于实现是用了 143 行还是 50W行对于开发者而言不重要, 不过可以肯定的是更少的代码一定是可以带来更少的 Bug 出现概率。

-----

最后我觉得波总,还有其它看到这条评论的同学。ioc & aop 仅仅是概念而已,没必要一看到 ioc & aop 就把 Spring 搬出来。

而且波总也大可不必太敏感。真正的底层技术的更新真的没那么快,就像操作系统原理几十年过去了基本还是那个样子。ioc & aop 这个概念也是 n久了,但是框架不知道换了多少代。 对于代码写的多了的人自然知道只要是 提供了类似 @Inject 这样的功能,原理嘛都是一个样子的。 只是实现可能不一样而已。

底层 其实实现原理就是那么几个换来换去还是这几个。

引用来自“Role”的评论

都是老司机,选轮胎那只能看谁家卖的轮胎耐用跑得快了。:grimacing:
IOC有这么复杂吗?何必视其为洪水猛兽。一直很奇怪jFinal只有AOP,没有IOC。现在总算加了个@Inject出来,还忙不叠与IOC划清界线。 实际上IOC没这么复杂, 比较成熟短小且实现了JSR330标准的IOC工具只有几百行代码(Feather),如果将AOP功能加入,也只需要1500行代码就搞定(见拙作jBeanBox)。 IOC不是没有用,在处理复杂对象的构造、单例缓存、隔离对象依赖时可以简化代码。jFinal的优点是整合,但最大的问题也是整合,因为它是一个封闭的整合环境(笔者在替换jFinal3.4版的Dao工具为自写的DAO工具时发现jFinal的Web和Dao层代码有藕合,这是架构上不应该出现的),实际上SpringBoot也是封闭的整合环境,因为它建立在Spring内核不被替换的前提下,但SpringBoot好在除了内核外,其它的功能都可以自由切换包括DAO工具等。 如果把jFinal的IOC/AOP与其它IOC/AOP工具比较,把它的DAO与其它DAO工具比较,实际上并不出彩,而且自成一家,没有考虑流行的JSR/JPA等标准,不利于项目的移植。
小强哥unas
小强哥unas
大话不多说了,之前创业用jfinal的简单快速的特点的确解决了中小团队面临的技术太多太复杂的情况,现在也在小项目上一直在使用jfinal。波总给代码开发回归简洁树立了典型,也希望支持更多三方扩展,毕竟很多人还是希望少操心,当然jboot也做得不错,相辅相成。
长篇小说
感谢波总推出新产品!我是jfinal使用者,大约使用有3年时间了,原来接触过各式各样框架,都没有顺利落地项目,接触jfinal之后,开始逐步提升,并且得到了波总的耐心指点,赚多少钱不敢自夸,但肯定比上班族多多了。所以我认为,评判一个项目,主要在于他产生的实际价值,在于肯定创造人的无私奉献精神!
Role
Role

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“JFinal”的评论

用 Interceptor 、Enhancer 实现 Aop 是 jfinal 七年前第一个版本就有的东西,jfinal 3.5 添加的这个 Aop.java、AopFactory 与 IOC 完全无关,更不需要 IOC 容器,根本谈不上是回到 Ioc & aop 这条路上来,更谈不上饶了好大一圈,143 行代码而已


其一,jfinal 的 Aop 七年前就有了,其二 Ioc 根本不需要,所以你说的 “终于回归到 ioc & aop” 这个是纯属不粘边

jfinal 3.5 对 aop 仅增加了 143 行代码,只是为了省代码引入依赖注入,而且设计目标与设计方式与 spring 截然不同

jfinal 最擅长的事情是消解、消灭一些不必要的概念,让事情变得简单舒适。这个从 jfinal 3.0 发布的模板引擎会有更切实的体会:https://www.oschina.net/news/81225/jfinal-3-0-released

引用来自“哈库纳”的评论

Interceptor 是 aop 的概念、新加的这个 @Inject 实际上就是 ioc 概念。和容器没什么关系的,只不过一些框架没有所谓的容器就没有完整的 meta 信息无法进行 @inject 而已。

但实际上类似 Guice 这样的 IoC 框架,实际使用中已经不需要把 Bean 注册到容器里,一样可以 getInstance 时候自动完成依赖注入。 我的 Hasor 也具备这种特质,所以从这个角度而言,我觉得无论是 Hasor 也好还是 JFinal 也好 既然提供了 Interceptor 和 @Inject 那就是走在 aop & ioc 的道路上。

因此我才说从上面的角度来讲 JFinal 回到了 ioc & aop 这条路上。


至于实现是用了 143 行还是 50W行对于开发者而言不重要, 不过可以肯定的是更少的代码一定是可以带来更少的 Bug 出现概率。

-----

最后我觉得波总,还有其它看到这条评论的同学。ioc & aop 仅仅是概念而已,没必要一看到 ioc & aop 就把 Spring 搬出来。

而且波总也大可不必太敏感。真正的底层技术的更新真的没那么快,就像操作系统原理几十年过去了基本还是那个样子。ioc & aop 这个概念也是 n久了,但是框架不知道换了多少代。 对于代码写的多了的人自然知道只要是 提供了类似 @Inject 这样的功能,原理嘛都是一个样子的。 只是实现可能不一样而已。

底层 其实实现原理就是那么几个换来换去还是这几个。
都是老司机,选轮胎那只能看谁家卖的轮胎耐用跑得快了。:grimacing:
Role
Role

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“山哥”的评论

哈哈,当初的初心是好的,但是维护着维护着就变成了另外一个 Spring,唉~~~

引用来自“JFinal”的评论

jfinal 3.5 的重要功能 aop 仅添加 143 行代码,怎么可能变成臃肿无比的 spring,想变成 spring 那样臃肿起码得再加 50 万行代码

引用来自“哈库纳”的评论

添加多少行代码不重要,从功能上来讲已经和 spring-mvc 趋同了。 我想这就是 山哥 的意思。

波总说的臃肿应该是代码上的臃肿,对于 1周功能就要上线,下一周就要完成一个版本的迭代的实际情况没人会关注是用 143 行还是 50万行实现 AOP。 而是是否可以用 143 行完成业务开发,并且稳定运行在线上。
角度不同自然关注点也不同,不能相提并论。
哈库纳
哈库纳

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“JFinal”的评论

用 Interceptor 、Enhancer 实现 Aop 是 jfinal 七年前第一个版本就有的东西,jfinal 3.5 添加的这个 Aop.java、AopFactory 与 IOC 完全无关,更不需要 IOC 容器,根本谈不上是回到 Ioc & aop 这条路上来,更谈不上饶了好大一圈,143 行代码而已


其一,jfinal 的 Aop 七年前就有了,其二 Ioc 根本不需要,所以你说的 “终于回归到 ioc & aop” 这个是纯属不粘边

jfinal 3.5 对 aop 仅增加了 143 行代码,只是为了省代码引入依赖注入,而且设计目标与设计方式与 spring 截然不同

jfinal 最擅长的事情是消解、消灭一些不必要的概念,让事情变得简单舒适。这个从 jfinal 3.0 发布的模板引擎会有更切实的体会:https://www.oschina.net/news/81225/jfinal-3-0-released
Interceptor 是 aop 的概念、新加的这个 @Inject 实际上就是 ioc 概念。和容器没什么关系的,只不过一些框架没有所谓的容器就没有完整的 meta 信息无法进行 @inject 而已。

但实际上类似 Guice 这样的 IoC 框架,实际使用中已经不需要把 Bean 注册到容器里,一样可以 getInstance 时候自动完成依赖注入。 我的 Hasor 也具备这种特质,所以从这个角度而言,我觉得无论是 Hasor 也好还是 JFinal 也好 既然提供了 Interceptor 和 @Inject 那就是走在 aop & ioc 的道路上。

因此我才说从上面的角度来讲 JFinal 回到了 ioc & aop 这条路上。


至于实现是用了 143 行还是 50W行对于开发者而言不重要, 不过可以肯定的是更少的代码一定是可以带来更少的 Bug 出现概率。

-----

最后我觉得波总,还有其它看到这条评论的同学。ioc & aop 仅仅是概念而已,没必要一看到 ioc & aop 就把 Spring 搬出来。

而且波总也大可不必太敏感。真正的底层技术的更新真的没那么快,就像操作系统原理几十年过去了基本还是那个样子。ioc & aop 这个概念也是 n久了,但是框架不知道换了多少代。 对于代码写的多了的人自然知道只要是 提供了类似 @Inject 这样的功能,原理嘛都是一个样子的。 只是实现可能不一样而已。

底层 其实实现原理就是那么几个换来换去还是这几个。
JFinal
JFinal

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“山哥”的评论

哈哈,当初的初心是好的,但是维护着维护着就变成了另外一个 Spring,唉~~~

引用来自“JFinal”的评论

jfinal 3.5 的重要功能 aop 仅添加 143 行代码,怎么可能变成臃肿无比的 spring,想变成 spring 那样臃肿起码得再加 50 万行代码

引用来自“哈库纳”的评论

添加多少行代码不重要,从功能上来讲已经和 spring-mvc 趋同了。 我想这就是 山哥 的意思。

波总说的臃肿应该是代码上的臃肿,对于 1周功能就要上线,下一周就要完成一个版本的迭代的实际情况没人会关注是用 143 行还是 50万行实现 AOP。 而是是否可以用 143 行完成业务开发,并且稳定运行在线上。
jfinal 是 MVC + ORM,spring 也有这些功能,在功能上有相同的地方这个在所难免

关于代码量的问题,不管别人关不关心,jfinal 必须是要极度关心的。每一行代码对于 jfinal 来说都是要维护的,多一行代码就多一点维护成本

多一行代码就增加一点 bug 的概率,这点就跟说话一样,所谓言多必失,同样一个功能,同样水平的人写的代码,代码量多的那个在概率上来说 bug 概率会高。 bug 概率关系到系统稳定性
哈库纳
哈库纳

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“山哥”的评论

哈哈,当初的初心是好的,但是维护着维护着就变成了另外一个 Spring,唉~~~

引用来自“JFinal”的评论

jfinal 3.5 的重要功能 aop 仅添加 143 行代码,怎么可能变成臃肿无比的 spring,想变成 spring 那样臃肿起码得再加 50 万行代码
添加多少行代码不重要,从功能上来讲已经和 spring-mvc 趋同了。 我想这就是 山哥 的意思。

波总说的臃肿应该是代码上的臃肿,对于 1周功能就要上线,下一周就要完成一个版本的迭代的实际情况没人会关注是用 143 行还是 50万行实现 AOP。 而是是否可以用 143 行完成业务开发,并且稳定运行在线上。
返回顶部
顶部