Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I was going through the internal implementation of System.out.println().Though I understood how this is working but couldn't figure out :
Why they decided to use the System class in the first place.
They could have directly used PrintStream class which is present in the io package.
What is the significance of the syntax className.referenceVariable.Methodname, since we generally don't use this. Is there any specific reason for this.
Can anybody elaborate on these points or any related information would be great.
According to my understanding, System class name was to indicate any interactions with System on which JVM is running. To perform Read or Write operations on the System Console, or reading environment variables in the System etc.
You can always use PrintStream directly as well there is no harm. But then you have to create a PrintStream object every time in your class and call methods inside use it. Instead its already created statically in System class for us to use it readily.
As for your 3rd query, Eran already answered it in the comments.
The System class states that:
Among the facilities provided by the System class are standard input, standard output, and error output streams; access to externally defined properties and environment variables; a means of loading files and libraries; and a utility method for quickly copying a portion of an array.
Since you were checking the source code of System class, you might've noticed that out object is final and is set to null. It's the setOut() method which assigns a value to the out variable (it's a native code).
I know, how can JVM set value to a final variable after it's been set to null, right? Being a JVM has its own advantages!
Before a value gets assigned to out object, a separate method called checkIO is also triggered, which checks for IO permission.
So System class was designed as a collection of standard input, output, and error streams. It also instructs JVM to initialise the objects, like the out object.
Regarding the syntax of System.out.println(), Eran has already explained it.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am used to programming in static languages like Java, where changing the signature of a method will cause a compilation error for every line of code that calls the method I changed. This makes modifying large projects much more easy, because I can make a change, and then let the compiler tell me about all the places that I need to fix.
When dealing with a large project in a dynamic language like Python or Ruby, how do you make code changes, and still remain confident that you are not going to be surprised with a run-time error in production because of some scenario you forgot about?
I've seen my fair share of NullPointerExceptions and ArrayIndexOutOfBoundsExceptions in Java, so it's not like these things never happen in a static language, I would just think they happen a lot less.
Here are some ideas for providing some level of the protection that you are used to in Java:
As stated in a previous comment, you should definitely provide adequate unit and integration testing to prevent any issues during a refactor. Testing is even more important in a dynamic language than in a statically-typed language. You should check that values are properly passed and handled in each of your functions.
Use PyCharm and search for usages on a method prior to making the update. This is not full-proof, but does find a good amount of method usage to allow for an easier refactor.
Do a global find for the method name in your editor or search program of choice.
Provide exception handling in your functions for cases where the type is incorrect or a value is unset.
Handle args and kwargs passed into your function carefully. Perhaps provide an error or debug log if you receive an unexpected input.
Provide default values for undefined parameters to a function.
Here is an example of providing a default value for a parameter to ensure that it is defined and initialized to None (similar to null) in the function if it is not passed in with a value:
def my_function(my_parameter=None):
# Do something with my_parameter
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have a Utils class that loads a large list of Strings (a static variable) and defines a function that uses this list.
I use this function in another class Solution. Currently, I am calling Utils.my_function every time I use it (in a big for loop, so it is called thousands times). Would it be faster if I instantiate a Utils in Solution? (would the list of words defined in Utils be defined only one time?)
a large list of Strings (a static variable)
...
would the list of words defined in Utils be defined only one time?
By definition, a static variable is loaded only once. So it's already the fastest you can do.
EDIT : the devs who code Java are smart. It's very likely that the JVM can detect your array is accessed very often, and will optimise its operations, whether it is a static or instance variable. However I cannot give you more information than this, and maybe some Java experts can give you a more accurate answer.
Well, as already pointed out that static is only called once anyway. Another thing you can do is batch processing -- http://java.dzone.com/articles/batch-processing-best
Instead of looping by each line -- call a set of lines at a time then perform your functions, then move to the next set, etc. You would need to profile your app to see how many lines would yield a good response for the app.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am currently working on an uni assignment. We have to write Javadoc comments. My problem is that I don't really know to whom I'm "talking" here.
Some examples for comments to different methods in my project:
"The next thing we care about is the number of..."
"We want to remove those items from the list because..."
So the questions is: can i put Javadocs like that or do I have to write them in formal language? And who do I adress in my sentences (if I can adress someone).
It's entirely up to you / your team how formal or informal to make your Javadoc.
It's relatively rare to directly address anyone (either with "you" or "we"), but again, it's your call. Consider the JDK's docs, which typically go something like this:
The String class represents character strings. All string literals in Java programs, such as "abc", are implemented as instances of this class.
Direct, clear, and impersonal. Just state the facts.
Another example (from Object#equals):
Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.
Notice how it didn't say "Note that you must generally override..." It doesn't tell anyone what to do, just notes that if doing X, generally it's necessary to do Y.
Javadocs matter most if you're publishing to third parties. You won't be present to expound on your code. Third parties will want to just use your classes wo/ worrying about how they fulfill their contract. Your documentation should tell them what they need to know: what the terms of the contract is. They need to know what to provide, what to expect back, exceptions, invariants, etc.
I would say keep the language formal in that case. It reflects better on you.
You don't communicate with third parties the same way you do your friends. Better to keep it formal.
I would stop using "we" and think more in terms of "you". It's about the consumer of your library, not the developers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm writing classes work like FilterInputStream or FilterOutputStream.
Looks like
public FilterReadableByteChannel implements ReadableByteChannel {
// Should I permit null for channel?
public FilterReadableByteChannel(final ReadableByteChannel channel) {
// ...
}
}
And I found that both FilterInputStream and FilterOutputStream permit null source.
* #param in the underlying input stream, or <code>null</code> if
* this instance is to be created without an underlying stream.
Question:
Is there any practical reason for this?
Is there any possible case that changing the underlying source after created?
I know that Why Not? could be an answer, but I want to know if there were any reason why the original API designer did this.
Is there any practical reason for this?
Yes. Even if not declared as such, classes Filter*Stream are conceptually abstract classes. IOW, they only exist to be extended. Subclasses could need to provide the in or out parameters after construction (example: lazily; on first real use), and Filter*Stream gives them this flexibility.
Is there any possible case that changing the underlying source after created?
The obvious case is when source is initially null. Other cases that come to my mind are:
1. Creating a subclass of Filter*Stream that acts as a selector. IOW, has several underlying streams and methods to switch from one to the other.
2. Creating a subclass of FilterInputStream that concatenates different InputStreams.
3. Creating a subclass of FilterOutputStream that splits output into different OutputStreams.
I know that Why Not? could be an answer, but I want to know if there were any reason why the original API designer did this.
Yes: generality.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
i have been reading about this topic , and the more i read the more confused i get ,
can somebody please elaborate , we were using language C which follows structural approach ,
so what was wrong with this approach , that we moved to create a object oriented language JAVA .
I have been reading so many theoretical aspects , can some body please give more of a few practical illustrations ,
WHY WE NEEDED OBJECT ORIENTED APPROACH IN THE FIRST PLACE
I am not looking for an answer to be given in any interview or tutorial
I am looking for an answer to get the better understanding/practical importance of object oriented aproach
There are many explanations regarding this. But I would like to refer this
Modularity: The source code for a class can be written and maintained independently of the source code for other classes. Once
created, an object can be easily passed around inside the system.
Information-hiding: By interacting only with an object's methods, the details of its internal implementation remain hidden from
the outside world.
Code re-use: If a class already exists, you can use objects from that class in your program. This allows programmers to
implement/test/debug complex, task-specific objects, which you can
then use in your own code.
Easy Debugging: If a particular object turns out to be a problem, you can simply remove it from your application and plug in a
different object as its replacement. This is analogous to fixing
mechanical problems in the real world. If a bolt breaks, you replace
it, not the entire machine.