I've always had a pet peeve that introductory Java books teach developers the bad habit of using the static keyword and executing business logic code in the main method.  I believe this is done in part out of a misguided intention of avoiding confusion, but also out of laziness.

 I've seen lots of bugs and unmaintainable architectural choices (some subtle, some not)  introduced by overuse of static references and methods, and find myself wondering how much of this is attributable to the failure of Java teachers to make the distinction between class and object clearer from the outset. 

 I'm very pleased to see BlueJ (which I first learned of here on JTraining) as an effort to remedy this general failure in Java and OO programming training. 

Java is a great programming language, but everyone who uses the term knows that it is much more than that. At a minimum, the term includes, the JVM, the API libraries (the language is almost useless without them.) Of course, in any practical application that includes so much more: frameworks, functional libraries, coding conventions, development infrastructure such as unit test and continuous build, and so on and so on.

 The gist of my post is that far beyond all these technical extensions to "Java" as a technical term, I tend to think of "Java" as a development and software engineering culture, and, for me, that culture implies an attitude of learning. The technology of the Java environment is evolving so quickly that learning is just plain part of the normal ongoing routine. 

Great developers are naturally part of great teams. Great teams are great in part because they allow their members to flourish and become great. A key element of that greatness, in my opinion and in my experience, depends on continuous, ongoing learning. 

De annotaties zijn al een tijdje ingeburgerd in Java en iedereen die ooit met Java 1.5 of hoger heeft gewerkt, zal het vertrouwde @-tje herkennen, maar hoe vaak heb je er nu een zelf gemaakt? Waarschijnlijk nooit, want dat is toch het domein van de Springs, Hibernates en andere frameworks in deze wereld. Hoe gaat het überhaupt in zijn werk? Het is namelijk geen onderdeel van een of ander certificaat.
Op internet zijn wel wat dingen te vinden over hoe annotaties te maken, maar daarbij valt me op dat er nooit wordt ingegaan op zogenaamde runtime annotaties, annotaties die je ook tijdens het runnen van jouw programma kunt gebruiken.

Annotaties zijn in feite niet meer dan interfaces:

public @interface Ranked {
      String column() default "";
}

Er vallen wel een aantal dingen op; voor het keyword interface staat een @-tje en de property declaratie ziet er heel verschillend uit. Ook ben je wat beperkt in je typekeuze voor een property. Alleen primitieve types, String, Class, annotaties en enums mogen of een 1-dimensionale array hiervan. Geen objecten dus. In de praktijk is dit echter niet echt een belemmering.
Het keyword default geeft, geheel verwacht, een standaard waarde aan de property. Als je dit keyword weglaat, is deze property verplicht om in te vullen.
De overige configuratie kun je op de interface annoteren en zal ik even de vier nuttigste opties doornemen:

@Retention:
Dit geeft aan wanneer een annotatie beschikbaar is op de class. Dit kan zijn alleen tijdens build-time, tijdens compile-time of tijdens runtime. Zie de enum RetentionPolicy.

@Target
Dit geeft aan waar de annotatie geldig is, bv. op types, fields of methods. Zie de enum ElementType.

@Documented
Dit geeft aan of de annotatie ook wordt meegenomen met de Javadoc.

@Inherited
Dit geeft aan of de annotatie ook wordt doorgegeven via inheritance.

Onze annotatie zie er na configuratie er als volgt uit:

@Retention(value=RetentionPolicy.RUNTIME)
@Target(value={ElementType.TYPE})
@Documented
public @interface Ranked {

}

Dus kunnen we deze annotatie tijdens runtime nog steeds gebruiken en mag deze alleen op classes worden gebruikt. De @Documented spreekt vanzelf.
Nu is de annotatie klaar voor gebruik op de bekend manier:

/*
* Deze class is geranked.
*/
@Ranked
public class Product {

}
 
Nu moeten we ook nog wat met deze property gaan doen, want ook al lijkt Spring soms magisch, het werkt niet vanzelf. Onze magie zit bijvoorbeeld in de DAO, waar we entiteiten met @Ranked automatisch sorteren. (Ja, ik weet dat dit ook kan met @Sort kan)

if (persistentClass.isAnnotationPresent(Ranked.class)) {
            return findByCriteriaOrdered(Order.desc(RANK));
}

Waar het hier om gaat is de method isAnnotationPresent van de class Class. Deze kijkt of een annotatie tijdens runtime (vandaar de RetentionPolicy) in de class aanwezig is. Als dat zo is, kun je daarmee iets doen, zoals hier gebeurd.

Dan Dyer shares 10 tips for publishing open source Java libraries. Read more at his original post.

He recommends to:

1. Make the download link prominent.

Probably most of the Java users is aware that String object is more complex than just an array of char. To make the usage of strings in Java more robust additional measures were taken – for instance the String pool was created to save memory by reusing the same String objects instead of allocating new ones.

Another optimisation that is adding the offset and count fields to the String object instances to improve the performance of substring() method. Even though this mechanism is very helpful in practice, not many people are aware how easily you can create a major memory leak because of that! (check out this article if you're interested). It is funny how in Java even simpliest stuff can bite you in your behind:)

Het uploaden van bestanden is vaak een niet-triviale taak. Eerst moet je het bestand worden gevalideerd op type en grootte, naar een tijdelijke bestemming worden gestreamed en daarna gekopieerd, wat nu al simpeler klinkt dan het is als je het zelf moet doen.
Met RichFaces wordt het echter een stuk simpeler, een oplossing die ik jullie niet wilde onthouden.

De component:

Met de <rich:fileUpload> tag plaats je de component. In mijn geval ziet het er als volgt uit:

<rich:fileUpload maxFilesQuantity="1"
            immediateUpload="true"  onsizerejected="alert('Uw bestand mag niet groter dan 1000KB zijn');"
            ontyperejected="alert('Alleen *.jpg, *.gif, *.png en *.bmp bestanden zijn toegestaan als plaatje');"
            acceptedTypes="jpg, gif, png, bmp"
            fileUploadListener="#{bean.upload}">
</rich:fileUpload>

Dit creëert een upload-component dat één plaatje accepteert en het meteen upload na het selecteren. Als het groter is dan 1000KB (te configureren als maxRequestSize init-param bij het rich-faces filter in web.xml) of als niet voldoet aan de bestandtype-eis, dan geeft dit component netjes een melding. De listener verwijst naar een specifiek event in de achterliggende bean.

public void upload(UploadEvent event) throws IOException {
        UploadItem item = event.getUploadItem();
        String filePath = //path waar het bestand naar toe moet

        File file = new File(filePath);
        file.createNewFile();
        FileOutputStream fos = new FileOutputStream(file);
        // In de web.xml is ook weer configureren of er  tijdelijke bestanden worden
        // gemaakt of dat alleen het geheugen wordt gebruikt. Standaard wordt er
        // gebruik gemaakt van tijdelijke bestanden.
        //<init-param>
        //   <param-name>createTempFiles</param-name>
        //   <param-value>true</param-value>
        //</init-param>   
        if (item.isTempFile()) {
            FileInputStream fis = new FileInputStream(item.getFile());
            IOUtils.write(IOUtils.toByteArray(fis), fos);
            fis.close();
        } else {
            IOUtils.write(item.getData(), fos);
        }
        fos.close();
}

Merk op dat ik bij deze code ook de IOUtils uit Apache Commons gebruik om de bestandsafhandeling aanzienlijk te vereenvoudigen.
Hiermee is het bestand geupload, inclusief nette afhandeling van eventuele fouten. Bedankt RichFaces!

As indicated by Jeanne Boyarsky, Oracle/Sun is reinventing the SCJP into the Sun Java Programmer Plus Certification.  The big difference is the new exam will require hands on programming instead of memorizing obscure details.

This exam is not yet implemented, but in beta stage and Sun is looking for interested developers to try out this new approach. If you're interested, you can sign up for this.

Personally, I think this is a good step. Currently, preparation for the exam seems to involve reading one or more exam preparation guides, memorizing APIs and getting your hands on a number of test exams. Good programmers who haven't done that will not automatically pass, but bad programmers who put in the right effort might. Of course, we'll have to wait and see how it will be implemented in the end.

Would you expect the following code to produce different results when comparing with '==' ?

Example 1:

Sinds een tijdje (ergens rond Eclipse 3.3/3.4) treedt er een lastig probleem op in de volgende situatie:

- Je hebt een web applicatie project in Eclipse
- Je bouwt de war met Maven
- Je deployed het binnen Eclipse met de standaard Tomcat-plugin