Group items tagged

This article is about how to setup remote debugging in eclipse which is pretty important for development across operating system.

Eclipse Integration for Karaf is the integration of the Apache Karaf application platform and the Eclipse IDE. Notable features include: An Eclipse Run/Debug launcher configuration that configures Karaf to run inside the workbench transparently to the developer Automatic deployment of workspace plugin projects to running Karaf instances without copying files A Target Platform Definition that allows developers to target only the bundles found in Karaf distributions A Target Platform Provisioner that automatically constructs a target platform from any Karaf distribution on the user's local disk JMX instrumentation of the Running/Debugging Karaf instance. Eclipse views that display the Bundle and Service status of Karaf instances Experimental features: Web Tools Platform integration including: Karaf server runtime with associated classpath maintenance Karaf runtime locator that scans local disks for compatible Karaf distributions Install from the EIK Update Site

"JAnnocessor is a new open-source framework for powerful, flexible, yet easy processing of annotated Java code. Its main purpose is compile-time, annotation-driven source code generation in a declarative and customizable fashion. JAnnocessor is built on top of Java APT, encapsulating the Java source code model in a rich and convenient high-level domain model that serves as a good target for expressive matching and transformation. Finally, a template engine is used for customizable template-based source code generation. Having simplicity and productivity in mind, JAnnocessor has many useful features that make it enjoyable: smart imports organization, logging delegation, graphical UI for real-time debug, hot swap of processors and templates, as well as out-of-the-box common annotations, processors and templates."

A "flight data recorder" and correstponding "time traveling debugger" to playback the data. Integrated into Eclipse.

Sapphire - develop UI without wiring individual widgets Little has changed in the way Java desktop UI is written since the original Java release. Technologies have changed (AWT, Swing, SWT, etc.), but fundamentals remain the same. The developer must choose which widgets to use, how to lay those widgets out, how to store the data being edited and how to synchronize the model with the UI. Even the best developers fall into traps of having UI components talk directly to other UI components rather than through the model. Inordinate amount of time is spent debugging layout and data-binding issues. Sapphire aims to raise UI writing to a higher level of abstraction. The core premise is that the basic building block of UI should not be a widget (text box, label, button, etc.), but rather a property editor. Unlike a widget, a property editor analyzes metadata associated with a given property, renders the appropriate widgets to edit that property and wires up data binding. Data is synchronized, validation is passed from the model to the UI, content assistance is made available, etc. This fundamentally changes the way developers interact with a UI framework. Instead of writing UI by telling the system how to do something, the developer tells the system what they intend to accomplish. When using Sapphire, the developer says "I want to edit LastName property of the person object". When using widget toolkits like SWT, the developer says "create label, create text box, lay them out like so, configure their settings, setup data binding and so on". By the time the developer is done, it is hard to see the original goal in the code that's produced. This results in UI that is inconsistent, brittle and difficult to maintain.

Writing your own logging framework is the perfect coding crime. If you can convince your manager to put it on the project plan, you are guaranteed to have success. At the end of each day, you will go home feeling happy and satisfied. It will feel like you are doing something creative. You will get the intellectual stimulation without the risk of failure. Even the Sun engineers fell into this trap. Prior to Java 4, we had a perfectly good logging framework in Log4J. However, instead of adopting this into the standard Java distribution, we ended up with java.util.logging. There are lots of Java logging frameworks available, even meta-logging frameworks like SLF4J and Jakarta Commons. These are supposed to abstract the logging frameworks so you can change the implementation without touching your code. http://www.javaspecialists.eu/archive/Issue177.html