@Valeria – there is no “silver bullet” for this problem. It could be due to many different reasons. I suggest that you contact support@mathworks.com

@Michelle – Thanks for your follow-up. The items I listed above are a minor inconvenience rather than cause of actual grief… Perhaps the term “woes” in the title was an exaggeration. On the other hand, I rarely have a chance to use this term in day-to-day, and it had a nice ring to it, and article titles do need to attract the eye…

Anyway, running the pre-release exe directly from its bin folder doesn’t work. It’s the first thing I tried upon discovering that all my old Start-menu shortcuts have been deleted by the new R2011b installation. When you run the pre-release exe it simply launches the the new R2011b executable. I’m guessing that some important Windows registry key has been overwritten by the new installer. The bottom line is that while the PR is still “installed” on my computer, it cannot in fact be run. This is a moot point now, as the PR expiration date has now passed, but I think it should be investigated to determine whether there is any bug in there that could have a wider effect. For example, what happens when we get a service-pack release as last year? – will the original (“SP0”) not be accessible any longer? If so, this could be troublesome. Let the user decide if they want to overwrite the existing version or not. Matlab users are smart enough to design rockets and cars, surely they can manage this decision.

Path – I am not sure why this happened. Perhaps because of the pre-release vs. Prod versions mixup that caused the previous issue.

Bootstrap loader: we’ve seen this issue occasionally, too. We’ve made sure that the development team knows that it’s still happening.

Installing Japanese doc: We are aware that this is unnecessary and hope to be able to address it to reduce download sizes/times for our users.

Running prerelease after installing general release: I’m not sure what issues you are finding here. Our installer doesn’t touch the existing prerelease installation when installing the general release. We do point the operating system to the latest release, so that shortcuts, add/remove programs, etc. find the latest release. You should be able to run the prerelease by running MATLAB.exe directly from the bin dir (or making a new shortcut to it).

path: I’m a bit puzzled about your path issue, too. We don’t migrate path from release to release (this is actually something I’d like to see changed), so the only way I see this happening is if you have your new MATLAB intentionally pointing to your old pathdef.m. The default locations for pathdef.m are in release-specific folders. I’m sure I’m missing something, so please clarify if I am.

For people who need to update or reinstall Matlab frequently, it may be useful to create their own “checkinstall.m” script. Some of my toolboxes have such a checkinstall.m, mainly to check/fix missing or interfering path extensions, pathdef, classpath etc in case that the toolbox needs M-files, MEX-files or libraries elsewhere on the path, but also to setup/clear persistent and global variables and doing some set(0,’Default…’,stuff). However, I did not yet need a global checkinstall.m for Matlab itself, and I did never go so far and copy/move/delete or dynamically rewrite critical files on hard disk automatically (see, e.g., savepath.m, update_toolbox_cache.m). Since my checkinstall.m files are all highly project-specific, it would not make much sense to upload them anywhere. The point I want to make here is:

It can save lots of future work to copy+paste some code from matlabrc.m, hgrc.m, pathdef.m, classpath.txt and others, learn about the ressources used there, and remix all this to create your own checkinstall.m, init.m, startuser.m or whatever you may call it. Of course, one can also edit any toolbox/local/*.* file directly, at least if it does not make one mad to fix a dozen of core Matlab files manually twice a year, always taking care that nothing important gets lost. Hence, I would always try to fix setup issues by user/project specific path automation scripts which are executed only on demand.
Neverthesess, I always found it quite conclusive to load the matlabrc.m and alike functions into an editor and compare them with older versions. Changes in these functions may reveal more about new features than one would find in the official Matlab release notes.

Of course, the above recommendations are clearly a matter of personal taste, and some issues are definitely awkward to solve by purely project/toolbox specific scripting. But finally, although a manually or automatically patched Matlab installation may be much more convenient and performant on the programmer’s single-user machine, one should never forget that such tweaks can easily turn into severe flaws: (1) My M-code may possibly not run as intended on other systems; and I suppose most customers won’t like me to tell them that something is wrong with their Matlab/Java. (2) After pimping my Matlab, how could I even test whether my code is still suitable for other users?

I hope I made clear that I do not citicize but rather appreciate anybody who thoroughly investigates and understands post-installation issues, specifically those who know where fixes are mandatory, optional, or even dangerous. However, take care!

Just in case you missed it:

% similar to your findjobj.m
com.mathworks.xwidgets.desktopexamples.UIExplorerDesktop.main(''); 

% amazing! just amazing
com.mathworks.xwidgets.desktopexamples.EventViewer.main('');

com.mathworks.xwidgets.desktopexamples.SystemPropertyViewer.main('');

% I would love to have such UI control
com.mathworks.xwidgets.treetableexample.TreeTableExample; 

(run line-by-line; beware, closing some of those windows shuts Matlab down)