Re: [PATCH] ob-java

[ian martins <ianxm@jhu.edu>]

On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri <jarmo.hurri@iki.fi> wrote:
> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>
> > It seems that you have changed some classloader settings in the new
> > code. I have examples which used to work perfectly; now they still
> > compile, but fail to run, throwing exception
> >
> > java.lang.NoClassDefFoundError
>
> I had some extra time today, so I took a look at ob-java.el. Unless
> header argument dir is set, java is run in a temporary directory. So I
> can get around this problem by setting header argument
>
> :dir "."
>
> which is nice, at least as a workaround.

It looks like you quoted a previous email there but I never saw it.

You're right that this is a change. I will revert the default
behaviour. in the meantime you could do something like

(setq org-babel-default-header-args:java
      (cons '(:dir . ".")
            org-babel-default-header-args:java))

in your init file after loading org to fix it everywhere.

> I am not sure what the default behaviour should be. At the moment,
> though, I do not think temporary dir is a good default, because by
> default the program will then the "miss" all opened (data) files as
> well. Right?

I agree we should not change the default behavior, but I'm not sure
about data files. The run directory shouldn't change, just the place
where the files are written. when I run this block the java and
classfiles are written to my babel temp dir but it prints out the path
of the org file.

#+begin_src java :results output silent
    System.out.println( System.getProperty("user.dir"));
#+end_src

> Perhaps all babel languages have a common policy here that I am not
> aware of.

I've not seen it documented, but the other babel languages I've used
write to the temp dir. Java is the only one I'm aware of that
defaulted to writing to the current directory.

> But in any case it looks to me that the behaviour has changed now, so if
> it is changed in the stable branch (I am running master), I think it
> should be documented clearly (as an incompatible change). Perhaps it
> already is documented like that.

Yes, you're right that is a change. The current behavior is documented
in ob-doc-java [1], but it isn't called out as a change in behavior.
This is because I didn't notice it as a change, or I'd have not done
it. These changes happened in part because I wrote ob-java in a
circuitous way. I first wrote ob-haxe (for the language haxe) based on
ob-C and ob-python and then made ob-java from it. When I wrote ob-haxe
I wasn't thinking about maintaining ob-java behaviour, and it wasn't
documented, and there weren't tests, so when I had a new ob-java it
wasn't easy to see what might have changed. It is very helpful that
you tested your existing source blocks and investigated changes.
Thanks for reporting. I'll bring back the old default behavior.

[1] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#org932f876