My favorites | Sign in
Project Home Downloads Wiki Issues
READ-ONLY: This project has been archived. For more information see this post.
Project Information
Members
Featured
Wiki pages

Under Design and Construction (current process is ScriptLanguage design)

GitHub has become the new development home of jarvar and ScriptLanguage.

Load up jar files and execute them on a very low security overhead platform. That is to say loose much of the overheads of a full Java install. The limits of design require few security checks on the jar or classes, and a limited and simple class library.

Development of the library considers the fact that a simple abstraction layer on top of SE/ME/ANDROID allows a common code base, and a reasonable library size. Also an NSPlugin is being considered. The cross-platform Qt toolkit would be best for developing a JRE free application, although the faster than light toolkit is more compact.

The abstraction layer is being developed for my own project use, but does have application in device cross usage. So the project is not just about a new Java bytecode engine, but also a new simpler, for programmer and memory restricted user, JRE replacement. AProjectTimeline has been created, which has no set dates.

Simplicity involves using the same threading address for loading byte, short, char and int, for example. Also saving threaded intermediate files as .jvr may be useful, and could become decent uncluttered language. OOP class explosions are a hindrance to common usage.

ConceptDiscussion is a page to discuss freely, any matters relating to the project via comments. It has some sub-pages for more specific discussion.

Outline of the Runtime

The principle classes of Audio, Keys, Storage and Video, are used to provide a Virtual class which is used to access the system. The Process class is a simple class which every application must subclass. It is constructed first and has its methods called by the OS. This is how the application starts and persists.

The rest of the class library is a simplified set of GUI components, with very few configuration options, some abstract file system and networking tools, all based on UTF-8 (not a binary literal character encoding), an abstract keyboard handler, menu/button abstractions, and a scripting engine for user macro creation. The later being an underused feature of many applications.

Best care is taken to ensure features are available over a large platform set, as well as native jarvar, while no attempt has been made to make the library exhaustive of all possible need. This in some ways presents the natural boundary between thin client and server. A thin enough client to put on any kind of fat server?

Why?

First I wish to develop my own Java applications simply, and the edition boundaries are somewhat of a pain. The consumption of coding hours in 'conversions' could be better spent making something new. Second I want to develop my own 4GL (called ScriptLanguage in this project), so I may gain the benefits of script coding (highly interactive and a fast development cycle) which I have experienced via languages like Tcl, PHP and bash. And finally I really hate the class forest know as the JRE. I hate many examples of coding which use an excess of classes, all different, and consider nothing about code reuse, keeping binaries small, and thrashing the L1 cache of any processor they load into.

"Someone's posh is my un-usability."

"Someone's over use is my capital expenditure."

Powered by Google Project Hosting