MATLAB Central Newsreader - The major problem with nojvm deprecation in R2008B and beyond (OS X only?)

The major problem with nojvm deprecation in R2008B and beyond (OS X only?)

First Last — Mon, 10 Nov 2008 18:58:02 -0500

I'm running a "server" machine (Mac Pro, OS X 10.5.5) and running MATLAB remotely from this machine via ssh and the command line.

In previous versions of MATLAB, I would run

matlab -nojvm -nodesktop

and still get graphics forwarding via X11 to the client desktop. Most importantly, I was able to manipulate handle graphics in order to change figures remotely.

R2008B gives the message that nojvm is now deprecated, which can be found officially here:

http://tinyurl.com/65bwuv [mathworks.com]

However, this is a huge problem for those of us who run MATLAB remotely on OS X machines and need graphics on the client. Specifying the -display switch doesn't work. Graphics simply aren't forwarded any longer of X11. Additionally, handle graphics do not appear to be supported. Is there a solution to this problem, or will there be?

Re: The major problem with nojvm deprecation in R2008B and beyond

Walter Roberson — Mon, 10 Nov 2008 20:33:04 -0500

First Last wrote:
> I'm running a "server" machine (Mac Pro, OS X 10.5.5) and running MATLAB remotely from this machine via ssh and the command line.

> In previous versions of MATLAB, I would run

> matlab -nojvm -nodesktop
>
> and still get graphics forwarding via X11 to the client desktop.

In theory, you should be able to use matlab -nodesktop -nosplash for that purpose,
I think. You might have to have JVM installed on the server.

In practice, we ssh -X in to a FedoraCore3 server and run matlab R2007a over X11
without difficulty, with or without desktop. However, for our Ubuntu server
with R2008a, using -nodesktop or -nodisplay does not allow Matlab to start up;
using it with the full desktop works okay in ssh -X mode though. I have a case
open about the R2008a requiring a display to run; Mathworks told me this morning
that they haven't seen that on any other machines.

--
.signature note: I am now avoiding replying to unclear or ambiguous postings.
Please review questions before posting them. Be specific. Use examples of what you mean,
of what you don't mean. Specify boundary conditions, and data classes and value
relationships -- what if we scrambled your data or used -Inf, NaN, or complex(rand,rand)?

Re: The major problem with nojvm deprecation in R2008B and beyond

Brian Arnold — Tue, 11 Nov 2008 02:11:11 -0500

Hi First Last at Nospam,

The -nojvm will cause an error when remotely connected (this has been
the case since R2007a). If you are starting MATLAB on a remote Mac
server, use -noawt instead of -nojvm, to continue using X11 Figures,
until deprecated support for non-native X11-based Figures becomes an
error in a future release.

We will always continue to support the command line interface (CLI) on
the Mac platform for remote connections, but in a future release, this
will no longer include Figure window forwarding through X11.

We need to make MATLAB a better citizen on the Mac for the majority of
Mac customers, and continuing to support X11 is contrary to that goal.
We intend for more and more of MATLAB to be Cocoa-based, either directly
or indirectly (through other frameworks which are Cocoa-based including
Java).

At some point between now and then, you will need to make some decisions to:

- use licenses that run MATLAB locally to leverage the
   benefits of the hundreds of UI features such as the
   Function Browser (new to R2008b), for a full desktop
   user experience;
- use Parallel Computing Toolbox and/or Distributed Computing
   Server to harness the full power of your Mac Pros or Xserves
   remotely, while retaining the full desktop user experience
   (this also scales as you add more hardware);
- use in-model UI-forwarding such as VineServer or Apple
   Remote Desktop for an acceptable desktop user experience;
- use MATLAB for Linux through virtualization on your Macs,
   for a limited-but-usable remote desktop user experience;
- wait for Apple to provide a miracle solution (other than
   Apple Remote Desktop), for multi-user context-forwarding of
   Cocoa-based applications (b/c that's where we are headed).

I realize that you have other options; these are the only ones over
which we have any degree of control, and believe to be acceptable paths
forward.

As a Mac user and a Mac developer, I hope you make the right decisions
for your environment, and that we are able to continue to serve you.

- Brian

First Last wrote:
> I'm running a "server" machine (Mac Pro, OS X 10.5.5) and running MATLAB remotely from this machine via ssh and the command line.
>
> In previous versions of MATLAB, I would run
>
> matlab -nojvm -nodesktop
>
> and still get graphics forwarding via X11 to the client desktop. Most importantly, I was able to manipulate handle graphics in order to change figures remotely.
>
> R2008B gives the message that nojvm is now deprecated, which can be found officially here:
>
> http://tinyurl.com/65bwuv [mathworks.com]
>
> However, this is a huge problem for those of us who run MATLAB remotely on OS X machines and need graphics on the client. Specifying the -display switch doesn't work. Graphics simply aren't forwarded any longer of X11. Additionally, handle graphics do not appear to be supported. Is there a solution to this problem, or will there be?

Re: The major problem with nojvm deprecation in R2008B and beyond

Walter Roberson — Tue, 11 Nov 2008 18:46:18 -0500

Brian Arnold wrote:
> We will always continue to support the command line interface (CLI) on
> the Mac platform for remote connections, but in a future release, this
> will no longer include Figure window forwarding through X11.

That's quite disappointing, to me at least. The effect is to force me to choose
between the reliability of a Mac and the usability of the application.
I don't have room on my desk for yet another monitor to be able to buy
a Mac to display "locally" (and I already have multiple feeds into my
monitor.)

When I buy a computer, reliability is a quite strong consideration: I have
wasted quite enough of my life already getting #$@$ PC hardware to work,
or rescuing MS Windows from its own follies.

It's like when I go to buy my glasses: when the optician says "You have to go
High Index lens at $750" (plus the frame) I say "Urk! Ulp, Okay then", because
I *need* my glasses to work well in order to get through life. Working with
low-reliability software and hardware is bad for my blood pressure and bad
for my mental state. My unix machine gets rebooted about 3 times a year
(pesky cosmic rays!); for my MS Windows PC it isn't uncommon to need to reboot
3 times just to install a single program :(

Thus when I next upgrade systems (and I'm overdue for an upgrade), if
Matlab isn't going to handle X11 off of Mac OS-X, then my question is
going to be, "Well, how about Octave or MathCAD ? Do they do enough of what
I need?" And if the answer is "Yes, they do", then Mathworks loses a sale
and I go for the Mac; if, on the other hand, Matlab did handle X11 off
of Mac OS-X smoothly, then the question of switching to another package
would not occur.

> We need to make MATLAB a better citizen on the Mac for the majority of
> Mac customers, and continuing to support X11 is contrary to that goal.

It is difficult for me to find an interpretation of that sentence under which
I would not consider the sentence to be incorrect. The closest I have managed
so far is that it might not be economically -feasible- to maintain dual support,
or that it might be a bunch of trouble to provide two different binaries, one
for X11 work and one for "native" work. But "contrary" to the goal? No, that
I am having a fair bit of difficulty with.

Re: The major problem with nojvm deprecation in R2008B and beyond

Walter Roberson — Mon, 10 Nov 2008 20:11:43 -0500

Re: The major problem with nojvm deprecation in R2008B and beyond

daniele — Fri, 23 Jan 2009 22:16:03 -0500

Brian Arnold <Brian.Arnold@mathworks.com> wrote in message

> At some point between now and then, you will need to make some decisions to:
>
> - use licenses that run MATLAB locally to leverage the
> benefits of the hundreds of UI features such as the
> Function Browser (new to R2008b), for a full desktop
> user experience;
> - use Parallel Computing Toolbox and/or Distributed Computing
> Server to harness the full power of your Mac Pros or Xserves
> remotely, while retaining the full desktop user experience
> (this also scales as you add more hardware);
> - use in-model UI-forwarding such as VineServer or Apple
> Remote Desktop for an acceptable desktop user experience;
> - use MATLAB for Linux through virtualization on your Macs,
> for a limited-but-usable remote desktop user experience;
> - wait for Apple to provide a miracle solution (other than
> Apple Remote Desktop), for multi-user context-forwarding of
> Cocoa-based applications (b/c that's where we are headed).
>

I wonder if this was told to my advisor before he bought the license for using matlab with through 5 remote connections to a MAC OS server. If this is a known issue it should have been clearly specified by the seller.