关于jdk的问题

逍遥jc 2014-10-16 09:05:45
我在环境变量中配置的jdk版本是32位的,eclipse也是32位的,但是在eclipse中通过build path 引入了同版本JDK(但是是64位的)。这样是可行的。有知道原因的么?环境变量配置和eclipse必须是一样,这个我是知道的。
...全文
422 15 打赏 收藏 转发到动态 举报
写回复
用AI写文章
15 条回复
切换为时间正序
请发表友善的回复…
发表回复
humanity 2014-11-20
  • 打赏
  • 举报
回复
纯 Java 的程序完全可以在所有 32位和64位的 JRE 上运行,也理论上应该能在所有厂商的 JRE 上运行(JVM 规范中要求的,除非你使了厂商专用的类,比如 JDBC-ODBC 桥接驱动在 IBM JRE 中就没有)。64位与32位的差别仅在于“当你使用了 dll / so 这些 native 功能时”。
引用 14 楼 u010111184 的回复:
引用 12 楼 humanity 的回复:
在项目属性中选了 64 位 JRE /JDK 库,但你在运行时依然可以换32位的 JDK / JRE,这要看你的 Launching profile 是怎么配置的,eclipse 默认地做法是把你的项目的 build path 中的设置复制过去当默认值,但我们可以手工改它。 [quote=引用 11 楼 humanity 的回复:] 正确,Java 编译得到的结果是抽象化的字节码,并未直接对应到机器码。这个时候是不需要知道目标机器是什么操作系统平台或硬件平台的。但 DLL 相关的东西就不同了它本身是 native 的,就是跟硬件平台和操作系统平台直接相关,在编译链接的过程中已经确定了。 你说的 Eclipse 的自己运行所用的 JRE 那只是“让 Eclipse 运行起来”,它跟我们开发时编译一个项目没有任何关系。比如你用一个 JRE 1.3 运行一个老版本的基于 Eclipse 2.1 IBM WSAD 5.1.2,但它的 workspace 中的项目都是 WebSphere 5.1 对应的 JDK 1.4 的,这没有任何问题。 [quote=引用 10 楼 u010111184 的回复:] [quote=引用 5 楼 humanity 的回复:] 纠正: 因此编译的过程当然就跟操作系统 【没】有关系。 [quote=引用 4 楼 humanity 的回复:] Java “一次编译,到处运行” 就是要解决跨平台的问题,让 Java 代码与平台无关(只要我们不直接使用 DLL 或操作系统特有的功能)。因此编译的过程当然就跟操作系统有关系,而在运行的时候则需要让 JVM 与相应的操作系统配对,然后我们能过配置命令行参数来记程序与操作系统配合(这个时候已经与程序开发没有关系了吧)。
就是说编译时用的是64位的JDK。而我真正使用的时候是32位的JDK?是这样么?[/quote][/quote][/quote] 明白了。就是运行时使用的是64位的JRE。[/quote]
逍遥jc 2014-11-20
  • 打赏
  • 举报
回复
引用 12 楼 humanity 的回复:
在项目属性中选了 64 位 JRE /JDK 库,但你在运行时依然可以换32位的 JDK / JRE,这要看你的 Launching profile 是怎么配置的,eclipse 默认地做法是把你的项目的 build path 中的设置复制过去当默认值,但我们可以手工改它。
引用 11 楼 humanity 的回复:
正确,Java 编译得到的结果是抽象化的字节码,并未直接对应到机器码。这个时候是不需要知道目标机器是什么操作系统平台或硬件平台的。但 DLL 相关的东西就不同了它本身是 native 的,就是跟硬件平台和操作系统平台直接相关,在编译链接的过程中已经确定了。 你说的 Eclipse 的自己运行所用的 JRE 那只是“让 Eclipse 运行起来”,它跟我们开发时编译一个项目没有任何关系。比如你用一个 JRE 1.3 运行一个老版本的基于 Eclipse 2.1 IBM WSAD 5.1.2,但它的 workspace 中的项目都是 WebSphere 5.1 对应的 JDK 1.4 的,这没有任何问题。 [quote=引用 10 楼 u010111184 的回复:] [quote=引用 5 楼 humanity 的回复:] 纠正: 因此编译的过程当然就跟操作系统 【没】有关系。 [quote=引用 4 楼 humanity 的回复:] Java “一次编译,到处运行” 就是要解决跨平台的问题,让 Java 代码与平台无关(只要我们不直接使用 DLL 或操作系统特有的功能)。因此编译的过程当然就跟操作系统有关系,而在运行的时候则需要让 JVM 与相应的操作系统配对,然后我们能过配置命令行参数来记程序与操作系统配合(这个时候已经与程序开发没有关系了吧)。
就是说编译时用的是64位的JDK。而我真正使用的时候是32位的JDK?是这样么?[/quote][/quote][/quote] 明白了。就是运行时使用的是64位的JRE。
大数据小白 2014-11-18
  • 打赏
  • 举报
回复
可能是这样,32配64的能配上,但是64配32的配不上。
humanity 2014-10-23
  • 打赏
  • 举报
回复
在项目属性中选了 64 位 JRE /JDK 库,但你在运行时依然可以换32位的 JDK / JRE,这要看你的 Launching profile 是怎么配置的,eclipse 默认地做法是把你的项目的 build path 中的设置复制过去当默认值,但我们可以手工改它。


引用 11 楼 humanity 的回复:
正确,Java 编译得到的结果是抽象化的字节码,并未直接对应到机器码。这个时候是不需要知道目标机器是什么操作系统平台或硬件平台的。但 DLL 相关的东西就不同了它本身是 native 的,就是跟硬件平台和操作系统平台直接相关,在编译链接的过程中已经确定了。

你说的 Eclipse 的自己运行所用的 JRE 那只是“让 Eclipse 运行起来”,它跟我们开发时编译一个项目没有任何关系。比如你用一个 JRE 1.3 运行一个老版本的基于 Eclipse 2.1 IBM WSAD 5.1.2,但它的 workspace 中的项目都是 WebSphere 5.1 对应的 JDK 1.4 的,这没有任何问题。


引用 10 楼 u010111184 的回复:
[quote=引用 5 楼 humanity 的回复:]
纠正:
因此编译的过程当然就跟操作系统 【没】有关系。

[quote=引用 4 楼 humanity 的回复:]
Java “一次编译,到处运行” 就是要解决跨平台的问题,让 Java 代码与平台无关(只要我们不直接使用 DLL 或操作系统特有的功能)。因此编译的过程当然就跟操作系统有关系,而在运行的时候则需要让 JVM 与相应的操作系统配对,然后我们能过配置命令行参数来记程序与操作系统配合(这个时候已经与程序开发没有关系了吧)。


就是说编译时用的是64位的JDK。而我真正使用的时候是32位的JDK?是这样么?[/quote][/quote]
humanity 2014-10-23
  • 打赏
  • 举报
回复
正确,Java 编译得到的结果是抽象化的字节码,并未直接对应到机器码。这个时候是不需要知道目标机器是什么操作系统平台或硬件平台的。但 DLL 相关的东西就不同了它本身是 native 的,就是跟硬件平台和操作系统平台直接相关,在编译链接的过程中已经确定了。 你说的 Eclipse 的自己运行所用的 JRE 那只是“让 Eclipse 运行起来”,它跟我们开发时编译一个项目没有任何关系。比如你用一个 JRE 1.3 运行一个老版本的基于 Eclipse 2.1 IBM WSAD 5.1.2,但它的 workspace 中的项目都是 WebSphere 5.1 对应的 JDK 1.4 的,这没有任何问题。
引用 10 楼 u010111184 的回复:
引用 5 楼 humanity 的回复:
纠正: 因此编译的过程当然就跟操作系统 【没】有关系。 [quote=引用 4 楼 humanity 的回复:] Java “一次编译,到处运行” 就是要解决跨平台的问题,让 Java 代码与平台无关(只要我们不直接使用 DLL 或操作系统特有的功能)。因此编译的过程当然就跟操作系统有关系,而在运行的时候则需要让 JVM 与相应的操作系统配对,然后我们能过配置命令行参数来记程序与操作系统配合(这个时候已经与程序开发没有关系了吧)。
就是说编译时用的是64位的JDK。而我真正使用的时候是32位的JDK?是这样么?[/quote]
逍遥jc 2014-10-22
  • 打赏
  • 举报
回复
引用 5 楼 humanity 的回复:
纠正: 因此编译的过程当然就跟操作系统 【没】有关系。
引用 4 楼 humanity 的回复:
Java “一次编译,到处运行” 就是要解决跨平台的问题,让 Java 代码与平台无关(只要我们不直接使用 DLL 或操作系统特有的功能)。因此编译的过程当然就跟操作系统有关系,而在运行的时候则需要让 JVM 与相应的操作系统配对,然后我们能过配置命令行参数来记程序与操作系统配合(这个时候已经与程序开发没有关系了吧)。
就是说编译时用的是64位的JDK。而我真正使用的时候是32位的JDK?是这样么?
逍遥jc 2014-10-22
  • 打赏
  • 举报
回复
引用 1 楼 yybjroam05 的回复:
可能是运行时找的变量里的路径,你环境配的是32位的,估计是这个原因吧。
我也不太清楚,估计是这么个道理。启动的时候参照环境变量的里JDK。具体启动的时候按照引入的JDK运行。
逍遥jc 2014-10-22
  • 打赏
  • 举报
回复
引用 7 楼 u010096810 的回复:
这样可以查看你安装路径,
程序启动时使用的是64位的JDK。我特意打印了。JDK 信息:1.6.0_45 64bit。因为如果是32位的JDK的话,JVM分配的内存是有限制的,压根程序就启动不了。
最重要的决定 2014-10-16
  • 打赏
  • 举报
回复
这样可以查看你安装路径,
最重要的决定 2014-10-16
  • 打赏
  • 举报
回复
可能是你 使用的就是32位,64位的根本没有用到,
humanity 2014-10-16
  • 打赏
  • 举报
回复
纠正: 因此编译的过程当然就跟操作系统 【没】有关系。
引用 4 楼 humanity 的回复:
Java “一次编译,到处运行” 就是要解决跨平台的问题,让 Java 代码与平台无关(只要我们不直接使用 DLL 或操作系统特有的功能)。因此编译的过程当然就跟操作系统有关系,而在运行的时候则需要让 JVM 与相应的操作系统配对,然后我们能过配置命令行参数来记程序与操作系统配合(这个时候已经与程序开发没有关系了吧)。
humanity 2014-10-16
  • 打赏
  • 举报
回复
Java “一次编译,到处运行” 就是要解决跨平台的问题,让 Java 代码与平台无关(只要我们不直接使用 DLL 或操作系统特有的功能)。因此编译的过程当然就跟操作系统有关系,而在运行的时候则需要让 JVM 与相应的操作系统配对,然后我们能过配置命令行参数来记程序与操作系统配合(这个时候已经与程序开发没有关系了吧)。
humanity 2014-10-16
  • 打赏
  • 举报
回复
Java Build Path 如名字所示,它只是用在编译的时候,而编译的时候并不使用 DLL / SO 链接库,所以不会出错的。 32 位/ 64位的差异主要是它们的 DLL / SO 链接库不一样,在运行时与操作系统的版本有关系。
skyWalker_ONLY 2014-10-16
  • 打赏
  • 举报
回复
运行的时候使用的是32位的jvm,你build path中的只是jar包
yybjroam05 2014-10-16
  • 打赏
  • 举报
回复
可能是运行时找的变量里的路径,你环境配的是32位的,估计是这个原因吧。

62,610

社区成员

发帖
与我相关
我的任务
社区描述
Java 2 Standard Edition
社区管理员
  • Java SE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧