There's two possibilities.

The first is due to differences in how IO is implemented on Windows versus on UNIX in JRuby. Because Windows POSIX is a little spotty in places, we need to use win32 functions to emulate Ruby behavior. We have not done this work yet. It could affect reopening stdio streams because on Windows they just wrap the ones the JDK provides, rather than being true native streams.

The second is due to our implementation of Readline, which currently uses a Java library called jline. Unfortunately this library takes over the stdio streams, breaking code like yours that wants to be in IRB and still redirect stdio.

On my macos system, your code appeared to work just fine, which makes me think it's not directly a jline problem.

FWIW, this may be the same problem (or similar) as #1372. See also #3721.

Apologies if I didn't mention it, but yes this problem seems exclusive to windows. It is part of a larger problem. We have a Sinatra application that runs fine on Mac and Linux (using these APIS). On windows these APIS cause the application to just die. No Exceptions, just death...

How does this affect a Sinatra application?

Again apologies for my lack of clarity...

The Sinatra app runs in MRI ruby. When I bring it up it does it's initial babbling and then it just dies, without any exception, but only on Windows. Mac and Linux users have no problems. I begin to suspect it was the 'STDOUT.reopen' that was causing the issues. Out of curiosity, I tried it in JRuby. When JRuby returned:

#<IO:c:\temp\log\jruby2.txt>

and MRI Ruby appeared to lock up I thought I had found the first instance of a bug on Windows MRI Ruby that JRuby could handle. It took further digging before I realized what was going on. It motivated the diff (I will place it last) where I pulled out those redirects. It results in the Sinatra app working on Windows, Linux, and Mac. Again, this app runs via MRI. I just thought I should write up the JRuby bug. Perhaps I stumbled upon a case where two wrongs make a right.

diff --git a/via_soap_emulator/lib/via_soap_emulator.rb b/via_soap_emulator/lib/via_soap_emulator.rb
index fd270c7..38b4028 100755
--- a/via_soap_emulator/lib/via_soap_emulator.rb
+++ b/via_soap_emulator/lib/via_soap_emulator.rb
@@ -18,25 +18,57 @@ LOG_DIR     = CURRENT_DIR + 'log'
 
 prep_the_globals
 
+at_exit do
+  puts "Goodbye!"
+  LOG_HANDLE.close
+end #must be before sinatra
 require 'sinatra'
 
 set :server,  :webrick
 set :port,    (ENV['VIA_PORT'] || '9292').to_i
 
-log_file = "#{LOG_DIR}/#{settings.environment}.log"
-STDOUT.reopen(log_file)
-STDERR.reopen(log_file)
-STDOUT.sync = true
-STDERR.sync = true
+LOG_FILE = "#{LOG_DIR}/#{settings.environment}.log".freeze
+LOG_HANDLE = File.new(LOG_FILE, File::CREAT|File::RDWR|File::TRUNC)
+
+
+module Kernel
+  alias :original_puts :puts
+  alias :original_warn :warn
+end
+
+def log(str)
+  LOG_HANDLE.write(str.to_s + "\n")
+  LOG_HANDLE.flush
+  #original_puts "Wrote to file" #note: you can do things like this here!
+end
+
+def chat (obj, *arg, redirect)
+  log(obj)
+  arg.each do |e|
+    log(e)
+  end
+  self.send(redirect, obj, *arg) #append to the real stdout/sderr too!
+  nil
+end
+
+module Kernel
+  def puts(obj='', *arg)
+    chat(obj, *arg, :original_puts)
+  end
+
+  def warn(msg, *smth)
+    chat(msg, *smth, :original_warn)
+  end
+
+end
 
 configure do
   enable :logging
-  file = File.open(log_file, 'w')
+  file = LOG_HANDLE
   file.sync = true
   use Rack::CommonLogger, file
 end
 
-
 get '/' do
   haml :index
 end
@@ -48,13 +80,12 @@ end
 
 
 get '/log' do
-  File.open(log_file, 'r').read.gsub("\n",'<br>')
+  File.open(LOG_FILE).read.gsub("\n",'<br>')
 end
 
 
 get '/log/clear' do
-  STDOUT.reopen(log_file)
-  STDERR.reopen(STDOUT)
+  LOG_HANDLE.truncate(0)
   redirect '/'
 end
 
@@ -88,7 +119,7 @@ get '/:end_point' do |end_point|
 
   print_stuff
 
-  render_an_xml_file_for end_point
+  render_an_xml_file_for service: "???", end_point: end_point
 end
 

Ahh ok, so this isn't something unique to Sinatra; it would affect any library that attempts to redirect STDOUT using reopen on Windows.

I thought that reopen used to work even with the JDK streams. Perhaps we regressed.

Most likely to happen with Windows IO work in 9.2 (unstarted).

This is likely still an issue due to the lack of native IO support on Windows, which will not be ready for 9.3.