REST with RISC OS?

In my daily job I am developing webservices using Java which use the (Representational state transfer) a lot. RESTful webservices are used quite a lot on the internet and I wonder whether there is a way to communicate with REST webservers from RISC OS. I know that there is no current Java implementation but maybe there are C-libraries that could be used? Is it true, that GCC for RISC OS supports C#? I ask because C# is in some way similar to Java and has REST libraries available. Easy handling of JSON objects would be very welcome, too.

Short explanation: REST is often used for the communication between a website running in your browser and an internet server. If there is a programming language / framework supporting REST it would be possible access the webservice features from a program instead of a browser. This is important if we ever want to see desktop clients for cloud services (dropbox, photo storage, translations for example – there are other critical point like authentification which have to be solved as well, also the API of such webservices can be quite complex).

From HTTP it’s just POST, GET, PUT, etc.
So it should be possible, even from Basic.
Curl can help.

There are also many examples in C. Like this one:
https://gist.github.com/nolim1t/126991

GCC does not support C#, not on RISC OS and not anywhere else. There once was some movement to port Vala to RISC OS (which is similar to C#, and the compiler translates Vala to C and should be easily portable), but I think nothing came off it.

Someone could of course start porting Roslyn :-)

GCC does not support C#

True. On the other hand, C# or Java is not (at all) needed for REST calls.

There are also many examples in C. Like this one:
https://gist.github.com/nolim1t/126991

An example like that is a bit too simple to be useful in the general case. Most REST APIs will need the client to support a wide range of different technologies – HTTP and SSL for the transport (and ideally gzip as well to minimise bandwidth usage), UTF-8, XML, JSON, etc. for representing data, OAuth, JWT, etc. for authentication, different date/time formats, etc. It’s the kind of thing where you’ll want to be using off-the-shelf libraries for handling a lot of the grunt work, rather than attempting to build everything up from scratch. You can even use code generators to create client libraries from API specifications (to take the pain out of writing and maintaining your own definitions for the different data structures and request parameters)

C/C++ is likely to be your best bet. riscos.info has at least a few useful packages (although one of my bug-bears is that their package listing doesn’t show when the package was last built), and for any plain data processing libraries you can probably compile them pretty easily via the GCCSDK autobuilder.

This is where a working java implementation would be handy, of course.

Get java running and you’ve access to the multitude of freely-available libraries that do all of these things. You also get Groovy, which makes them all instantly scriptable, too.

This is where a working java implementation would be handy, of course.

Fading fashion. I’ve lost track of the number of applications that have been ditched or re-written without Java because the version specific elements caused so many problems.
You’ve seen lot’s of comments about NHS systems and legacy requirements I’m sure. The biggest cause of those legacy issues? Java.

I see that comment a lot and it always makes me laugh. It’s about as much a fading fashion as COBOL has been for the last 20 years, and for much the same reasons – Java will be around a long time, due in no small part to the sheer volume of enterprise code both in existence and still being written. Banks, insurance companies, telecomms companies – they’re all heavily invested. And that means everyone else is, too

A decent JVM will support far more than just java, as well: like these

Don’t be fooled into thinking java’s going anywhere anytime soon. If you want easily accessible cross-platform code without having to massively re-work it all yourself, it still is (and will be for some time to come) the obvious answer.

And the ‘version’ argument is not one I tend to buy, it’s usually trotted out to try and hide the fact that they’re trying to run a decade-old unmaintained piece of software on new hardware and OS. Even in that instance, java is usually far less effort than compiled C to remedy.

Fading fashion.

Maybe Java is no longer fashionable, but usage is surely not fading, but expanding. Especially if you think about all the JVM languages like Scala, Kotlin and Groovy – after all, “get java running” includes all these languages.

I have also not yet heard about Android’s popularity fading…

I’ve lost track of the number of applications that have been ditched or re-written without Java because the version specific elements caused so many problems.

It is quite hard to write version specific Java applications. Developers who have mastered that skill will easily write version specific code in any language.

You’ve seen lot’s of comments about NHS systems and legacy requirements I’m sure. The biggest cause of those legacy issues? Java.

Surely not the “cause”.

Anyway, having a full Java implementation for RISC OS would be great to fill many of the gaping holes of RISC OS software. But it is certainly no small effort, although Oracle now has a rather powerful virtual machine on ARM as part of OpenJDK, which is a major step forward compared to the JamVM alternative.

And the ‘version’ argument is not one I tend to buy, it’s usually trotted out to try and hide the fact that they’re trying to run a decade-old unmaintained piece of software on new hardware and OS.

Actually it’s “trotted out” when you have users that need access to two different apps where one has a dependency on a legacy “feature” that no longer exists in newer versions because the “feature” was actually an undocumented item that was plugged when the security flaw was fixed and the other app needs a whizzy new feature thus the two are incompatible.

Surely not the “cause”.

In as much as the feature aspect above is the cause of incompatibility and said incompatibility causes problems in moving installs onto current release OS.

So to modify your statement: not the cause, but one of them and a major one.

Actually it’s “trotted out” when you have users that need access to two different apps where one has a dependency on a legacy “feature” that no longer exists in newer versions because the “feature” was actually an undocumented item that was plugged when the security flaw was fixed and the other app needs a whizzy new feature thus the two are incompatible.

So you are running unmaintained software. Surely not a good idea, and surely not “caused” by Java. Countless Windows applications stopped working with any security related Windows fix.

Actually, with Java, you can still deploy multiple versions on the same machine without problems (unless you need applets of course, then it gets “interesting”), so it is better in running legacy stuff than the OS itself.

Maybe we should take this discussion to Aldershot…trying to get back on topic: having Java available on RISC OS would be really great, not only for ease of REST use!

Actually, with Java, you can still deploy multiple versions on the same machine without problems (unless you need applets of course, then it gets “interesting”),

Yes, “interesting” is definitely the word. Like the Chinese curse.

having Java available on RISC OS would be really great,

I think it would be “interesting”

Like I said – porting of a jvm would likely be no small task, but would give you access to a number of languages, and a massive library of pre-written and supported software, most of which would require no porting work whatsoever. And part of that massive library gives you web servers, IDEs, office apps (and REST libraries, to bring this back on topic)…

Having old software not work with newer systems is really not a java problem. If anything, it’s significantly less of a problem for java than most, given how easy it is to decompile and fix (in the worst case, far simpler than that in most cases). And because the runtime’s level of backwards compatibility is generally far greater that that of, for example cLib. To bring up software using undocumented features as an issue seems a tad odd when you look at the zeropain/high vector stuff as an example on here. Or some of the assembler tricks used over time.

Got a breaking change between two JVMs and a specific need for both? Then install them both on the system and set JAVA_HOME for each app. Job done.

APIs and ABIs change. And those changes may break existing compiled software and/or codebases. Java’s not immune from that, but it’s definitely not the worst offender.

Just out of interest, does Java expect a POSIX compliant world?

Nope. There are (I believe) specific java functions you can use to detect POSIX compliancy, so you can code accordingly.

There are JVMs for Amiga, Arduino and even drop-in firmware replacements for Lego Mindstorms – if that’s possible, surely RISCOS must be…

I believe the Arduino one runs in something like 8K, so it’s not going to be a full JVM. There are numerous incarnations of Java (ME, SE, and some others I can’t remember), plus varying levels of support – I doubt the Mindstorm will be capable of running Eclipse, for example. Plus there’s apparently a 32 bit / 64 bit divide lurking as well?

That said, I do wonder why there hasn’t been any JVM for RISC OS since Acorn’s sort-of-maybe effort way back when. Because it seems to me that asides from a little bit of intelligence (garbage collection etc), it’s basically an emulator for an invented architecture is it not?

Yes, Java is partly an emulator for a fake architecture, but also there is the vast class library functionality.

I seem to recall Acorn’s effort being a Java 1.0.2 VM and they had an in-progress version of 1.1 (including Swing). One or both of these versions had a JIT compiler, too.

Same sort of thing as C# and .net (that is essentially a Java clone)

That said, I do wonder why there hasn’t been any JVM for RISC OS since Acorn’s sort-of-maybe effort way back when.

For a long time, there was just no suitable codebase to get ported – open source efforts had little compatibility with “the real thing” (SableVM, Keffe, the GNU Classpath project and GCJ…) and were at least one major version behind. There was SableVM for RISC OS, but it was never close to complete. I am not sure how far Peter Naulls got with Chockchino, which was announced as a clean-room Java 1.1 implementation (which would have been perfect for late 90s browser applet stuff). Sun always provided versions for Windows, Linux and Solaris, and IBM catered for AIX and zOS, and Apple for MacOSX. So there was little need for a true open source alternative.

Nowadays, there is OpenJDK, but the platform got soooooo big, that porting is again very hard. And: Java is trademarked, so you can’t even call your Java port “Java”…

Acorn’s 1.0.2 was quite good, though – complete AWT implementation (based on the toolbox – I guess the initial round of toolbox gadgets was specified as “we need at least everything AWT has”), and for an interpreter quite nippy. The 1.2 prereleases featured a JIT, but it was early days, and unfortunately Acorn folded before 1.2 was finished.

And: Java is trademarked, so you can’t even call your Java port “Java”…

Yes, those serial patent trolls fired a sueball at Starbucks, which is funny given that in the mind of a geek, caffeine definitely came first…
I’m surprised they haven’t tried suing the island – just think, 140 million instant patent infringers. Imagine the royalties…

OpenJDK for embedded ARM (v7 and AARCH32) systems exists – I take it that’s still a long way from being something that could run under RISCOS?

Download it here…

And I guess the licensing will always be something to watch out for…

The main problem with using Java as a gateway to a large collection of software is the amount of effort needed to provide a standard library implementation that third party applications can depend on. The most obvious part of this is the GUI library that applications will use. As already mentioned, Acorn added AWT support, but my impression was that no self-respecting developer would use that, choosing to use something like Swing instead.

Those applications may also rely on accessing platform-native features to perform some tasks, possibly via JNI. Maybe some Java-heads here can describe the ins and outs of doing this and what it would require from RISC OS to make it work nicely. I’ve only ever done Java stuff on Android (which has it’s own set of peculiarities) and even there I don’t actually write code in Java.

AWT is still the base for Swing as it provides access to the platform’s native windows and dialogs (the so-called “heavyweight components”). So without AWT no Swing. In Acorn’s Java 1.2 beta, Swing worked to an extent. Nowadays, you need to implement the quite complicated Java2D stuff more or less completely for a good Swing experience, but abstraction got a lot better starting with Java 7 (project Caciocavallo).

Come to think of it, there is a great toolkit named Webswing, that provides a kind of remote desktop to run applets on the server und show it’s UI in the browser – it contains its own AWT Toolkit implementation, maybe this could be used for a first quick shot at “RISC OS Java”.

There is a bit of system specific stuff in JDIC aka “Java Desktop Integration”, but this is a very thin abstraction to e.g. control the system tray (which RISC OS does not have) or open the system’s default browser or mail application, which would be easily implemented.

If you want SWT (for Eclipse), you need to implement the whole native stuff anyway, and it would be interesting to see where the SWT abstraction would not work well with the ideas the WIMP has. Same would be a project to provide a RISC OS Pluggable L&F for Swing. Acorn Java had a shot to automatically convert AWT menubars into WIMP popup menus, but it only worked to the extent that the AWT application software did not assume too much.

At the end of the day, it would be great if one of our porting experts could have a look at the current OpenJDK to see how much native stuff there is to get ported. And if the Zero VM and/or JamVM are reasonably easy to port to RISC OS – I could imagine that threading would be a headache, and absence of a good JIT might make things a bit slow.

I thought it was the other way round – SWT was a wrapper around native objects (with low-level implementation where native objects don’t exist), but Swing was entirely a low-level implementation, so no AWT required?

(I use java and groovy a lot, but generally either writing server-side batch jobs or messing about with my own homebrew spring-based webapp, so not so familiar with this stuff)

I’m surprised they haven’t tried suing the island –

As the Island has been around and named for a long time imagine if they counter sued.