Develop Reference

java try-with-resource not working with scala

In Scala application, am trying to read lines from a file using java nio try-with-resource construct.
Scala version 2.11.8
Java version 1.8
try(Stream<String> stream = Files.lines(Paths.get("somefile.txt"))){
stream.forEach(System.out::println); // will do business process here
}catch (IOException e) {
e.printStackTrace(); // will handle failure case here
}
But the compiler throws error like
◾not found: value stream
◾A try without a catch or finally is equivalent to putting its body in a block; no exceptions are handled.
Not sure what is the problem. Am new to using Java NIO, so any help is much appreciated.

If your are on Scala 2.13 then you should use the Using object:
import scala.util.Using
val a: Try[Int] = Using(new FileInputStream("/tmp/someFile")) { fileInputStream =>
// Do what you need in fith you fileInputStream here.
}
It takes two functions. The first one is a function that can create or provide the closable resource, and the second function is the one that takes the closable resource as a parameter, and can use it for something. Using will then in simple terms do the following for you:
Call the first function to create the closable resource.
Call the second function, and provide the resource as a parameter.
Hold on to the returned value of the second function.
Call close on the resource.
Return the value (or exception) it got from the second function wrapped in a Try.
Using can be used on many other things than Classes that implements AutoCloseable, you just have to provide an implicit value, telling Using how to close your specific resource.
In older versions of scala, there is no directly support for javas try-with-resources construct, but your can pretty easy build your own support, by applying the loan pattern. The following is a simple but not optimal example, that is easy to understand. A more correct solution is given later in this answer:
import java.lang.AutoCloseable
def autoClose[A <: AutoCloseable,B](
closeable: A)(fun: (A) ⇒ B): B = {
try {
fun(closeable)
} finally {
closeable.close()
}
}
This defines a reusable method, that works pretty much like a try-with-resource construct in java. It works by taken two parameter. First is takes the a subclass of Autoclosable instance, and second it takes a function that takes the same Autoclosable type as a paremeter. The return type of the function parameter, is used as return type of the method. The method then executes the function inside a try, and close the autocloseble in its finally block.
You can use it like this (here used to get the result of findAny() on the stream.
val result: Optional[String] = autoClose(Files.lines(Paths.get("somefile.txt"))) { stream ⇒
stream.findAny()
}
In case your want to do catch exceptions, you have 2 choices.
Add a try/catch block around the stream.findAny() call.
Or add a catch block to the try block in the autoClose method. Note that this should only be done, if the logic inside the catch block is usable from all places where autoClose is called.
Note that as Vitalii Vitrenko point out, this method will swallow the exception from the close method, if both the function supplied by the client, and the close method on the AutoCloseable throws an exception. Javas try-with-resources handles this, and we can make autoClose do so to, by making it a bit more complex:
def autoClose[A <: AutoCloseable,B](
closeable: A)(fun: (A) ⇒ B): B = {
var t: Throwable = null
try {
fun(closeable)
} catch {
case funT: Throwable ⇒
t = funT
throw t
} finally {
if (t != null) {
try {
closeable.close()
} catch {
case closeT: Throwable ⇒
t.addSuppressed(closeT)
throw t
}
} else {
closeable.close()
}
}
}
This works by storing the potentially exception the client function throws, and adding the potential exception of the close method to it as a supressed exception. This is pretty close to how oracle explains that try-with-resource is actually doing it: http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html
However this is Scala, and a lot of people will prefer to program in a more functional way. In a more functional way, the method should return a Try, instead of throwing an exception. This avoids a side effect of throwing an exception, and makes it clear to the client that the response may be a failure that should be handled (as pointed out in the answer by Stas). In a functional implementation, we would also like to avoid having a var, so a naive attempt could be:
// Warning this implementation is not 100% safe, see below
def autoCloseTry[A <: AutoCloseable,B](
closeable: A)(fun: (A) ⇒ B): Try[B] = {
Try(fun(closeable)).transform(
result ⇒ {
closeable.close()
Success(result)
},
funT ⇒ {
Try(closeable.close()).transform(
_ ⇒ Failure(funT),
closeT ⇒ {
funT.addSuppressed(closeT)
Failure(funT)
}
)
}
)
}
This could them be called like this:
val myTry = autoCloseTry(closeable) { resource ⇒
//doSomethingWithTheResource
33
}
myTry match {
case Success(result) ⇒ doSomethingWithTheResult(result)
case Failure(t) ⇒ handleMyExceptions(t)
}
Or you could just call .get on myTry to make it return the result, or throw the exception.
However as Kolmar points out in a comment, this implementation is flawed, due to how the return statement works in scala. Consider the following:
class MyClass extends AutoCloseable {
override def close(): Unit = println("Closing!")
}
def foo: Try[Int] = {
autoCloseTry(new MyClass) { _ => return Success(0) }
}
println(foo)
We would expect this to print Closing!, but it will not. The problem here is the explicit return statement inside the function body. It makes the method skip the logic in the autoCloseTry method, and thereby just returns Success(0), without closing the resource.
To fix that problem, we can create a mix of the 2 solutions, one that has the functional API of returning a Try, but uses the classic implementation based on try/finally blocks:
def autoCloseTry[A <: AutoCloseable,B](
closeable: A)(fun: (A) ⇒ B): Try[B] = {
var t: Throwable = null
try {
Success(fun(closeable))
} catch {
case funT: Throwable ⇒
t = funT
Failure(t)
} finally {
if (t != null) {
try {
closeable.close()
} catch {
case closeT: Throwable ⇒
t.addSuppressed(closeT)
Failure(t)
}
} else {
closeable.close()
}
}
}
This should fix the problem, and can be used just like the first attempt. However it shows that this a bit error prone, and the faulty implementation has been in this answer as the recommended version for quite some time. So unless you trying to avoid having to many libraries, you should properly consider using this functionality from a library. I think that there is already one other answer pointing to one, but my guess is that there is multiply libraries, that solves this problem in different ways.

Alternatively, you can use Choppy's (Disclaimer: I am the author) TryClose monad do this in a for-comprehension in a composeable manner similar to Scala's Try.
val ds = new JdbcDataSource()
val output = for {
conn <- TryClose(ds.getConnection())
ps <- TryClose(conn.prepareStatement("select * from MyTable"))
rs <- TryClose.wrap(ps.executeQuery())
} yield wrap(extractResult(rs))
Here's how you would do it with your stream:
val output = for {
stream <- TryClose(Files.lines(Paths.get("somefile.txt")))
} yield wrap(stream.findAny())
More info here:
https://github.com/choppythelumberjack/tryclose

You have the already mentioned in one of the answers approach:
def autoClose[A <: AutoCloseable, B](resource: A)(code: A ⇒ B): B = {
try
code(resource)
finally
resource.close()
}
But I think the following is much more elegant:
def autoClose[A <: AutoCloseable, B](resource: A)(code: A ⇒ B): Try[B] = {
val tryResult = Try {code(resource)}
resource.close()
tryResult
}
With the last one IMHO it's easier to handle the control flow.

Converting String to Integers the safe way

I have a little method that amongst other things also converts a string into an integer. Since the string is a parameter of the method I want to make sure that that string is convertable. So I was just wondering what would be the safest and / or fastest way.
Version A: Just leave it as it is and take the risks (which I'm trying to avoid)
public static int stringToInt(String param) {
return Integer.valueOf(param);
}
(in terms of speed, what kind of difference would it make to version B and C?)
Version B: Catch the exception
public static int stringToInt(String param) {
try {
return Integer.valueOf(param);
} catch(NumberFormatException e) {
return -1;
}
}
Version C: Check each letter of the string to see, if it's a digit number or not
public static int stringToInt(String param) {
for(char c : param.toCharArray()) {
if(!Character.isDigit(c))
return -1;
}
return Integer.valueOf(param);
}
Note that the parameter has to be a positive number and the -1 is supposed to be the "error value" in my little program, in other words, all three versions of methods would work perfectally fine in my program.
I'm very open to any other suggestion you can give me, so feel free to create your own version, if you think yours is better.
Thank you very much for your support in advance.

Guava offers a utility method for this which returns null in case your String can't be parsed.
https://google.github.io/guava/releases/19.0/api/docs/com/google/common/primitives/Ints.html#tryParse(java.lang.String)
Integer result = Ints.tryParse("1"); //returns 1
Integer result = Ints.tryParse("-1"); //returns -1
Integer result = Ints.tryParse("a"); //returns null

First, note that version C is not bulletproof: it would reject negative numbers, and would not catch numbers that are too large.
Version B is OK, yet it makes the caller change the coding style: rather than catching an error and processing it together with other errors, the caller would need to check for -1 all the time. This may be suboptimal in situations where you read multiple integers, but the error processing does not depend on which particular one has failed. In addition, new coders using your API may forget to check for -1, and use the error code inadvertently.
That's why I would stay with the first option: the code using version A would look instantly familiar to anyone who knows Java API, without the need to learn what happens inside your function.

I believe a modified B to throw an exception rather than returning -1 will be the best choice. It is good to throw the exception up to the level, where it can be processed to send the proper response to the user. Returning a value like -1 will make your code error prone. Assume that a different programmer is consuming your method and he/she just have the signature of your method. So it is not clear from the signature what he/she should code to handle an exception or error scenario. But if you throw the exception and add it to your method declaration then it will enable the other programmer to consume your method properly alongwith the required exception handling. For me this looks the best:
public static int stringToInt(String param) throws NumberFormatException {
try {
return Integer.valueOf(param);
} catch(NumberFormatException e) {
// return -1;
throw e;
}
}

Java 8 without any API:
Optional.ofNullable(strNum)
.map(Integer::valueOf).orElse(null);

public int stringToInt(String param) throws NumberFormatException {
Optional.ofNullable(param.replaceAll("\\s+", ""))
.map(Integer::valueOf).orElse(null);
/*
or
Optional.ofNullable(param.replaceAll(" ", ""))
.map(Integer::valueOf).orElse(null);
*/
}
use the replaceAll to replace white spaces the plus is cpu friendly even though seems not needed.

I used a combination of 2 answers to have it safe for nulls, empty or blank strings, and non numeric characters:
public static Integer safeStringToInt(String param) {
return Optional.ofNullable(param).map(Ints::tryParse).orElse(null);
}

Java 8: Mandatory checked exceptions handling in lambda expressions. Why mandatory, not optional?

I'm playing with the new lambda features in Java 8, and found that the practices offered by Java 8 are really useful. However, I'm wondering is there a good way to make a work-around for the following scenario. Suppose you have an object pool wrapper that requires some kind of a factory to fill the object pool, for example (using java.lang.functions.Factory):
public class JdbcConnectionPool extends ObjectPool<Connection> {
public ConnectionPool(int maxConnections, String url) {
super(new Factory<Connection>() {
#Override
public Connection make() {
try {
return DriverManager.getConnection(url);
} catch ( SQLException ex ) {
throw new RuntimeException(ex);
}
}
}, maxConnections);
}
}
After transforming the functional interface into lambda expression, the code above becomes like that:
public class JdbcConnectionPool extends ObjectPool<Connection> {
public ConnectionPool(int maxConnections, String url) {
super(() -> {
try {
return DriverManager.getConnection(url);
} catch ( SQLException ex ) {
throw new RuntimeException(ex);
}
}, maxConnections);
}
}
Not so bad indeed, but the checked exception java.sql.SQLException requires a try/catch block inside the lambda. At my company we use two interfaces for long time:
IOut<T> that is an equivalent to java.lang.functions.Factory;
and a special interface for the cases that usually require checked exceptions propagation: interface IUnsafeOut<T, E extends Throwable> { T out() throws E; }.
Both IOut<T> and IUnsafeOut<T> are supposed to be removed during migration to Java 8, however there is no exact match for IUnsafeOut<T, E>. If the lambda expressions could deal with checked exceptions like they were unchecked, it could be possible to use simply like the following in the constructor above:
super(() -> DriverManager.getConnection(url), maxConnections);
That looks much cleaner. I see that I can rewrite the ObjectPool super class to accept our IUnsafeOut<T>, but as far as I know, Java 8 is not finished yet, so could be there some changes like:
implementing something similar to IUnsafeOut<T, E>? (to be honest, I consider that dirty - the subject must choose what to accept: either Factory or "unsafe factory" that cannot have compatible method signatures)
simply ignoring checked exceptions in lambdas, so no need in IUnsafeOut<T, E> surrogates? (why not? e.g. another important change: OpenJDK, that I use, javac now does not require variables and parameters to be declared as final to be captured in an anonymous class [functional interface] or lambda expression)
So the question is generally is: is there a way to bypass checked exceptions in lambdas or is it planned in the future until Java 8 is finally released?
Update 1
Hm-m-m, as far as I understand what we currently have, it seems there is no way at the moment, despite the referenced article is dated from 2010: Brian Goetz explains exception transparency in Java. If nothing changed much in Java 8, this could be considered an answer. Also Brian says that interface ExceptionalCallable<V, E extends Exception> (what I mentioned as IUnsafeOut<T, E extends Throwable> out of our code legacy) is pretty much useless, and I agree with him.
Do I still miss something else?

Not sure I really answer your question, but couldn't you simply use something like that?
public final class SupplierUtils {
private SupplierUtils() {
}
public static <T> Supplier<T> wrap(Callable<T> callable) {
return () -> {
try {
return callable.call();
}
catch (RuntimeException e) {
throw e;
}
catch (Exception e) {
throw new RuntimeException(e);
}
};
}
}
public class JdbcConnectionPool extends ObjectPool<Connection> {
public JdbcConnectionPool(int maxConnections, String url) {
super(SupplierUtils.wrap(() -> DriverManager.getConnection(url)), maxConnections);
}
}

In the lambda mailing list this was throughly discussed. As you can see Brian Goetz suggested there that the alternative is to write your own combinator:
Or you could write your own trivial combinator:
static<T> Supplier<T> exceptionWrappingSupplier(Supplier<T> b) {
return e -> {
try { b.accept(e); }
catch (Exception e) { throw new RuntimeException(e); }
};
}
You can write it once, in less that the time it took to write your
original e-mail. And similarly once for each kind of SAM you use.
I'd rather we look at this as "glass 99% full" rather than the
alternative. Not all problems require new language features as
solutions. (Not to mention that new language features always causes
new problems.)
In those days the Consumer interface was called Block.
I think this corresponds with JB Nizet's answer.
Later Brian explains why this was designed this way (the reason of problem)
Yes, you'd have to provide your own exceptional SAMs. But then lambda
conversion would work fine with them.
The EG discussed additional language and library support for this
problem, and in the end felt that this was a bad cost/benefit
tradeoff.
Library-based solutions cause a 2x explosion in SAM types (exceptional
vs not), which interact badly with existing combinatorial explosions
for primitive specialization.
The available language-based solutions were losers from a
complexity/value tradeoff. Though there are some alternative
solutions we are going to continue to explore -- though clearly not
for 8 and probably not for 9 either.
In the meantime, you have the tools to do what you want. I get that
you prefer we provide that last mile for you (and, secondarily, your
request is really a thinly-veiled request for "why don't you just
give up on checked exceptions already"), but I think the current
state lets you get your job done.

September 2015:
You can use ET for this. ET is a small Java 8 library for exception conversion/translation.
With ET you can write:
super(() -> et.withReturningTranslation(() -> DriverManager.getConnection(url)), maxConnections);
Multi line version:
super(() -> {
return et.withReturningTranslation(() -> DriverManager.getConnection(url));
}, maxConnections);
All you need to do before, is creating a new ExceptionTranslator instance:
ExceptionTranslator et = ET.newConfiguration().done();
This instance is thread safe an can be shared by multiple components. You can configure more specific exception conversion rules (e.g. FooCheckedException -> BarRuntimeException) if you like. If no other rules are available, checked exceptions are automatically converted to RuntimeException.
(Disclaimer: I am the author of ET)

We developed an internal project in my company that helped us with this. We decided to went public two months ago.
This is what we came up with:
#FunctionalInterface
public interface ThrowingFunction<T,R,E extends Throwable> {
R apply(T arg) throws E;
/**
* #param <T> type
* #param <E> checked exception
* #return a function that accepts one argument and returns it as a value.
*/
static <T, E extends Exception> ThrowingFunction<T, T, E> identity() {
return t -> t;
}
/**
* #return a Function that returns the result of the given function as an Optional instance.
* In case of a failure, empty Optional is returned
*/
static <T, R, E extends Exception> Function<T, Optional<R>> lifted(ThrowingFunction<T, R, E> f) {
Objects.requireNonNull(f);
return f.lift();
}
static <T, R, E extends Exception> Function<T, R> unchecked(ThrowingFunction<T, R, E> f) {
Objects.requireNonNull(f);
return f.uncheck();
}
default <V> ThrowingFunction<V, R, E> compose(final ThrowingFunction<? super V, ? extends T, E> before) {
Objects.requireNonNull(before);
return (V v) -> apply(before.apply(v));
}
default <V> ThrowingFunction<T, V, E> andThen(final ThrowingFunction<? super R, ? extends V, E> after) {
Objects.requireNonNull(after);
return (T t) -> after.apply(apply(t));
}
/**
* #return a Function that returns the result as an Optional instance. In case of a failure, empty Optional is
* returned
*/
default Function<T, Optional<R>> lift() {
return t -> {
try {
return Optional.of(apply(t));
} catch (Throwable e) {
return Optional.empty();
}
};
}
/**
* #return a new Function instance which wraps thrown checked exception instance into a RuntimeException
*/
default Function<T, R> uncheck() {
return t -> {
try {
return apply(t);
} catch (final Throwable e) {
throw new WrappedException(e);
}
};
}
}
https://github.com/TouK/ThrowingFunction/

Have you considered using a RuntimeException (unchecked) wrapper class to smuggle the original exception out of the lambda expression, then casting the wrapped exception back to it's original checked exception?
class WrappedSqlException extends RuntimeException {
static final long serialVersionUID = 20130808044800000L;
public WrappedSqlException(SQLException cause) { super(cause); }
public SQLException getSqlException() { return (SQLException) getCause(); }
}
public ConnectionPool(int maxConnections, String url) throws SQLException {
try {
super(() -> {
try {
return DriverManager.getConnection(url);
} catch ( SQLException ex ) {
throw new WrappedSqlException(ex);
}
}, maxConnections);
} catch (WrappedSqlException wse) {
throw wse.getSqlException();
}
}
Creating your own unique class should prevent any likelihood of mistaking another unchecked exception for the one you wrapped inside your lambda, even if the exception is serialized somewhere in the pipeline before you catch and re-throw it.
Hmm... The only thing I see that's a problem here is that you are doing this inside a constructor with a call to super() which, by law, must be the first statement in your constructor. Does try count as a previous statement? I have this working (without the constructor) in my own code.

Wrapping the exception in the described way does not work. I tried it and I still get compiler errors, which is actually according to the spec: the lambda expression throws the exception which is incompatible with the target type of the method argument: Callable; call() does not throw it so I can not pass the lambda expression as a Callable.
So basically there is no solution: we are stuck with writing boilerplate. The only thing we can do is voice our opinion that this needs fixing. I think the spec should not just blindly discard a target type based on incompatible thrown exceptions: it should subsequently check whether the thrown incompatible exception is caught or declared as throws in the invoking scope.
And for lambda expressions that are not inlined I propose we can mark them as silently throwing checked exception (silent in the sense that the compiler should not check, but the runtime should still catch).
let's mark those with => as opposed to ->
I know this is not a discussion site, but since this IS the only solution to the question, let yourself be heard and let's change this spec!

Paguro provides functional interfaces that wrap checked exceptions. I started working on it a few months after you asked your question, so you were probably part of the inspiration for it!
You'll notice that there are only 4 functional interfaces in Paguro vs. the 43 interfaces included with Java 8. That's because Paguro prefers generics to primitives.
Paguro has single-pass transformations built into its immutable collections (copied from Clojure). These transforms are roughly equivalent to Clojure transducers or Java 8 streams, but they accept functional interfaces that wrap checked exceptions. See: the differences between Paguro and Java 8 streams.

You can throw from your lambdas, they just have to be declared "with your own way" (which makes them, unfortunately, not re-usable in standard JDK code, but hey, we does what we cans).
#FunctionalInterface
public interface SupplierIOException {
MyClass get() throws IOException;
}
Or the more generic-ized version:
public interface ThrowingSupplier<T, E extends Exception> {
T get() throws E;
}
ref here. There is also a mention of using "sneakyThrow" to not declare the checked exceptions, but then still throw them. It that hurts my head a bit, maybe an option.

jOOλ is a library that supports wrapping all sorts of functional interfaces throwing checked exceptions into equivalent JDK functional interfaces. For example:
// Wraps the checked exception in an unchecked one:
Supplier<Class<?>> supplier = Unchecked.supplier(() -> Class.forName("com.example.X"));
// Re-throws the checked exception without compile time checking:
Supplier<Class<?>> supplier = Sneaky.supplier(() -> Class.forName("com.example.X"));
I've made some more examples in this blog post here.
Disclaimer: I made jOOλ

Using Scala's Either, Right and Left from Java

How might a Java program wrap a value into a scala.Either? For example, how would the following Scala code be written in Java?
Right("asdf")
Left(new Exception())
The following fails with "cannot find symbol method apply(java.lang.String)"
Right.apply("asdf");
The following fails with "cannot find symbol method apply(java.lang.Exception)"
Left.apply(new Exception());

If I understand the question correctly, assume you have the following Scala method:
def foo(stringOrDate: Either[String, Date]) {
//...
}
you can call it from Java code by single creating Either subclasses instances:
scalaObject.foo(new Left<String, Date>("abc"));
scalaObject.foo(new Right<String, Date>(new Date()));
If you want to pass functions from Java code, you have to implement Function* trait depending on the function arity:
def foo(stringOrStringFun: Either[String, () => String]) {
//...
}
In Java:
scalaObject.foo(new Left<String, scala.Function0<String>>("abc"));
scalaObject.foo(new Right<String, scala.Function0<String>>(
new scala.Function0<String>() {
#Override
public String apply() {
throw new RuntimeException();
}
}));
Of course in Scala it is much simpler as it supports lambdas on the syntax level:
foo(Left("abc"))
foo(Right(throw new RuntimeException()))

Warning: compile with -Xlint:unchecked pops on this code!

import java.lang.reflect.Method;
public class ClassLoadingTester
{
public static void main(String a[]){
try{
ClassLoader loader=new CustomClassLoader();
Class c=loader.loadClass("AddClass");
loader=null;
Object o=c.newInstance();
Method m=c.getMethod("getTwoNumbers",new Class[]{String.class,String.class});
m.invoke(o,new Object[]{"2","3"});
}catch(Exception e){
e.printStackTrace();
}
}
}
This code snippet generates a warning when i compile in java.
I think it pertains to this line,
Method m=c.getMethod("getTwoNumbers",new Class[]{String.class,String.class});
When I attempt to put <String> like this new Class<String>[]{String.class,String.class}
It generates an error saying generic array type I'm doing my code in BlueJ.
But when I leave the code as is it generates that irritating warning ^^.
I just want to get rid of that warning what should I do with that line of code?

You can't create arrays of generic types like Class<String>, hence the error. So you don't have much choice other than adding a #SuppressWarnings("unchecked") annotation before the statement to silence the warning.
Note that these warnings almost always have a reason, and silencing them this way regularly may easily result in runtime class cast exceptions! So always think three times before using #SuppressWarnings("unchecked") - use it only when you are absolutely sure the cast is safe and there can be no negative consequences. In this case it looks safe to me to use it.

int t=10, a=7, b=52, d=97;
if((t + d) / 2 > b && (d - t) % 2 != 0)
if(a%2==0 || b%2==0)
System.out.println(--t + a);
else
System.out.println(--t - a);
else
System.out.println(t + ++a);