倍增 Java 程序员的开发效率

简介: 应用计算困境:Java 作为主流开发语言,在数据处理方面存在复杂度高的问题,而 SQL 虽然简洁但受限于数据库架构。SPL(Structured Process Language)是一种纯 Java 开发的数据处理语言,结合了 Java 的架构灵活性和 SQL 的简洁性。SPL 提供简洁的语法、完善的计算能力、高效的 IDE、大数据支持、与 Java 应用无缝集成以及开放性和热切换特性,能够大幅提升开发效率和性能。

应用计算困境
顾开发还是顾架构?
Java 是当前应用开发最常用的语言,但是 Java 写数据处理的代码并不简单,比如针对两个字段的分组汇总要写成这样:

Map<Integer, Map<String, Double>> summary = new HashMap<>();
    for (Order order : orders) {
        int year = order.orderDate.getYear();
        String sellerId = order.sellerId;
        double amount = order.amount;
        Map<String, Double> salesMap = summary.get(year);
        if (salesMap == null) {
            salesMap = new HashMap<>();
            summary.put(year, salesMap);
        }
        Double totalAmount = salesMap.get(sellerId);
        if (totalAmount == null) {
            totalAmount = 0.0;
        }
        salesMap.put(sellerId, totalAmount + amount);
    }
    for (Map.Entry<Integer, Map<String, Double>> entry : summary.entrySet()) {
        int year = entry.getKey();
        Map<String, Double> salesMap = entry.getValue();
        System.out.println("Year: " + year);
        for (Map.Entry<String, Double> salesEntry : salesMap.entrySet()) {
            String sellerId = salesEntry.getKey();
            double totalAmount = salesEntry.getValue();
            System.out.println("  Seller ID: " + sellerId + ", Total Amount: " + totalAmount);
        }
    }

相比之下 SQL 就要简单很多,一句 group by 就出来了。

SELECT year(orderdate),sellerid,sum(amount) FROM orders GROUP BY year(orderDate),sellerid
早期应用程序的确就是 Java 和 SQL 配合工作的,业务流程在应用端用 Java 实现,而数据处理则放到后端数据库中使用 SQL 实现。这种架构因为受制于数据库而难以扩展和移植,对现代应用很不友好,而且很多时候还面临无库或跨库的情况,也没有 SQL 可用。

所以后来很多应用也开始采用全 Java 架构,特别是微服务的兴起以后,数据库只做简单读写,业务流程和数据处理都在应用端通过 Java 实现,这样就能与数据库解耦,获得良好的扩展和移植性,从而带来架构上的优势。但这又会面临前面提到的 Java 开发难问题。

看起来开发和架构只能顾一头,用 Java 享受架构的优势就必须忍受开发困难,反之用 SQL 就要容忍架构上的缺点,面临两难境地。

还有什么办法?
那我们想办法增强 Java 的数据处理能力呢?这样既能避免了 SQL 的问题,同时还能克服 Java 的不足。

事实上,Java 下的 Stream、Kotlin、Scala 都在尝试做这件事。

Stream

Java8 以后引入的 Stream,增加了很多数据处理方法,前面的计算用 Stream 实现。

Map<Integer, Map<String, Double>> summary = orders.stream()
            .collect(Collectors.groupingBy(
                    order -> order.orderDate.getYear(),
                    Collectors.groupingBy(
                            order -> order.sellerId,
                            Collectors.summingDouble(order -> order.amount)
                    )
            ));

    summary.forEach((year, salesMap) -> {
        System.out.println("Year: " + year);
        salesMap.forEach((sellerId, totalAmount) -> {
            System.out.println("  Seller ID: " + sellerId + ", Total Amount: " + totalAmount);
        });
    });

Stream 的确能一定程度简化计算代码,但整体来看仍然繁琐,远不及 SQL 简洁。

Kotlin

而号称更强大的 Kotlin 则有进一步改进:

val summary = orders
        .groupBy { it.orderDate.year }
        .mapValues { yearGroup ->
            yearGroup.value
                .groupBy { it.sellerId }
                .mapValues { sellerGroup ->
                    sellerGroup.value.sumOf { it.amount }
                }
        }
    summary.forEach { (year, salesMap) ->
        println("Year: $year")
        salesMap.forEach { (sellerId, totalAmount) ->
            println("  Seller ID: $sellerId, Total Amount: $totalAmount")
        }
    }

Kotlin 也简单了一些,但还是不够,和 SQL 的差距仍然很大。

Scala

再看看 Scala:

val summary = orders
        .groupBy(order => order.orderDate.getYear)
        .mapValues(yearGroup =>
            yearGroup
                .groupBy(_.sellerId)
                .mapValues(sellerGroup => sellerGroup.map(_.amount).sum)
    )
    summary.foreach { case (year, salesMap) =>
        println(s"Year: $year")
        salesMap.foreach { case (sellerId, totalAmount) =>
            println(s"  Seller ID: $sellerId, Total Amount: $totalAmount")
        }
    }

Scala 则又简单了一些,但仍然不能和 SQL 同日而语。Scala 还有过于沉重的缺点,使用起来并不方便。

其实这些技术的发展方向是对的,只是现在做的还不够好。

编译语言难以热切换
另外,Java 这些作为编译语言,不支持热切换,修改代码要重新编译部署,经常要重启服务,响应多变需求时的体验恶劣。SQL 在这方面反而没问题。

Java 开发麻烦,架构也有缺点,SQL 架构上很难满足,两难困境很难解决。还有什么办法吗?

终极解决办法 SPL,还有 SPL,纯 Java 开发的数据处理语言,开发简单、架构灵活。

语法简洁
我们回顾前面分组汇总的计算,Java 这些的实现:

3b342b9b2d1466c489bd11fcbf55b42a_1721999233107100.png

相比之下,SPL 则要简洁得多:
QQ_1730859339496.png

这已经与 SQL 的实现一样简单了:

QQ_1730859355407.png

SELECT year(orderdate),sellerid,sum(amount) FROM orders GROUP BY year(orderDate),sellerid
其实,很多时候 SPL 代码比 SQL 更简单。由于对有序计算和过程计算的支持,SPL 更擅长完成一些复杂计算。比如计算股票连涨天数, SQL 要嵌套三层,别说写,读懂都不容易。

select max(continuousDays)-1
  from (select count(*) continuousDays
    from (select sum(changeSign) over(order by tradeDate) unRiseDays
       from (select tradeDate,
          case when closePrice>lag(closePrice) over(order by tradeDate)
          then 0 else 1 end changeSign
          from stock) )
group by unRiseDays)

这个计算 SPL 一句就能完成,比 SQL 简单很多,更是能甩 Java 那些几条街。

QQ_1730859393480.png

完善、独立的计算能力
SPL 提供了专业的结构化数据对象序表,并在序表的基础上提供了丰富的计算类库。包括常规的过滤、分组、排序、去重、连接等计算,比如一般的:

QQ_1730859436264.png

更重要的是,SPL 的计算能力与数据库无关,没有数据库时一样可以工作,具备独立的计算能力,不像 ORM 技术要翻译成 SQL 执行。

高效易用的 IDE
除了语法简单,SPL 还有功能全面的开发环境。提供单步执行、设置断点等调试功能,还有可视结果面板,可以实时查看每步计算结果,对调试非常友好。

ec777c4d73144759b489e5d183680312_1721999232332100.png

大数据支持
SPL 还支持大数据,内存装不装得下都能计算。

内存计算:
QQ_1730859489123.png

外存计算:

QQ_1730859510419.png

从上面的代码可以看到,SPL 外存计算的代码与内存计算几乎完全一样,不会额外增加工作量。

SPL 也很容易实施并行计算,只需要在串行计算代码上增加一个 @m 选项就可以,比 Java 不知道简单多少倍。
QQ_1730859527780.png

与 Java 应用无缝集成
SPL 采用 Java 开发,将 JAR 包嵌入应用即可使用,通过标准 JDBC 接口执行或调用 SPL 脚本,整体很轻,甚至可以在安卓上工作。

JDBC 调用代码:

Class.forName("com.esproc.jdbc.InternalDriver");
    con= DriverManager.getConnection("jdbc:esproc:local://");
    st =con.prepareCall("call SplScript(?)");
    st.setObject(1, "A");
    st.execute();
    ResultSet rs = st.getResultSet();
    ResultSetMetaData rsmd = rs.getMetaData();

有了轻量易集成的特点,SPL 可以无缝集成进主流 Java 框架,尤其适合在微服务框架内部充当计算引擎使用。

开放性
SPL 还具备良好的开放性,可以对接多种数据源并实时混合计算,很容易处理无库或多库场景。

78248600c2d9fd7d271a6805ff73f81a_1721999232695100.png

不管什么数据源,只要能访问到,SPL 就都能读取并混合计算,啥都行。

数据库和数据库:
QQ_1730859592185.png

RESTful 和文件:

QQ_1730859615275.png

JSON 和数据库:

QQ_1730859637524.png

解释执行热切换
SPL 是解释型语言,修改代码无需重启服务即可实时生效,天然支持不停机热切换,能更好适应需求多变的数据业务。

3ce125987a145e113cfb8f10504c4c5e_1721999232896100.png

支持热切换还可以进一步独立计算模块,单独管理和运维,使用上更加灵活方便。

有了 SPL,可以大幅提升 Java 程序员的开发效率,同时获得架构上的优势。兼顾 Java 和 SQL 优点的同时,还能进一步简化计算、提升性能。SPL 现已开源,欢迎前往乾学院沟通了解!

相关文章
|
8天前
|
前端开发 Java 程序员
菜鸟之路day02-04拼图小游戏开发一一JAVA基础综合项目
本项目基于黑马程序员教程,涵盖面向对象进阶、继承、多态等知识,历时约24小时完成。项目去除了登录和注册模块,专注于单机游戏体验。使用Git进行版本管理,代码托管于Gitee。项目包含窗体搭建、事件监听、图片加载与打乱、交互逻辑实现、菜单功能及美化界面等内容。通过此项目,巩固了Java基础并提升了实际开发能力。 仓库地址:[https://gitee.com/zhang-tenglan/puzzlegame.git](https://gitee.com/zhang-tenglan/puzzlegame.git)
33 6
|
11天前
|
Java 应用服务中间件 API
【潜意识Java】javaee中的SpringBoot在Java 开发中的应用与详细分析
本文介绍了 Spring Boot 的核心概念和使用场景,并通过一个实战项目演示了如何构建一个简单的 RESTful API。
29 5
|
11天前
|
前端开发 Java 数据库连接
【潜意识Java】深度解读JavaWeb开发在Java学习中的重要性
深度解读JavaWeb开发在Java学习中的重要性
24 4
|
11天前
|
SQL Java API
|
11天前
|
前端开发 Java 数据库连接
Java后端开发-使用springboot进行Mybatis连接数据库步骤
本文介绍了使用Java和IDEA进行数据库操作的详细步骤,涵盖从数据库准备到测试类编写及运行的全过程。主要内容包括: 1. **数据库准备**:创建数据库和表。 2. **查询数据库**:验证数据库是否可用。 3. **IDEA代码配置**:构建实体类并配置数据库连接。 4. **测试类编写**:编写并运行测试类以确保一切正常。
27 2
|
1月前
|
移动开发 前端开发 Java
Java最新图形化界面开发技术——JavaFx教程(含UI控件用法介绍、属性绑定、事件监听、FXML)
JavaFX是Java的下一代图形用户界面工具包。JavaFX是一组图形和媒体API,我们可以用它们来创建和部署富客户端应用程序。 JavaFX允许开发人员快速构建丰富的跨平台应用程序,允许开发人员在单个编程接口中组合图形,动画和UI控件。本文详细介绍了JavaFx的常见用法,相信读完本教程你一定有所收获!
Java最新图形化界面开发技术——JavaFx教程(含UI控件用法介绍、属性绑定、事件监听、FXML)
|
23天前
|
监控 JavaScript 数据可视化
建筑施工一体化信息管理平台源码,支持微服务架构,采用Java、Spring Cloud、Vue等技术开发。
智慧工地云平台是专为建筑施工领域打造的一体化信息管理平台,利用大数据、云计算、物联网等技术,实现施工区域各系统数据汇总与可视化管理。平台涵盖人员、设备、物料、环境等关键因素的实时监控与数据分析,提供远程指挥、决策支持等功能,提升工作效率,促进产业信息化发展。系统由PC端、APP移动端及项目、监管、数据屏三大平台组成,支持微服务架构,采用Java、Spring Cloud、Vue等技术开发。
|
1月前
|
存储 JavaScript 前端开发
基于 SpringBoot 和 Vue 开发校园点餐订餐外卖跑腿Java源码
一个非常实用的校园外卖系统,基于 SpringBoot 和 Vue 的开发。这一系统源于黑马的外卖案例项目 经过站长的进一步改进和优化,提供了更丰富的功能和更高的可用性。 这个项目的架构设计非常有趣。虽然它采用了SpringBoot和Vue的组合,但并不是一个完全分离的项目。 前端视图通过JS的方式引入了Vue和Element UI,既能利用Vue的快速开发优势,
136 13
|
1月前
|
算法 Java API
如何使用Java开发获得淘宝商品描述API接口?
本文详细介绍如何使用Java开发调用淘宝商品描述API接口,涵盖从注册淘宝开放平台账号、阅读平台规则、创建应用并申请接口权限,到安装开发工具、配置开发环境、获取访问令牌,以及具体的Java代码实现和注意事项。通过遵循这些步骤,开发者可以高效地获取商品详情、描述及图片等信息,为项目和业务增添价值。
95 10
|
1月前
|
前端开发 Java 测试技术
java日常开发中如何写出优雅的好维护的代码
代码可读性太差,实际是给团队后续开发中埋坑,优化在平时,没有那个团队会说我专门给你一个月来优化之前的代码,所以在日常开发中就要多注意可读性问题,不要写出几天之后自己都看不懂的代码。
71 2