在 Java 中使用文件路径的最佳实践

发布于 2024-12-09 18:34:53 字数 385 浏览 0 评论 0原文

我正在尝试加载属性文件来创建配置。即 foo.properties。

存储此配置文件的最佳位置是什么。在我将使用初始化使用类的包中?在 src 的根级别?

另外,在访问文件时,我使用文件在文件系统中的位置:即:c:\configs\foo.properties。

对此有更好的做法吗?例如使用相对于项目的路径而不是文件系统位置?如果是,我如何引用项目树中属性文件的位置。例如:

src/
   /com.foo.bar
   /com.foo.car
   /com.foo.zar
   foo.properties

假设我想将属性文件读取到内存中,如何在不使用操作系统位置或文件系统中的位置的情况下访问此 foo.properties。

I m trying to load properties file to create a configuration. namely foo.properties.

What the best place to store this config file. Within the package where i will use initialize the using class? on the root level of the src?

Also, while accessing the files, i am using the location of the file in the file system: ie: c:\configs\foo.properties.

Is there a better practice for this? such as using the path relative to the project rather than the file system location? if yes, how can i reference the location of a property file within a project tree. such as:

src/
   /com.foo.bar
   /com.foo.car
   /com.foo.zar
   foo.properties

lets say i want to read the properties file to memory, how do i access this foo.properties without using the OS location/ or the location in the file system.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

任性一次 2024-12-16 18:34:53

我一直看到的完成方式是将属性文件放在 src/main/resources 中,然后使用 getResourceAsStream()

这是一个值得一看的好问题:加载包含在罐子

The way that I've always seen it done is to place the properties file in src/main/resources and then access it with getResourceAsStream().

This would be a good question to look at: Load a resource contained in a jar

可可 2024-12-16 18:34:53

如果您想保持与当前结构接近的内容,那么您只需添加一个 resources 文件夹,如下所示:

src/
   /com.foo.bar
   /com.foo.car
   /com.foo.zar
resources
   /foo.properties

但我强烈建议遵循 Maven 目录结构,它们确实为您提供了很大的灵活性:

src/
    /main
        /java
            /com.foo.bar
            /com.foo.car
            /com.foo.zar
        /resources
            /foo.properties

无论我建议您将资源放在与 Java 包之一匹配的文件夹结构中,这样您就可以轻松地将它们作为资源加载,避免绝对文件路径与相对文件路径的难题。像这样的事情:

src/
    /resources/
       /com/foo/bar/foo.properties

给定一个类 com.foo.bar.MyClass 你可以做这样的事情:

InputStream is = MyClass. getResourceAsStream("com/foo/bar/foo.properties");

If you want keep something close to your current structure then you can just add a resources folder, like so:

src/
   /com.foo.bar
   /com.foo.car
   /com.foo.zar
resources
   /foo.properties

But I highly recommend following Maven directory structures, they really do give you a lot of flexibility:

src/
    /main
        /java
            /com.foo.bar
            /com.foo.car
            /com.foo.zar
        /resources
            /foo.properties

Regardless of what layout you go with I would recommend putting your resources in a folder structure matching one of your Java packages, that way you can easily load them as resources, avoiding your absolute vs relative file path conundrum. Something like this:

src/
    /resources/
       /com/foo/bar/foo.properties

And given a class com.foo.bar.MyClass you can do something like this:

InputStream is = MyClass. getResourceAsStream("com/foo/bar/foo.properties");
云醉月微眠 2024-12-16 18:34:53

我认为位置实际上取决于您的项目。我通常喜欢有一个特定的文件夹来存储配置文件。

至于访问文件的方式,使用绝对路径是一个非常糟糕的想法:想象一下,您想要将应用程序作为 Jar 分发,将其部署在 Web 服务器上,或者干脆将其完全移动到另一个地方!

看一下:

http://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#getResourceAsStream-java.lang.String-

如果您的类路径中有属性文件(作为例如,您的源代码的一部分),然后您可以以相同的方式加载它,无论您在哪里(即使在罐子内)。

I think the location really depends on your project. I usually like having a specific folder to store configuration files.

As to the way you access the file, using absolute paths is a really bad ideia: Imagine you want to distribute your application as a Jar, deploy it on a web server, or simply move it to another place completly!

Take a look at:

http://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#getResourceAsStream-java.lang.String-

If you have the properties file in your classpath (as part of your source, for instance), then you can load it in the same way independently of where you are (even inside a jar).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文