Java User-Interface Client (JUICe) libraries 5r10

These are of interest to anyone using Java to write Swing-based graphical user-interface (GUI) apps, especially client ones.

JUICe Cmds
classes intended to make it easier to write GUI commands (to be invoked interactively)
JUICe Alerts
classes for displaying values using JComponents which can flash and beep
JUICe Application-Framework*
classes intended to be used as the framework of the app itself, and designed to allow the same code to be run either as an application or an applet. Note that this package is dependent on the Cmds one (whose classes must be in the Java classpath), and provides an interface to the Alerts one (whose classes, as of version 4.1.0r3, need only be in the classpath if they are utilised by the app itself).

Please see the JUICe API (javadoc) documentation for further details.


demo screenshot


Automatic project-creation using Maven 2

Incorporating JUICe into an existing Maven 2 project


Change log

N.B. In the interests of having a clean API (and until people start to complain!), we reserve the right to make changes which are liable to break dependent apps.

5r10: ~.cmds: ICmd.execute() now throws Exception, not Throwable; ICmdsApp.postFailed(..) now takes Exception, not Throwable; command thread now recreated after being stopped by applet container

5r9: ~.cmds: IExe, IExe.ITog renamed Exe, Exe.Tog (since not intended to be inherited by app classes); IAppContext renamed AppContext (for same reason)

5r8: ~.cmds: Exes.getExe(..) deprecated in favour of new Exes.newExe(..)

5r7: ~.cmds: TheCmdsApp.clearLastPost() now called if an ICmd.IDisj.execute() returns null

5r6: TheApplication.loadJUICeResources() now effective, should start(..) be called from a different thread; jarfile names lose the 'core-'

5r5: 5r4 changes undone--TheApplication.loadJUICeResources() added instead; ~.alerts/~.cmds: TheAlerts/CmdsController.loadResources() becomes loadJUICeResources()

5r4: now ensures resources correctly loaded from JUICe jarfiles if security manager set in IApp.displayApplication(); ~.alerts, ~.cmds: TheAlertsController, TheCmdsController gain static loadResources() methods, in support of the above

5r3: ~.cmds: ICmd toString() now used to initialise Action.NAME, Action.ACTION_COMMAND_KEY; AbstractApp.setProperties() added

5r2: ~.cmds: focus now restored after applet dialogue boxes dismissed (at least on macs!)

5r1: applet's destroy() now tidies up; IApp (AbstractApp) replaces TheAbstractApp

4r8: ~.alerts.AlertPanel bug-fix: now revalidate() after add()ing an alert. (Not required by JREs used when testing previous releases!)

4r7: ~.alerts.MonLabel, TimeoutLabel back to using composition, in the interests of flexibility; have to add these by hand, but can still add their component JLabels using the GUI-builder; MonField becomes TitledLabel, but continues to extend JLabel

4r6: all classes involving JComponents now using inheritance rather than composition, so as to promote their use with GUI-builders; ~.alerts.MonField replaces RowMonField, ColMonField, IMonField

4r5: subclasses can now override started() to invoke something after the app has started (as opposed to during initialisation), and must now override stopApplet() and restartApplet() instead of stop() and start() respectively in the applet case; ~.cmds 4.2.0r2 bug fixed (affecting 'ICmd Combination' demo); ~.cmds.ICmd.ITog added--see new 'ICmd.ITog Toggle' demo; ICmd.IDisj cancellation behaviour improved

4r4: ~.cmds.Exes.getExe(ICmd, ICmd, boolean) added; may now be used in the absence of the ~.alerts classes; ~.cmds.ICmdsApp.postSucceeded() no longer called, if ICmd.execute() returns null; setRootComponent(Component) added to ~.cmds.TheCmdsController, allowing dialogue boxes to be centred wrt app's main window; missing tooltips added

4r3: ~.alerts.AlertPanel API change!

4r2: ~.cmds.ICmd.execute() now returns String!

4r1: command and alert-specific classes now in separate packages; etc.

Please see the API documentation for a more detailed log.