令应用开发效率飙升的 Java 类库

更多地使用 Java 而避免存储过程和复杂 SQL 是当前应用开发的一个潮流,这会在架构上带来优势,但用 Java 实现 SQL 式的运算并不是非常方便,很多任务要从头写起,开发效率其实反而会降低。
Hibernate/Mybatis/JOOQ 以及 Stream/Kotlin 等纯 Java 开源技术中提供了结构化数据对象及一些计算类库,能够在不破坏架构优势的同时一定程度地减少开发工作量,但这些开源技术的功能和 SQL 相比仍然相差很远,需求稍复杂时仍然要写大量 Java 代码,开发效率的提升很有限。

相比之下,esProc SPL 才是能使 Java 应用大幅飙升开发效率的开源技术。
esProc SPL 是纯 Java 的开源软件,它可以完全无缝地集成进 Java 应用中,就和应用程序员自己写的代码一样,一起享受成熟 Java 框架的优势。

不过,和前述那些开源类库不同,esProc 的功能并不是以 Java 的 API 的方式提供的,esProc 有自己的程序语言 SPL,SPL 脚本通过 esProc 提供的 JDBC 接口被 Java 程序调用,就像调用数据库 SQL 或存储过程一样。

Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
Statement statement = conn.createStatement();
ResultSet result = statement.executeQuery("=T(\"Orders.csv\").select(Amount>1000 && like(Client,\"*s*\")

为什么要设计一种新的程序语言而不直接封装成 Java API 呢?
Java 是编译型的静态语言,在这个基础上很难实现动态数据结构和便捷的 Lambda 语法,而这又是结构化数据运算中特别常见的,也是 SQL 的优势所在。
SQL 中任何一个 SELECT 语句都会产生一个新的数据结构,可以随意添加删除字段,而不必事先定义结构(类),这在结构化数据运算中家常便饭。但 Java 这类语言却不行,在代码编译阶段就要把用到的结构(类)都定义好,可以认为不能在执行过程中动态产生新的类(Java 理论上支持动态编译,但复杂度太大)。如果用一个专门的类来表示所有数据表,把字段名也作为类的数据成员,这又不能直接使用类的属性语法来引用字段,代码非常麻烦。
Lambda 语法是在 SQL 中大量使用,比如 WHERE 中的条件,本质上就是个 Lambda 表达式。Java 这种静态语言虽然现在也支持 Lambda 语法,但方便程度远远不如 SQL。每次书写时还是要有个函数头定义来告诉编译器现在要写 Lambda 函数了,代码看着很乱。在 Lambda 函数中也不能直接引用数据表的字段名,比如用单价和数量计算金额时,如果用于表示当前成员的参数名为 x,则需要写成 "x. 单价 *x. 数量" 这种啰嗦的形式。而在 SQL 中可以更为直观地写成 "单价 * 数量"。
解释型的动态语言才能实现 SQL 的这些特征,可以随时生成新的数据结构,也可以根据宿主函数本身决定当前参数是不是 Lambda 函数,从而没必要写个定义头,更可以根据上下文正确引用未写表名的字段。
SQL 是解释型动态语言,SPL 也是。Java 以及 Java 基础上的 Kotlin 和 Scala 都不是,所以用这些语言很难书写出简洁的代码。

SPL 提供了比 SQL 更完善的结构化数据对象(表、记录、游标)和更丰富的计算函数,包括 SQL 中有的过滤、分组、连接等基本运算,还有 SQL 中缺失的有序、集合等运算。所以,SPL 代码通常会比 SQL 更简洁易维护,和 Java 就更不用比了。
比如这个任务,计算一支股票最长连续上涨的天数,SQL 要写成多层嵌套,冗长且难懂:

select max(ContinuousDays) from (
    select count(*) ContinuousDays from (
        select sum(UpDownTag) over (order by TradeDate) NoRisingDays from (
            select TradeDate,case when Price>lag(price) over ( order by TradeDate) then 0 else 1 end UpDownTag from Stock ))
    group by NoRisingDays )

这样的计算逻辑,用 Java 写出来会更加繁琐,而用 SPL 就简单得多:

Stock.sort(TradeDate).group@i(Price<Price[-1]).max(~.len())

SPL 还有完善的流程控制语句,像 for 循环,if 分支都不在话下,还支持子程序调用。只用 SPL 就能实现非常复杂的业务逻辑,直接构成完整的业务单元,不需要上层 Java 代码来配合,主程序只要简单地调用 SPL 脚本就可以了。
esProc SPL 是纯 Java 程序,它可以被 Java 调用,也可以调用 Java。这样即便有个别用 SPL 不易实现而要使用 Java 实现的代码(比如某些对外的接口)或者已经有的现成 Java 代码,也都可以再集成进 SPL 中。SPL 脚本和主 Java 应用程序可以融为一体。

SPL 脚本存储成文件,置于主应用程序之外,代码修改可以独立进行且立即生效,不像 Stream/Kotlin 等 Java 类库在修改代码后还要和主程序一起重新编译,整个应用都要停机重启。这样可以做到业务逻辑的热切换,特别适合支持变化频繁的业务。

imagepng

SPL 支持的数据源也很丰富,无论关系数据库还是 NoSQL 或者 Kafka、Restful,无论是常规二维表还是多层次的 json,SPL 都可以计算处理,而不像 ORM 技术只能针对关系数据库。

imagepng

非常特别地,SPL 代码写在格子里,这和通常写成文本的代码很不一样。独立的开发环境简洁易用,提供单步执行、设置断点、所见即所得的结果预览,调试开发更方便。

imagepng

这里 写在格子里的程序语言 有对 SPL 有更详细的介绍。

最后,esProc SPL 在这里 https://github.com/SPLWare/esProc