We Keep Coding

Converting a public method into a private method

I recently refactored some code which converted a public method that was only being used in conjure with another public method, into one call.
public class service() {
public String getAuthenticatedUserName() {
return SecurityContext.getName();
}
public getIdentityUserIdByUsername(String username) {
return db.getUser(username).getId();
}
}
which was being utilised in a few other classes as service.getIdentityUserIdByUsername(service.getUsername()), which seemed redudant. A new method was created combining the two calls.
public getIdentityUserId() {
return getIdentityUserIdByUsername(getUsername());
}
The getIdentityUserIdByUsername() is still being utilised in other classes without the need for getUsername(). However, the getUserName() method is no longer used in other classes.
My example is much simpler than the implementation, the method has test coverage that is a bit awkward to do (mocking static classes without Powermock and a bit of googling etc). In the future it's likely we will need the getUsername() method, and the method will not change.
It was suggested in code review that the getUsername() method should now be private due to it not being called anywhere else. This would require the explicit tests for the method be removed/commented out which seems like it would be repeated effort to rewrite or ugly to leave commented out code.
Is it best practice to change the method to private or leave it public because it has explicit coverage and you might need it in the future?

Is it best practice to change the method to private or leave it public because it has explicit coverage and you might need it in the future?
IMO, you are asking the wrong question. So called "best practice" doesn't come into it. (Read the references below!)
The real question is which of the alternatives is / are most likely to be best for you. That is really for you to decide. Not us.
The alternatives are:
You could remove the test case for the private method.
You could comment out the test case.
You could fix the test case so that it runs with the private version of the method.
You could leave the method as public.
To make a rational decision, you need to consider the technical and non-technical pros and cons of each alternative ... in the context of your project. But don't be too concerned about making the wrong decision. In the big picture, it is highly unlikely that making the wrong choice will have serious consequences.
Finally, I would advise to avoid dismissing options just because they are "code smell". That phrase has the same issue as "best practice". It causes you to dismiss valid options based on generalizations ... and current opinions (even fashions) on what is good or bad "practice".
Since you want someone else's opinion ("best practice" is just opinion!), mine is that all of the alternatives are valid. But my vote would be to leave the method as public. It is the least amount of work, and an unused method in an API does little harm. And as you say, there is a reasonable expectation that the method will be used in the future.
You don't need to agree with your code reviewer. (But this is not worth making enemies over ...)
References:
No Best Practices by James Bach
There is no such thing as "Best Practices": Context Matters. by Ted Neward.

It can make sense to want to test private methods. The industry standard way to do this, which has quite some advantages, is this:
Ensure that the test code lives in the same package as the code it tries to test. That doesn't mean same directory; for example, have src/main/java/pkg/MyClass.java and src/test/java/pkg/MyClassTest.java.
Make your private methods package private instead. Annotate them with #VisibleForTesting (from guava) if you want some record of this.
Separately from this, the entry space for public methods (public in the sense of: This is part of my API and defines the access points where external code calls my code) is normally some list of entrypoints.. if you have it at all. More often there is no such definition at all. One could say that all public methods in all public types implicitly form the list (i.e. that the keyword public implies that it is for consumption by external code), which then by tautology decrees that any public method has the proper signature. Not a very useful definition. In practice, the keyword public does not have to mean 'this is API accessible'. Various module systems (such as jigsaw or OSGi) have solutions for this, generally by letting you declare certain packages as actually public.
With such tooling, 'treeshaking' your public methods to point out that they need no longer be public makes sense. Without them... you can't really do this. There is such a notion as 'this method is never called in my codebase, but it is made available to external callers; callers that I don't have available here, and the point is that this is released, and there are perhaps projects that haven't even started being written yet which are intended to call this'.
Assuming you do have the tree-shaking concept going, you can still leave them in for that 'okay maybe not today but tomorrow perhaps' angle. If that applies, leave it in. If you can't imagine any use case where external code needs access to it, just delete it. If it really needs to be recovered, hey, there's always the history in version control.

If the method is a public static then you can leave it as is because there is no impact of it being public. It is aside effect free method, it being exposed will never cause any harm.
If it is a object level public method then -
1) Keep it if it is like an API. It has well defined input, output and delivers a well defined functionality and has tests associated with it. It being public doesn't harm anything.
2) Make it private immediately if it has side effects. If it causes others methods to behave differently because it changes the state of the object then it is harmful being public.

Why can we call .orElse() on Optional.of()?

I'm curious why is it possible to do this (at least on Java 8):
Optional.of(null).orElse("something");
Optional.of(null) is basically a guaranteed null pointer. Making possible to invoke .orElse() on it gives a clumsy developer unexpected holes to fall into. I've been looking around to see if there's any justification to this. Maybe there's some scenario that this is supposed to address?

You can do this for the same reason you can write ((String) null).length(). The Java compiler has a static checker for certain things like type-safety, but does not check for or reject code which provably throws a NullPointerException. If it did, the code throw new NullPointerException(); would not be allowed either.
It's not generally the case that code which throws an exception is a mistake. While a static checker could detect this kind of thing and warn about it, it would be bad if this was an error. Some IDEs will generate their own warnings about probable-mistakes, but you have to decide what is or isn't worth checking for.
Detecting this probable-mistake requires a static checker designed with knowledge of the behaviour of the Optional.of method. The authors of the Java Language Specification have made the decision to warn for things like unsafe casts, but not for anything which depends on the semantics of the methods being used. One advantage of this decision is that it means the JLS can be maintained separately from the Java Class Library documentation.

There are languages where there is support for null checking right into the compiler (or even better languages that don't have such a "thing" at all) - this is burned into the compiler.
javac is not a such compiler and the be frank - I don't want it to become like this either. There are languages where there is syntax like ! or ? or !? - when I read this code it either screams on me or asks me something (this is my opinion).
Now, recall that Optional is designed for return types, so inside your method body you use an Optional chain of methods. If you really want to check if something is null or not there is Objects::requireNonNull - use that; if you are unsure if something is null or not, you could use Optional::ofNullable.
I know and read the arguments for Optional::of and Optional::ofNullable, I still don't like it, I wish it could be just the latter. But hey, people don't have to agree all the time: we do have Optional::isEmpty and Optional::isPresent. Is that a good decision? I don't know.
Like any other method call, you can pass null to any object reference, Optional is no different. Could they add semantics for the javac to support only Optional::of and null checking? Probably. How many people would request such a support for and this feature please?

Optional.of(null).orElse();
Obviously the above code will always cause an exception. But what about:
Optional.of(someMethod()).orElse();
with
Object someMethod() { return null; }
You probably think: sure, same thing.
Well, actually that is wrong. What if a subclass overrides someMethod() to return a value other than null?! Thus you can't decide at compile time whether that method will always return null at runtime.
Long story short: there are plenty of obvious, and also less obvious situations where the compiler could apply all kinds of techniques, like data flow analysis to determine whether code will result in a runtime exception or not. But there are also many others where that isn't possible.
The point here: it is up to the people defining the language to determine what they expect compilers to care about.
The java people opted for a simple compiler. One that compiles fast, and that isn't overly complicated to implement. Why? Because the compiler simply avoid overly complicated checking.

Should you return a passed parameter just to signal mutability in Java

I am sure this is more of a subjective question however I am curious people's oppinions...
Today at work I saw the following method....
public T execute(T dto){...return dto;}
This seemed redundant to me, in my mind this was better....
public void execute(T dto)
For now in this method lets say the following is called....
dto.setProperty(something);
But a colleague (and a few StackOverflow posts) suggest this is bad because it doesn't suggest that the method may be altering the T object. However this should be reflected on the object in the stack so why do I need a return.
Is this a valid reason, to me it seems to me this has to cause increases in overhead (although in all fairness we are using Java here)
Any insight as to which is better?

This depends on what T is, whether T is immutable, and what execute does. This question couldn't really be more generic and specifics matter.
void addPerson(Club clubFullOfPeople, Person person);
T clone(T t);
would both be valid and strike me as good design.
To answer your exact question - should you return to signal mutability? That absolutely strikes me as something that would signal IM-mutability if anything so, no, absolutely not, but you need clearer variable names, documentation etc. to communicate this.

It's not an unreasonable style, it's simply a decision that should be made (project by project) - go with the style used in the working environment. Next project/job may choose differently.

Neither style implies that the DTO can or cannot be altered. In fact, if anything, the first form would rather suggested that the parameterized DTO is not being altered, but if there are changes that are being made, they will be made in the returned object.
Advantages of returning the DTO:
Calls can be chained (this may be good or bad depending on the coding style and the use of the actual methods/objects). For example jQuery is built such that just about every call can be chained.
You can return a null value or some other object/form of the DTO to signify a failure of some sorts
In your "preferred" notation, the only way you can signify a failure is via Runtime Exceptions. Without know what the execute method is supposed to accomplish, this may be okay, or may indicate a larger problem in that Exceptions are being used to handle flow control (a bad thing).
Net result? I don't think there is a "better" solution - just something that matches more what you are currently doing in your existing codebase.

Explicit typing in Groovy: sometimes or never?

[Later: Still can't figure out if Groovy has static typing (seems that it does not) or if the bytecode generated using explicit typing is different (seems that it is). Anyway, on to the question]
One of the main differences between Groovy and other dynamic languages -- or at least Ruby -- is that you can statically explicitly type variables when you want to.
That said, when should you use static typing in Groovy? Here are some possible answers I can think of:
Only when there's a performance problem. Statically typed variables are faster in Groovy. (or are they? some questions about this link)
On public interfaces (methods, fields) for classes, so you get autocomplete. Is this possible/true/totally wrong?
Never, it just clutters up code and defeats the purpose of using Groovy.
Yes when your classes will be inherited or used
I'm not just interested in what YOU do but more importantly what you've seen around in projects coded in Groovy. What's the norm?
Note: If this question is somehow wrong or misses some categories of static-dynamic, let me know and I'll fix it.

In my experience, there is no norm. Some use types a lot, some never use them. Personally, I always try to use types in my method signatures (for params and return values). For example I always write a method like this
Boolean doLogin(User user) {
// implementation omitted
}
Even though I could write it like this
def doLogin(user) {
// implementation omitted
}
I do this for these reasons:
Documentation: other developers (and myself) know what types will be provided and returned by the method without reading the implementation
Type Safety: although there is no compile-time checking in Groovy, if I call the statically typed version of doLogin with a non-User parameter it will fail immediately, so the problem is likely to be easy to fix. If I call the dynamically typed version, it will fail some time after the method is invoked, and the cause of the failure may not be immediately obvious.
Code Completion: this is particularly useful when using a good IDE (i.e. IntelliJ) as it can even provide completion for dynamically added methods such as domain class' dynamic finders
I also use types quite a bit within the implementation of my methods for the same reasons. In fact the only times I don't use types are:
I really want to support a wide range of types. For example, a method that converts a string to a number could also covert a collection or array of strings to numbers
Laziness! If the scope of a variable is very short, I already know which methods I want to call, and I don't already have the class imported, then declaring the type seems like more trouble than it's worth.
BTW, I wouldn't put too much faith in that blog post you've linked to claiming that typed Groovy is much faster than untyped Groovy. I've never heard that before, and I didn't find the evidence very convincing.

I worked on a several Groovy projects and we stuck to such conventions:
All types in public methods must be specified.
public int getAgeOfUser(String userName){
...
}
All private variables are declared using the def keyword.
These conventions allow you to achieve many things.
First of all, if you use joint compilation your java code will be able to interact with your groovy code easily. Secondly, such explicit declarations make code in large projects more readable and sustainable. And of-course auto-completion is an important benefit too.
On the other hand, the scope of a method is usually quite small that you don't need to declare types explicitly. By the way, modern IDEs can auto-complete your local variables even if you use defs.

I have seen type information used primarily in service classes for public methods. Depending on how complex the parameter list is, even here I usually see just the return type typed. For example:
class WorkflowService {
....
WorkItem getWorkItem(processNbr) throws WorkflowException {
...
...
}
}
I think this is useful because it explicitly tells the user of the service what type they will be dealing with and does help with code assist in IDE's.

Groovy does not support static typing. See it for yourself:
public Foo func(Bar bar) {
return bar
}
println("no static typing")
Save and compile that file and run it.

Assert a good practice or not?

Is it a good practice to use Assert for function parameters to enforce their validity. I was going through the source code of Spring Framework and I noticed that they use Assert.notNull a lot. Here's an example
public static ParsedSql parseSqlStatement(String sql) {
Assert.notNull(sql, "SQL must not be null");
}
Here's Another one:
public NamedParameterJdbcTemplate(DataSource dataSource) {
Assert.notNull(dataSource,
"The [dataSource] argument cannot be null.");
this.classicJdbcTemplate = new JdbcTemplate(dataSource);
}
public NamedParameterJdbcTemplate(JdbcOperations classicJdbcTemplate) {
Assert.notNull(classicJdbcTemplate,
"JdbcTemplate must not be null");
this.classicJdbcTemplate = classicJdbcTemplate;
}
FYI, The Assert.notNull (not the assert statement) is defined in a util class as follows:
public abstract class Assert {
public static void notNull(Object object, String message) {
if (object == null) {
throw new IllegalArgumentException (message);
}
}
}

In principle, assertions are not that different from many other run-time checkings.
For example, Java bound-checks all array accesses at run-time. Does this make things a bit slower? Yes. Is it beneficial? Absolutely! As soon as out-of-bound violation occurs, an exception is thrown and the programmer is alerted to any possible bug! The behavior in other systems where array accesses are not bound-checked are A LOT MORE UNPREDICTABLE! (often with disastrous consequences!).
Assertions, whether you use library or language support, is similar in spirit. There are performance costs, but it's absolutely worth it. In fact, assertions are even more valuable because it's explicit, and it communicates higher-level concepts.
Used properly, the performance cost can be minimized and the value, both for the client (who will catch contract violations sooner rather than later) and the developers (because the contract is self-enforcing and self-documenting), is maximized.
Another way to look at it is to think of assertions as "active comments". There's no arguing that comments are useful, but they're PASSIVE; computationally they do nothing. By formulating some concepts as assertions instead of comments, they become ACTIVE. They actually must hold at run time; violations will be caught.
See also: the benefits of programming with assertions

Those asserts are library-supplied and are not the same as the built-in assert keyword.
There's a difference here: asserts do not run by default (they must be enabled with the -ea parameter), while the assertions provided by the Assert class cannot be disabled.
In my opinion (for what it's worth), this is as good a method as any for validating parameters. If you had used built-in assertions as the question title implies, I would have argued against it on the basis that necessary checks should not be removable. But this way is just shorthand for:
public static ParsedSql parseSqlStatement(String sql) {
if (sql == null)
throw new IllegalArgumentException("SQL must not be null");
...
}
... which is always good practice to do in public methods.
The built-in style of asserts is more useful for situations where a condition should always be true, or for private methods. The language guide introducing assertions has some good guidelines which are basically what I've just described.

Yes it is good practice.
In the Spring case, it is particularly important because the checks are validating property settings, etc that are typically coming from XML wiring files. In other words, they are validating the webapp's configuration. And if you ever do any serious Spring-based development, those validation checks will save you hours of debugging when you make a silly configuration mistake.
But note that there is a BIG difference between a library class called Assert and the Java assert keyword which is used to define a Java assertion. The latter form of assertions can be turned off at application launch time, and should NOT be used for argument validation checks that you always want to happen. Clearly, the Spring designers think it would be a really bad idea to turn off webapp configuration sanity checks ... and I agree.
UPDATE
In Java 7 (and later) the java.util.Objects class provides a requireNonNull convenience method to test if an argument is null and raise an exception. You use it like this:
SomeType t = ...
SomeType tChecked = Objects.requireNonNull(t);
or
SomeType tChecked = Objects.requireNonNull(t, "t should be non-null");
However, note that this method raises NullPointerException rather than IllegalArgumentException.

Based on Sun's guide on assertions, you should not use assertions for argument checking in public methods.
Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled.

In very large and poorly designed/maintained systems, if you're looking to improve predictability in methods that are, say, 6000 lines long and nobody in the company understands them anymore, it can be valuable to use the assert keyword to cause development environments to blow up, revealing bugs. But were you to implement those assertions in production, you might shortcircuit a patch that, though horribly conceived, fixed a problem. You want to fix that bad patch by discovering it in the dev environment, not production. So you would turn asserts on at development time, and turn them off in production.
Another valid use of the assert keyword at development time is to insert validity checks into algorithms that must execute in sub-millisecond times and are well enough insulated from unpredictable or untested callers. You may not be able to afford to preserve the validity check in production in such a case, though it's still very useful in development. On the other hand, if the source of the parameters you're validating is unpredictable or could become so (if it's determined partly by user input, for example), you can probably never afford to skip the check, even in production, and should take the performance hit as a cost of doing business. (In this last case, you probably wouldn't want to use an assert.) But you should opt for asserts to eliminate a production-time validity check only after profiling tells you you simply can't afford the overhead.

Yes it's a good idea. You're enforcing the contracting of the interface or class. If there is a contract violation you want to detect it as soon as possible. The longer you wait the more unpredictable the results can be and the harder it can be to diagnose.
When you explicitly check like this you should also provide an information message that when viewed in a log file can give useful context to help find the root cause or even just to realize you've made a wrong assumption about what the contract is.

I'm keeping my assertions in released binaries but with modified behavior: abort is not called but stacktrace is collected.
More details here: http://blog.aplikacja.info/2011/10/assert-to-abort-or-not-to-abort-thats-the-question/