Im folgenden wird beschrieben, wie man sein Projekt so strukturieren kann, dass auf der einen Seite das Testen erleichtert wird, auf der anderen Seite die Tests vom produktiven Java Quellcode separiert werden. Das erleichtert zum Beispiel die Paketierung zur Auslieferung an Kunden, die lediglich den produktiven Quellcode erhalten sollen.

Bei einigen Entwicklungsumgebungen, wie z.B. Netbeans, ist bereits bei einem leeren Java Projekt eine Separierung von Test Quellcode und Java Quellcode vorgesehen: Es gibt einen Ordner für “Test Packages” und einen für “Source Packages”. Im Dateisystem werden diese auf die Ordner “src” und “test” entsprechend abgebildet. Bei der Tastenausführung werden aus beiden Verzeichnissen die Quellen übersetzt und die Ergebnisse zusammen geführt. Bei dem von Netbeans standardmäßig erstellten Buildfile kann man auch von der Kommandozeile mittels “ant test” die Tests ausführen, bei “ant jar” wird eine JAR Datei (im “dist” Verzeichnis) erstellt, die lediglich den produktiven Code enthält.

Durch das ant Buildfile und die Projektstruktur ist damit ein Netbeans Projekt von Haus aus direkt für eine Continuos Integration Umgebung optimal vorbereitet.

Eclipse ist noch nicht ganz soweit, jedoch sollte man seine Projektstruktur auch hier so aufbauen: Der Code ist klar getrennt, verwendet man eine parallele Paket Struktur, können auch Methoden die “protected” oder “default” Sichtbarkeit haben, einfach getestet werden. So vermeidet man zu grob geschnittene Tests (nur “public” Methoden testen) bzw. unnötige Erweiterung der Sichtbarkeit, in dem man Methoden “public” macht, nur um sie testen zu können.

Das ganze ist sehr einfach: Startet man ein neues Projekt, so kann man bei der Einrichtung direkt ueber “create new source folder” neben “src” einen “test” Source-Folder anlegen.

Eclipse fügt dann entsprechend alle übersetzten Class Dateien, in diesem Fall “Sample” aus den produktiven Sourcen und “SampleTest” aus den Test Quellen im “bin” Verzeichnis zusammen:

Bei Eclipse muss man sich noch selber um ein Build-System kümmern, wenn man von der IDE unabhängig bauen möchte – und das möchte man. Immer.

Hier bietet sich z.B. “Maven” an, welches für einfache Projekte auch schnell einzurichten ist. Alternativ kann man auch ant oder das neue Gradle benutzen. Übrigens: Möchte man von Anfang an seine Projektstruktur bereits entlang der Maven Konventionen aufbauen, sollte man seine produktiven Sourcen unter “src/main/java” und seine Test Klassen unter “src/test/java” anlegen. Setzt man kein Maven ein, macht das keinen großen Unterschied, da die IDE-Ansicht sich nicht unterscheidet. Moechte man jedoch auf Maven später umstellen, spart man sich etwas Arbeit und hat sich bereits an die Konventionen gewöhnt.

Weitere Artikel:

1. SwingDemo Projekt
2. Modular Java (Buch)
3. Java EE Summit Berlin

Nachdem im ersten Teil der JPA Einführung die Infrastruktur für die Arbeit mit JPA fertig gestellt wurde, kommen wir nun zu den Entitätsklassen. Bei den Entities handelt es sich um ganz normale Java Klassen (POJOs), die kein spezielles Interface implementieren oder von einer vorgegebenen Oberklasse erben müssen. Lediglich ein default Konstruktor muss vorhanden sein.
Dank JPA Annotationen kann man erkennen, dass die Objekte persistiert werden.
Möchte man EJB3 konform arbeiten, so sollten die Annotationen dort angebracht werden, wo auf die Properties zugegriffen wird: An den Attributen für field-access, an den Getter-Methoden bei property-access. Dies sollte konsistent gemacht werden, und die beiden Formen sollten nicht gemischt werden. (Zwischen den beiden Formen wird über die Position der @Id Annotation unterschieden.)
Die Annotation der Attribute hat dabei den Vorteil, dass schnell erkennbar ist, was wie persistiert wird – kann jedoch bei einigen JPA Providern zu Performance Problemen führen. Auf der anderen Seite führen Getter-Methoden, die nicht zu persistierende Werte liefern und nicht explizit von der Persistierung ausgenommen werden zu möglicherweise schwer zu findenden Programmfehlern.

Ein Beispiel für eine einfache Entitätsklasse

@Entity
public class Person {
@Id
@GeneratedValue
private Long id;
private String vorname;
private String nachname;
// default constructor
public Person () {
}
// getter + setter
}

Die @Entity Annotation macht kenntlich, dass diese Klasse von JPA persistiert werden soll, @Id kennzeichnet den Primärschluessel und @GeneratedValue bedeutet, dass dieser automatisch generiert werden soll (also ein synthetischer Primärschlüssel).
Mit diesen wenigen Angaben ist bereits erreicht, dass Objekte der Person Klasse persistiert werden können – lediglich die Konfiguration der Datenbank für JPA fehlt noch. Die genaue Steuerung in welche Tabellen/Spalten die Speicherung in der Datenbank erfolgt ist optional, und wird ohne zusätzliche Konfiguration mit Default-Werten realisiert.

JPA persistence.xml Konfiguration

In der Datei “persistence.xml” (normalerweise im META-INF Verzeichnis) befindet sich die Datenbankkonfiguration fuer den JPA Provider.
Ein verkürztes Beispiel passende zu der Beispiel-Entität von oben:
<persistence xmln="http://java.sun.com/xml/ns/persistence" ... >
<persistence-unit name="addressbook">
<class>com.example.domain.Person</class>
<properties>
<property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver" />
...
</properties>
</persistence-unit>
</persistence>
Zuerst erfolgt die Angabe des symbolischen Namens unter welchem diese Konfiguration verfügbar gemacht wird, dann folgt welche Klasse(n) zu persistieren sind (falls diese nicht per @Entity bereits deklariert sind, je nach JPA Provider reicht die @Entity Annotation nicht aus) und schließlich die Konfiguration der Datenbankverbindung ueber den JPA Provider Hibernate.
Theoretisch sind verschiedene Persistence-Units möglich, ebenso kann über <provider> explizit der JPA Provider konfiguriert werden. In der Praxis findet sich jedoch für eine Anwendung in der Regel eine Persistence Unit und lediglich eine JPA Implementierung, die dann auch standardmäßig verwendet wird.
Die Properties des JPA Providers sind dabei spezifisch für den jeweiligen Provider – in diesem Fall Hibernate.

Objekt mittels JPA speichern

Nun fehlt nur noch, dass ein Entity Object mittels JPA auch gespeichert wird. Nachdem die Vorarbeiten erledigt sind, zeigt sich schnell wie einfach die Arbeit Objekte zu speichern und zu laden dank JPA wird:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("addressbook" ); //der symbolische Name
EntityManager em = emf .createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin ()
Person p = new Person ();
...
em.persist(p);
tx.commit();
em.close();
Im nächsten Teil folgt dann wie Objekte aus der Datenbank geladen, geändert und auch gelöscht werden können.

Weitere Artikel:

1. JPA Tutorial: JPA Einrichtung

Von der Firma SpringSource wurde jetzt “Spring Integration 2″ als Release Candidate 1 veröffentlicht. Spring Integration ist eine auf dem Spring Framework aufbauendes Framework das Enterprise Application Integration und die EAI Patterns von Hohpe und Woolf umsetzt. Dabei unterstützt Spring Integration Messaging innerhalb von Spring Anwendungen und ermöglicht so einen modularen und lose gekoppelten Aufbau der Anwendung, externe Systeme können jedoch deklarativ zusätzlich angebunden werden.

Spring Integration 2 bringt bereits Adapter für die Anbindung von verschiedenen Systemen wie Messaging (JMS, XMPP), FTP, Mail, Webservices und auch spezielle Dienste wie Twitter mit. Neu ist in der Version 2 von Spring Integration dass die Spring Expression Language verwendet werden kann, und in der Eclipse basierten Spring Source Toolsuite (STS) ein grafischer Editor für die Modellierung der  Spring Integration Realisierung vorhanden ist.

Spring Integration steht unter  der Apache 2 Lizenz und eignet sich somit für die Entwicklung kommerzieller Programme. Alle Neuigkeiten von Spring Integration 2 finden sich auch in dem Blogpost von SpringSource.

Hier gibt es ein paar Slides zu dem Vortrag zu Spring Integration auf dem SoftwareFreedomDay 2010 der JUG Muenster: Spring Integration Vortrag.

Weitere Artikel:

1. Kritische Sicherheitslücke im Spring Framework
2. Modular Java (Buch)
3. Java Testing best practice: Projekt Organisation

JPA, die Java Persistence API bietet im Vergleich zu JDBC ein erhöhtes Abstraktionsniveau und ermöglicht damit in kurzer Zeit Anwendungen zu entwickeln, in denen Daten dauerhaft gespeichert werden müssen.
Zum Hintergrund von JPA: Bei dem Umgang mit Datenbanken gibt es schon sehr lange JDBC (Java Database connectivity) als einheitliche API um die Verbindung zu Datenbanken herzustellen. Auch hier handelt es sich bereits um eine einheitliche Schnittstelle, jedoch wird darüber lediglich festgelegt, wie Verbindungen aufgebaut werden, wie eine Abfrage eingeleitet wird und wie Transaktionen manuell gesteuert werden können.
Damit bleiben zwei Probleme: Der SQL Code muss von Hand erstellt werden, was gerade bei CRUD (Create, Update, Delete) Anwendungen viel Produktivität kostet, und zudem ist der SQL Code in der Regel herstellerabhängig. Ein Wechsel von Oracle zu Postgres bedeutet damit das Programm an vielen Stellen ändern zu müssen. Auch sind händisch erstellte Abfragen nicht immer optimal: Lazy loading von Entitäten, Caching Strategien und Transaktionssteuerung können sehr aufwendig werden. Dazu gesellen sich der relativ hohe Wartungsaufwand und die Gefahr von Fehlern die erst zur Laufzeit entdeckt werden.Das Beispielprojekt wird ein einfaches Adressbuch, dabei werden Personen und ihre zugehörigen Adressen gespeichert. Im ersten Teil beschäftigen wir uns damit die Projektstruktur einzurichten, und die nötigen Bibliotheken zu installieren.

Dependencies

JPA selber ist lediglich eine API – diese wird durch einen sogenannten JPA Provider implementiert. Hibernate, OpenJPA und EclipseLink (bzw. Oracle Toplink) sind Beispiele fuer JPA Provider, die als OpenSource zur Verfuegung stehen und auch kommerziell verwendet werden koennen.
Am einfachsten lassen sich diese Abhaengigkeiten durch Maven erfuellen, Maven kuemmert sich dabei um Download der direkten und indirekten (transistiven) Dependencies. Fuer diejenigen, die bereits Maven Erfahrung haben und Maven mit JPA nutzen moechten, hier ein Beispiel (weiter unten findet sich ein fertiges Eclipse Projekt ohne Maven zum Download) fuer Hibernate als JPA Provider (und SLF4J zum Loggen):
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>3.4.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.4.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-c3p0</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.10</version>
</dependency>
</dependencies>

Manuelle Einrichtung

Hier eine Liste der nötigen Bibliotheken, für diejenigen, die von Hand (beinhaltet alle transitiven Abhängigkeiten) das Projekt konfigurieren möchten:

• antlr-2.7.6.jar
• c3p0-0.9.1.jar
• commons-collections-3.1.jar
• commons-logging-1.0.4.jar
• dom4j-1.6.1.jar
• ehcache-1.2.3.jar
• ejb3-persistence-1.0.2.GA.jar
• hibernate-annotations-3.4.0.GA.jar
• hibernate-c3p0-3.3.2.GA.jar
• hibernate-commons-annotations-3.1.0.GA.jar
• hibernate-core-3.3.2.GA.jar
• hibernate-ehcache-3.3.2.GA.jar
• hibernate-entitymanager-3.4.0.GA.jar
• hsqldb-1.8.0.10.jar
• javassist-3.4.GA.jar
• jta-1.1.jar
• slf4j-api-1.5.8.jar
• slf4j-simple-1.5.8.jar
• xml-apis-1.0.b2.jar

Diese JAR Dateien werden in den Classpath gelegt, normalerweise in einen “lib” Ordner, und anschließend wird der Classpath entsprechend konfiguriert. (In Eclipse über Rechtsklick auf das Projekt “Properties” im Menü auswählen, dann “Java Build Path” und dort mittels “Add JARs” die entsprechenden Dateien hinzufügen.)

JPA Projekt Download

Der Download als fertiges Eclipse Projekt (hier: Eclipse JPA Project) beinhaltet die nötigen JAR Dateien im “lib” Ordner, ist bereits entsprechend konfiguriert und benötigt kein Maven oder andere externe Tools.  (Die Ordnerstruktur verwendet jedoch die Maven Verzeichnisstruktur, was jedoch keine große Umstellung bedeuten sollte.)

Für dies Beispiel wird hsql als Datenbank verwendet, und dabei separat gestartet. Je nach Anwendung (Desktop oder Server) würde man in der Regel eine eingebettete Datenbank (Swing/Desktop Anwendung) oder eine externe Datenbank (Java Enterprise Application) verwenden. Hsql bietet den Betrieb als Embedded- und Standalone-Datenkbank an, dabei ist die JAR Datei mit rund 700kb relativ schlank und kann somit sehr gut für dieses Tutorial eingesetzt werden.

Um HSQL zu konfigurieren gibt es die Datei “server.properties”, die eine Datenbank konfiguriert, die in dem Ordner “db” abgelegt wird, “addressbook” heisst und auch als “addressbook” angesprochen wird.
Server properties:
server.database.0=db/addressbook
server.dbname.0=addressbook

Von der Kommandozeile startet man den HSQL Server dann aus dem Projekt Verzeichnis in dem sich der “db” Ordner, der “lib” Ordner mit der hsqldb JAR Datei  und die “server.properties” Datei befindet:
java -cp lib/hsqldb-1.8.0.10.jar org.hsqldb.Server

Damit ist die Vorbereitung der serverseitigen JPA Infrastruktur abgeschlossen, die nächsten Schritte beinhalten die Einrichtung von JPA Provider, Verbindung zur Datenbank und welche Java Klassen wie auf die Datenbank abgebildet werden sollen.
(Zum besseren Vergleich zwischen Hibernate und JPA beinhaltet das Beispielprojekt auch die entsprechende native Hibernate Konfiguration und die Hibernate API Aufrufe in separaten Klassen. Mehr dazu in den folgenden Artikeln.)

Weitere Artikel:

1. JPA Einführung: Entity Klassen
2. Java Testing best practice: Projekt Organisation

Hi again,

these days i’ve got the problem that i need to add a version number to the SteelSeries java component library and to be honest i had no idea how to realize it.

So after a short internet research i figured out that there is the ability to add version information to the manifest file that’s included in a jar file.

If you do not know what a manifest is or how it is embedded in the jar file you will find a detailled description here.

Now that i knew where to put the version information the question was how to get Netbeans adding this information automaticaly to the manifest file during the build process. Well Netbeans is using Ant under the hood to build your projects and because i knew ant build scripts from using the Hudson Continues Integration server it was easy to achieve this.

First of all you have to locate the build.xml file in your Netbeans projects folder. Simply open it in Netbeans itself and you will see something like this…

<?xml version="1.0" encoding="UTF-8"?>
<!-- You may freely edit this file. See commented blocks below for -->
<!-- some examples of how to customize the build. -->
<!-- (If you delete it and reopen the project it will be recreated.) -->
<!-- By default, only the Clean and Build commands use this build script. -->
<!-- Commands such as Run, Debug, and Test only use this build script if -->
<!-- the Compile on Save feature is turned off for the project. -->
<!-- You can turn off the Compile on Save (or Deploy on Save) setting -->
<!-- in the project's Project Properties dialog box.-->
<project name="SteelTest" default="default" basedir=".">
    <description>Builds, tests, and runs the project SteelTest.</description>
    <import file="nbproject/build-impl.xml"/>
    <!--
    There exist several targets which are by default empty and which can be 
    used for execution of your tasks. These targets are usually executed 
    before and after some main targets. They are: 
      -pre-init:                 called before initialization of project properties
      -post-init:                called after initialization of project properties
      -pre-compile:              called before javac compilation
      -post-compile:             called after javac compilation
      -pre-compile-single:       called before javac compilation of single file
      -post-compile-single:      called after javac compilation of single file
      -pre-compile-test:         called before javac compilation of JUnit tests
      -post-compile-test:        called after javac compilation of JUnit tests
      -pre-compile-test-single:  called before javac compilation of single JUnit test
      -post-compile-test-single: called after javac compilation of single JUunit test
      -pre-jar:                  called before JAR building
      -post-jar:                 called after JAR building
      -post-clean:               called after cleaning build products
    (Targets beginning with '-' are not intended to be called on their own.)
    Example of inserting an obfuscator after compilation could look like this:
        <target name="-post-compile">
            <obfuscate>
                <fileset dir="${build.classes.dir}"/>
            </obfuscate>
        </target>
    For list of available properties check the imported 
    nbproject/build-impl.xml file. 
    Another way to customize the build is by overriding existing main targets.
    The targets of interest are: 
      -init-macrodef-javac:     defines macro for javac compilation
      -init-macrodef-junit:     defines macro for junit execution
      -init-macrodef-debug:     defines macro for class debugging
      -init-macrodef-java:      defines macro for class execution
      -do-jar-with-manifest:    JAR building (if you are using a manifest)
      -do-jar-without-manifest: JAR building (if you are not using a manifest)
      run:                      execution of project 
      -javadoc-build:           Javadoc generation
      test-report:              JUnit report generation
    An example of overriding the target for project execution could look like this:
        <target name="run" depends="SteelTest-impl.jar">
            <exec dir="bin" executable="launcher.exe">
                <arg file="${dist.jar}"/>
            </exec>
        </target>
    Notice that the overridden target depends on the jar target and not only on 
    the compile target as the regular run target does. Again, for a list of available 
    properties which you can use, check the target you are overriding in the
    nbproject/build-impl.xml file. 
    -->

P L A C E   T H E   F O L L O W I N G   T A R G E T S   H E R E   !   !   !

</project>

Like it’s described in the text above there are different hooks where you could add your own stuff into the ant build script. Thinking about what kind of information to add to the manifest file i decided to not only add a version number but also a build number and in addition to this the subversion revision. This could be useful if someone would like to check out the sources for a specific version of the jar.

Means i need three things:

• version number
• build number
• subversion revision

To achieve this information i will use two hooks in the build script

• -post init
• -post jar

Getting the subversion revision is easy and i found a ant target for this that looks like this…

   <!-- Extract the svn revision from subversion -->

   <target name="-post-init" description="Get the svn revision of the current build">
       <exec outputproperty="svna.version" executable="svnversion">
           <arg value="-c" />
           <redirector>
               <outputfilterchain>
                   <tokenfilter>
                       <replaceregex pattern="^[0-9]*:?" replace="" flags="g"/>
                       <replaceregex pattern="M" replace="" flags="g"/>
                   </tokenfilter>
               </outputfilterchain>
           </redirector>
       </exec>
   </target>

Next thing we need is the version and the build number. Ant is able to create a automatic increasing buildnumber everytime you run the build script so this is also no big deal. The version number could either be read from a text file or hardcoded in the build script.

In this example i hardcoded the version number directly into the build file because this number won’t change very often.

In addition to the version and build numbering you might also want to sign your jar automaticaly after it’s creation, well that’s again easy to achieve in ant but lets have a look at the ant target…

<!-- Add the version information to the jar, sign the jar and create
     create a copy of the jar containing the version number in the filename -->
<target name="-post-jar">
    <property name="version.num" value="1.0" />
    <buildnumber file="build.num" />
    <tstamp>
        <format property="NOW" pattern="yyyy-MM-dd HH:mm:ss z" />
    </tstamp>
    
    <!-- Add the version information to the manifest file -->
    <jar>
        <manifest>
           <attribute name="PROJECT_NAME-Version" value="${version.num}.${build.number}" />
           <attribute name="PROJECT_NAME-SVN-Revision" value="${svna.version}" />
           <attribute name="PROJECT_NAME-BuildStamp" value="${NOW}" />
       </manifest>
  </jar>

    <!--Sign the jar file with you credentials -->
    <!--<signjar jar="${dist.jar}" alias="..." keystore="..." storepass="..." />-->
    
    <!-- Make a copy of the jar file and add the version number to the filename -->
    <copy file="${dist.jar}" tofile="${dist.dir}/PROJECT_NAME-${version.num}.jar" />
</target>

So as you can see in the file above the buildnumber will be generated by the tag <buildnumber> and will be stored in a file called “build.num”. If this file isn’t present it will be created automaticaly (might make sense to delete it for every new major version).

If you copy and paste this targets in the build.xml file of your project you only have to replace the PROJECT_NAME in the above examples with your project name and modify the version number and you are ready to go.

These modifications to the build.xml file will give you the following result in the manifest file of your jar.

Manifest-Version: 1.0

Ant-Version: Apache Ant 1.8.1

Created-By: 1.6.0_20-b02-279-10M3065 (Apple Inc.)

PROJECT_NAME-Version: 1.0.1

PROJECT_NAME-SVN-Revision: 1

PROJECT_NAME-BuildStamp: 2010-09-30 09:58:38 MESZ

For me this was the solution i was looking for but if someone has a trick how to improve it…PLEASE LET ME KNOW !!!

Follow me on twitter if you like…

Weitere Artikel:

1. Using Smack xmpp lib on Android with Netbeans
2. Netbeans Platform certified Training
3. Swing Weather Worldclock

Hi there,

this is just to inform you that there is a updated version of the Java Swing component library “SteelSeries” available.

I added 10 more components…

There are radial bargraphs which you could see below

In addition to these i added another version of the Radial2 component which is called Radial2Top

The last component i added is called RadialCounter. I saw this kind of component during a visit of a german u-boat

where it was used to visualize the depth of the boat.

In addition to the new components there a some more modifications like colored tickmarks etc.

For more info please go to http://www.harmonic-code.org

Follow me on twitter if you like…

Weitere Artikel:

1. SteelSeries Java Swing component library
2. Devoxx update
3. Devoxx update #2

Here we go again…

A few months ago i started a new project where i again focussed on gauges (i love that stuff). It took me some time because i only work on the project on my spare time (which is rare) but now i finished a first version of a little library that contains a lot of gauges for Java applications…

First of all i have to mention that this library was not meant to be a professional components library and should not be used on mission critical software. Means if you use the library it’s on your own risk !

I’ve never before created a component library and for me it was and is a great challenge to dive deeper into the Java universe…

But now let’s have some fun…

The library contains two general types of gauges, radial and linear ones and some little candy in the form of additional components like a Radar component etc.

I add some properties to the gauges that hopefuly will be useful for some of you.

Here is a short list of the most interesting features:

• frameDesign (metal, shiny metal, blackmetal)
• backgroundColor (dark gray, light gray, white, black, beige, red, green blue)
• pointer/bar color (red, green, blue, yellow, orange)
• a three colored track to visualize areas of special interest (e.g. a critical temperature range)
• thresholdIndicator
• blinking threshold led (red, green, blue, orange, yellow)
• adjustable tickmarks
• indicators for min. and max. measured values
• auto reset to zero feature

It should be possible for you to create your own components out of these library and  if you’ll take a look at the source you will find components like Radial1Lcd, Radial2Lcd and Radial3Lcd where i used Netbeans matisse gui builder to create the component from the FrameCircular and DisplaySingle components.

So you should be able to check read the sourcecode of these components and see how i did it (the easiest way would be to use Netbeans to check the source).

But to give you a impression, let pictures speak…Radial gauges…

Radial4 component

backgroundColor: beige

frameDesign: blackMetal

pointerColor: orange

ledColor: orange

Radial2Lcd component

backgroundColor: white

frameDesign: metal

pointerColor: red

ledColor: red

lcdColor: beige

digitalFont

Radial4 component

backgroundColor: black

frameDesign: shinyMetal

pointerColor: green

track: 70, 90, 100

Radial1Square component

backgroundColor: green

frameDesign: metal

pointerColor: red

ledColor: yellow

track: 0, 50, 100

Radial3Lcd component

backgroundColor: lightGray

frameDesign: blackMetal

pointerColor: blue

ledColor: blue

lcdColor: blueBlue

track: 40, 55, 70

Radial1Vertical component

backgroundColor: beige

frameDesign: metal

pointerColor: red

ledColor: red

Radial1Vertical component

backgroundColor: white

frameDesign: blackMetal

pointerColor: yellow

ledColor: orange

track: 0, 75, 100

threshold: 75

DigitalRadialLcd component

backgroundColor: black

frameDesign: blackMetal

lcdColor: green

DisplayCircular component

backgroundColor: blue

frameDesign: shinyMetal

digitalFont

Linear gauges…

Linear component

backgroundColor: darkGray

frameDesign: metal

ledColor: orange

valueColor: orange

track: 70, 85, 100

threshold: 50

vertical orientation

Linear component

backgroundColor: beige

frameDesign: blackMetal

ledColor: red

valueColor: red

lcdColor: green

digitalFont

minMeasuredValue: 0

maxMeasuredValue: 70

vertical orientation

Linear component

backgroundColor: white

frameDesign: shinyMetal

valueColor: green

ledColor: green

track 80, 90, 100

threshold: 80

orientation: horizontal

Linear component

backgroundColor: lightGray

frameDesign: blackMetal

valueColor: yellow

ledColor: yellow

lcdColor: standard

track: 0, 70, 100

Altimeter component

A component that behave like a altimeter that you might know from airplanes. It has three pointers

10 ft        :  the big fast pointer

100 ft      : the smaller slower pointer

1000 ft    : the pointer with the triangle at the end, moving very slow

Clock component

Just a simple analog clock component in the same look as the other gauges.

Compass component

A compass component that takes values in the range from -360…360 degrees.

Level component

A clinometer component that takes values in the range from -360…360 degrees.

Radar component

This is a little bit special component that like a lot. You could define a home position in the component which will then represent the center of the component.

Now you could add poi objects that represent locations defined by their latitude and longitude and the component will show these poi’s on the screen if they are in the range of the radar which could be defined.

This means if you read out data from a gps device and set the home position to the current position of the gps from time to time you could add some poi’s and they will appear and disappear on the radar screen when you move…

Download the library here…

I also create a project on Kenai where you could download the sourcecode or might want to participate…

There is a special blog that i created to present my Java Swing related stuff in more detail, please find it here. In that blog i will try to give you a more detailed view at the creation of these components.

Follow me on twitter if you like…

Weitere Artikel:

1. Custom swing component
2. SteelSeries update
3. Java AutoConversion textfield component

Just a short blogpost about a little tool that i would like to share with you…
A few months ago i was creating a worldclock with a night and day display where i needed a conical gradient.
So what is a conical gradient ? Here we go…

You might think “ok, it looks nice but where is it useful ?”…well here are three little examples…

So if you would like to achieve these results without the conical gradient paint you have to rotate a line a change the color at every angle. This works out but if it comes to large angles you have to decrease the stepsize which leads to artifacts around the rotation center.

So the conical gradient paint is especialy useful when you work with rotationally symetrical stuff. With this kind of gradient you could get more realistic results of circular structures like the two buttons in the image above. On the left side i used a conical gradient and on the right side i used a linear gradient.

For most of the stuff the linear approach will work but the conical gradient gives you a more realistic shading. Things like the stainless steel button is hard to be generated without a gradient like this.

So let me show you some code to give you an idea of how to work with the ConicalGradientPaint:

The syntax is similar to the LinearGradientPaint and RadialGradientPaint where you define a float array that holds all the fractions of the gradient, a color array that holds all the colors for each fraction and a point that defines the rotation center of the gradient.

Additional to that standard parameters i added a indicator for the usage of degrees and a rotation offset.

Usage:

ConicalGradientPaint cgp = new ConicalGradientPaint(USE_DEGREES, CENTER, OFFSET, FRACTIONS, COLORS);

USE_DEGREES = true/false

CENTER = java.awt.geom.Point2D

OFFSET = float (either 0.0f – 1.0f or 0.0f – 360.0f)

FRACTIONS = float[] (either values from 0.0f..1.0f or from 0.0f..360.0f)

COLORS = java.awt.Color[]

// Code for a simple cone like from black over white to black
final Ellipse2D CONE = new Ellipse2D.Double(0, 0, 150, 150);

final Point2D CONE_CENTER = new Point2D.Double(CONE.getCenterX(), CONE.getCenterY());

final float[] CONE_FRACTIONS =
{
    0.0f,
    0.5f,
    1.0f
};

final java.awt.Color[] CONE_COLORS =
{
    java.awt.Color.BLACK,
    java.awt.Color.WHITE,
    java.awt.Color.BLACK
};

final ConicalGradientPaint CONE_GRADIENT = new ConicalGradientPaint(
	CONE_CENTER,
	CONE_FRACTIONS,
	CONE_COLORS);

G2.setPaint(CONE_GRADIENT);

G2.fill(CONE);

As you can see it’s not magic but simple stupid java code and with a little variation in colors and fractions you could achieve effects like the stainless steel button.

In my free time i’m working on a new component library (mostly gauges) where i also could use the conical gradient paint.

In the screenshot you could see that the gauge has a area from 10 to 60 where it has a gradient in the background. This gradient is also filled by the ConicalGradientPaint.

So you see it could be useful to have this kind of gradient available and for that reason i would like to share it with you…

Here is the source as zipped Netbeans project. It contains the ConicalGradient class and a little demo that will give you an idea of how to use the paint.

In this project you’ll also find a compiled jar that you could start and it will show you this

So enjoy Swing and follow me on twitter if you like…

Weitere Artikel:

1. FXG to Java2D converter
2. Swing Worldclock
3. Drawing in code (Part 2)

AutoConversion EditText component:

Yesterday i created a Java Swing textfield component that autoconverts a given value into a selectable unit which could be useful.

In the evening i got the idea to port this component to Android and see if it will work there.

Just as a short note…if you are a Java developer you should take a look into Android…it’s sooooo nice, porting the component tooks me not more than 2 hours (and i’m not really into Android development).

Here is the result:

So you could type in a value with the unit of your choice and after leaving the field the value will be converted into the EditText “base unit”.

I changed the units with special characters like µ, Å, ² and ³ to u, A, 2 and 3 which leads to units like:

um  <=>  µm

A <=>  Å

m2  <=>  m²

m3  <=>  m³

and so on…

The upper spinner will select the type of unit you would like to use.

The middle spinner will select the current base unit for the textfield.

The lower spinner will adjust the number of decimals for the textfield.

Because it displays the unit directly in the textfield there’s no need for a additional label for the unit.

You also might check this little video

Well again this is nothing very fancy or gui related but it was a nice challange for me so i decided to share it with you… AutoConversionField.zip

follow me on twitter if you like…

Weitere Artikel:

1. Java AutoConversion textfield component
2. Using Smack xmpp lib on Android with Netbeans
3. SteelSeries Java Swing component library

AutoConversion textfield component:

If you drive a motorized stage of a microscope you often have to handle coordinates in a unit like millimeter [mm]. But it might happen that the sample in your microscope is only in the range of microns [µm].

So would it not be nice to directly type in the coordinates in µm and the textfield would automaticaly convert the unit into [mm] ?

This would increase the workflow a lot because you do not have to think about conversion of units. There seems to be countries that are using inches and people living there might like to type in coordinates in inches instead of millimeters..etc…

For this reason i created a little component that extends a standard javax.swing.JTextField and is now able to do the conversion. You could also use the conversion alone without the textfield to create some kind of unit converter…it’s up to you.

Here are a few screenshots of a demo app that uses the component:

So you could type in a value with the unit of your choice and after leaving the field or pressing enter the value will be converted into the textfields “base unit”.

The upper combobox will select the type of unit you would like to use (it supports angle, area, length, mass, temperature, time at the moment but one could easily add more units to it).

The middle combobox will select the current base unit for the textfield.

The lower combobox will adjust the number of decimals for the textfield.

Because it displays the unit directly in the textfield there’s no need for a additional label for the unit.

You also might check this little video

Well this is nothing very fancy or gui related but it was very useful for me so i decided to share it with you… ConversionField.zip

follow me on twitter if you like…

Weitere Artikel:

1. Android AutoConversion EditText component
2. SteelSeries Java Swing component library
3. Custom swing component