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 {}









share|improve this question
























  • 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 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










  • 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

















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 {}









share|improve this question
























  • 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 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










  • 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















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 {}









share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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'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










  • 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






  • 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










  • @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












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 {}





share|improve this answer





















  • 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











Your Answer





StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















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

























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 {}





share|improve this answer





















  • 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















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 {}





share|improve this answer





















  • 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













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 {}





share|improve this answer












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 {}






share|improve this answer












share|improve this answer



share|improve this answer










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


















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Сан-Квентин

Алькесар

Josef Freinademetz