jabref doesn't start with my JavaVM of choice

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in jabref.
For future reference you might be interested to know that a lot of applications have bug reporting functionality built in to them. This can be accessed via the Report a Problem option in the Help menu for the application with which you are having an issue. You can learn more about this feature at https://wiki.ubuntu.com/ReportingBugs.

On Fri, 15 Aug 2008 17:22:14 -0000, Launchpad Bug Tracker wrote:

[Disclaimer: I'm the maintainer of JabRef in Debian. I'm not
responsible for the package in Ubutnu, but the wrapper script you are
referring to is from me.]

> The JabRef package selects the JavaVM itself:
[..]
> test -n "$JAVA_HOME" && JAVA=${JAVA_HOME}/jre/bin/java
> fi
>
> export JAVA=${JAVA:=java}
>
> exec $JAVA -cp /usr/share/java/jabref.jar:/usr/share/java/antlr.jar:/usr/share/java/antlr3.jar:/usr/share/java/looks.jar:/usr/share/java/forms.jar:/usr/share/java/spin.jar:/usr/share/java/glazedlists.jar:/usr/share/java/microba.jar:/usr/share/java/pdfbox.jar:/usr/share/java/jempbox.jar net.sf.jabref.JabRefMain "$@"
[..9
> I expected it to pick the VM I've selected with update-java-alternatives.

You can us it with other JVMs if you set $JAVA_HOME.

The reason for the decision to look for specific Java VMs is
(1) in my experience JabRef only works with sun-java and openjdk
(2) I've received a couple of bug reports before I changed the wrapper
    scripts, which where caused by having the alternatives system
    point to some other JVM, and I got a bit tired of explaining
    to all of the bug reporters that they have to choose sun-java via
    update-alternatives.

In the Debian BTS I would take this bug "wontfix" but I leave the
manipulation of the bug in Launchpad to the Ubuntu guys.

Cheers,
gregor
--
 .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' : debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `- BOFH excuse #421: Domain controller not responding

Hey,

On 15.08.2008 20:41 gregor herrmann wrote:
> You can us it with other JVMs if you set $JAVA_HOME.
>
I've already set my VM with update-java-alternatives.

> The reason for the decision to look for specific Java VMs is
> (1) in my experience JabRef only works with sun-java and openjdk
Couldn't you detect those while starting and issue a warning then? I
don't think plain ignoring of the users will is a good direction to move to.

> (2) I've received a couple of bug reports before I changed the wrapper
> scripts, which where caused by having the alternatives system
> point to some other JVM, and I got a bit tired of explaining
> to all of the bug reporters that they have to choose sun-java via
> update-alternatives.
>
There should be documentation for that anyway...
If you detect a "wrong" VM you maybe could even provide the necessary
command to switch the VM. But I think fixing those bugs would be the to
way go anyway.

> In the Debian BTS I would take this bug "wontfix"
I'd rather discuss it first ;-)

Cheers,
   Muelli

On Fri, 15 Aug 2008 23:21:45 -0000, Muelli wrote:

> > The reason for the decision to look for specific Java VMs is
> > (1) in my experience JabRef only works with sun-java and openjdk
> Couldn't you detect those while starting and issue a warning then? I
> don't think plain ignoring of the users will is a good direction to move to.

Actually JabRef itself (not the wrapper) issues a warning.

> > (2) I've received a couple of bug reports before I changed the wrapper
> > scripts, which where caused by having the alternatives system
> > point to some other JVM, and I got a bit tired of explaining
> > to all of the bug reporters that they have to choose sun-java via
> > update-alternatives.
> There should be documentation for that anyway...
> If you detect a "wrong" VM you maybe could even provide the necessary
> command to switch the VM.

There is documentation at /usr/share/doc/jabref/README.Debian (and I
just saw that it's outdated -- oops).

> But I think fixing those bugs would be the to
> way go anyway.

Sure, but neither upstream nor someone else has yet figured out how
to make it work with other JVMs.

> > In the Debian BTS I would take this bug "wontfix"
> I'd rather discuss it first ;-)

After discussion, of course :)

BTW: Which JVM are you using?

Cheers,
gregor
--
 .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' : debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `- BOFH excuse #373: Suspicious pointer corrupted virtual machine

There is a document in /usr/share/doc/jabref/README.Debian, but it does not mention $JAVA_HOME.

Hey :)

On 16.08.2008 02:06 gregor herrmann wrote:
> Actually JabRef itself (not the wrapper) issues a warning.
>
Sounds good, doesn't it?

>>> (2) I've received a couple of bug reports before I changed the wrapper
>>> scripts, which where caused by having the alternatives system
>>> point to some other JVM, and I got a bit tired of explaining
>>> to all of the bug reporters that they have to choose sun-java via
>>> update-alternatives.
>> There should be documentation for that anyway...
>> If you detect a "wrong" VM you maybe could even provide the necessary
>> command to switch the VM.
>
> There is documentation at /usr/share/doc/jabref/README.Debian (and I
> just saw that it's outdated -- oops).
>
So if there's a good documentation, you shouldn't get tired ;-)
I think that if the warning even provides a copy&paste (or even a
clicky-) way to change the VM, there is no need to force the user to do
smth he doesn't want, i.e. he has selected his iced-tea VM and wants to
use it. Besides that, it just feels braindead to setup your Java
environment more than once with different mechanisms.

>> But I think fixing those bugs would be the to
>> way go anyway.
>
> Sure, but neither upstream nor someone else has yet figured out how
> to make it work with other JVMs.
>
What a pity. I wonder it doesn't work out of the box with different VMs,
but that's not the topic here.

> BTW: Which JVM are you using?
>
Back in the time, when I recognized that bug, it was iced-tea-java-7
IIRC, though I didn't install it on purpose. Now it's gone with some
update and I think it's the "normal" sun-vm...

Cheers,
   Muelli

On Sat, 16 Aug 2008 00:15:47 -0000, Benjamin Drung wrote:

> There is a document in /usr/share/doc/jabref/README.Debian, but it does
> not mention $JAVA_HOME.

Right, I'll add it soon.

Cheers,
gregor

--
 .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' : debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `- BOFH excuse #367: Webmasters kidnapped by evil cult.

On Sat, 16 Aug 2008 00:35:53 -0000, Muelli wrote:

> > Actually JabRef itself (not the wrapper) issues a warning.
> Sounds good, doesn't it?

It does -- for users who start it at the command line ...

> > There is documentation at /usr/share/doc/jabref/README.Debian (and I
> > just saw that it's outdated -- oops).
> So if there's a good documentation, you shouldn't get tired ;-)

Ack.

> > Sure, but neither upstream nor someone else has yet figured out how
> > to make it work with other JVMs.
> What a pity. I wonder it doesn't work out of the box with different VMs,
> but that's not the topic here.

Well, I'm wondering about several things in java-land ...
But wih penjdk we have a free and working JVM in both Debian and
Ubuntu now.

> > BTW: Which JVM are you using?
> Back in the time, when I recognized that bug, it was iced-tea-java-7
> IIRC, though I didn't install it on purpose. Now it's gone with some
> update and I think it's the "normal" sun-vm...

Ah, I see.
icedtea was replaced by openjdk, therefore I've changed the wrapper
script.

Cheers,
gregor
--
 .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' : debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `- BOFH excuse #298: Not enough interrupts

Like Gregor suggested I set the status to won't fix. The issue with the outdated wrapper script is fixed in Debian and merged to Ubuntu intrepid. So there is no need to keep this bug open, isn't it?

This bug was fixed in the package jabref - 2.3.1-6ubuntu1

---------------
jabref (2.3.1-6ubuntu1) jaunty; urgency=low

  * Merge from Debian unstable. (LP: #301224)
  * Remaining Ubuntu changes:
    - debian/control
      * Change build dependency default-jdk-builddep to default-jdk.
      * Modify Maintainer value to match the DebianMaintainerField
        specification.

jabref (2.3.1-6) unstable; urgency=low

  * debian/watch: back to the redirector at qa.debian.org.
  * Use java-wrappers instead of the hand-crafted wrapper script; thanks to
    Vincent Fourmond for the patch (closes: #506219).
  * Update README.Debian: mention supported Java virtual machines and
    JAVA_HOME (cf. LP: #258198).
  * debian/rules: set JAVA_HOME=/usr/lib/jvm/default-java.

 -- Onkar Shinde <email address hidden> Sat, 22 Nov 2008 21:01:02 +0530