!Java sources

Hi!

Do you have the sources to Acorn’s (IIRC unfinished) JDK 1.2 port? Now that Sun has released Java under the GPL, surely the Acorn version could be released as well?

Just because Sun have released sources under GPL that doesn’t change the licence under which acorn had rights when they produced the java port.

Of course not, but surely Acorn owned their RISC OS specific modifications to the sources provided by Sun? So if we could just get Acorn’s code, that might help us to port the current JDK to RISC OS.

I hate to pour cold water on the idea, but Acorn’s version was of crusty old Java 1.0.2. That’s two major revisions behind 1.2 (there was a 1.1 as well). I think I remember Pete Goodliffe saying that there wasn’t much that was reusable about the class libraries (that’s Acorn’s contribution) between different versions of Java. And to top it all, I’m not sure that Java was included in the sale of RISC OS from Pace to Castle (maybe not even Acorn to Pace). Development pretty much stopped about the same time as Phoebe, IIRC, and the sources were always kept separate from the rest of RISC OS.

The way I remember it, was that Acorn wanted to jump one version and go straight to Java 1.2 (renamed to Java 2 just before release, though the JDK version numbering remained). IIRC the reason was that the changes between Java 1 and Java 2 were so major, that most of Acorn’s class libraries had to be rewritten. However since then Java has not changed so drastically, so if we could somehow get hold of Acorn’s code, we might still be able so salvage some of it.

I think I might still have an alpha or beta version of Acorn’s Java 1.2 somewhere, I will have a look later and see what documentation came with it.

Morning, sorry for jumping on this very old thread – but I wonder was the source code for this ever found? Java 1.2 would be a game changer for Java use on Acorn as it would allow use of Swing, which is still one of the main GUI options on Java. I have a number of Java apps that could be ported fairly easily to 1.2.

Welcome Ian. There’s a thread here that concerns a recent port of Java, in case you missed it.

As Ben said quite a number of years ago, the source code was kept entirely separate from RISC OS. This was because it was always cross-compiled on Solaris, had long filenames, and lots of file extensions, not for any licensing reasons.

I thought that Pace did own the source code, but obviously not to Sun’s code. Element14 Ltd (not Inc) also retained a licence. I specifically asked about continuing the project at the time, and was told that permission could theoretically come from either party.

It’s correct that Acorn did jump straight from 1.0.2 to 1.2 Java 1.1 was skipped just because it would have been pointless, and Sun only certified builds for a certain period of time. Swing was happily running… painfully slowly, and not with a native look and feel. I don’t recall any beta releases, but it’s possible. It was very usable, but probably a long way off being certifiable, which would have been a requirement for any release.

I can imagine speed was an issue at the time, but with RPi and probably even Iyonix it would be usable today. I’ve run Swing reasonably on older PPC Mac’s with similar chip speeds.

I managed to get hold of an original copy of the original Java 1.0.2 CD. Installation looks a bit complex involving replacing the Boot folder, and swapping things around after reboots. Does that sound normal?

I honestly can’t remember. It needed the new Window Manager (for nested windows), and updated toolbox modules. Updating the Wimp needs to be done before the Wimp starts, so that’s probably the cause of the !Boot faff. Those have obviously been part of RO for years, so maybe the installation is easier now and that part may be irrelevant.

I’ve no idea if it runs on a 32-bit system (under aemulor). It’s unusual compared to other apps due to multithreading (OS_SetCallBack, I think), so it’s quite possible aemulor doesn’t support that well. It also had a JIT which would generate 26-bit code. I can’t recall if the “holey dynamic areas [batman]” were released (sparse DAs) – I certainly wrote the proof of concept, and it won’t use the RO4+ SWIs for that as it’s what influenced them.

It also did some amazing cunningness to make the C library thread safe, which could be incompatible with a 32-bit address space (it literally just compares the pc with the address of the SharedCLibrary, and triggers another callback if it is inside. It won’t work with qsort, so let’s hope that doesn’t keep state).