@kares I have thought about this conversion in the past and was never really sure if this was reasonable or not. Firstly, Ruby File is more than the path but also it's openess (whereas in Java those are different objects) which leads to the second issue is if we ever make a IO.to_java then how will these two methods compare? I am not saying I am against this going in but I have never felt very solid on this behavior.

@enebo have given it thought as well, but either case for the common case it seemed to make still sense.
its for sure a different style of thinking Ruby's File.new vs Java new File() but having an object that you could easily "convert" and pass to a Java API seems reasonable -> probably won't get used much thought.

RubyFile has a getPath() so it seemed natural that users might assume its something of a 'plain-old' path (which is only one step away from new java.io.File( rubyFile.getPath() )).

as for IO -> there's to_input_stream and to_output_stream (they check on readability/writeability respectively) which I think means that it makes sense to have io.to_java(java.io.InpuStream) part of the supported conversion as well (setting up a second PR).
IO's don't convert to java.io.File only Ruby's File (and Tempfile)

do I make sense?

@kares yeah if to_java can accept the stream types then the no arg being path does make a lot more sense and it will be compatible with IO having the same sort of logic.

exactly + the conversion isn't auto-matic ... compatibility first, users have to request it (or JI has to run into a Java File method signature): file.to_java same as before but now file.to_java(java.io.File) works ...