Re: Lack of extension
Posted: Feb 28, 2007 3:43 PM
> I'm not sure how developed the virtualization techniques
> were in those days, but I doubt that anyone at the time
> could demonstrate an effective implementation that allowed
> a real-time application to be cost, memory and speed
> competitive with a typical embedded system of that era. If
> you have an example from the historical record that
> indicates otherwise, I'd be happy to hear about it.
My contention is that it wasn't as developed as we had technology and knowledge for because only "hardware dudes" were writing software in small devices. They didn't understand what was needed.
There were countless examples of virtualization in the form of P-Code and the like. There were small stack based machines used in the likes of calculators etc.
The J2SE JVM (then) was "larger" than these because of the native interfaces back to file, socket and system interfaces. The GC implementation was the complicating factor. At the same time that Java appeared, I was finishing a similar language that is/was used inside of the 5ESS switch for procedure automation. It used a simple counting collector, and did not have a threading model, which simplifies many things.
> > > Many of the embedded systems of that era didn't even
> > > include OS's, so adding a JVM would increase resource
> > > requirements significantly.
> > If you have to "add" a JVM in a micro environment, you
> > haven't designed your micro environment to capitalize
> > Java. Instead you've decided that Java can't add any
> > value and so it should just be an add-on that you can
> > pitch when it fails to meet the needs of the users.
> I think it's a hard case to make that one would include
> (if you prefer that word to "add") Java as a way of
> reducing the memory footprint or making the micro system
> run faster. I suspect that it is used for the same reason
> that most high-level languages are used - to simplify and
> accelerate software development.
I did not say that it would "reduce memory footprint" or "run faster". That would not be the point of using Java in a micro environment. The point of using Java in that environment is to capitalize on language features that would allow you to do testing outside of the micro environment, as well as remove/reduce memory management issues. By using Java, you could also design software that ran on multiple different hardware types by designing it to take advantage of the Java platform, instead of calling into native code that was non-portable.
> > This is precisely what has happened in the cell phone
> > industry. J2ME CLDC with MIDP is terrible to use on
> > mobile phones because you can't make it interact with the
> > user without disabling everything else the user wants to
> > use the phone for. The manufactures don't think Java is a
> > platform. They think that Java is an add-on for games and
> > gimics.
> Keep in mind that Java can't really be used for the core
> activity of a cell phone: signal processing. They have to
> use DSP's for that. So for cell phones, it's always going
> to be an add-on to some degree.
DSP software can be written in Java and targeted to a DSP. I've written some DSP algorithms in Java. It is possible, even though the perfect math in Java can be a problem.
The DSP is not where you should be writing user interfaces and many other types of things that some developers use it for, just because there's memory available to add more to the DSP. That just makes you more dependent on that platform because you have to write software differently.
> > Java is not an add-on technology! Java is a platform
> > technology. If you are not getting everything that you
> > need out of Java, I'd wager that you have not put it
> > enough to the problem space to allow it to work
> > effectively.
> > RTSJ demonstrates that Java can provide real-time
> > programming. Java smart card (every resident of Korea,
> > and Brazil carries a Java smart card), demonstrates
> > Java can be a platform on a very limited device.
> I think a lot of this is Java "branding". One can always
> reduce the functionality of any language or platform and
> then say "It can run on a smart card". One can always
> make changes to the standard implementation to allow
> semi-real-time capability. The point is that some
> compromise will be involved that makes the "new"
> implementation differ from the norm.
Yes, there are incompatible differences in the platform. Sun has acknowledged this as a problem, and I believe they will start to address the more prominent issues, such as the J2ME Connector mechanisms which don't exist in J2SE.
> There are two criteria you can use to judge these
> different implementations: 1) Will every standard program
> run on the new implementation? 2) Will there be enough in
> common with the standard implementation that programmers
> can leverage their knowledge?
> Typically, the answer to 1 is no and the answer to 2 is
I don't use those criteria exactly. I ask these questions.
1) Can the new platform support the intended audience without compromising the development practices of that domain?
2) If new functionality is needed for the new platform can that be introduced into the old platform without impacting existing software?
3) Is there a big enough audience to need a new platform or do we just need new features on the old platform that allow it to scale to the new domain?