Gava is a Java Integrated Development Environment (IDE), built in pure Java, to develop Java applications and applets. Most of Gava is developed in Gava itself. As a pure Java application, Gava can run on both Windows and Unix/Linux platforms. It requires JRE 1.4 to execute, but it can debug JDK1.2, 1.3, and 1.4.

More Info About Gava

Intuitive, fast, and powerful. Gava is a fast IDE built with many unique and well-thought-out optimizations. Gava users will enjoy a smooth coding feeling throughout the development phases - fast start-up, fast code completion, fast compiling, etc. With a relatively simple but intuitive GUI, Gava provides users powerful functionalities. It suits the needs of all developers, from entry-level to advanced.

Internationalization. Gava is an IDE designed for developing international Java applications. First, Gava itself is a multilingual Java application. Developers can set Gava to any language, no matter what OS (localized or English version) it is running on. Second, Gava provides many functionalities and tools to easily develop multilingual applications, with either localization or internationalization technologies.

Write once, develop anywhere. With Gava, you can not only run your projects on multi-platforms, you can also develop your projects on multi-platforms. Gava implements an OS-independent project management architecture. Based on this architecture and other special features in Gava, developers can easily port Gava's projects to different platforms, file systems, or file directories.

Multiple debugging sessions. Gava can debug multiple debuggees within the same running instance of Gava. This feature makes Client Server debugging much easier, Gava users don't have to switch between running applications.

Customizable. Gava is configurable. Gava users can customize the GUI look and feel with their favorable fonts and colors to create a work environment suitable for different occasions, either for demonstration or development.

Now Gava SE 1.0 is available for download. We would appreciate any and all feedback regarding the product. You may download a fully funtional 30 days trial version from our download page, and try it to see how you like it. Thank you.

I do not desire to start another flaming thread, but I have to question why we have yet another java ide. We have several open source ide's with plenty of plugins available to the java development community. Additionally, we also have several commercial ide's, also with a plethora of plugins. Java Enterprise, Client and Micro development appears to not need another ide.

As discussed in other forums, java has some major work to do in the ease of development category (I am not trying to debate what features are required for ease of development). As a community, let's invest our time in developing and extending environments that will enhance our productivity. Let's make sure that many of the productivity enhancing features of java 1.5 can be leveraged by a winner in the ide category. As a community, we can have large impacts into the development and direction of either Eclipse or NetBeans in the open source community. With continual feedback from the user community and a tight focus around leveraging some of the award winning capabilities in the Visual Studio tools, we further our abilities to deliver the highest quality products that match our end user's requirements within the shortest timelines possible.

To the team at Gava, I am not saying that your ide is not quality nor am I attempting to shame the engineering team. I merely desire to point out that we already have too many disparate unfocused ide tools within the java community. While competition is great and needed, too many choices and tools that are disparate will rarely if ever bring parity for price and feature capabilities. I would rather see us come together within a consortium in order to improve some of the tools that have several years of market presence.

Having said that I must say too, that it's also important to have someone redesign and rethink something from the bottom up. Like IntelliJ IDEA. Who would have thought there was space for "yet another Java IDE" when IDEA launched? Yet IDEA is by far my preferred IDE now, and it's very popular with it's users. (Eclipse, JBuilder, JWhatever - go home, you slipped! :-) )

I am myself involved in "yet another object persistence framework" because the ones that were available didn't suit the needs I have had so far.

The same could be said about logging api's. Most of them make the "mistake" of assuming the programmer knows if a log is "severe", "error", "warning" etc. But really some of them turns out to be another category in production, or the severity level may change over time due to system changes. Thus, the operator should be able to change the severity level of a log (with a certain code) at runtime. Not at compile time!! Maybe the current log-api's can handle this, maybe they need changes, maybe they need a new redesign.

Anyways, my point is that sometimes it is GOOD when someone rethinks and redesigns a common idea and comes up with a new angle on the same problem. If Gava brings something new to the table, it's worth looking at.

Oh... and I have actually also been thinking about doing another editor where everything internally is represented as XML-dom trees... :-) Mostly an editor for data, not an IDE. My idea was to make plugin development a lot easier than with the current IDE's. So yes, sometimes I do believe we need to start over :-D

The same could be said about logging api's. Most of them make the "mistake" of assuming the programmer knows if a log is "severe", "error", "warning" etc. But really some of them turns out to be another category in production, or the severity level may change over time due to system changes. Thus, the operator should be able to change the severity level of a log (with a certain code) at runtime. Not at compile time!! Maybe the current log-api's can handle this, maybe they need changes, maybe they need a new redesign.

The common "mistake" in most logging apis is: there is no separation for log request (logging methods) and control (management methods). What you want, if I understand it correctly, is a dynamic control which class to log, what is the log threshold at runtime. Runtime control must synchronize all JVM in a cluster.

I defintely don't agree with people saying there are too many Java IDEs out there! Competition results in innovation and without innovation, we're screwed.

We've all loved JBuilder (ok, let's not shout that out too loud :), we've had Code Warrior, we've had Kawa, we've had NetBeans, we've had IDEA, there'll always be newer - better or worse - IDEs. Just giving feedback to the NetBeans team or posting at the Intellij.net forums will not create significantly better IDEs, it'll just maek the companies / communities improve on their existing IDEs. NetBeans will always be slower than IDEA, but IDEA will never get better in GUI designing than NetBeans... Newer parties might give some competition, which might in fact result in an IDEA that combines speed with GUI design...

If you're saying the IDEs we have right now are sufficient and enough, you might as well say 'why didn't we stick with C++'!

I look at the features and they want $100 .. at least give us something that is worth the effort and especially worth the money.

To be honest, $100 is not that much money for software if it is useful.

I haven't checked out this IDE and probably won't have time to unless it does something unique that I need, but still, best of luck to them. The world will always need people who are crazy/stupid/brave enough to build something new without any idea of whether anyone will pay for it.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.