粉丝2.6万获赞16.1万

呃,你们现在用的是 g d k 哪一个版本?呃,主流还是 g d k 八?就新建的项目的话,会用到比较新的时期。嗯,用到比较新的时期了。呃,那后面升级的一些版本,包括 g d k 八,就是后面升级的一些内容,或者说一些特性,有去了解过吗? 只要有这个那么大表达式,就让代码写起来更加方便。 ok, 这个虽然在开发的时候呢,就可能不会特意去关注啊,但是既然你在工作里面去做了这个版本的升级,对吧?并且用到了一些新的版本,那你还是要清楚每一个版本后面的一些特性 啊,它大致可以分为几个关键的版本啊。如果你担心简历上的东西讲不出来,我已经把面试经常问到的一些技术站场景图都整理在两百万字的面试文档了,里面针对每个知识点都有很详细的解析思路, 只要你是我的粉丝,留言六六六就可以打包带走。那第一个版本就是 g t 八,对吧?这个也是非常经典的一个版本,这也是我们现在啊大部分公司还在用的一个版本。那主要就是引入了 number 的 表达式和 spring api, 那 么这两个玩意呢,改变了 java 的 一些编程范式, 那比如说函数式编程和并行处理变得非常优雅,同时呢,他带来一些新的日期的一个 api, 对 吧?彻底解决了一些老 date 类的一些痛点,比如说精确度不足,失去混乱、病发问题等等。然后第二个呢,就是,呃,升级的就是九呃到十一。那么九到十一呢?它主要做的几件事项,第一个模块化系统 啊,它从价格层面对吧,对 g d k 的 自身啊,和我们大型应用进行了一个拆分和分装,更好地去支持了一些云月生的部署。那当然这个东西呢,就是推广的比较慢啊,但是它是有用的。然后 g d k 十一呢,就是有一个比较经典的,比如说就是 h t p client 啊,它告别了老旧的 h d u l commission, 并且引入了 z g c。 z g c 是 在十一的时候引入的,那么这个是以超低停顿时间为目标的一个垃圾回收器,并且它开始移出了一些 java 一 的版本,让 java 看起来更加轻量化。 然后接下来呢,就是 g d k 十二到十七,那重点呢,就是在于语法堂和新特性的一些叠代啊,那么比如说引入一个文本块,然后解决了多行制服穿的一个书写难题,然后引入了雷克的类,然后用于简化我们纯数据对象的定义,还有像 switch 表达式的增强,让代码看起来更加简单。 然后在类型方面呢,增加了像秘分类对吧? excel 来去更加精准的控制类的一个继承,然后以及像 python matching, 对 吧?就是模式匹配。然后其次方面呢,就是除了十一引入的 z g c 对 不对?那还实现了一些分带式的 z g c, 然后进一步的提升了性能。 然后最后啊,就是可能现在你们还没有用到的就是 g d k 二十一,它引入了一个虚拟现成,那么用极低的开销来支持百万级的一个现成,那么这个呢,以后啊,就是肯定会有一个比较大的作用,能够去根本上改变我们便携高兵法应用的一个方式, 同时呢还能保证,对吧?就是后面可以去回归到我们一个同步组色的模型,并且还能保证高性能好。那么这个呢,可能也是在 java 之后啊,最重要的一个东西了,就是虚拟现成。

主任部的三点零就要出来了,官方已经宣布不再支持扎瓦吧,而是最低要求要扎瓦时期了。很多人问要不要做升级,什么时候升级?刚好最近呢,这里边要公布了一份二零二二年扎瓦工程师的生产力报告,其中有几项调查呢,就是关于 jtk 版本的使用以及升级计划的,可以给大家简单解读一下。 从报告上给这个数据来看呢,目前市面上主流的 gdk 的版本还是以扎瓦巴和扎瓦石一为主,总占比呢超过了百分之六十。 对于升级扎瓦时期的计划上面来看的话,有百分之六十左右的人呢表示会在一年内升级到 jdk 时期,只有百分之八的人表示不会升级。可以看到整体的行业趋势上呢,大家还是普遍的愿意升级到 jdk 时期的, 升级的主要原因呢,大家更在意的可能是这个版本是不是 lts 的呃,以及他的安全性和性能上面是否有一些提升。呃,看了行业的一些趋势之后呢,总结一下我的观点。首先呢,如 如果你用的是 gtk 八以下的版本,并且有升级计划的话,那么建议你呢就一步到位,直接升级到 gtk 十七,因为这个是目前最新的 lts 的版本。呃,还有就是如果希望将来使用 sprrenfree, mark 六以及 surpro 三点零的话,那么就建议升级到扎瓦时期,因为不升级的话是用不了的。 还有呢,就是如果你遇到了一些性能的问题,安全性的问题,或者是希望使用到一些新版本当中才有的新的特性的话,那建议大家升级到扎瓦时期,除了以上几种情况的话,如果你还在用的是扎瓦吧,并且线上跑的也挺好的,也没有准备用新的 spa 的话,那么其实是可以不用升级的。

今天老师傅搭建一个技能交通后端系统,我们先下载 jdk 二十五,下载完成解压就好了,我们用 jdk 二十五,你信不信?还在用 jdk 八,那么你认为星球环境可以升级到 jdk 二十五吗?欢迎交流。我们去 steam 网站粗细划一个项目, 把这个模板下载下来,用 id 打开, 我们先用 idr 配置 jdk, 哎,怎么不能导入,这个是个什么错?为啥 jdk 文件不正确,我们问问 ai 看看。这提到文件权限可能不对,我们去看看 jdk 目录权限怎么都是数字,我们修改一下试试。 怎么还是在报错,这不科学啊,怎么还是不对,老师傅也没办法了, 看来今天老师傅也遇到难题了,不管了,反正能导入进去,只是没有版本号,我们先建个夹板文件,写个 hello world 运行一下看看,嘿嘿嘿,怎么又报错了,这都是英文啊,看不懂啊,看不懂,别着急啊别着急,我们多找找。 难道是 idea 的 版本不对?我们上网搜搜, 果然最新的 idea 才支持 jdk 二十五,我们安装一个最新的 idea 试 试,果然成功了,不容易啊不容易,并且导入 jdk 二十五也不报错了,接下来写个小页面测试一下, 接下来我们用命令翻译一下我们的项目,哎哎哎,怎么又报错了?这个好像是说没问的版本不能低于三点六点三, 还好我装了一个三点八的,没问版本,老师傅专业吧,什么软件都有准备,我们再试一下,走你。哎哎哎,怎么还是不对,这个意思是 jdk 版本不对,我们看下脚本, 原来是这里,我们指定了 jdk 的 版本是 jdk 八小意思,我们修改成我们安装的最新的 jdk。 二十五 这步就好了。下一期我们将配置包移动连接、 mysl 和连接值,敬请期待。

各位 gdk 八的兄弟们,我扛不住诱惑,先去升级到 gdk 十七了,现在 gdk 的版本升级的非常快,已经到 gdk 二十了。 gdk 的版本虽多,但应用最广泛的还是 gdk 八,正所谓他发任他发,我用张老八。 其实我也不太想升级 gdk 版本,感觉投入高,收益少。而不过有一次我看到了一些使用 gdk 时期的信誉卡写的代码,让我改变了对升级 gdk 的看法,因为这些信誉卡我确实想用。废话不多说,上代码。 首先是文本块,这个更新非常实用,在没有这个特性之前,编写长文本非常的痛苦。虽然 rde 等计算开发工具可以自动处理,但最终效果仍然丑陋,充满拼接的符号。现在通过字符串块,我们可以轻松的编写 gs, html 等内容,效果更清爽。 这个新特性值得很高分的评价,因为他让我们只需关注字不串的本身,而无需关心拼接的操作。然后是控制针异常的增强 空指针异常一直是扎瓦成员的痛点,对于报测信息,无法直观的指出哪个对象为空,只掏出了一个 npe 和一堆对战的信息。定位问题非常的耗时而且麻烦, 尤其是遇到喜欢急联调用的代码时,租行的排查真是令人头疼。现在扎瓦时期的新特性提供了更详细的控制异常的信息,帮助开发者迅速定位问题的源头。然后是 record, 在扎瓦中, p o, p o, d, t, o 等通常包含对象变量以及相应的 get 和赛的方法。尽管可以通过工具化 i d, e 去生成这些代码,但修改和维护起来仍然非常麻烦, 为此扎瓦引入了标准解决方案,为靠他通过简洁的语法定义数据类,大大简化了 top 类的编写。接下来是全新的 switch 表达式,在扎瓦十二的时候就引入了 switch 表达式,注意这里是表达式,而不是语句,原来的 switch 是语句,如果被清楚两者的区别的话,最好先了解一下, 主要的差别就是表达式有返回值,而语句则没有再配合。模式匹配,全新的思维使用起来非常的爽。然后是私有接口方法,所以在战马时期里面,如果一个得放的方法体很大,那么可以通过新增接口私有方法来进行一个合理的拆分。最后是模式匹配,在 gdk 时期中,模式匹配主要用于 instinct 表达式, 模式匹配增强了一丝丝恶物的语法和功能,向类型检查和类型转换更加简洁和高效。你还知道哪些新特性呢?

我专门自定义了一个菜单,名字叫继续,因为项目初步或者稳定运行之后, ai 经常还会反复问我要不要继续执行下一步, 以前每次都得重新输入继续,现在只要点一下这个菜单就会自动发出继续,整个操作流畅很多,也特别实用。 关注我,了解更多使用技巧。

任何 java 项目都必须依赖 jdk 吗?答案是不一定。你可能会说,怎么可能不依赖 jdk, 怎么翻译和运行呢?这听上去确实有道理,但是如果你深究的话,这个问题可能会有更深刻的答案。比如,你有没有想过 jdk 本身是一个 java 项目吗? 这里是源码世界,用动画演绎编程知识。你平时写的业务型 java 项目肯定离不开 jdk, 这其实没毛病,但我们可能忽略了一个特例, jdk 本身也是一个 java 项目,比如 jdk 中包含了 java 核心内库,包含了编辑器等工具, 这些都是使用 java 语言编写的。所以你觉得 jdk 本身需不需要依赖 jdk 呢?嗯,想要回答这个问题, 首先应该弄清楚所谓依赖 jdk 到底在依赖什么。我们知道, java 程序想要从源码到运行,离不开核心类、库、编辑器,还有 jvm 虚拟机, 而这几样东西都包含在 jdk 中。对于 jdk 项目本身,其核心类和编辑器都是以库或工具的形式提供给其他开发者使用的,所以只需要依赖 jdk 中的编辑器其实就够了。 进而可以回答刚才的问题, jdk 在 翻译环节确实是需要依赖 jdk 的。 哎,不对啊, jdk 依赖 jdk, 怎么有一种鸡生蛋、蛋生鸡的感觉?这难道不会造成循环依赖吗? 其实不用担心,通常情况下,在翻译某一个版本的 jdk 时,会选用上一个临近版本的 jdk 作为依赖。 比如你要开发翻译 jdk 二十六,那你的开发环境里就得先装好 jdk 二十五,用 jdk 二十五中的编辑器来编 jdk 二十六的原码,你以为这就万事大吉了?有没有感觉哪里还有点不对劲?我们来捋一捋。 如果新版本只是对旧版本做性能优化或者 bug 修复,那还好,但是万一要引入新的语法怎么办?比如 jdk 八中引入了拉姆纳表达式这种新的语法, jdk 七的编辑器来翻译带有拉姆纳表达式的代码,肯定会报错呀,这咋整? 能想到这一层,说明我们已经对 java 语言的研发迭代有了更深刻的理解。其实解决这个问题也不难, 具体流程是这样的,首先用 jdk 七的语法写一个可以翻译拉姆纳表达式的编辑器,然后用 jdk 七原来的编辑器来编辑这个刚写好的新的编辑器,最后用新的编辑器来编辑 jdk 八的原码。这听上去似乎有点绕嘴, 但如果你捋清楚之后,会深刻体会到其中的巧妙。这种现象在计算机语言的发展过程中被称为自举。问题到这里并没有结束,继续按这个逻辑推导, jdk 八依赖 jdk 七, jdk 七又依赖 jdk 六,直到第一个版本的 jdk 再往前,就没有 jdk 可以 依赖了。 所以,最核心的问题来了,第一个 jdk 到底是怎么诞生的?这个问题和前面的 jdk 八引入新特性的问题很类似,其实第一个 jdk 版本根本不需要依赖另一个 jdk。 前面有说过,要想翻译一个 jdk, 其实只需要依赖一个可以翻译它的编辑器就可以了。 至于这个编辑器是怎么实现的并不重要,这就好办了呀,我们可以用其他语言写一个可以翻译 java 语言的编辑器就好了呀。 所以第一版 jdk 其实是依赖 c 加加写的编辑器实现了首次翻译。一旦实现首次翻译,第一版 jdk 就 有了, 也象征着 java 语言诞生了。自此之后,想要开发 jdk 新版本,就可以依赖旧版本的 jdk 实现自我迭代和升级,这个过程就好比自己把自己举起来一样,所以形象的称作自举。当然, 几乎所有的编程语言都有类似的诞生和发展方式,比如 c 语言。第一个 c 语言编辑器是用会编写的,后来 c 语言慢慢成熟,就用 c 语言自己写了自己的编辑, 从而实现了自己。最后问你一个问题,为什么 jvm 需要用 c 加加来写? jvm 可以 用 java 语言来写吗?为什么?请将你的理解写到评论区,如果喜欢我的视频,欢迎点赞和关注,下期见!

呃,今天来录一个视频。呃,一部分同学问过一个问题啊,就是说,哎,店里面怎么来指定项目的?一个 gdk? 呃,有时候新建项目的话,这个比较简单啊,有时候说你拿到了一个别人的项目的话,呃,这时候来指定一下你本地 jdk 的话。呃,首先先把这个项目打开,我这随便建了一个项目,然后点击你的这个 fail。 呃,然后选择这一块 sentence, 就设置下面的这么一个 project, 这个选项 好,选择过来之后的话,可以看到这有个 project settings 选这个。呃,然后右边的话,你就可以看到这有一个 s d k。 在这个地方,你就可以来指定你这个项目要用的一个 g d k 的版本了。 呃,我本地的话是有一个 g d k 十七和一个一点儿八。呃,如果你这儿没有空的话,点这个 l s d k, 然后点这个 g d k, 然后来你本地去选择一下你那个 g d k 的一个路径就行了。呃,比如说像这个都可以看到,我本地的话两个 g d k。