Free java code software for linux

Java for C++ is a tool to generate C++-wrapper-classes for existing Java-classes. This tool reads a list of Java class names and creates source code for C++-classes to wrap them.
The implementation of the wrapper classes uses JNI (Java Native Interface) to call the "real" Java classes.
The C++-API to use these wrapper classes is very close to the API of the original Java classes. So developers of C++-software can use Java-classes as if they have been implemented in C++.
Enhancements:
- A problem where null values for method arguments, method return values, or field values caused some generated code to crash was fixed.
- Updating is strongly encouraged.

Q2Java project allows Quake2 games to be written in Java.
Q2Java is a game DLL for Quake2 that allows game code to be written in Java instead of C.
It currently runs on Win32, Solaris, and Linux platforms. It takes advantange of many Java features including security, cross-platform binary compatibility, internationalization, dynamic classloading, just to name a few things.
Enhancements:
- Fixed a pretty serious problem in the native implementation of Engine.getRadiusEntities() where if there were more than 32 "hits", you overran a buffer and potentially could crash the game. Even if you dont want to adopt the new Java code in this version, at least use the new DLL so you can avoid this problem.
- getMaxPlayers() to find out what is the max number of players the server is configured for.
- isValid() for finding out whether a NativeEntity is actually bound to the underlying engine, or has been freed and is kind of a ghost.

JSwat is a graphical, stand-alone Java debugger, using the JPDA library.
JSwat Java Debugger offers breakpoints with monitors and conditions, colorized source code display, single-stepping, displaying variables, viewing stack frames, and expression evaluation.
Main features:
- breakpoints with conditionals and monitors
- colorized source code display
- graphical display panels showing threads
- stack frames
- visible variables
- loaded classes
- command interface for more advanced features
- Java-like expression evaluation, including method invocation.

Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. Java checkstyle Tool automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.
Checkstyle is highly configurable and can be made to support almost any coding standard. An example configuration file is supplied supporting the Sun Code Conventions. As well, other sample configuration files are supplied for other well known conventions.
Checkstyle can check many aspects of your source code. Historically its main functionality has been to check code layout issues, but since the internal architecture was changed in version 3, more and more checks for other purposes have been added. Now Checkstyle provides checks that find class design problems, duplicate code, or bug patterns like double checked locking.
Enhancements:
- This release contains a number of enhancements and bugfixes.
- The highlights include performance improvements in the StrictDuplicateCode check and a new CrossLanguageRegexpHeader check that allows checking file headers for languages other than Java.

GData Java Client provides a library and source code that make it easy to access data through Google Data APIs.

The Google data APIs ("GData" for short) provide a simple standard protocol for reading and writing data on the web. GData combines common XML-based syndication formats (Atom and RSS) with a feed-publishing system based on the Atom publishing protocol, plus some extensions for handling queries.

Google also provides a set of client libraries for interacting with GData-enabled services, in a variety of programming languages. Using these libraries, you can construct GData requests, send them to a service, and receive responses.

Java::Import::Design is the design of the Java::Import Module.

MOTIVATIONS

The original motivation for writing this module came out of a project I was working on during my previous employment. We had built a system in which a major part was implimented using EJBs on a J2EE server. In addition, we had a large component of the system, that already existed, and was written in Perl. We did not want to scrap our Perl work but it was becoming more tedious to maintain two implimentations as more and more things were being added to the system.

So, we decided that the major pieces of business logic would reside on the J2EE server and the Perl would be modified to make calls to the server. After some time and experimentation we began to realize that the memory footprint as well as the amount of time needed to make calls to the server using existing Perl to Java integration sulutions were just not acceptable. We therefore set out to find some other way. We tried all sorts of things but in the end we couldnt find anything that met our requirements and therefore decided to keep the origional system of doing things.

While at that job we never did find a suitable way to integrate our two systems. However, the problem still haunted me. It wasnt until the end of my career at that company that I saw an announcement for Googles first Summer of Code. It just so happened that as Google was announcing their brand new program that I had begun to play with the GNU GCJ suite of Java tools and came up with the idea of taking advantage of their ability to natively compile Java code for use with Perl. This may not have been a new idea but I couldnt find anything that would help me so I decided to write and submit a proposal to Google. Well, I was accepted and you now have Java::Import.

When I began to work on this project I started by creating my own namespace instead of stepping on the toes of the other existing Java/Perl integration project, Inline::Java. I did this primarily because I wanted a clean slate on which I could fully explore the nuances of GCJ, in particular its CNI interface. As I worked my module started to evolve into its own beast and at that point it seemed locigal to keep my own namespace. It is not my intention to replace Inline::Java and I still think that in te future much of the work I have done can be used by Inline::Java as an option to use GCJ specific functionality.