java runtime environment,idea还需要jdk吗?
是的,IntelliJ IDEA需要安装JDK才能编写和运行Java代码。无法使用JRE(Java Runtime Environment)。需要确保已安装JDK并配置正确的JAVA_HOME环境变量。

JDK和JRE的区别是什么?
1、面向人群不同:
JDK是面向开发人员使用的SDK,是Java开发运行环境。
JRE是Java Runtime Enviroment是指Java的运行环境,是面向Java程序的使用者。如果你不需要开发只需要运行Java程序,那么你可以安装JRE,例如程序员开发出的程序最终卖给了用户,用户不用开发,只需要运行程序,所以用户在电脑上安装JRE即可。
2、重要程度不同:
JRE的地位就象一台PC机一样,编写的Java程序必须要JRE才能运行。只要你的电脑安装了JRE,就可以正确运行Java应用程序。
3、安装位置不同:
如果安装JDK,电脑有两套JRE,一套位于 \jre 另外一套位于 C:\Program Files\Java\j2re1.4.1_01 目录下。
怎样查找JDK的安装路径?
回答如下:在Windows操作系统中,可以通过以下步骤查找JDK的安装路径:
1. 打开“控制面板”。
2. 单击“程序”。
3. 单击“Java”。
4. 在“Java控制面板”中,单击“Java”选项卡。
5. 点击“查看”按钮,可以看到JDK的安装路径。
在Linux或Mac操作系统中,可以通过以下命令查找JDK的安装路径:
1. 打开终端。
2. 输入命令“echo $JAVA_HOME”。
3. 如果该命令返回JDK的安装路径,则可以直接查看。
4. 如果该命令没有返回JDK的安装路径,则可以在文件系统中搜索JDK的安装目录。常见的安装目录为“/usr/lib/jvm/”或“/usr/java/”。可以使用命令“sudo find / -name jdk”来搜索JDK的安装路径。
jdk有jre为什么还要安装jre?
1.JDK是Java Development Kit的缩写,包括了Java运行环境,Java工具和Java基础的类库。
2.JRE是Java Runtime Environment缩写,指Java运行环境,包含JVM。
由上可见,用JDK开发Java程序时,如果不涉及到Java程序的运行,可以没有JRE环境;但是在Java程序开发时,进行程序的运行与调试是必须的,必须要有Java程序的运行环境,也就是JRE的存在;所以JDK安装必须要安装JRE。
为什么NET平台在技术上远强过Java?
你可能对平台的这个概念的认识范围偏窄了点。
重点一:生态!生态!生态!
重点二:Java的开发环境更容易让人成长,从统计上看Java研发人员的IT认知和水平是普遍高于.Net的。我面过很多.Net程序员,很少能碰到技术过关的程序员(问一个TCP的半连接就能死一大片人)。
重点三:平台归平台,一个强大的IT民工拥有的更多是平台无关的知识和技能。比如线程和IO,精通了这两项,我相信哪个平台你都会上手很快,也会很牛逼。
重点四:你不是必须在Java和.Net之间做出是非的选择!客户端开发,可以优选Winform和Wpf。服务端开发,可以用你喜欢的平台喜欢的姿势构建微服务。如果有时间和资本,完全可以把Java的生态"复制"到.Net上来(第一步可以考虑把netty搬过来,但是你最好要保持别人的版本更新)。
重点五:开源和跨平台再我看来不是最重要的,前有Mono,现在有netcore,一个反编译,想看源码随意。开放的姿态才是最重要的:一个平台如何促进更多有意义的技术协议的产生和推广,如何激发广大IT人员发挥创造力去壮大社区,这个很重要,这样才能有更丰富的生态环境。
最后的重点:我大部分的时间都用在.NET上了,但是我并没有和她结婚,根据需要,我经常去搞外遇。github上我follow的大部分项目都不是.NET的。
最后再上一堆废话。
.NET拥抱开源之前
.NET的优势:
首先,是的封闭生态,好处在于学习门槛低和学习较少东西就可以搭建一个简单的平台。
其次,是.NET在语言级别设计是领先Java的,微软在编程便利性上下了很大的功夫,"傻瓜式"积木搭建估计是他一直追求的东西。从Java5到现在Java10,可以看到不少C#早已存在的东西。不过例如泛型之类的设计,Java在类型擦除后,中间代码已经没有了泛型的身影。
再次,是VS作为IDE的强大,这个是必须称赞的,.Net开发不二之选。
.NET的劣势:
首先,是.Net太注重入门的门槛,却让很多人浑浑噩噩很多年。人都是懒惰的,许多人都是能完成任务就好,点到即止。举个简单的例子,我面试过很多工作多年的.Net程序员,他们连最基本的委托和事件的本质都不了解。抛开event关键字的支持,合格的.Net程序员应该有能力自己实现委托和事件的机制。这里并不是说真要去重复造这么个轮子,在碰到某些情况需要你上手设计的时候,你根本就无从下手(比如要实现一个挂弱引用的委托来做一个进程内的消息订阅中心)。
其次,是封闭带来的知识局限性。数年前,除了从Java移植过来的部分开源库,大量的.Net程序员实际上都是在利用.NET本身的应用程序模型做研发,再多一点就是把GoF的设计模式应用一下。在技术理论的扩展方面,难就一个字。比如,一个小东西,动态代理,看看它是如何来的?
最后,在封闭的生态下,看着Java那庞大的开源社区只能留着口水考虑移植或者仿照设计。
.NET拥抱开源之后....然并卵,但是我喜欢他的Aspnetcore应用程序模型。如果你看过Aspnet的同步模型源码,估计你早就不想用Aspnet了。
一个字,太晚了,就算别的公司被你优秀的基础架构看湿了,也只能去换裤子,毕竟成熟的公司看重的是生态。举个不恰当的例子,同一个城市一个一千人口的生活圈和一个百万人口的生活圈的小区房子价值做对比看看,或者你要做生意选哪个生活圈?


还没有评论,来说两句吧...