From: ian martins <email@example.com>
To: Jarmo Hurri <firstname.lastname@example.org>
Cc: Org-Mode mailing list <email@example.com>
Subject: Re: [PATCH] ob-java
Date: Sat, 14 Nov 2020 10:46:10 -0500 [thread overview]
Message-ID: <CAC=rjb5rjJa5Tke=zOn8fyfrnU2k0wcGfR=B8+qwsxR70w9MXA@mail.gmail.com> (raw)
On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri <firstname.lastname@example.org> wrote:
> Jarmo Hurri <email@example.com> 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
(cons '(:dir . ".")
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
> 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 , 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.
next prev parent reply other threads:[~2020-11-14 15:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 12:35 [PATCH] ob-java ian martins
2020-10-05 13:23 ` ian martins
2020-10-09 11:15 ` ian martins
2020-10-20 18:28 ` John Herrlin
2020-10-20 19:17 ` John Herrlin
2020-10-21 2:37 ` ian martins
2020-10-21 5:59 ` John Herrlin
2020-10-21 12:47 ` ian martins
2020-10-21 13:54 ` John Herrlin
2020-10-22 12:23 ` ian martins
2020-10-22 12:56 ` John Herrlin
2020-10-24 17:05 ` Kyle Meyer
2020-10-25 2:10 ` ian martins
2020-10-25 2:40 ` Kyle Meyer
2020-10-25 19:36 ` ian martins
2020-11-05 16:29 ` Jarmo Hurri
2020-11-05 17:10 ` ian martins
2020-11-06 5:21 ` Jarmo Hurri
2020-11-06 23:00 ` ian martins
2020-11-09 14:06 ` Jarmo Hurri
2020-11-10 13:14 ` ian martins
2020-11-10 6:29 ` Jarmo Hurri
2020-11-14 11:47 ` Jarmo Hurri
2020-11-14 15:46 ` ian martins [this message]
2020-11-15 4:36 ` Jarmo Hurri
2020-11-17 12:07 ` ian martins
2020-12-14 5:55 ` Bastien
2020-11-11 7:45 ` Bastien
2020-10-24 11:58 ` Bastien
2020-10-25 0:30 ` ian martins
2020-10-28 9:13 ` Bastien
2020-10-31 11:03 ` ian martins
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).