The main goal of the Java API for KML (JAK) is to provide an automatically generated full reference implementation of the KML object model defined by OGC’s KML standard and Google’s GX extensions. It is an object-oriented API that enables the convenient and easy use of KML in existing Java environments. KML is an XML-based language schema that describes and visualizes geographic data. The language is often used in 2D web based maps and 3D virtual globes. APIs for XML dialects are implemented using two layers. The current official XML schema of KML in conjunction with the JAXB technology is used to generate Java class representations automatically. KML’s schema is a document describing the correct syntax of KML files and can, therefore, be used for validating the corresponding KML files. The semantic application layer, which is found on top of the JAXB layer, is abstracted from the raw generated classes and defines a well-shaped API. This API provides easy out-of-the-box access to KML for the user. This project provides a Java API for KML in order to enable this.
jTracer is a visualization tool for libcsdbg. When libcsdbg creates a stack trace for a caught exception, a thread, or a process-wide stack trace dump, it can be configured to broadcast the trace data through TCP/IP (UDP/IP, RS-232, USB, etc. are under development). jTracer catches those data and visualizes them to the user, sorted and ordered by TCP/UDP/IP address/port (or serial port), process ID, and executable, thread, and timestamp. It's particularly useful when you're doing cross-development and your target platform has no resources to visualize output. The rationale behind the development of jTracer is similar to gdb/gdbserver functionality.
Upsilon is a distributed, flexible, and extensible system monitoring application. Being distributed means you run service checks on Upsilon nodes in your network where it makes sense, either on every server or on a management network, inside or outside the firewall. You can run checks on secure, hard to reach networks, and push those results to a central server. You can optionally execute "agentless" checks just by using SSH. Being flexible means that if you can script it, you can monitor it. Unlike most monitoring systems, the monitoring scripts are external to the main server, so you can use Upsilon to execute your monitoring scripts in an extremely robust way. Upsilon has been used to monitor many different things and is API-compatible with all nagios monitoring scripts. Being extensible means you can add monitoring checks to Upsilon at runtime without needing to restart the server. The upsilon-node and upsilon-web projects both have their own REST APIs.