1. 如何保证 java 应用安全标准答案来了
如何保证 Java 应用安全？
在 Java 程序内存中保护密码安全，可以通过引入机密计算技术来实现。龙蜥社区云原生机密计算 SIG 推出了 Java 机密计算实现技术——Teaclave Java TEE SDK。该技术具有显著优点，已经经过企业级内部场景验证并在 Apache 社区开源。它在软件工程顶级会议 ICSE 2023 上发表的论文获得了 ACM SIGSOFT 杰出论文奖，是自 2020 年以来，龙蜥社区云原生机密计算 SIG、上海交通大学、大连理工大学首次获此荣誉。
保护 Java 程序内存中密码的安全，关键在于如何在运行时环境中安全使用敏感数据。密码一旦解密后，即以明文形式存在于 Java 堆上，可能导致被攻击或主动泄漏。为了解决这一问题，Teaclave Java TEE SDK 通过将密码从内存中销毁，大大减少了敏感信息暴露的时间窗口。此外，通过将密码保存为 char 数组或 byte 数组，避免了反射调用，使得销毁过程更加便利。使用 byte 数组保存密码，更是增加了信息的隐蔽性，使其难以被解读。
然而，当前在网络上找到的解决方法，如缩短明文密码在内存中的存放时间，仅缩短了敏感信息暴露的时间窗口，并未真正保护明文密码。这些方法对密码的销毁时间判断弹性较大，开发人员未必能准确判断何时是最佳时机。更典型的案例，如著名的 log4j 漏洞问题，攻击者能够利用漏洞将恶意类文件上传至服务器，并通过 Java 动态类加载机制运行，窃取 Java 堆中的私钥，进而获得服务器与客户端之间通信内容的完全访问权限。
为了解决 Java 程序安全性问题，机密计算技术成为了一个标准答案。它通过提供硬件级的系统隔离，保障数据安全和程序运行安全。机密计算将执行环境分为富执行环境（REE）和可信执行环境（TEE），认为 REE 和 TEE 应该相互隔离，TEE 需要通过硬件加密来保证外界无法知晓其中的内容。这一机制在 1999 年即已提出，并在随后的 20 多年中得到了发展。
其中，SGX、TrustZone 等提供了通用型机密计算的硬件基础，Intel、微软等开源的驱动和 SDK 则为通用型机密计算提供了软件基础。然而，直接在 TEE 中运行 Java 程序并不友好，因为 TEE 只能执行 native 程序。为解决这一问题，Occlum 作为介于 TEE 底层 SDK 与 JVM 之间的一层 LibOS，支持 JVM 在 TEE 中的运行。然而，Occlum 方案存在安全性和性能下降的问题，TCB（可信计算基）过大，导致安全性不佳；性能下降，TEE 硬件与 REE 相比存在性能退化。
针对上述问题，Teaclave Java TEE SDK 提出了一种在 TEE 中仅放入可信代码的解决方案。通过将可信代码从 Java 代码直接编译为 native code 放入 TEE 运行，Teaclave Java 采用模块分隔、机密计算服务化、简洁的机密计算服务生命周期管理 API、Java 静态编译等关键技术特性，将应用代码分为 Host、Enclave 和 Common 三个模块。Host 中为普通安全非敏感程序，Enclave 中为安全敏感程序，Common 中则是两者的公共代码。通过将可信代码放入 TEE 运行，实现了 Java 应用的机密计算，降低了安全性和性能的下降问题。Teaclave Java 提供了一站式快速实现 Java 机密计算应用的开发和构建能力，简化了 Java 机密计算的开发门槛。
在实际应用中，Teaclave Java 通过将应用的普通代码放在 REE 中执行，安全敏感的解密和私钥放在 TEE 中，实现了对敏感数据和运算过程的保护。在机密计算框架的对比中，Teaclave Java 的 TCB（可信计算基）大小仅为 Occlum 的大约 1/20 到 1/10，具有更高的安全性。运行时性能方面，Teaclave Java 的 native image 会直接以 native 代码形式运行，启动速度非常快，适用于小型应用。对于长时间执行的应用，性能优势会逐渐减小。此外，Teaclave Java 的运行时内存使用量更少，为应用提供了更高效、安全的运行环境。
综上所述，Teaclave Java TEE SDK 是解决 Java 应用安全问题的有效方案，它通过硬件宽容性、安全沙箱隔离、高效的运行时性能和简洁的开发流程，为 Java 应用提供了全面的安全保障。未来，随着 GraalVM 的 Java 静态编译技术被贡献给 OpenJDK，Teaclave Java 方案将获得 JDK 的原生支持，进一步提升其性能和易用性。同时，Teaclave Java 项目的源代码已被贡献至 Apache 社区，加入机密计算框架 Teaclave 项目，正在开源孵化中。
2. 为什么ACM初赛用java、c\c++等都可以，到了决赛只能用C/C++
你问的这个问题吧，真的没有一个标准答案，有许多考量吧。
1. 规则制定：
无可厚非，赛制也可以增加java来作为一种语言，所以只要组织这个活动的委员会投票增加的话也就是了。只不过可能某些原因没有增加。
Final一般要求更加严格，所以修改规定什么的也就更加难。在该比赛发起时java并不如现在使用广泛，后来随着其流行性以及其他语言的情况，考虑在区域赛中增加了支持这些语言已经照顾了很多programmer。这首先区域赛可以稍微灵活点，自主性大点，就比如体育比赛中得到世锦赛名额什么的和后面最终比赛的规则什么的会有些不一样。要新增加java等需要得到委员会的投票认可，但因为公平性、评判性等因素难以得到赞成票，可以看下面的考虑。
2. 公平性与评判方便：
为什么问公平性呢，这是因为不同语言的运行环境、编译原理等什么的都不一样。无法给出一个完整的时间换算公式。比如区域赛中的c给1s而java给5s，可是不同的算法c和java的运算效率的倍数是会动态变化的，所以这样对c及java语言的某一方可能会不公平。
类库不一样，比如有的算法一种语言有库直接可以调用，另外一种却要去实现，这样也会造成不公平。记得08年杭州赛区当时有道题就java有算法直接可以调，然后评委临时规定用java的不可以直接调这个函数。
上面两点也无形中表明如果多种语言的话评判也会很难。
如果你说不支持其他语言不公平的话，要知道到这个级别的，一般c语言是都应该会的。而且它的运行效率高，以及用的比较早，所以就继续喽。
以上只是我个人的分析，你觉得不合理的话请指出，应该也许还会有其他因素影响。你自己也可以去想。或者你可以问中国为什么不改革腐败呢，可是这些也不是我们所能决定的。