cygwin有java sdk吗？
cygwin有java sdk吗？
Is there a java sdk for cygwin?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
cygwin有java sdk吗？
Is there a java sdk for cygwin?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
如果有一个使用 cygwin 文件系统和 X-windows 进行显示的本机 cygwin 实现，那就太好了，不幸的是我不知道这样的版本。 我认为移植 OpenJDK 也需要付出很大的努力，但我还没有尝试过。
It would be nice if there were a native cygwin implementation which used the cygwin file system and X-windows for display, unfortunately I am not aware of such a release. I would assume it is quite an effort to port OpenJDK as well, but I haven't tried.
虽然 cygwin 没有 java sdk，但如果您愿意为各种问题提供变通办法，则可以让 Windows jdk 工作：
根据我的经验，第一个项目符号是迄今为止最大的问题，尽管这三个项目有些相互关联。 作为解决第一个问题的副作用，分离器往往会自行处理。
这三个问题在很大程度上通过建立一个开发环境来解决，在该环境中，所有感兴趣的文件路径（如 java.io.File 和 java.nio.Path 等所查看的）都可以在不指定驱动器号的情况下表示。
事实证明，在 Windows 下，很少需要在文件路径字符串中使用反斜杠。 我遇到的该规则的唯一例外是在为需要反斜杠的程序（例如 CMD.EXE）生成命令行时将文件路径字符串作为参数传递。 java.io 和 java.nio 包都接受正斜杠，因此，Microsoft 开发库也接受正斜杠。 大多数拒绝带有正斜杠的路径的程序（恕我直言）可能是无缘无故地这样做。
因此，真正的问题是 java.io.File 无法将“/cygdrive/c”识别为引用“C:\”。
换句话说，以下文件测试将返回 false：
而这按预期工作：
Windows 的最新版本现在支持通用符号链接，提供了一种设置不使用驱动器号的 cygwin 开发环境的方法。 通过整个文件系统的统一视图（所有文件都出现在“/”下面，默认驱动器号不变，例如C:），可以从文件路径字符串中丢弃驱动器号。 换句话说，您希望能够将“c:/”引用为“/”。 这可以通过多种方式完成，其中一种是对 c:/ 下面的其他驱动器进行符号链接，例如：
如果环境变量 CYGWIN 包含“winsymlinks:native”，这将创建一个 Windows 符号链接，结果是（假设 c: 是默认驱动器）你的java程序将正确识别字符串“/d”作为指代“D：\”，所以你可以这样做：
如果你不能或不愿意修改你的cygwin环境，还有另一种方法，这是更多普遍的。 您可以扩展 java.io.File 并覆盖构造函数和各种方法（实际上）将 cygwin 路径转换为其 Windows 等效路径（如 cygpath -m 或 -w），并将 Windows 路径字符串转换为更类似于 POSIX 的格式。 我有这样一个库（用 scala 编写，但可以从 java 使用）并打算使其可用，希望很快就能实现。
Although there is no java sdk for cygwin, you can get the Windows jdk to work if you are willing to accommodate workarounds for various problems:
In my experience, the first bullet is by far biggest problem, although the three are somewhat inter-related. The separators tend to take care of themselves as a side-effect of solving the first problem.
All three problems are largely resolved by setting up a development environment in which all file paths of interest (as viewed by java.io.File and java.nio.Path, etc.) can be represented without specifying a drive letter.
As it turns out, it's rarely necessary to use backslashes in a file path string under windows. The only exceptions to this rule that I have encountered are when passing file path strings as parameters when spawning a command line for a program that require backslashes (e.g., CMD.EXE). The java.io and java.nio packages all accept forward slashes, and so, for that matter, do the Microsoft development libraries. Most programs that reject a path with forward slashes are (IMHO) likely to be doing so gratuitously.
So, the real problem is that "/cygdrive/c" is not recognized by java.io.File as referring to "C:\".
In other words, the following file test will return false:
whereas this works as expected:
Recent versions of Windows now support general symlinks, providing a way to setup a cygwin development environment in which drive letters are not used. With a unified view of the entire filesystem (with all files appearing below "/", the default drive letter being invariant, e.g., C:) , the drive letter can be discarded from file path strings. In other words, you want to be able to refer to "c:/" as "/". This can be accomplished in various ways, one being to symlink other drives below c:/, for example:
If env variable CYGWIN contains "winsymlinks:native", this will create a Windows symlink, with the result that (assuming c: is the default drive) your java program will correctly recognize the string "/d" as referring to "D:\", so you can do this:
If you are unable or reluctant to modify you cygwin environment, there is another approach, which is more universal. You can extend java.io.File and override constructors and various methods to (in effect) to translate cygwin paths to their windows equivalent (like cygpath -m or -w), and to translate windows path strings to a more POSIX-like format. I have such a library (written in scala, but usable from java) and intend to make it available, hopefully sometime soon.