Hi Guys,

Got a bit of a strange issue here that for the life of me I cannot solve, everything I have read seems to point to me doing the right thing, but I always get the same error.

I have written my own JVM for use on our product, I have this working pretty well, I still have a few bits to finish up, but it's looking good.

Now I'm trying to create some native classes to allow access to hardware & peripherals on our product, so I need to create packages, and for the life of me I cannot get them to work.

I am on OS X El Capitan with the latest JDK that I downloaded from oracle.

And for example, I have the following structure:


in test.java I have at the top


and in mike.java I have


I generated the class files using:


and that created the folder structure and placed the mike.class in the appropriate folder, all great so far....

But when I come to compile test.java I get:


if I try (which I believe is wrong anyway, but seeing as nothing else was working it seemed worth a try):


I get the same error, no matter what I do it always thinks that it cannot see the kestrel folder. I've spent hours reading the net and looking at examples and they appear to be doing the same as me and they apparently work.

Any idea what I am doing wrong? Am I misunderstanding something?

The first question is to sort out what directory you're in (i.e., what's "."?). For what it's worth, I've now got all 140 of my sophomores working with Gradle, wherein you lay out your files in a standardized setup and then you can just type something cute like gradlew test and it will compile your code to a separate "build" directory and then run all your unit tests for you, reporting the failures. Very slick.

Thanks for the reply, I was writing out a response when I finally realised what I was doing wrong. I've sat here for ages looking at this and couldn't spot it.

The issue is that the import statement should have been:



to import all classes, the error it was giving me was completely correct, package kestrel didn't exist because there was no class called io!

My brain is frazzled.

Now that I've solved the initial import, it's now parsing mike (I can see that if I turn on -verbose) but it's complaining that it can't find the mike class, so I've done something else stupid.

First hurdle over though.

I'm using javac by hand because our software tool which allows app development and test on simulated hardware is the IDE for app development (currently we make use of a much simpler virtual machine which is starting to make application development harder for people).

It's running on a very constrained microcontroller and I've implemented some of the most useful classes directly in 'C' for performance and saving of RAM. I realised that using javac with some of the other options I can remove all the bootstrap classes, so I can use our inbuilt implementations with stub classes in the SDK.

Many thanks, if it wasn't for your response I wouldn't have just realised my mistake!

All solved!

Works like a charm.

Well, that's all good then. You might still want to check out Gradle. Among other things, I've been impressed by:

- The built-in support for CheckStyle. Add one line to the build.gradle file, and now I can run "gradle checkstyleMain" and it will make sure my Java code (and my students' code) is properly formatted based on a super-vicious spec that I provide for them (in another file in a standard location).

- IntelliJ notices if you've got a build.gradle file and offers to import your project as a gradle project. It will then run the Gradle actions itself when you hit the "run" button. Totally seamless.

Thanks, I'll take a look. Does grade support some sort of XML output for build logs? In other words, can I use it to make my life easier when parsing compiler output?

I implemented threads in my JVM yesterday, I have a few opcodes left to implement but they're simple ones and are going to be a cut and paste of other things. Also implemented the garbage collector as well.

I should point out, that I'm extremely limited, the heap (and heap manager) is set up for 20 kilobytes, so when I say it's for use on a constrained system it really is. (Although it is an STM32 running at 160Mhz)

I have a lot of stuff going on, RTOS, USB stack, Bluetooth stack, modem stack, GPS, our own IO peripheral system not to mention the current VM which is going to be replaced and finally the DSP section which is a what the product is all about.

I've still got a load of RAM free, so will take more of that for the JVM at a later stage.

Gradle looks simple, but a Gradle build file is really a program in the Groovy programming language, so you can get all sorts of complicated with it. As an example, for my Android projects, I've got some Groovy code that calls out to Git to extract some version names and strings (based on the most recent git tag).

If you need output in some particular format, you can probably swing it. The real fun comes from all the plugins where somebody has already done the heavy lifting for you.

So you're building a teeny tiny JVM? Interesting. Sounds like you don't have much space for any sort of compiler on the platform. Have you thought about doing an ahead-of-time compiler, so all you're running on your tiny platform is native machine code + the runtime system?

Ahh, ok, I was trying trying to be lazy and avoid having to parse stdout! It sure would be nice if compilers handled their output as XML and then formatted it to text by default!

Yeah, it's a tiny JVM. My main aims are to ensure that it's "crash proof" and that it checks that any pointers used internally only point to addresses inside the JVM heap, obviously we have our own IP in our product that we don't want people accessing by buffer overflows etc.

This obviously has an impact on ultimate speed because of bounds checking, but because it's interpreted at no point is the user app running anywhere other than the sandbox. Also the Java compiler does all the smarts, we don't validate the instructions or the locals (the compiler handles that for us), so while a user could hand assemble a Java app which messed about and fiddled with object references, our bounds checking would cause the JVM to exit with no ill effects

Fortunately the processor has oodles of processing power and the user applications are not massively complex. Java is a great fit and will allow us to provide our customers with a better set of tools to develop their apps on. I will compile the class files into a more compact version minus the fluff in the Java class file that we don't have any interest in.

When I first mused the VM idea when we were planning the project I did originally think about Java, but baulked at the idea of writing a JVM, turns out though that it's not been quite as much effort as I expected, kind of makes me wish I'd gone down this route a couple of years back!

I really appreciate you taking the time to respond on this stuff!

Sounds like what you're building today is pretty much what the very original JVM was intended to be: a lightweight way of shipping code to run on set-top boxes and other devices with very limited resources.

I suspect that you'll eventually go down the same route as everybody else, moving from bytecode to some sort of internal representation where you can run an optimizer (e.g., to hoist bounds checks outside of a loop). Given your memory constraints, I can't just recommend that you adopt Dalvik or equivalent wholesale, since they're going to want to run a full-blown optimizing compiler. However, if you could run that elsewhere and just run the compiled output on your embedded device, then you might be in good shape.

FYI, there's a thing called J2ME (https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition) meant explicitly for your sort of constrained environment, and it appears to still be under active development. I have no idea what the licensing terms are, so caveat emptor.

And, lastly, I'm no lawyer, but given how Oracle is suing Google over Android's use of Java, make sure your own lawyers are cool with what you're doing.

Saw this on Twitter this morning; seems relevant: https://xkcd.com/801/

haha

Pfft though, took me around about a week to write the JVM and a smattering of native "required classes". Funnily enough, I've just been doing some code tidy up on it so that I can hand the project over to my junior dev so that he can flesh out the native classes.