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 4 years ago.
Improve this question
How do I navigate to the informative messages about a deprecated class in Java documentation?
I have seen something like this in other answers:
From StringTokenizer documentation:
StringTokenizer is a legacy class that is retained for compatibility
reasons although its use is discouraged in new code. It is recommended
that anyone seeking this functionality use the split method of String
or the java.util.regex package instead.
But how do I get to this informative message in the Java docs? All I can see is a DEPRECATED link at the top. I need the extra information so I can understand the reason for it being deprecated and use its alternative.
There won't be any reliable way to do that. The text you have found is an informal advice about the class. This class is NOT formally deprecated. Deprecated means something very specific in the Java context. It is much stronger than "use is discouraged in new code".
If a class or class member is really deprecated in Java, you will see a #Deprecated annotation in the source code. This is what the Java tool chain pays attention to. There may also be a #deprecated javadoc tag with an explanation and suggestions for alternatives, where appropriate. That is what is turned into the "Deprecated:" heading in the javadocs.
Finding informal advice like the example you have identified would probably require searching the Java library codebase or the javadoc tree for key phrases like "legacy" and "not recommended". You would then need to manually filter out the false positives.
Most of the time, the reason a class was deprecated is because a better alternative was found or because it's simply no longer required.
As for the deprecated link at the top you mentioned, I assume you mean the following: https://docs.oracle.com/javase/8/docs/api/deprecated-list.html
Well, like you said, those are all the information you'll find, and they're pretty descriptive too.
Let's take the constructor Date(int year, int month, int day) for example, if you scroll down to the deprecated constructor section, you can find the following:
java.sql.Date(int, int, int)
instead use the constructor Date(long date)
and it does the same thing for every classes/methods/interfaces marked with the #Deprecated annotation in the JDK.
Also, for StringTokenizer, if you read just below the line you quoted, it says the following:
The following example illustrates how the String.split method can be
used to break up a string into its basic tokens:
String[] result = "this is a test".split("\\s");
for (int x=0; x<result.length; x++)
System.out.println(result[x]);
Basically, StringTokenizer is no longer necessary because the String object now has a split method, which makes StringTokenizer useless.
Related
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 7 years ago.
Improve this question
First off, I know not to use dollar signs in class names, because inner classes get dollar signs in their .class file names. I've also seen synthetic variable names like this$0, so I tend to avoid dollar signs in identifiers like any good Java programmer.
However, I find single-letter type parameters like <T> to be repugnant. If I'm making a generic class that has parameters for requests and responses, for instance, I have a naming problem. What should I use, <TRequest, TResponse>? <R1, R2>? Gross.
I've started doing <$Request, $Response>. It's readable, it's distinct, and I can't imagine any .class file naming conflicts. Seems to me like low-hanging fruit for making Java code more readable. Any JVM gurus or insightful devs want to tell me why this is a terrible idea?
Edit: As for readability, I may be drawn towards this by my use of other languages in which variables are prefixed with dollar signs, and generic types are types with a more variable nature than class types. As for convention, yes, I'm a fan; I want to know whether this would work as a convention, or if some technical issue would prevent it.
Convention, convention, convention.
Although you're free to do as you wish, the general convention can be found in the Java Trails.
The most commonly used type parameter names are:
E - Element (used extensively by the Java Collections Framework)
K - Key
N - Number
T - Type
V - Value
S,U ,V etc. - 2nd, 3rd, 4th types
You'll see these names used throughout the Java SE API...
Breaking these conventions should only be done when:
Following the above protocol would make the generic more confusing to use
The readability gains can be readily identified by other collaborators
Explicitly in the case of $, the JLS has a recommendation against using $ as a generic identifier.
The $ sign should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems.
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 7 years ago.
Improve this question
This post may be considered to be inappropriate for stackoverflow, although I'm not trying to insult the Java language or anything like that. I enjoy coding in Java, but there is something regarding System.out.println that I have been wondering for quite a while.
Why is it that we are always forced to type System.out.println() or System.out.print() every time we want to print? Sure, we could make a void function to save time and energy in programs that we will have several print statements (which I sometimes do) like so:
public static void print(String output) {
System.out.print(output);
}
and then just call print (and if you want to really be thorough you can overload the function with arguments involving ints, doubles, chars, etc). But why is it that the Java language itself doesn't already allow us to print to the console by just writing print? Some languages (such as Python) make printing to console that neat and simple - so why doesn't Java?
Again - I'm not saying that the Java language is poorly designed, or trying to start a thread that is intended to bash Java. I'm sure the language designers had their reasons for designing it the way they did, and it would help me to understand why it is so. It would be much easier to just need to type print instead of System.out.print, so there must be reasons for why we must type System.out.print - I just can't figure out those reasons. I've tried googling for information on this issue and can't find anything relevant to the issue.
Please refrain from opinionated responses about the Java language - I want actual facts that explain this phenomenon.
Simply, Java doesn't have global functions.
Also, according to The Java Language Environment (a '90s book co-authored by James Gosling):
Java has no functions. Object-oriented programming supersedes functional and procedural styles. Mixing the two styles just leads to confusion and dilutes the purity of an object-oriented language. Anything you can do with a function you can do just as well by defining a class and creating methods for that class.
It's not to say that functions and procedures are inherently wrong. But given classes and methods, we're now down to only one way to express a given task. By eliminating functions, your job as a programmer is immensely simplified: you work only with classes and their methods.
So there is at least one language designer's reasoning.
You may shorten the call by statically importing System.out:
import static System.out;
class Example {
public static void main(String[] args) {
out.println("hello world!");
}
}
Since System.out is an object, its instance methods cannot be statically imported.
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 8 years ago.
Improve this question
On a project that I am working on, we are debating when to use get (getFoo) vs a normal name (foo) in java. When I look around in java core and guava, I see that there are many examples where get is omitted. Is there any doc that covers when guava or new java APIs will use the get prefix and when not to? Is there a convention these developers use here?
Thanks for taking the time to read this.
Examples:
ByteBuffer : http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#compact()
ForwardingObject : http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/collect/ForwardingObject.html#delegate()
Stopwatch : http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Stopwatch.html#elapsed(java.util.concurrent.TimeUnit)
Ticker : http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Ticker.html#systemTicker()
EDIT:
As of http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf, "A Java Bean is a reusable software component that can be manipulated visually
in a builder tool." In our code base, the issue of get vs no get comes when the code has nothing to do with value or data objects (objects that represent data). When the class represents data, we are fine doing get.
My main question is why both java and guava choose to use non get methods for non data objects and what are their conventions.
The get prefix comes from the JavaBeans Conventions, which states that if you have an accessor for a property, then the accessor method's name must start with get, unless it is a boolean (the primative type), in which case is should start with is. Note that you use the get prefix to return type Boolean.
Throughout most of Java's API this is the convention that is used, which would be my recommendation as well. Your decision is up to you, but whichever convention you pick, I would suggest to be consistent and not mix the two.
While the idea of dropping the "get" appeals to me, the problem comes when you also have a setter. You would have to do something like
public String name(); // getter
and
public void name(String newName); // setter, xor use the below **instead** but not both
public Foo name(String newName); // if you prefer fluent/builder style
Which "looks weird" to a Java programmer. And until 1 minute ago I thought it was illegal, and my original post mistakenly said so until I tested it. You learn something everyday...
Added in response to #DwB
One good reason to use get/set is that many 3rd party frameworks expect this convention, as they use reflection to reason about your class. However, a framework could be able to look for combinations like the above, or be configured to use these methods instead of the usual get/set. This was almost in my original post but I haven't used Spring, Hibernate etc. in a few years so I'm not up to speed on what some of them will on won't allow if you aren't using get/set.
For example, Jackson can use annotations and mixins to define mappings, no need to follow get/set convention. I would think that Spring, JSF etc. could do likewise, (somebody please edit this answer with details as needed) though with some extra work. Whether this extra work is worth the "conciseness" of eliminating get/set is unclear. I'd say no, but YMMV.
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 8 years ago.
Improve this question
Is there a Java recommendation or industry best-practice suggestion for including, or not including, the this parameter when it isn't explicitly necessary?
For instance, assuming there are no naming clashes between instance variables and local variables, is it preferential to use
this.someParam
or simply
someParam
and when calling methods that are in the same class is it preferential to use
this.someMethod()
or
someMethod()
The argument in favor of the former is that it makes the code more explicit. The argument in favor of the latter is that it makes the code cleaner.
I'm curious if there is any documentation out there that recommends one way or another (I can't find any, google searches with the word this are obviously tricky) or if it is simply a matter of preference.
On the merits of explicit versus cleaner: Excluding "this." is no doubt less text character "noise" (albeit small) in source file. The "this." explicitness would be helpful for example if using a small text viewer when looking at a method with many lines of code (should that be the case anyway?). So at best the explicitness has limited usefulness - especially as modern IDEs highlight instance variables. I am of the opinion of excluding "this." as code style.
I don't know that there is a "wrong" answer here. However, in my 15+ years writing Java, the convention that I have seen is to NOT include "this" unless it is necessary.
You can minimize confusion by naming variables in a consistent way. There are several good convention documents out there. Pick one and follow it. Some examples:
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
https://source.android.com/source/code-style.html
http://www.javaranch.com/style.jsp
There is no reason to prefer one or the other. It's a matter of opinion.
My opinion is that you should only use this if needed. There are some situations when you have to use this, such as if a local variable has the same name as an instance variable. It happens a lot in my constructors:
public MyClass(String s, int i) {
this.s = s;
this.i = i;
}
If you are working on a team, I recommend coming up with a strategy you all agree with, so you don't waste too much time reformatting each others code. Also, for me, it's pretty annoying to look at code that uses this too much (such as that generated by JD).
As for:
parameters/attributes - I always suggest using consistent approach throughout the code. In most cases all automatically generated getters and setters of Java classes need to use this to distinguish parameter name from actual object attribute. Consistency is then a good reason to use this for instance variables throughout the code. Sample setter which uses this to avoid ambiguity:
public void setName(String name) {
this.name = name;
}
methods - this.someMethod() is just longer than someMethod() and does not provide any benefit over the shorter someMethod(). If we call the latter, it is already known that we are in fact calling this.someMethod(). There is no ambiguity in calling just someMethod() like it is for parameters, so I would discourage the use of this.someMethod().
In my opinion, there is no common guidelines for all Java developers in the world defining good practices for using this. I'd rather follow the guidelines used in your company/project, or, if there are none, your own ways of writing well-read code.
There isn't a best-practice suggestion. Most teams simply have their own coding style.
Personally, I try to use use this for all my instance variables, but tend to avoid it for methods.
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'll be honest. I need help with a homework question that I'm stumped with.
Describe something that historically started as a pattern and is now supported with
a language feature in Java.
They're probably looking for enums.
Before Java 1.5 introduced language support for enums, standard practice was to define a set of public static final ints as enum values.
This pattern can be seen all over Swing.
Many of these constants are defined in interfaces so that classes can implement the interface and use the constants without a qualifying typename; the SwingConstants interface is a great example.
The most obvious pattern I can think of around that is iterating via Iterable<T> and Iterator<T>, which is now available as a feature via the enhanced for-each loop.
From http://en.wikipedia.org/wiki/Java_version_history: Enumerations (typesafe enum pattern)
More on this pattern in item 21 in Chapter 5 of 'Effective Java' (found here: http://java.sun.com/developer/Books/effectivejava/Chapter5.pdf)
Annotations are all about metadata that used to stored in a variety of xml files or in javadoc comments now you can use annotations to store metadata with the code.
Dependency injection is another pattern that while not part of the java language is making its way into the core jdk frameworks.
Iterators. They have a special for loop which is translated into hasNext() and next() calls.
I would suggest Generics. That was not part of Java from the beginning but was implemented from 1.5 and above.
enums.........................
Observer/Observable which is the "Observer[GOF]" pattern from the gang of four... : http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/book/hires/pat5gfso.htm
Comparator<T> which is the "Strategy[GOF]" pattern also from the gang of four : http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/book/hires/pat5ifso.htm
And many more !
Performance.
(Oops. I am sorry. Always thought C++ templates have something to do with the pattern. I was wrong)
<<<<< Ignore the following lines >>>>>
Not sure if I am right but let me take a shot.
Java Generics are roughly based on Template pattern
http://blogs.msdn.com/b/csharpfaq/archive/2004/03/12/88913.aspx
(Link is on C# generics though)
There haven't been many language features added which appear in the JLS.
Perhaps you could argue that the #Override supports the pattern of overriding/implementing methods by detecting when a method was inteded to override a parent's method/implement an interface method but does not.
http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html search for #Override
I noticed no one mentioned Prototype (clone) and Momento (Serializable).