blocks|key|2819102|text|如果这些值不是特定于环境的(即dev,qa,stage特定的)，并且在代码的整个生命周期中不发生变化，则在代码中将它们声明为静态最终值。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2819103|常量的缺点是，如果对常量做了一些更改，则需要重新编译它们，这在属性中不是这样，但如果是常量，则根本不应该更改。|2819104|例如:-在dev/qa/prod/prod环境中，您可能有不同的用户名"admin“凭据。|2819105|然后，您可以像public+static+final+String+userId="admin"一样定义管理用户，但是要从属性文件中提供密码，并根据运行代码的环境对其进行更改。|2819106|喜欢|2819107|dev.properties+admin.password+=+123456.
qa.properties+admin.password+=+abcdef.|blockquote|BOLD|2819108|然后根据您的环境从属性文件中读取这些密码。|2819109|entityMap^0|F|C|0|0|0|7|15|0|0|0|E|14|D|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|13|8|@]|D|@]|E|$]]|$1|N|3|O|5|P|7|14|8|@$9|15|A|16|B|Q]|$9|17|A|18|B|Q]]|D|@]|E|$]]|$1|R|3|S|5|6|7|19|8|@]|D|@]|E|$]]|$1|T|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|U|$]]

Declare them as static final in your code if these values are not environment ie <code>dev,qa,stage</code> specific and doesn't change throughout the lifecycle of your code.

Downside of constants are that you need to recompile them, if you make some change to them, which will not be the case in property but if its a constant it shouldn't change at all.

For example :- you might have different credentials for user name "admin" in your dev/qa/stage/prod environment. 

Then you can define the admin user like <code>public static final String userId="admin"</code> but password you want to supply from the property file and change it according to the environment in which you running your code.

like 

<blockquote>
 dev.properties admin.password = 123456.
 
 qa.properties admin.password = abcdef.
</blockquote>

And then read it these password from the properties file based on your environment.

blocks|key|1173627|text|真正的答案取决于你的需求。在现实世界中，没有"A比B更好“。只是：“给定要求x、y、z比B更有帮助”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1173628|因此，您只需考虑这两种方法的优缺点，才能决定什么对您“更好”。|1173629|使用常量的优点：|1173630|编译时间安全|unordered-list-item|1173631|编译器首先支持|1173632|简单:只有一个常数。属性需要来自文件，它们都是平面字符串，甚至可以是缺少的。|offset|length|style|BOLD|1173633|常量的缺点：|1173634|修补程序要求您向客户提供重新编译的类文件。|1173635|为了应用be修复，需要停止运行代码的JVM；或者至少需要重新部署容器(就像Tomcat中的WAR+)。|1173636|属性只是“相反的方式”。|1173637|换句话说:如果您愿意，您可以编写许多复杂的代码，允许您通过重新读取属性信息来“修补”正在运行的应用程序。通过这样做，您可以通过提供一个新的属性文件并触发应用程序中的一些“重读属性”挂钩来修补正在运行的应用程序。但毫无疑问:实现正确、可靠的方法是hard。|1173638|但是，除非上面的特性对您来说是真正的值，否则使用普通编译时常量可能会更好。您可以看到，“部署更新”是将文件提供给客户。这些文件中的大部分都是类文件或属性文件并不重要(当我们不是在讨论“热修复”要求时)。|1173639|entityMap^0|0|0|0|0|0|10|1|0|0|0|0|0|3E|4|0|F|3|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|19|8|@$M|1A|N|1B|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|T|5|H|7|1D|8|@]|9|@]|A|$]]|$1|U|3|V|5|H|7|1E|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1F|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1G|8|@$M|1H|N|1I|O|P]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1J|8|@$M|1K|N|1L|O|P]]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|13|$]]

The real answer depends on your requirements. There is no "A is better than B" in the real world. Only: "A is more helpful given requirements x,y,z than B".

Therefore you simply have to consider the pros/cons of both approaches in order to decide what is "better" for you. 

<h2>Advantages of using a constant:</h2>

<ul>
<li>compile time safety</li>
<li>compiler support in the first place</li>
<li>simplicity: there is just a constant. Properties need to come from files, they are all flat strings, they can even be missing.</li>
</ul>

<h2>Disadvantages of constants:</h2>

<ul>
<li>a bugfix requires you to provide re-compiled classfiles to your customers</li>
<li>in order to apply the bugfix, either the JVM running your code needs to be stopped; or at least your container (like a WAR in Tomcat) needs to be re-deployed. </li>
</ul>

Properties are just "the other way round".

In other words: if you want to, you can write a lot of complicated code that allows you to "patch" a running application by enabling it to re-read property information. 
By doing so, you enable your customer to patch a running application by providing a new property file and triggering some "re-read properties" hook inside the application. But make no mistake: implementing a correct, reliable way of doing that is hard.

But unless the above feature is of real value to you, you are most likely better of using plain compile-time constants. You see, "deploying an update" is about giving files to the customer. It doesn't really matter that much of those files are class files or property files (when we are not talking about "hotfix" requirements).

blocks|key|1106431|text|我试过这两种方法-文件和公共静态的最后一堂课，这两种方法都很有效。不过，值得注意的是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1106432|如果您的程序需要由希望更改这些常量的各方测试/运行，那么在文件中声明将是特别有利的。在这种情况下，这将被称为App/program的属性。Spring采用这种配置方法。|unordered-list-item|1106433|在类中声明它们将需要一次又一次地重新构建应用程序，但是如果这些常量不改变，或者不需要被多方访问，您可以非常容易地选择静态的最后类方法。例如，Android声明在R.java文件中动态生成的常量。顺便说一句，这种方法在你的手中保持着控制。使用您的代码的3rs方将无法更改这些常量。文件方法将控制传递到其他人的手中，以改变他们。|1106434|Object还希望您在配置文件中有Bean属性，但是在Java注释中，两者之间存在某种区别，并巧妙地解决了这一问题。|1106435|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|M|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|N|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|O|8|@]|9|@]|A|$]]]|J|$]]

I have tried both the ways - File and a public static final class and both work. Some points to note though:

<ul>
<li>Declaring in a file would be specifically advantageous if your program needs to be tested/run by various parties who would like to change these constants. In this case, these would be called properties of App/program. Spring follows this approach for config.</li>
<li>Declaring them in a class would warrant re-building the App again and again but if these constant don't change or are not required to be accessed by multiple parties, you can very easily pick the static final class approach. Android declares constants dynamically generated in R.java file as an example. 
This approach retains control in your hand by the way. 3rs parties using your code would not be able to change these constants.
The file approach passes control into others' hands for varying them.</li>
</ul>

Object Mappers would also prefer you to have Bean properties in config files but in Java Annotation sort of lies in between the two and solves it elegantly.

blocks|key|2819258|text|问题的答案取决于你想要完成什么。但其中也有一个误解。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2819259|属性文件|offset|length|style|BOLD|2819260|属性文件并不意味着替代或替代常量。它们用于存储可配置的值，如ip、语言等。从文件加载常量不符合常量的目的。|2819261|常数|2819262|另一点是，public+static+final变量在java中不是一种很好的方法，首选的方法是使用枚举器。(来自有效Java，第30项:使用枚举而不是int+constatns)。enum将迫使您以有意义的方式对常量进行分组，而充满随机public常量的类很难管理。Enum使您能够提供功能，例如检查、验证、将常量与倍数对象关联起来，并且可以在switch语句中使用它。Enums也被编译，这使得它们更有效率，更有类型。这本书更详细地解释了enums的好处。|CODE|2819263|我认为最好的方法是考虑值是否会根据某些外部因素而变化，还是始终保持不变。|2819264|属性文件和对配置的全局访问|2819265|假设您的属性文件中有一个ip，并且您希望能够从代码中的任何地方访问这个值。您只需读取该值并将其加载到公共静态最终变量中即可。|2819266|如果这样做，如何控制该值被初始化，或者配置的值是正确的？在这种情况下，您可以使用单例类模式(只能存在类的一个实例)，它加载文件并检查值是否正确。|2819267|它可以将值存储在private+static+final变量中，并启用一个getter来执行所需的检查，以确保值是正确的。这使您可以全局访问变量，并在一个地方将逻辑分组。|2819268|下次在文件中添加值时，只需更新这个类，而不需要在代码中搜索它所在的位置以及检查是否正确。|2819269|Note|2819270|许多人说，没有真正的“最好的方式”做某事。我认为这是真的，但如果您能够访问Effetive+Java+(+Joshua+)这样的书籍，您应该阅读它们，并向已经编码了很长时间的人学习。|2819271|entityMap|0|LINK|mutability|MUTABLE|url|https://books.google.es/books?id=ka2VUBqHiWkC&pg=PA167&lpg=PA167&dq=Effective%2520java%2520page%2520153&source=bl&ots=yZLiLku6V_&sig=FR_SLUWOjvZigpzoKQvmtwhXnMI&hl=en&sa=X&ved=0ahUKEwiftNWl3cbTAhUqIMAKHbhMDdMQ6AEIKzAB#v=onepage&q&f=false^0|0|0|4|0|0|0|2|0|5|J|2J|4|3B|6|3Q|4|4T|6|56|5|65|5|1L|W|0|0|0|0|8|0|0|0|8|K|0|0|0|4|0|11|D|1H|7|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@$D|1E|E|1F|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1G|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1H|8|@$D|1I|E|1J|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1K|8|@$D|1L|E|1M|F|N]|$D|1N|E|1O|F|N]|$D|1P|E|1Q|F|N]|$D|1R|E|1S|F|N]|$D|1T|E|1U|F|N]|$D|1V|E|1W|F|N]|$D|1X|E|1Y|F|N]]|9|@$D|1Z|E|20|1|21]]|A|$]]|$1|O|3|P|5|6|7|22|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|23|8|@$D|24|E|25|F|G]]|9|@]|A|$]]|$1|S|3|T|5|6|7|26|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|27|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|28|8|@$D|29|E|2A|F|N]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|2B|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|2C|8|@$D|2D|E|2E|F|G]]|9|@]|A|$]]|$1|12|3|13|5|6|7|2F|8|@$D|2G|E|2H|F|G]|$D|2I|E|2J|F|G]]|9|@]|A|$]]|$1|14|3|-4|5|6|7|2K|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]]]

The answer to the question depends on what you want to accomplish. But there is also a misunderstanding in it.

Property files

Property files are not meant to be a substitute or an alternative to constants. They are used to store configurable values such as an ip, languages, etc. Loading constants from a file defeats the purpose of a constant.

Constants

The other point is that <code>public static final</code> variables are not a good approach in java, the preferred way is to use an enumerator.(From <a href="https://books.google.es/books?id=ka2VUBqHiWkC&amp;pg=PA167&amp;lpg=PA167&amp;dq=Effective%20java%20page%20153&amp;source=bl&amp;ots=yZLiLku6V_&amp;sig=FR_SLUWOjvZigpzoKQvmtwhXnMI&amp;hl=en&amp;sa=X&amp;ved=0ahUKEwiftNWl3cbTAhUqIMAKHbhMDdMQ6AEIKzAB#v=onepage&amp;q&amp;f=false" rel="nofollow noreferrer">Effective Java, Item 30: Use enums instead of int constatns</a>). An <code>enum</code> will force you to group the constants in a meaningful way, while a class full of random <code>public</code> constants is difficult to manage. An <code>Enum</code> enables you to provide functionalities, for example checks, validation, associate the constant with multiples objects and it can be used in <code>switch</code> statements. <code>Enums</code> are also compiled which makes them more efficient and typesafe. The book explains the benefits of <code>enums</code> in much greater detail.

I think the best approach is to consider whether the value will change depending on some external factor or if it will always remain the same. 

Property files and global access to the configuration

Imagine you have an ip in your property file and you want to be able to access this value from anywhere in your code. You could just read the value and load it in a public static final variable.

If you do this how are you going to control that the value is initialized, or the configured value is correct? Well in this cases you can use the singleton class pattern (Only one instance of the class can exist), that loads the file and checks that the values are correct. 

It can store the value in a <code>private static final</code> variable and enable a getter that can perform the needed checks to ensure that the value is correct. This gives you global access to the variables and groups the logic in a single place. 

Next time you add a value to the file you just need to update this class, and don't need to search in the code where it was and if the checks were correct.

Note

Many people are saying that there is not really a "best way" of doing something. I think it's true, but it's also true that if you have access to books like Effetive Java from Joshua Bloch, you should read them and learn from people that have been coding for a really long time.

blocks|key|2819349|text|还有第三种选择:系统属性。可以在用于启动程序的命令行中定义它们，还可以使用常量来轻松访问它们并提供默认值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2819350|示例：|2819351|public+static+final+String+HOSTNAME+=+System.getProperty("my.host-name",+"localhost");|code-block|syntax|javascript|2819352|不过，提供默认值并不总是一个好主意。|2819353|也就是说，您选择的方法将取决于问题的答案:是程序的值部分，还是安装程序的上下文的一部分。|2819354|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

There is a third option: system properties. They can be defined in the command line you use to launch you program, and you can also use a constant to ease access them and provide a default value.

Example:

<pre><code>public static final String HOSTNAME = System.getProperty("my.host-name", "localhost");
</code></pre>

It is not always a good idea to provide a default value though.

That been said, the method you choose will depend on the answer to the question: is the value part of the program, or is it part of the context in which the program is installed.

What should be best approach to declare constant value in my java program?

Is it the best approach to declare constant value in .properties file or declare that value as static final in nature in a different class?

Constants vs properties in java

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在我的java程序中声明常量值的最佳方法是什么？是在.properties文件中声明常量值还是在不同类中将该值声明为静态最终值的最佳方法？

问java中的常量与属性
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java中的常量与属性EN