边缘计算也算是火爆了几年了

arm+linux造就了各种派的流行，

java在arm+linux里早就可以顺畅执行了
我看只不过很多人还停留在过去的时代。

如果你有很多知识资产在java上，边缘计算我看已经能够很好的适配运行
现在Graalvm也已成熟，完全可以编译为本地代码的方式运行

如果你打算重新开始，选啥语言确实是个令人纠结的事情。

我们有个项目，我正准备上graalvm大干一场，结果上游跟我说非C++不可，还要求用动态库集成。



很多人可能还没意识到，安卓就在边缘计算范畴内，java已经是事实上市场占有率最高的语言。
--
FROM 115.171.62.*

最近我刚刚做完一些验证

对于springboot 3后 号称改善了对graalvm的支持，但我自己的一些微服务的程序进行aot编译，运行不成功

没有用框架的一些程序，成功进行了编译运行，启动过程确实快，适合边缘计算

有些框架专门面向这个graalvm边缘计算，比如红帽推动的quarkus。

有个命令行框架picocli，也号称面向边缘计算。

我认为已经达到工业级成熟度了。

【 在 hothail 的大作中提到: 】
: graalvm现在什么情况
: 任意给springboot的程序就能编译成native？
: 还是只是支持部分技术
--
FROM 223.72.76.*

很棒棒

我们以前也做个试验，spring编译，最大的感觉就是过程巨慢
最近也感觉，如果要把java变成native，还是换个框架（结合紧密）也许是真的好选择

【 在 youngcle 的大作中提到: 】
: 最近我刚刚做完一些验证
: 对于springboot 3后 号称改善了对graalvm的支持，但我自己的一些微服务的程序进行aot编译，运行不成功
: 没有用框架的一些程序，成功进行了编译运行，启动过程确实快，适合边缘计算
: ...................
--
FROM 123.186.158.*

某种程度吧
看过一个对比，运行时占用内存降低30%左右
刚启动时候占用的少50%

另外就是还有
jar小了，对应各种占用小了
启动快了，几秒就行，比现在几十秒
- 来自 水木社区APP v3.5.7
【 在 littleSram 的大作中提到: 】
: 编译成native就可以减少内存占用了？
--
FROM 123.186.158.*

我认为用啥语言应该取决于你的业务和外部生态。
本着不重新造轮子的逻辑，更应该以生态为主。
当然，c/c++生态现在是个啥样我也说不清，我脑子里还停留在VC+mfc时代，已经十多年不搞了。

说说我最近的一些工作。
1、我验证quarkus进行native-image编译，fastXML里的jackson之类的反射有问题，不过traceAgent跑一边生成native-configuration后就ok了，运行效果不错。

2、如何进行交叉编译。使用qemu可以在linux或者windows上，模拟出一个arm系统，然后在其中安装C相关开发包，arm版本graalvm编译。可以直接下载ubuntu-cloudimage作为启动镜像，改下root密码，扩一下硬盘还是比较方便的。遗憾的是编译时间超长，我的demo程序在X86本机做一次native-image编译，需要5、6分钟，在模拟器跑了大概20分钟。日常开发还是得在x86环境做，模拟器里编译只能做最终交付偶尔用。
demo程序jar集合大概200多兆，编译后本地执行文件80兆

3、我尝试在几个平台做了native-image对比运行时长测试，程序为单线程运行，大量计算和几十兆得文件写出。
    i9笔记本大概2-3秒
    一个dell工作站，志强处理器，主频没看，大约4秒
    一个arm桌面PC做了测试，ft-2000/4，运行8秒
    一个安卓手机，小米11，骁龙888，运行大概4秒
几个环境都是固态存储，可以认为主要差异在CPU段。

单核性能，国产CPU还是有较大差距。真的搞脱钩，国产arm也不让造了，把数以亿计的高性能手机CPU，拆下来用来搞服务器，我看也没问题。




【 在 BlackHouse 的大作中提到: 】
: 如果不能用框架，那确实不如用C++方便了。
:
--
FROM 115.171.63.*