Read a single int from an optional .properties file
up vote
3
down vote
favorite
I am no newcomer to Java. One thing that confounds me is why it is so messy to load values from .properties files.
I have an application where, if the .properties file is found, then the value if found, should be used. And in any other circumstance, to use the default. (In the correct deployment, the server is run with sufficient permissions to engage with the socket listener 443, whereas in the development environment or any other environment where a person goes to the trouble to insert the .properties file, another port will be used).
The location of the file is com/foo/bar/webserver.properties
in the in the same directory as the class file com/foo/bar/WebServer.class
.
The content of webserver.properties
is simply:
listen=4444
Since this such a terribly simple function I would like to know if the community of reviewers sees a more elegant/succinct/secure/complete/correct way to load the value. I feel like I must be overlooking something basic for what feels like, to me, should be a one-liner more like the imaginary API:
// set int value for key "listen", or else default value 443
int port = Properties.loadProperties( "webserver.properties" ).getInt( "listen", 443 );
And here is my real code for review:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
if ( webserverProperties == null ) {
port = 443;
} else {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
}
catch ( NumberFormatException e ) { port = 443; }
finally {}
java beginner configuration properties
|
show 3 more comments
up vote
3
down vote
favorite
I am no newcomer to Java. One thing that confounds me is why it is so messy to load values from .properties files.
I have an application where, if the .properties file is found, then the value if found, should be used. And in any other circumstance, to use the default. (In the correct deployment, the server is run with sufficient permissions to engage with the socket listener 443, whereas in the development environment or any other environment where a person goes to the trouble to insert the .properties file, another port will be used).
The location of the file is com/foo/bar/webserver.properties
in the in the same directory as the class file com/foo/bar/WebServer.class
.
The content of webserver.properties
is simply:
listen=4444
Since this such a terribly simple function I would like to know if the community of reviewers sees a more elegant/succinct/secure/complete/correct way to load the value. I feel like I must be overlooking something basic for what feels like, to me, should be a one-liner more like the imaginary API:
// set int value for key "listen", or else default value 443
int port = Properties.loadProperties( "webserver.properties" ).getInt( "listen", 443 );
And here is my real code for review:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
if ( webserverProperties == null ) {
port = 443;
} else {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
}
catch ( NumberFormatException e ) { port = 443; }
finally {}
java beginner configuration properties
Have you consider using xml de/serializing to load and save the properties?
– tinstaafl
Nov 26 at 15:39
2
Java'sProperties
class is old, and it shows. It's also designed specifically to work only withString
values. It sounds like it's not a great choice for the problem you've got. You might want to consider using a different abstraction or writing your own. It shouldn't be that hard to compose aProperties
instance into the fluent API you're describing as your ideal.
– Eric Stein
Nov 26 at 16:02
@tinstaafl, no I did not, because I am reading a single int value. I fail to see how that would simplify the operation, but I am happy to learn something from your answer.
– Douglas Held
Nov 26 at 16:47
I realize your code only loads one property value. However your title indicates you may want to load more than one. It seems to in that case de/serializing would be more efficient.
– tinstaafl
Nov 26 at 17:11
I think if I had many properties to read, I would write a Properties intermediary class with methods that would look very much like my code sample. And then, I think it would be appropriate. But, to only read a single int I think 12 lines of code is dubious.
– Douglas Held
Nov 26 at 17:18
|
show 3 more comments
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I am no newcomer to Java. One thing that confounds me is why it is so messy to load values from .properties files.
I have an application where, if the .properties file is found, then the value if found, should be used. And in any other circumstance, to use the default. (In the correct deployment, the server is run with sufficient permissions to engage with the socket listener 443, whereas in the development environment or any other environment where a person goes to the trouble to insert the .properties file, another port will be used).
The location of the file is com/foo/bar/webserver.properties
in the in the same directory as the class file com/foo/bar/WebServer.class
.
The content of webserver.properties
is simply:
listen=4444
Since this such a terribly simple function I would like to know if the community of reviewers sees a more elegant/succinct/secure/complete/correct way to load the value. I feel like I must be overlooking something basic for what feels like, to me, should be a one-liner more like the imaginary API:
// set int value for key "listen", or else default value 443
int port = Properties.loadProperties( "webserver.properties" ).getInt( "listen", 443 );
And here is my real code for review:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
if ( webserverProperties == null ) {
port = 443;
} else {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
}
catch ( NumberFormatException e ) { port = 443; }
finally {}
java beginner configuration properties
I am no newcomer to Java. One thing that confounds me is why it is so messy to load values from .properties files.
I have an application where, if the .properties file is found, then the value if found, should be used. And in any other circumstance, to use the default. (In the correct deployment, the server is run with sufficient permissions to engage with the socket listener 443, whereas in the development environment or any other environment where a person goes to the trouble to insert the .properties file, another port will be used).
The location of the file is com/foo/bar/webserver.properties
in the in the same directory as the class file com/foo/bar/WebServer.class
.
The content of webserver.properties
is simply:
listen=4444
Since this such a terribly simple function I would like to know if the community of reviewers sees a more elegant/succinct/secure/complete/correct way to load the value. I feel like I must be overlooking something basic for what feels like, to me, should be a one-liner more like the imaginary API:
// set int value for key "listen", or else default value 443
int port = Properties.loadProperties( "webserver.properties" ).getInt( "listen", 443 );
And here is my real code for review:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
if ( webserverProperties == null ) {
port = 443;
} else {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
}
catch ( NumberFormatException e ) { port = 443; }
finally {}
java beginner configuration properties
java beginner configuration properties
edited Nov 26 at 19:21
asked Nov 26 at 13:14
Douglas Held
1186
1186
Have you consider using xml de/serializing to load and save the properties?
– tinstaafl
Nov 26 at 15:39
2
Java'sProperties
class is old, and it shows. It's also designed specifically to work only withString
values. It sounds like it's not a great choice for the problem you've got. You might want to consider using a different abstraction or writing your own. It shouldn't be that hard to compose aProperties
instance into the fluent API you're describing as your ideal.
– Eric Stein
Nov 26 at 16:02
@tinstaafl, no I did not, because I am reading a single int value. I fail to see how that would simplify the operation, but I am happy to learn something from your answer.
– Douglas Held
Nov 26 at 16:47
I realize your code only loads one property value. However your title indicates you may want to load more than one. It seems to in that case de/serializing would be more efficient.
– tinstaafl
Nov 26 at 17:11
I think if I had many properties to read, I would write a Properties intermediary class with methods that would look very much like my code sample. And then, I think it would be appropriate. But, to only read a single int I think 12 lines of code is dubious.
– Douglas Held
Nov 26 at 17:18
|
show 3 more comments
Have you consider using xml de/serializing to load and save the properties?
– tinstaafl
Nov 26 at 15:39
2
Java'sProperties
class is old, and it shows. It's also designed specifically to work only withString
values. It sounds like it's not a great choice for the problem you've got. You might want to consider using a different abstraction or writing your own. It shouldn't be that hard to compose aProperties
instance into the fluent API you're describing as your ideal.
– Eric Stein
Nov 26 at 16:02
@tinstaafl, no I did not, because I am reading a single int value. I fail to see how that would simplify the operation, but I am happy to learn something from your answer.
– Douglas Held
Nov 26 at 16:47
I realize your code only loads one property value. However your title indicates you may want to load more than one. It seems to in that case de/serializing would be more efficient.
– tinstaafl
Nov 26 at 17:11
I think if I had many properties to read, I would write a Properties intermediary class with methods that would look very much like my code sample. And then, I think it would be appropriate. But, to only read a single int I think 12 lines of code is dubious.
– Douglas Held
Nov 26 at 17:18
Have you consider using xml de/serializing to load and save the properties?
– tinstaafl
Nov 26 at 15:39
Have you consider using xml de/serializing to load and save the properties?
– tinstaafl
Nov 26 at 15:39
2
2
Java's
Properties
class is old, and it shows. It's also designed specifically to work only with String
values. It sounds like it's not a great choice for the problem you've got. You might want to consider using a different abstraction or writing your own. It shouldn't be that hard to compose a Properties
instance into the fluent API you're describing as your ideal.– Eric Stein
Nov 26 at 16:02
Java's
Properties
class is old, and it shows. It's also designed specifically to work only with String
values. It sounds like it's not a great choice for the problem you've got. You might want to consider using a different abstraction or writing your own. It shouldn't be that hard to compose a Properties
instance into the fluent API you're describing as your ideal.– Eric Stein
Nov 26 at 16:02
@tinstaafl, no I did not, because I am reading a single int value. I fail to see how that would simplify the operation, but I am happy to learn something from your answer.
– Douglas Held
Nov 26 at 16:47
@tinstaafl, no I did not, because I am reading a single int value. I fail to see how that would simplify the operation, but I am happy to learn something from your answer.
– Douglas Held
Nov 26 at 16:47
I realize your code only loads one property value. However your title indicates you may want to load more than one. It seems to in that case de/serializing would be more efficient.
– tinstaafl
Nov 26 at 17:11
I realize your code only loads one property value. However your title indicates you may want to load more than one. It seems to in that case de/serializing would be more efficient.
– tinstaafl
Nov 26 at 17:11
I think if I had many properties to read, I would write a Properties intermediary class with methods that would look very much like my code sample. And then, I think it would be appropriate. But, to only read a single int I think 12 lines of code is dubious.
– Douglas Held
Nov 26 at 17:18
I think if I had many properties to read, I would write a Properties intermediary class with methods that would look very much like my code sample. And then, I think it would be appropriate. But, to only read a single int I think 12 lines of code is dubious.
– Douglas Held
Nov 26 at 17:18
|
show 3 more comments
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
you could at least get rid of the if
by combining the exceptions:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( NumberFormatException|NullPointerException e ) { port = 443; }
finally {}
or ignore exceptions at all:
int port= 443;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( Exception e ) {}
finally {}
Yes, I think the second option is good, and in fact in this case the empty finally{} block can also be omitted. Thank you.
– Douglas Held
Nov 28 at 14:02
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
you could at least get rid of the if
by combining the exceptions:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( NumberFormatException|NullPointerException e ) { port = 443; }
finally {}
or ignore exceptions at all:
int port= 443;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( Exception e ) {}
finally {}
Yes, I think the second option is good, and in fact in this case the empty finally{} block can also be omitted. Thank you.
– Douglas Held
Nov 28 at 14:02
add a comment |
up vote
1
down vote
accepted
you could at least get rid of the if
by combining the exceptions:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( NumberFormatException|NullPointerException e ) { port = 443; }
finally {}
or ignore exceptions at all:
int port= 443;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( Exception e ) {}
finally {}
Yes, I think the second option is good, and in fact in this case the empty finally{} block can also be omitted. Thank you.
– Douglas Held
Nov 28 at 14:02
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
you could at least get rid of the if
by combining the exceptions:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( NumberFormatException|NullPointerException e ) { port = 443; }
finally {}
or ignore exceptions at all:
int port= 443;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( Exception e ) {}
finally {}
you could at least get rid of the if
by combining the exceptions:
int port;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( NumberFormatException|NullPointerException e ) { port = 443; }
finally {}
or ignore exceptions at all:
int port= 443;
try ( InputStream webserverProperties = WebServer.class.getResourceAsStream( "webserver.properties" ) ) {
Properties p = new Properties();
p.load( webserverProperties );
String listen = p.getProperty( "listen", "443" );
port = Integer.parseInt( listen );
}
catch ( Exception e ) {}
finally {}
answered Nov 27 at 21:19
Timothy Truckle
4,748416
4,748416
Yes, I think the second option is good, and in fact in this case the empty finally{} block can also be omitted. Thank you.
– Douglas Held
Nov 28 at 14:02
add a comment |
Yes, I think the second option is good, and in fact in this case the empty finally{} block can also be omitted. Thank you.
– Douglas Held
Nov 28 at 14:02
Yes, I think the second option is good, and in fact in this case the empty finally{} block can also be omitted. Thank you.
– Douglas Held
Nov 28 at 14:02
Yes, I think the second option is good, and in fact in this case the empty finally{} block can also be omitted. Thank you.
– Douglas Held
Nov 28 at 14:02
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f208445%2fread-a-single-int-from-an-optional-properties-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Have you consider using xml de/serializing to load and save the properties?
– tinstaafl
Nov 26 at 15:39
2
Java's
Properties
class is old, and it shows. It's also designed specifically to work only withString
values. It sounds like it's not a great choice for the problem you've got. You might want to consider using a different abstraction or writing your own. It shouldn't be that hard to compose aProperties
instance into the fluent API you're describing as your ideal.– Eric Stein
Nov 26 at 16:02
@tinstaafl, no I did not, because I am reading a single int value. I fail to see how that would simplify the operation, but I am happy to learn something from your answer.
– Douglas Held
Nov 26 at 16:47
I realize your code only loads one property value. However your title indicates you may want to load more than one. It seems to in that case de/serializing would be more efficient.
– tinstaafl
Nov 26 at 17:11
I think if I had many properties to read, I would write a Properties intermediary class with methods that would look very much like my code sample. And then, I think it would be appropriate. But, to only read a single int I think 12 lines of code is dubious.
– Douglas Held
Nov 26 at 17:18