# Multi-Phasic Applications: SquirrelJME * Copyright (C) 2013-2016 Steven Gawroriski * Copyright (C) 2013-2016 Multi-Phasic Applications **SquirrelJME** is intended to be a Java ME 8 compatible environment for strange and many other devices. The source is written in pure Java. ## Licenses * [GNU Affero General Public License, Version 3 or later](license.mkd) ## Links * [Online repository](http://multiphasicapps.net:8080/squirreljme) ## Goals * _To be self-hosting_ - it can build itself while running on itself, provided there is a filesystem. * _To be small_ - Smaller programs are easier to maintain and are usually simpler. * _To be fast_ - With the potential of AOT/JIT, systems that do not normally have a port of an existing virtual machine will usually only have an interpreter. * _To be compatible_ - So that existing Java ME 8 applications can run on this virtual machine. * _To compile once and run anywhere_ - Current and up to date Java implementations are limited only to a few select systems (_Solaris_, _Linux_, _BSD_, _Mac OS X_, and _Windows_). Java ME 8 as of this writing only supports the *FRDM-K64F* and the *Raspberry Pi*. There are multitudes of devices that support **J2ME**, however that is horribly out of date when compared with the Java that is used today (**J2ME** is equal to Java 1.4 which was released in _2002_). ## Donations You may donate to SquirrelJME to help keep the author alive and to possibly help the purchase of various hardware: * BitCoin (**BTC/XBT**): [`1HNRD44krsCFUzUvVWaXr5jqvuyZDZy71M`]( bitcoin:1HNRD44krsCFUzUvVWaXr5jqvuyZDZy71M) * LiteCoin (**LTC**): [`LKytAQcbPyox75uYMKo1NH1w2k1SqBaELi`]( litecoin:LKytAQcbPyox75uYMKo1NH1w2k1SqBaELi) * DogeCoin (**DOGE**): [`DPsW21MV8RMuXhA3GoN8VPjkmQEugrEn8h`]( dogecoin:DPsW21MV8RMuXhA3GoN8VPjkmQEugrEn8h) # Important Statements ***THIS SOFTWARE IS INCOMPLETE AND IN ITS CURRENT STATE IS NOT CURRENTLY 100% COMPATIBLE WITH JAVA ME 8. THERE ARE CURRENTLY NO RELEASED VERSIONS OF THIS SOFTWARE. AS SUCH THE FIRST RELEASE WILL BE WHEN IT IS COMPATIBLE SO AS TO NOT VIOLATE POTENTIAL LICENSES, AND IF POSSIBLE BE VERIFIED WITH ANY APPLICABLE TCKS (SO IT WOULD BE AN "OFFICIAL" IMPLEMENTATION).*** ***JAVA AND ALL OTHER RELATED TRADEMARKS AND COPYRIGHTS ARE OWNED BY ORACLE CORPORATION . THE IMPLEMENTATIONS OF THE JAVA ME 8 APIS AND ASSOCIATED JSRS/JEPS IS CONSIDERED BY MYSELF TO BE IN THE FAIR USE (AND IT ALSO HELPS THE JAVA ECOSYSTEM BY PERMITTING IT TO RUN IN MORE PLACES WHERE IT IS NOT SUPPORTED BY ORACLE).*** # Supported Operating Systems and Freestanding Hardware ## Hosted ## Freestanding # Differences Between Java SE and Java ME Java ME is a much lighter Java platform and here are the things which are missing along with a reason as to why this may be a good thing: * No finalizers (the `finalize()` method). * Finalizers are very integrated with how the garbage collector works. * It is never known when they will actually be called (if ever). * Timing attacks could be performed when finalizers are called between garbage collection runs. * No serialization. * Not all objects are `Serializable`. * Serialization uses virtual machine magic to access internal details. * The `transient` keyword should never appear. * Simplifies implementation. * No reflection. * There is `Class.forName()` and `Class.newInstance()`, however they are trivial to support. * More secure because access checks do not have to be performed at run-time to determine if it is permissable to access an object. * Random object fields (and finals) can be cached because their reference or primitive values will never change. * More secure because for example changing `Boolean.TRUE` to be `false` may cause security exploits with code that relies on it being `true`. * No `invokedynamic` instruction. * Simplifies virtual machine operation, at the cost of lambdas (which could be smartly wrapped in anonymous classes by a compiler). However, given these differences there are advantages: * Faster * Due to the lack of reflection, optimization is safer because finals are truly final. This means no exceptions are required to allow for this change. * Lighter * The main library is much smaller which means it will load faster and use less memory. Less memory means it can run on smaller systems such as calculators. There are also disadvantages however: * Without reflection, one cannot include plugins dynamically from the program. * However, Java ME 3 (or so) added LIBlets which may be optional and provide a slight alternative to plugins. These however are fixed to the JAR/JAD which means that the difficulty is increased. * Alternatively, Java ME 8 has `ServiceLoader` which enables JARs to potentially be merged to provide services. Also using `Class.forName()` and `Class.newInstance()`, plugins using a common interface can be initialized when they are not directly known. # Limitations These are planned limitations: * Only _4,096_ classes may be used at any one time, provided there is enough memory to load all of them. Note that in standard desktop Java, this would mean that almost the entire standard class library has been loaded. # Programming Considerations ## Do Not Use Static Modifiable/Mutable Globals In Standalone Classes The garbage collector upon determining that a class (which may contain static variables treated as globals) is no longer referenced, it may be garbage collected. This means that if you set a global in a class such as that and then reference it later, it may be reset to its default value. This is more likely to happen on lower memory systems where the garbage collector will act more aggressively.