Develop Reference

Can we combine two methods that differ largely based on type?

I have two similar, but of different types, blocks of code in Java:
private Integer readInteger() {
Integer value = null;
while (value == null) {
if (scanner.hasNextInt()) {
value = scanner.nextInt();
} else {
scanner.next();
}
}
return value;
}
private Double readDouble() {
Double value = null;
while (value == null) {
if (scanner.hasNextDouble()) {
value = scanner.nextDouble();
} else {
scanner.next();
}
}
return value;
}
Is it possible to make just one method which would work for both of them?

I'd say, use a generic method, combined with the functional interfaces introduced in Java 8.
The method read now becomes a higher order function.
private <T> T read(Predicate<Scanner> hasVal, Function<Scanner, T> nextVal) {
T value = null;
while (value == null) {
if (hasVal.test(scanner)) {
value = nextVal.apply(scanner);
} else {
scanner.next();
}
}
return value;
}
Calling code becomes:
read(Scanner::hasNextInt, Scanner::nextInt);
read(Scanner::hasNextDouble, Scanner::nextDouble);
read(Scanner::hasNextFloat, Scanner::nextFloat);
// ...
So the readInteger() method can be adapted as follows:
private Integer readInteger() {
return read(Scanner::hasNextInt, Scanner::nextInt);
}

You could have something with three methods:
One which says if there is a value of the right type
Another which gets the value of the right type.
Another which discards whatever token you have.
For example:
interface Frobnitz<T> {
boolean has();
T get();
void discard();
}
You can pass this into your method:
private <T> T read(Frobnitz<? extends T> frob) {
T value = null;
while (value == null) {
if (frob.has()) {
value = frob.get();
} else {
frob.discard();
}
}
return value;
}
And then just implement Frobnitz for your Double and Integer cases.
To be honest, I'm not sure this gets you very much, especially if you've only got two cases; I'd be inclined just to suck up the small amount of duplication.

A lot of people have answered that you can use generics, but you can also simply remove the readInteger method, and only use the readDouble, as integers can be converted to doubles without data loss.

This is about code duplication.
The general approach is to turn similar code (you have) into equal code that can be extracted to a common parameterized method.
In your case what make the two code snipped differ is the access to methods of Scanner. You have to encapsulate them somehow. I'd suggest to do this with Java8 Functional interfaces like this:
#FunctionalInterface
interface ScannerNext{
boolean hasNext(Scanner scanner);
}
#FunctionalInterface
interface ScannerValue{
Number getNext(Scanner scanner);
}
Then replace the actual invocation of methods in scanner with the functional interface:
private Integer readInteger() {
ScannerNext scannerNext = (sc)->sc.hasNextInt();
ScannerValue scannerValue = (sc)-> sc.nextInt();
Integer value = null;
while (value == null) {
if (scannerNext.hasNext(scanner)) {
value = scannerValue.getNext(scanner);
} else {
scanner.next();
}
}
return value;
}
There is one more problem that the type of the value variable differs. So we replace it with its common supertype:
private Integer readInteger() {
ScannerNext scannerNext = (sc)->sc.hasNextInt();
ScannerValue scannerValue = (sc)-> sc.nextInt();
Number value = null;
while (value == null) {
if (scannerNext.hasNext(scanner)) {
value = scannerValue.getNext(scanner);
} else {
scanner.next();
}
}
return (Integer)value;
}
Now you have to places with a big equal section. You can select one of those sections starting with Number value = null; ending with the } before return ... and invoke your IDEs automated refactoring extract method:
private Number readNumber(ScannerNext scannerNext, ScannerValue scannerValue) {
Number value = null;
while (value == null) {
if (scannerNext.hasNext(scanner)) {
value = scannerValue.getNext(scanner);
} else {
scanner.next();
}
}
return value;
}
private Integer readInteger() {
return (Integer) readNumber( (sc)->sc.hasNextInt(), (sc)-> sc.nextInt());
}
private Double readDouble() {
return (Double) readNumber( (sc)->sc.hasNextDouble(), (sc)-> sc.nextDouble());
}
Comments argue against the use of custom interfaces against predefined interfaces from the JVM.
But my point in this answer was how to turn similar code into equal code so that it can be extracted to a single method rather that giving a concrete solution for this random problem.

Not an ideal solution but it still achieves the necessary removal of duplicate code and has the added benefit of not requiring Java-8.
// This could be done better.
static final Scanner scanner = new Scanner(System.in);
enum Read{
Int {
#Override
boolean hasNext() {
return scanner.hasNextInt();
}
#Override
<T> T next() {
return (T)Integer.valueOf(scanner.nextInt());
}
},
Dbl{
#Override
boolean hasNext() {
return scanner.hasNextDouble();
}
#Override
<T> T next() {
return (T)Double.valueOf(scanner.nextDouble());
}
};
abstract boolean hasNext();
abstract <T> T next();
// All share this method.
public <T> T read() {
T v = null;
while (v == null) {
if ( hasNext() ) {
v = next();
} else {
scanner.next();
}
}
return v;
}
}
public void test(String[] args) {
Integer i = Read.Int.read();
Double d = Read.Dbl.read();
}
There are some minor issues with this such as the casting but it should be a reasonable option.

A totally different approach from my other answer (and the other answers): don't use generics, but instead just write the methods more concisely, so you don't really notice the duplication.
TL;DR: rewrite the methods as
while (!scanner.hasNextX()) scanner.next();
return scanner.nextX();
The overall goal - write it as a single method - is only possible if you accept some amount of additional cruft.
Java method signatures do not take into account the return type, so it's not possible to have a next() method return an Integer in one context, and Double in another (short of returning a common supertype).
As such, you have to have something at the call sites to distinguish these cases:
You might consider passing something like Integer.class or Double.class. This does have the advantage that you can use generics to know that the returned value matches that type. But callers could pass in something else: how would you handle Long.class, or String.class? Either you need to handle everything, or you fail at runtime (not a good option). Even with a tighter bound (e.g. Class<? extends Number>), you still need to handle more than Integer and Double.
(Not to mention that writing Integer.class and Double.class everywhere is really verbose)
You might consider doing something like #Ward's answer (which I do like, BTW: if you're going to do it with generics, do it like that), and pass in functional objects which are able to deal with the type of interest, as well as providing the type information to indicate the return type.
But, again, you've got to pass these functional objects in at each call site, which is really verbose.
In taking either of these approaches, you can add helper methods which pass the appropriate parameters to the "generic" read method. But this feels like a backwards step: instead of reducing the number of methods to 1, it's increased to 3.
Additionally, you now have to distinguish these helper methods somehow at the call sites, in order to be able to call the appropriate one:
You could have overloads with a parameter of value type, rather than class type, e.g.
Double read(Double d)
Integer read(Integer d)
and then call like Double d = read(0.0); Integer i = read(0);. But anybody reading this code is going to be left wondering what that magic number in the code is - is there any significance to the 0?
Or, easier, just call the two overloads something different:
Double readDouble()
Integer readInteger()
This is nice and easy: whilst it's slightly more verbose than read(0.0), it's readable; and it's way more concise that read(Double.class).
So, this has got us back to the method signatures in OP's code. But this hopefully justifies why you still want to keep those two methods. Now to address the contents of the methods:
Because Scanner.nextX() doesn't return null values, the method can be rewritten as:
while (!scanner.hasNextX()) scanner.next();
return scanner.nextX();
So, it's really easy to duplicate this for the two cases:
private Integer readInteger() {
while (!scanner.hasNextInt()) scanner.next();
return scanner.nextInt();
}
private Double readDouble() {
while (!scanner.hasNextDouble()) scanner.next();
return scanner.nextDouble();
}
If you want, you could pull out a method dropUntil(Predicate<Scanner>) method to avoid duplicating the loop, but I'm not convinced it really saves you that much.
A single (near-)duplicated line is way less burdensome in your code than all those generics and functional parameters. It's just plain old code, which happens to be more concise (and, likely, more efficient) than "new" ways to write it.
The other advantage of this approach is that you don't have to use boxed types - you can make the methods return int and double, and not have to pay the boxing tax unless you actually need it.
This may not be of advantage to OP, since the original methods do return the boxed type; I don't know if this is genuinely desired, or merely an artefact of the way the loop was written. However, it is useful in general not to create those objects unless you really need them.

Reflection is an alternative if you don't care about performance.
private <T> T read(String type) throws Exception {
Method readNext = Scanner.class.getMethod("next" + type);
Method hasNext = Scanner.class.getMethod("hasNext" + type);
T value = null;
while (value == null) {
if ((Boolean) hasNext.invoke(scanner)) {
value = (T) readNext.invoke(scanner);
} else {
scanner.next();
}
}
return value;
}
Then you call
Integer i = read("Int");

Way to parseInt without try-catch in Java 8?

Is there a better way to try to convert to int a string that can be or not an integer?
Integer.parseInt(String value) will work well with "25" or "019" but not with "hello" or "8A".
In Java 8, we have optional values, for example:
public static void main(String[] args) {
Optional<Integer> optionalResult = functionThatReturnsOptionalInteger();
Integer finalValue = optionalResult.orElse(0);
System.out.println(finalValue);
}
public static Optional<Integer> functionThatReturnsOptionalInteger() {
Integer[] ints = new Integer[0];
return Stream.of(ints).findAny();
}
You do not need to check nulls, because the Optional wrapper expose useful methods to deal with this kind of situations.
But if you want to parseInt a string, that can be null, or does not contains a valid integer, the solution is the same as always:
public static Integer parseIntOrDefault(String toParse, int defaultValue) {
try {
return Integer.parseInt(toParse);
} catch (NumberFormatException e) {
return defaultValue;
}
}
How can improve this with Java 8 features, why Integer.parseInt() has not been overloaded to return an Optional in case of bad argument? (Or just add a new method Integer.parseIntOptional() to Integer wrapper)

There doesn't exist anything like this in the standard library afaik, but you can write a method that parses a String into an Optional<Integer> like this:
public static Optional<Integer> parseInt(String toParse) {
try {
return Optional.of(Integer.parseInt(toParse));
} catch (NumberFormatException e) {
return Optional.empty();
}
}

Unlike other answers that are now deleted, I don't think this really has to do with Java being backwards-compatible.
Because an empty Optional represents a value that is absent, it would mean that the method actually worked but no results are returned.
However, parsing hello as an integer will not work and has to throw an exception, because it is an error rather than an empty result. Keep in mind that NumberFormatException extends IllegalArgumentException.
More generally speaking, Optional was made for dealing with possibly absent values (instead of using null for that), and not for error handling. Also, Optional doesn't provide any way to know what is the error and why there is one.

I don’t want to speculate why such method does not exist, but if you like neither, perform a pre-test nor catch an exception, you need a re-implementation, e.g.
public static OptionalInt parseInt(String s) {
if(s.isEmpty()) return OptionalInt.empty();
final int len = s.length(), limit;
final boolean negative;
int i = 0;
switch(s.charAt(0)) {
case '-':
i=1;
if(len==1) return OptionalInt.empty();
negative = true;
limit = Integer.MIN_VALUE;
break;
case '+':
i=1;
if(len==1) return OptionalInt.empty();
// fall-through
default:
negative = false;
limit = -Integer.MAX_VALUE;
}
final int limitBeforeMul = limit / 10;
int result = 0;
for(; i < len; i++) {
int digit = Character.digit(s.charAt(i), 10);
if(digit < 0 || result < limitBeforeMul || (result *= 10) < limit + digit)
return OptionalInt.empty();
result -= digit;
}
return OptionalInt.of(negative? result: -result);
}
This basically does the same as Integer.parseInt, but returns an empty OptionalInt for invalid strings instead of throwing an exception…
As you might notice, the hardest part is to handle numbers close to Integer.MIN_VALUE resp. Integer.MAX_VALUE correctly.

Without a try-catch and still returning an Optional - you could do
Optional<Integer> result = Optional.ofNullable(input)
.filter(str -> str.matches("-?\\d+"))
.map(Integer::parseInt);
EDIT: Regex updated to support negative numbers
WARNING: As pointed out in the comments, will still throw a RuntimeException if the parsed String turns out to be outside the range of Integer.MIN_VALUE and Integer.MAX_VALUE

Google's Guava library provides a helper method to do this: Ints.tryParse(String).It runs null when the string is not parsable. You can checkout the documentation.

Using Mutiny it can be written like this.
If you just want to do something with the result you could do it in a single expression
Uni.createFrom()
.item(() -> Integer.parseInt(toParse))
.onFailure().recoverWithItem(defaultValue)
.subscribe().with(i -> System.out.println(i));
Or create a method like the one intended
public static Integer parseIntOrDefault(String toParse, int defaultValue) {
Integer[] toReturn = new Integer[]{null};
Uni.createFrom()
.item(() -> Integer.parseInt(toParse))
.onFailure().recoverWithItem(defaultValue)
.subscribe().with(i -> toReturn[0] = i);
return toReturn[0];
}
This solution adds a library, but the lib is not specific to handle this problem. It uses reactive programing, futures, callbacks and a fluent API and proves to be flexible enough to solve this problem.

How to handle null compare method arguments in Comparator?

I have created an implementation of Comparator<Entity>, but when I use this comparator to sort an Array<Entity>. I will receive an java.lang.NullPointerException, because when I map the entity to a static collections which is already removed. Now my problem is I don't know what to return to skip the compare method.
public class CustomComparator implements Comparator<Entity> {
public int compare(Entity e1, Entity e2) {
if( e1== null || e2 == null) {
return // don't know what to return to skip this method;
}
Vector2 e1Pos = Mapper.transform.get(e1).position;
Vector2 e2Pos = Mapper.transform.get(e2).position;
}
}

You can't "skip" the comparison. What would you expect the sorting code to do? You've got to provide it with a result.
Two options are common:
Throw a NullPointerException to indicate that you just don't support comparing null values. That's explicitly an option in the compare documentation
Decide that null comes before everything else, but is equal to itself
The latter implementation would be something like:
public int compare(Entity e1, Entity e2) {
if (e1 == e2) {
return 0;
}
if (e1 == null) {
return -1;
}
if (e2 == null) {
return 1;
}
Vector2 e1Pos = Mapper.transform.get(e1).position;
Vector2 e2Pos = Mapper.transform.get(e2).position;
return ...;
}

To elaborate on Jon's answer, and answer Ron's question, one should always look at the spec before deciding what to do. In this case it says "Unlike Comparable, a comparator may optionally permit comparison of null arguments, while maintaining the requirements for an equivalence relation." See the comparator API. It elaborates on what is meant. I can't see any other reasonable solution.

Using comparator for several characteristics in java

I have a list to be sorted but it cannot be done if values are represented as strings. Example:
to sort: OB123, OB1212, Maintenance, Daily check, OB123
desired result: Daily check, Maintenance, OB123, OB123, OB1212
if values are strings result is: Daily check, Maintenance, OB1212, OB123,OB123
Therefore I need to use comparator to first sort aircraft numbers such OB123 by their carrier(OB), than by their number (123) and sometimes suffix (""). And after that I would like to compare the whole name with all the rest values as "daily check" etc.
So far I can sort only flight Ids:
#Override
public int compareTo(FlightNumberDisplay toCompare) {
int result = _carrier.compareTo(toCompare.getCarrier());
if (result == 0) {
result = _number.compareTo(toCompare.getNumber());
if (result == 0) {
result = _suffix.compareTo(toCompare.getSuffix());
}
}
return result;
}
So since "Daily check" has also carrier+number+suffix representation it is sorted according to it. The question is how to sort them according to their names.

Well, you can make a comparison checking for numbers in the strings:
FlightComparator.java
public class FlightComparator implements Comparator<String> {
public int compare(String arg0, String arg1) {
// both have numbers, compare them
if (containsNumber(arg0) && containsNumber(arg0)) {
Integer i1, i2;
try {
i1 = getNumber(arg0);
} catch (NumberFormatException ex) {
return 1;
}
try {
i2 = getNumber(arg1);
} catch (NumberFormatException ex) {
return -1;
}
return i1.compareTo(i2);
} else {
// no numbers
return arg0.compareTo(arg1);
}
}
private boolean containsNumber(String string) {
return string.matches(".*\\d+.*");
}
private Integer getNumber(String string) throws NumberFormatException {
return Integer.parseInt(string.replaceAll("\\D+",""));
}
}
TEST IT
public static void main(String[] args) {
String[] ss = {"OB123", "OB1212", "Maintenance", "Daily check", "OB123"};
Collections.sort(Arrays.asList(ss), new FlightComparator());
list(ss);
}
private static void list(String[] ss) {
for (String s : ss) {
System.out.println(s);
}
}
OUTPUT
Daily check
Maintenance
OB123
OB123
OB1212
DISCLAIMER
Now, while this data seems correct for what you ask, is not a real answer to your problem. Also if flight letters are different ie, OM1212, OR1212, this will only compare the numbers, so to complete solve your problem now, you can choose between
use this Comparator and compare data as shown (not using attributes)
adapt this Comparator<String> to Comparator<Flight> (best option)
CREDITS
Method getNumber created from this answer
Method containsNumber from this answer

You can extract the carrier information in another List, there you can parse it by Integer using parseInt() and then sort it.
Later you can merge both lists.

How could this Java method be improved?

I am parsing XML files and I have several methods similar to:
public static Integer getInteger(Object integer) {
if (integer == null) {
return 0;
}
try {
return Integer.parseInt(integer.toString(), 10);
} catch (Exception ex) {
return 0;
}
}
So basically, you pass an object in with the assumption of converting it to an Integer (I also have versions for Float, etc).
This seems to work well but being a Java newbie, I was wondering how you would improve it. I am especially interesting in the boxing/unboxing aspect (at least, from a C# developer's perspective).
Thanks
EDIT
Sorry, I wasn't clear to what goes into the method. Yes, it's for an XML file now so it's always a string. But the string could be empty or maybe even null. I guess I wanted to always return a 0 if there was an error of any kind.

You shouldn't generally catch Exception. Catching NumberFormatException would be more appropriate here.
Any reason for converting to Integer instead of int? Why not let the caller perform the boxing conversion if they need it?

You don't say whether integer is an instance of Integer or not. If it is you can just cast it:
Integer i = (Integer) integer;
having checked for null and instanceof first.
If it is not an instance of Integer then what you're doing seems reasonable, although you only need to catch a NumberFormatException.

You should use instanceof operator, then make safe casting (so if Object integer is instanceof Integer, cast it).
Then you don't have to catch Exception (which in this case is unchecked NumberFormatException)
public static Integer getInteger(Object integer) {
if (integer == null) {
return 0;
}
if (integer instanceof Integer) {
return (Integer)integer;
}
return 0;
}
EDIT
If data is coming from XML, then it will of course never be Integer :) Then parsing from String is required still, so see other answers.

As Jon hinted, returning int (the primitive data type) instead of Integer (the wrapper class) would probably be better (assuming you never want to return null).
Also, adding this code could be a shortcut, when the input is often an Integer object or other Number subclass (I'm calling the input input because it's too confusing otherwise):
if (input instanceof Number) {
return ((Number) integer).intValue();
}

Returning Integer makes sense if you want to signal, that a value is empty. You're testing that already but you shouldn't return 0, unless you have a very clear and somewhat special requirement to do so. No value is not equal to 0.

Also, you can add more special cases besides null, like check for empty string:
public static Integer getInteger(Object integer) {
if (integer == null) {
return 0;
}
try {
String s = integer.toString();
if (s.isEmpty())
return 0;
return Integer.parseInt(s, 10);
} catch (Exception ex) {
return 0;
}
}
On the other side, you can cut all special cases, and go with only:
public static Integer getInteger(Object integer) {
try {
return Integer.parseInt(integer.toString(), 10);
} catch (Exception ex) {
return 0;
}
}
In the end, performance gains (or losses) depends on what portion of your input data is null, empty, unparsable integers, or "normal" integer strings.