Download JAR files tagged by reflection with all dependencies

Skeletal implementation of interface javax.lang.model.util.Types, plus concrete realization backed by core Java Reflection API, akin to JEP 119. This module implements those methods in interface javax.lang.model.util.Types that pertain to the Java type system, plus it provides a method for resolving formal type parameters to actual type arguments. These methods have no equivalent in the Java Reflection API. The abstract skeletal implementation in this module is meant to be specialized for a particular javax.lang.model implementation. The abstraction makes this module well-suited to be used in projects that contain javax.lang.model as part of their domain model (for instance, implementations of alternative languages on top of the JVM).

A set of reflection utilities and miscellaneous utilities related to working with classes and their fields with no dependencies which is compatible with java 1.5 and generics. The package was originally created by Aaron Zeckoski for the Sakai Project and Generic DAO project but was repackaged to make it distributable by request. It is used in the RSF framework (http://www2.caret.cam.ac.uk/rsfwiki/) and the EntityBroker among other things. Note about the BeanUtils provided dependency: BeanUtils is not required if you are not using it in your project. Note about the Hibernate provided dependency: Hibernate is not required if you are not using it in your project.

Janet Sudoku is a powerful Sudoku Generator and Sudoku Solver library for Java (since jdk 1.5) Android .NET (since 2.0) MONO CLS compliant. Additionally library delivers Janet Sudoku Demo App implementation in a simple form of command line tool, yet highly functional. 1. Sudoku Generator - generate Sudoku puzzles using variety of different methods. 2. Sudoku Solver - Solve any Sudoku puzzle, get the path leading to the correct solution. Check whether unique solution exists. Find all solutions if more than one present. Analyse many built-in examples of Sudoku puzzles or load any other. 3. Manipulate the board by applying transformations not affecting solution existence (i.e. rotation, reflection, permutation, swapping segments, and others). Interact with the library via consisted and well documented API. 4. Janet Sudoku Demo App - use simple, yet highly functional, command line tool to generate, solve evaluate different puzzles.

JCQL is a tool allowing to generate boilerplate java code from existing cassandra schema. It is intended to be used with Cassandra 2.1+ due to support of UDTs (User Defined Types)/Tuples/Collections. Cassandra's UDTs/Tuples/Collections and an ability to introspect schema through java driver make it possible to automatically generate POJOs and corresponding mappers between database and java models. Properly generated java code saves development efforts and is less error-prone compared to hand coding. Accompanied with proper CI and deployment it can also guarantee consistency between database and java models at any point of application lifecycle from development to production rollout. JCQL does not rely on java reflection or annotations which means all discrepancies between actual cassandra schema and what client code expects it to be will be identified during compilation not at runtime in the middle of the night right after production release. No need to worry about Cassandra client code performance implications due to use of reflection.

All Gwt jre emulation code goes in this module, as well as any gwt-compiler overrides. xapi-gwt-api.jar must come before gwt-dev.jar on your compile classpath. A plugin is being built to automatically adjust maven runtime dependencies, but users of ant or IDEs will need to ensure the super jar comes before gwt-dev. We will petition gwt to accept our mods, but, until then, if you want bleeding edge features, you gotta do bleeding edge configuration. Code that ties directly into other modules, like java.lang.reflect for the reflection submodule, have their super-source here, and generators or other implementations in their own modules. This is to maintain consistency in what is or isn't whitelisted in XApi GWT. Some modules, like appengine, provide dependency-specific super-source in their own packages. This module is for jre, junit and core XApi services.

JSONXML project is library used to parse/format tree-like object structures in most popular text formats: XML and JSON. For parsing it accepts "java.io.Reader" and return java object. For formatting it accepts java object and "java.io.Writer". Object is generally structure that contains Map and/or List elements. Map is ordered set of named items. List is set of unnamed items. Reflection may be used to convert objects into set of maps/lists and vice versa. JSON parser is implemented explicitly. XML parser is based on SAX parser and applies only certain rules for result. Library is designed to allow various entry points for variable decisions depending on end use needs. 1. Formats - formats are used to enable locale-specific parsing/formatting of numbers and dates. 2. ReflectiveBuilder - enables reflection. Default implementation uses getters/setters only. 3. ObjectsRegistry - used to keep track of parsed or formatted objects and allow resolvable references in formatted (text) form.

XApi is a dependency injection, service-oriented, polyglot java framework. It is comprised of standalone modules for use in web, desktop and mobile java applications. This codebase enables complete reuse of all code across your java stack, as well as the ability to easily define your own Platform, so you can build your own customized runtime environment to extend or replace existing platforms. It is currently geared towards servlets and gwt clients, but the target we are currently developing include: java, gwt [webkit, firefox, ie], javafx, playn [android, ios, flash], appengine & vert.x For Google Web Toolkit, we also include reflection support, more complete emulation of java.lang.Class, zero-overhead dependency injection, a range of code generation utilities, and even "magic-method injection" (for production compiles any method in the app can be swapped out with others based on configuration properties, or any AST mangling / code generating methods you wish to write). There is also a bytecode transformer in the works which will replace calls into the DI utility with direct references to static final factories, to allow the java compiler to completely erase all injection overhead in all java runtimes.

This is the main aggregator for all gwt submodules. All gwt-specific code resides here. Submodules should avoid inheriting from each other unless necessary. This goes for maven structure and gwt.xml structure. The super module is where our jre emulation layer and super-source live; all modules should inherit super, and a minimum of other modules. Some modules, like injection, are fulfilling an api in the core module, and should be accessed only through core service interfaces. Other modules, like reflection, are capable of being standalone inherits, but can benefit from core utilities like injection, so, two (or more) .gwt.xml modules may be provided. As XApi nears 1.0, all submodules will be routinely stitched together into an uber-jar, in order to have a single jar with a single gwt module that can provide all of the services at once. Internal projects will never use the uber jar, to help maintain modularity, but external projects that want to use more than one service will certainly prefer inheriting one artifact, instead of twelve. When distributed in uber-jar format, it will likely be necessary for either the uber jar, or just xapi-gwt-api.jar to appear before gwt-dev on your compile-time classpath. If using gwt-maven-plugin, the gwtFirstOnClasspath option may become problematic. If so, we will provide a forked gwt-plugin to make sure our compiler enhancements are included in the build process. There is also work going on to make a super-source-everything plugin, which will use maven to find source files, and generate synthetic .gwt.xml for you, as part of an effort to create a wholly unified programming environment. In addition to java-to-javascript, we intend to compile java-to-java and possibly other languages, like go; imagine implementing gwt deferred binding to eliminate cross-platform differences between server environments, or operating systems, or versions of a platform, or anywhere else a core api needs to bind to multiple implementations, depending on the runtime environment.