deprecated javacomponent and javaframe

Starting from R2019b we are warned that javacomponent and javaframe property will be removed.

This is a bad news for me (and I guess also for Yair and his wonderful blog).

I would like to open this thread so tips and tricks for replacement during the transition.

For example I use javacomponent to drag the file/folder on windows explorer into a GUI, not sure how I can do that when it will be removed.

[Rik]

Maybe that is an empty threat. You can run the code below to see a warning that has existed for years now (it was several years old already when I published maximize on the FEX).

figure(1),clf(1)
imshow(rand(300,300,3))
drawnow % Required to avoid Java errors
jFig = get(gcf, 'JavaFrame');
jFig.setMaximized(true);

output:

Warning: figure JavaFrame property will be obsoleted in a future release. For more information see the
JavaFrame resource on the MathWorks web site.

[Steven Lord]

That entry in the Release Notes includes a link to a page with some background information and a table of documented replacements for undocumented and legacy features. On that page you can complete an online survey if you have additional usage scenarios beyond the ones listed in the table.

[Bruno Luong]

Yes the list is here

Complete survey? Really? The first thing that kick a warning and draw my attention is the capability of drag/drop a file in the GUI figure and it's not in this list.

[Adam]

I make fairly heavy use of javacomponent via Yair's findjobj and uicomponent File Exchange submissions for embedding java UI components (mostly sliders and spin controls) into GUIs so the loss of this will break a large number of our GUIs in a major way.

I realise there are some good-looking slider and similar components for use with uifigures (these look more like the java ones which look miles better than the old Matlab sliders), but I don't see a range slider, which is one I use from java a lot.

I have written numerous reusable multi-components based on this (e.g. slider + spin control in a panel or java slider with some regular controls in an often-used combination), also utilising the GUI Layout Toolbox for putting together many of my UIs and as far as I know this toolbox does not support uifigures and related components so I guess it's going to be time for us to stop upgrading until we can sort out all the issues that will come from this.

The link the warnings point to basically just suggests uifigures. Maybe these support everything that old-style figures do now, but last time I tried to use them they still had fundamental functionality missing and you can't mix and match components with old and new figures obviously. I'll fill in the survey, for what it's worth, but since the linked page says it is too much work to keep supporting these functions it doesn't seem much worth bothering. So unless Yair has plans and ideas up his sleeve to allow things like uicomponent to still work without javacomponent it's certainly beyond my capability to fix!

[Guillaume]

I would suspect that javacomponent and co. get removed if/when guide gets removed. So I doubt it's going to happen in the very near future. Possibly, all figures would have transitioned to uifigures before then (I have no inside knowledge on any of this).

In theory, with the new uihtml added in R2019b, you can now do everything you could with old style figures. In practice, it's going to be a lot of efforts to transition complex controls. You basically need to rewrite old style java/activex controls in html5. On the other hand, that's the same transition that's been happening on the web, where browsers stop supporting java/flash/proprietary plugins, so we're not alone.

[Walter Roberson]

This discussion needs to be understood in the context that Oracle made big changes to Java licensing that make it expensive to continue to use Java. In theory each customer needs to license Java per desktop (and probably per VM) for all new Java releases, so Mathworks is effectively frozen in Java release, and the older releases are now only getting critical security patches.

You will find that a lot of vendors are getting rid of java. Oracle broke the market.

There were other concerns about Java, so there had been grumbling about it anyhow, but mostly not enough to push people off it except some high performance markets. The licensing change was the push that forced the issue.

[Xiangrui Li]

I thought uihtml in R2019b may make the file drag-n-drop easier. There are many example of code, like this one, working for web page. But when I tried it on uifigure, it won't accept the drop at all. Anyone knows if there is a switch to turn the drop on somewhere?

Edit: Here is the minimum code I tested:

<div id="dropZone" style="width: 120px; height: 100px; border: 2px solid red">Drop a file here</div>
<div id="textZone" style="width: 360px; height: 40px"></div>

<script type="text/javascript">
    var dropZone = document.getElementById('dropZone');

    dropZone.addEventListener('dragover', function(e) {e.preventDefault();});

    dropZone.addEventListener('drop', function(e) {
        e.preventDefault();
        document.getElementById('textZone').innerHTML = e.dataTransfer.files[0].name;
    });
</script>

Save the above as DnD_test.html into Matlab pwd. Open it in web browser, and drag and drop a file from OS file manager into the red box. The file name will show up, indicating DnD works.

In Matlab (R2019b+), load the html into a uifigure:

fig = uifigure('Position', [200 200 380 200]);
h = uihtml(fig, 'Position', [10 10 360 180]);
h.HTMLSource = './DnD_test.html';

When dragging a file into the box at uifigure, no-DnD symbol shows up.

[Martin Lechner]

Using "Using form input for selecting" from your mentioned HTML Rocks tutorial is working.

I'm no expert in HTML and JavaScript, but if I drop a file in your example somewhere in the browser window (out of your drop zone) the complete browser window is replaced by my content (only works in a browser, not in a Matlab figure). So I think this drag and drop support is disabled for this reason in Matlab UI figures.

Answer 1

[Yair Altman]

I am very sorry to say that I am not aware of any easy way to make the transition from a Java-rich GUI to uifigures. All the main UI components are available (and then more), but many customizations of the components that are possible in Java are missing (for example, Border, Renderer, Editor etc.) not to mention the 30+ Swing callbacks for mouse/keyboard/action events that make Java GUIs "come to life".

In addition, there are simply too many fundamental differences that [IMHO] would foil any automated conversion attempt. For example, uifigure [still] do not have toolbars, toolstrips, customizable icon, or non-pixel units (esp. normalized).

Moreover, the fantastic GUILT (GUI Layout Toolbox), on which many existing GUIs depend, still does not have a uifigure variant (the new grid layout/container fills much of the need but a one-to-one variant of GUILT would remove a huge amout of necessary rework).

The new uihtml and uistyle functions look good at first glance, but in fact provide only a limited solution. We [still] have no documented way to customize existing uicomponents with our own CSS and JavaScript code, nor the ability to apply project/figure-wide CSS templates and JS functions. I can certainly understand MathWorks for not willing to commit its new UI framework to specific technologies such as CSS and JS, but the end result is that users are severly limited in their ability to customize their UIs.

The bottom line is that [at least at the current time] it looks like users need to manually redevelop their uifigure GUIs. Even with this manual redevelopment, we are severly limited in the new uifigure's customization compared to legacy Java-based UIs. Hopefully these limitations will be resolved over time, leaving us with just the benefits of uifigures over legacy figures (there are many of those as well, don't get me wrong).

Nobody should really be upset about this: we all knew that using undocumented Java in Matlab GUI carried a risk and would not last forever. It worked well for nearly 20 years (and possibly for several more years in the future). This is longer than the lifetime of most tecnologies - How long did DOS programs live before they had to be redeveloped for Windows, then again for the web, then again for mobile? In fact, Matlab's Java UI lifetime may turn out to be longer than the future lifetime of uifigures, before we will need to redevelop our GUIs yet again to fit some future new technology.

Speculating about the future, I hope that MathWorks will make a gradual transition i.e., first remove GUIDE but keep Java GUI running, then (in a subsequent release) make uifigure the default figure type but keep legacy figures running, then (in another subsequent release) remove the Java dependency in all of Matlab but still enable legacy Java-based GUIs to run using either the built-in JVM or (when they stop shipping Java) a user-installed JVM. Such gradual steps will make the transition from Java to web-based UIs much smoother over time and will allow users enough time to (re)develop the UIs without time pressure. The business benefit to MathWorks will be that users will keep upgrading their Matlab release, avoiding the debacle of R2014b in which many users stopped upgrading and stuck with 14a since the new HG2 broke (or froze) their programs. Having said that, MathWorks has many business and R&D considerations that I am not aware of, so they may decide not to follow my suggested gradual transition path: we might discover that R2020a brakes all legacy Java GUI - I hope not, but I really have no idea.

[Bruno Luong]

Yair: "For example, uifigure [still] do not have toolbars, toolstrips, customizable icon, or non-pixel units (esp. normalized). "

UICONTEXTMENU is missing in UIFIGURE and AFAIK there is no easy workaround.

All that makes us still develop with GUIDE.

[Steven Lord]

FYI uicontextmenu is supported on uifigure starting in release R2020a.

[Walter Roberson]

@Yair Altman

After R2021b drops (presumably within the next three weeks), I would appreciate if you could update your remarks here based upon whatever becomes available with R2021b.

[Yair Altman]

@Walter Roberson As far as I can tell, the situation in R2021b is essentially the same as what I've reported two years ago, in my main answer above. There were indeed a few improvements to AppDesigner over this time period:

• 20a - uicontextmenu; uitoolbar; and uicontrol icons
• 20b - figure export; full axes support (finally!); some improvements to the AppDesigner interface; custom UI components; figure icon (finally!); and a few component properties
• 21a - uihyperlink; checkbox trees; keyboard control of ui components; some additional improvements to the AppDesigner interface; and a few component property changes
• 21b - small improvements to dialog popups and some uicomponents; some additional improvements to the AppDesigner interface

Unfortunately, IMHO the core limitations that I presented in my answer remain unchanged, namely:

1. it is still next to impossible to customize components using template-like CSS and JS code outside uihtml panels.
2. converting any non-trivial existing Java-based GUI to uifigures is such a difficult task that a complete re-write might be a better choice
3. multiple limitations, annoyances, inconveniences, and plain missing features of AppDesigner
4. missing Matlab equivalents of important Java-based controls and customizations
5. still no uifigure-based variant of GUILT for backward compatibility of existing code
6. inability to use plain-text mlapp files (e.g. upload custom text-files into AppDesigner; import panels from external files etc)
7. horendous performance of uifigures (time to appearance). [Note: performance used to be bad also for interactivity with the figure once it's already displayed, but this part at least has apparently been addressed and now seems ok. However, initial figure appearance is still terribly slow]

In the past year I tried [again] to create some not-too-complex apps using AppDesigner. In the end I got something half-way decent and usable UI, but it was a painful experience and the end result was still inferior in terms of performance, appearance and usability than a comparable Java-based UI that could have been created much faster. AppDesigner is much (much!) better than it used to be just a few years ago, but as of 21b it still has quite a lot of limitations, annoyances, and missing features that are required to create modern-looking GUIs; and the missing controls and customizations require UI comporomises that were not required with Java-based UIs.

Creating programmatic apps (without AppDesigner) avoids the AppDesigner limitations but also its benefits. With the improvements made in recent releases to AppDesigner I would no longer prefer programmatic UI creation over AppDesigner-created , so we are definitely going in the right direction.

But the bottom line is that IMHO we seem to still be far away from functional parity between the Java and web-based UIs, so I hope MathWorks won't pull the plug out for Java UI in the near future.

[Walter Roberson]

@Yair Altman

Thank you for the update and analysis!

[David Sampson]

Simple GUI Layout Toolbox containers work from R2020b. Flex containers work from R2022a. We hope to fix all remaining issues in Q1 2023.

https://www.mathworks.com/matlabcentral/fileexchange/47982-gui-layout-toolbox

Answer 2

[Martin Lechner]

Set the Icon of an uifigure

My colleague Andreas Justin had found a solution to get the webwindow of an uifigure (see the attached function). This solution don't throws the warning "Warning: The JavaFrame figure property will be removed in a future release." as the usage of mlapptools.getWebWindow(figWeb) does (see mlapptools).

This webwindows has the property Icon which can be changed by setting the path to a new icon (in Windows it must be an *.ico file).

% Web based Matlab figure (uifigure) -> webwindow is returned
figWeb = uifigure
ww = getWebWindowOfUiFigure(figWeb);
% set a new icon; on Windows systems it must be an .ico file
ww.Icon = fullfile(matlabroot, '\toolbox\matlab\toolstrip\web\image\uicontainer.ico')

Function to get the webwindow of an uifigure:

function webWindow = getWebWindowOfUiFigure(fig)
    % returns the underlaying webwindow of the given figure handle in case of an uifigure, otherwise it returns an empty
    % webwindow array
    %
    %%Example
    %{
    % standard Java based Matlab figure -> no webwindow is returned
    fig = figure
    ww = getWebWindowOfUiFigure(fig);
    assert(isempty(ww))
    
    % Web based Matlab figure (uifigure) -> webwindow is returned
    figWeb = uifigure
    ww = getWebWindowOfUiFigure(figWeb);
    assert(numel(ww) == 1)
    
    % change the figures icon
    ww.Icon     % returns the current path of the icon
    % set a new icon; on Windows systems it must be an .ico file
    ww.Icon = fullfile(matlabroot, '\toolbox\matlab\icons\file_open.png')
    ww.Icon = fullfile(matlabroot, '\toolbox\matlab\icons\webicon.gif')
    % "C:\MATLAB\R2019b\toolbox\compiler\Resources\default_icon.ico"
    ww.Icon = fullfile(matlabroot, '\toolbox\matlab\toolstrip\web\image\uicontainer.ico')
    
    %}
    figNameOrig = fig.Name;                   % original figure name
    figNameTemp = [fig.Name, tempname('$')];  % creaet a unique temporary figure name (in case of multiple figures with the same name exists
    fig.Name = figNameTemp;     % rename the figure in case of multiple figures with the same name exists
    drawnow
    ww = matlab.internal.webwindowmanager.instance.findAllWebwindows();
    webWindow = matlab.internal.webwindow.empty();
    for ii = 1:numel(ww)
        if strcmp(ww(ii).Title, figNameTemp)
            webWindow = ww(ii);
            break;
        end
    end
    fig.Name = figNameOrig;     % restore orignal figure name
end

Answer 3

[Xiangrui Li]

Some missing functionality are added gradually. After some test with R2020b, I can conform the following：

1. figure icon is implemented: hFig.Icon = 'fullFilename.png'
2. uicontextmenu is there, but I have not used it yet
3. print() won't work for fiie and clipboard export, but exportgraphics and copygraphics serve the purpose
4. uitable allows to select cell/row by code, as well as single row selection, although not documented
5. file/folder DnD can be done with some tricks

I just posted a simple code to do the file drag and drop to uifigure. Comments and suggestion are welcome.

Answer 4

[Mark Schoen]

MATLAB has been working to encompass the functionality of the Swing-based framework (including "javacomponent" and "JavaFrame") by adding a whole host of new functions and features. The following link lists some of the most common features you can now access as alternatives to Java Swing:

https://www.mathworks.com/products/matlab/app-designer/java-swing-alternatives.html

If you have additional "javacomponent" or "JavaFrame" usage scenarios not covered in the table in the link above, please complete the survey near the top of the page (orange box) to help us better understand your needs. The survey should only take 1–2 minutes to finish.

[Martin Lechner]

As Yair stated above, the main drawback of the new uifigures and apps is that there are no possiblities to add custom mouse/keyboard actions. The appdesigner already supports a context menu but a normal Matlab user doesn't have this possibility.

I think if Mathworks would use the appdesigner for developing all their GUI's without addionally tricks and enhancements the "normal Matlab user" would also be happy.

The above mentioned survey is more or less about missing components but there is still missing a lot of functionallity as state above. Mathworks should define what they have in minde to replace still missing features from the old style Java based GUI's (e.g. will be provieded in one of the next releases, not supported anymore).

For me very important features und functions are:

• mouse/keyboard/action events
• uicontextmenu
• no accellerators on buttons or other GUI components (only menu supports accelerators)
• customisation of the figure icon

[Bruno Luong]

Completely agree with Martin. Those four missing listed features prevent me to make transition to AppDesigner.

Incompatible between AppDesigner figure and normal figure is also a headache to handle. In GUI users do not need to care about what type of figure he/she plots.

[Jesse Hopkins]

Please please please address the 'keypressfcn' functionality in edit-box widgets if you haven't already. Unfortunately I can't find my old new-reader posts about this issue, but it goes way back to R14->R2007A udpate. In R14, it was possible to finagle edit-box keypressfcn callback to retreive the current string in the edit-box by toggling focus, thus was a way to validate input on each keystroke. (without toggling focus, the keypressfcn would only see the string since the last 'enter' press). That behavior was removed in R2007A and never came back AFAIK. Thus using built-in matlab capability there is no reliable means to get the current string in a edit widget, since KeyPressFcn only can see the text since the user last pressed 'enter'.

Since R2007A I've been using javacomponent to get at the 'KeyTypedCallback' and using the underlying java object to access the string property, which is reliably updated on each keypress.

If that goes away, please don't leave me stranded with no way to validate input on each keystroke!

P.S. I did submit a bug report on this issue way back when, and it is actually still in the system (00489099). The bug report is shown status "Bug/Enhancement Complete", but I never signed off on it! Still seems to be an issue in R2017B.

[Jesse Hopkins]

I'm pleased to learn that App Designer edit boxes indeed have a valid callback for each keystroke with reliable string values: ValueChangingFcn. Hooray!