CMake in Apache NetBeans

 How to use CMake in Apache NetBeans

As of this writing, the C/C++ plugin for NetBeans has not yet been donated to Apache by Oracle. However, you can still download and install the plugin.

1. Navigate to Tools -> Plugins, click on Settings tab and add the following update center if not already added: NetBeans 8.2 Plugin Portal, URL: http://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz.
2.  Click on Available Plugins tab and select the C/C++ plugin and click on Install.

If you run Apache NetBeans with JDK 14, then the installation will fail: 

The Plugin Installer found problem timeout of loading C/C++ Repository[org.netbeans.modules.cnd.repository/1.32.6.1] while install the following plugins) . 

You may check which JDK version you are running Apache NetBeans by clicking on Help -> About (Windows, Linux) or NetBeans -> About (MacOSX). This depends on the default JDK on your system, or if you have set netbeans_jdkhome in etc/netbeans.conf file to JDK 14. In that case, a solution is provided by this link:

1. Copy pack200(.exe) and unpack200(.exe) to jdk-14/bin from a previous JDK version.

 Assuming that cmake is already installed in your system, before you are able to use it in NetBeans, you need to first set it up:

1. Click on Tools -> Options (Windows, Linux) or NetBeans -> Preferences (MacOSX) and then on C/C++ button and select the Build Tools tab.
2. Fill in the CMake Command: with the path of cmake in your system (e.g. /usr/lib/cmake)
3. Click OK

 Assuming that you have already created the CMakeLists.txt file inside the folder of your C/C++ project: 

1. Select File -> New Project, then the C/C++ category and then the Project: C/C++ Project with Existing Sources. 
2. Specify the folder that contains existing sources and leave the rest settings the default, i.e. checked Use Build Analyzer and Automatic configuration mode. The Next button is enabled, which means by clicking it, NetBeans runs the cmake command to generate the Makefile and builds the project automatically.
   

 

OpenJDK How to Build

OpenJDK is the reference implementation of any JDK Enhancement Proposals (JEPs) or even Java Specification Requests (JSRs). You might have many reasons why you want to build it from sources and don't download one of the pre-built binaries, e.g.:

• company policy that enforces you to build open source projects from source
• you wish to get access to the latest early access OpenJDK
• you want a build for your special platform

You can download latest OpenJDK 9 binaries from this page. Sources can be found in the Mercurial repositories. E.g. OpenJDK 9 repos are here; project Jigsaw repo contains the hitting edge of the modular implementation, if you wish to be in the hitting edge. Below, you get some tips on how to build OpenJDK 9.

1. Clone the JDK 9 Master mercurial repository. 
2. Read the README or README-builds.html file for more instructions.
3. Next step before you start building is to execute: bash get_source.sh or ./get_source.sh if your shell is already bash. It is very important, after each update to call this command. The reason is that hg update only updates the master repository. OpenJDK consists of a number of mercurial repositories which need to be updated, too. This can be done by the get_source.sh command.
   
4. ./configure --disable-warnings-as-errors
5. sudo make all

The above commands build the latest version of OpenJDK. If you wish to build an earlier version of OpenJDK you need to follow these tips:

1. hg up [tag]  e.g. jdk-9+147
2. cd corba
3. hg up [tag]  e.g. jdk-9+147
4. Repeat steps 2 & 3 for directories: hotspot, jaxp, jaxws, jdk, langtools, nashorn 
5. ./configure --disable-warnings-as-errors
6. sudo make clean
7. sudo make all

Best luck for your OpenJDK builds.

Book review: Mastering Lambdas: Java Programming in a Multicore World

Book review: Mastering Lambdas: Java Programming in a Multicore World

Best practices for using Lambda Expressions and Streams

by Maurice Naftalin

"Expensive perfumes come in small bottles" they say.
λ-programming is the new top feature of Java 8 the one that will mostly change the way Java programmers program. While other books on the topic go into describing the new API providing simple examples, Maurice's book follows a more pragmatic way, describing "Best practices for Using Lambda expressions and Streams". The book tackles difficult topics and doesn't provide simple examples to just demonstrate the API usage like other books do. The author tries to introduce the reader on the new way of thinking in a functional way by using his experience in solving complex problems. E.g. he writes an implementation of the UNIX grep command using lambdas and explains how to do it and what errors one has to tackle to achieve their target. He also devotes a whole chapter on streams' performance. He explains the difference between static, bound and unbound instance method references as well as how overloading works. And many more practical problems that someone might come up with while using lambdas and streams.
In more detail:
In Chapter 1 Maurice lays the pillars for the reasoning about these new Java 8 features that will analyse in the rest of his book:

• from internal to external iteration
• from collections to streams 
• from sequential to parallel

He goes into the details of explaining the reasoning behind the design solutions and selected syntax of the above topics convincing the reader of how naturally these changes were introduced into the language.
Chapter 2 is devoted to lambda expressions. It compares lambdas to anonymous inner classes, he talks about variable capture (a.k.a. closures), and moves on to functional interfaces. The sub-chapters are as concise as they should be. He explains the difference between static, bound and unbound instance method references (do you know the difference?) and ends up with (function) type checking and the rules of overloading resolution (both with lambda expressions and method references).
Chapter 3 provides an introduction to streams by comparing them to pipelines. He describes how to start a stream (pipeline), how to transform it (e.g. filtering, mapping, sorting, truncating etc.) and how to end it (e.g. reduce, collect, search etc.). He touches parallelism and debugging. He provides useful and pragmatic examples.
Chapter 4 talks about how to end streams, i.e. about reductions and collections. He also goes into the pain of explaining how to write your own collector. Everything is explained with diagrams on how they work as well as with working examples.
Chapter 5 talks about how to create streams, i.e. sources and spliterators. Here he introduces the worked example of a recursive grep command.
Chapter 6 tackles stream performance. He uses jmh to microbenchmark sequential and parallel streams, sorting, distinct, spliterators, collectors etc. Parallel streams aren't always faster than sequential streams but they must satisfy some conditions to perform better.
Chapter 7, finally, talks about how default methods allow the API to evolve keeping backwards compatibility at the same time.
Small and to the point, all in all a very useful book on the subject, one that you 'll revisit again and again while programming with the new lambdas and stream APIs in Java 8.
Maurice Naftalin is the author of another famous book "Java Generics and Collections" and maintains the lambda FAQ from which he has gained a long experience about the new API. His new book should be under the pillow of every Java developer.

Tip: What is wrong with this code?

import javax.swing.*;


public class GuiExample {
    public static void main(String[] args) {
        createGui();
    }

    private static void createGui() {
      final JFrame frame = new JFrame();
      JButton button = new JButton("Click me!");
      button.addActionListener(
            new ActionListener() {
                   public void actionPerformed(ActionEvent e) {
                        JOptionPane.showMessageDialog(frame, "Button clicked!");
            }
      });
      frame.getContentPane().add(button);
      frame.setSize(100, 80);
      frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      frame.setVisible(true);

   }
}

...
...
...
...
...
...
...
...
...

Answer: It should be executed in the AWT thread!


import javax.swing.*;


public class GuiExample {
    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Runnable() {
            @Override
            public void run() {
                createGui();   
            }
        });

    }

    ...
}

or using the new Java8 syntax:

SwingUtilities.invokeLater(() -> createGui());

Tip: Is this code thread safe?

import java.util.*;

public class AlertProvider {
  private final List<Alert> alerts = Collections.synchronizedList(new ArrayList<>(10));

  public Collection<Alert> getAlerts() {
    return Collections.unmodifiableCollection(alerts);
  }

  private final static AlertProvider instance = new AlertProvider();

  public static AlertProvider getInstance() {
    return instance;
  }

  public boolean addAlert(Alert alert) {
    return alerts.add(alert);
  }

  public boolean removeAlert(Alert alert) {
    return alerts.remove(alert);
  }

  public void removeAll() {
     Collection<Alert> toRemove = new ArrayList<>();
     for (Alert alert : getAlerts()) {
        if (alert.canBeDeleted()) {
           toRemove.add(alert);
        }
     }
     alerts.removeAll(toRemove);
  }

  public Collection find(final String key) {
     Collection<Alert> alertsFound = new ArrayList<>();
     if (key != null) {
        for (Alert alert : alerts) {
           if (alert.getDescription().contains(key)) {
              alertsFound.add(alert);
           }
        }
     }
     return Collections.unmodifiableCollection(alertsFound);
  }
}


The answer is no. It throws a ConcurrentModificationException. But why? We do have 'secured' our alerts list to be a synchronizedList.

...
...
...
...
...
...
...
...
...

The problem is that while one thread accesses the alerts list, another thread may modify the list. So how can we solve the ConcurrentModificationException?

private final List<Alert> alerts = new CopyOnWriteArrayList<>());

This creates a copy of your list on each modification of its elements. If you don't store many elements to your list you shouldn't worry about performance. 
Most developers will go away with this change and they are done. Our class is not fully thread safe though. The other lists used inside some of its methods are not thread safe. So either you also make them CopyOnWriteArrayLists or use the synchronized block as shown below.



import java.util.*;

public class AlertProvider {
  private final List<Alert> alerts = new CopyOnWriteArrayList<>();

  public Collection<Alert> getAlerts() {
    return Collections.unmodifiableCollection(alerts);
  }

  private final static AlertProvider instance = new AlertProvider();

  public static AlertProvider getInstance() {
    return instance;
  }

  public boolean addAlert(Alert alert) {
    return alerts.add(alert);
  }

  public boolean removeAlert(Alert alert) {
    return alerts.remove(alert);
  }

  public void removeAll() {
     Collection<Alert> toRemove = new ArrayList<>();
     for (Alert alert : getAlerts()) {
        if (alert.canBeDeleted()) {
          synchronized(toRemove) {
           toRemove.add(alert);
          }
        }
     }
     alerts.removeAll(toRemove);
  }

  public Collection find(final String key) {
     Collection<Alert> alertsFound = new ArrayList<>();
     if (key != null) {
        for (Alert alert : alerts) {
           if (alert.getDescription().contains(key)) {
             synchronized(alertsFound) {
              alertsFound.add(alert);
             }
           }
        }
     }
     return Collections.unmodifiableCollection(alertsFound);
  }
}

A few things about software design

While there are a number of frameworks for web development (JEE, Spring etc.) that provide Off-The-Shelf design guidelines to help developers structuring their code, standalone (desktop) applications lack one. It is unfortunate to see even very good developers having difficulties in designing their code and creating spaghetti code.

Software design should be simple. In this blog entry we present some simple guidelines to good design. The Model-View-Controller (MVC) software architecture will be used. Even though the examples are in Java, these guidelines can be easily applied to other Object-oriented programming languages.

1. Software officially starts from the requirements (most of the time). You should seek for a formal document that describes what you have to do, or put them down to paper (or in electronic form). Start by identifying the domain objects; these represent entities of the real world most of the time. E.g. if you have to develop an electronic library system, then your domain objects would be: Book, Librarian, User, etc. Try to identify the attributes (fields) of each domain object, e.g. for the Book(ISBN, title, authors, pages) etc. Assuming Java as your programming language, you should create 3 packages: model, view, controller. Inside model, create a domainobjects sub-package and inside there create the domain objects as Plain Old Java Objects (POJOs) or Value Objects (VOs). These should only contain the attributes and getters/setters. They are the base of your application, the objects that hold and transfer your data. They should contain no processing logic, like e.g. extractMessageFromNetworkObject() or parseWsdl(). Think that you should be able to directly persist them to a database. This way you can populate them from different sources (database, network, web services) without any change to them.
2. Then you should be able to populate the domain objects with data. This is the job of a controller. It could be a controller that parses a text file, or retrieves data from a database or a SOAP message etc. Ideally, it should be a utility class with static methods and no state. It should return a VO (domain object), e.g. public static Book getBookBy(String isbn); retrieves a Book record from the database and creates and returns a Book VO out of it.
3. To display the book data to the UI (an HTML form, a JavaFX client etc.), the view class should call the above controller to retrieve the Book object or another controller which will prepare the data according to the wishes of the view. This controller should ideally return the required data; the view should only deal with the presentation of the data, not their processing.
4. Some more guidelines that enforce encapsulation and low coupling. 
1. Avoid dependencies to attributes as much as possible; e.g. assume a method that calculates the key of Book to be used by the e-Library application as the id (could be ISBN too but too slow). This could be a private method of the Book class (since it is private it doesn't matter much and doesn't violate the POJO discipline). This method calculates the key based on information from ISBN, the title, the authors and the category (e.g. science, history etc.). Instead of creating a method calculateKey() that depends on the attributes isbn, title, category, authors,  the method signature should be calculateKey(String isbn, String title, Category category, List authors) and you should pass the attributes as parameters to the method, where it is being called inside the Book class. If you need to refactor this method to another class, you only need to modify the callers to the method and you are done!
2. Try to reduce dependencies among classes. Think twice before you create a new dependency to another class and take a minute to think of the consequences. Think what could be changed in the future and what the impact will be. You should be able to easily refactor your code. Keep it simple.
3. Try to use design patterns but don't overdo it. Design patterns provide a clean design that most of the time can be proved a good choice for future changes of requirements. You choose which design pattern might be appropriate for your problem by its intent.
4. Comment your code; use javadoc and ideally a Software Architecture/Design Document. Unecessary documented code is much better than no comments at all. There you describe your intent, things for other developers to pay attention to, source (e.g. URL) of your algorithm, TODOs, the design pattern you use (or use annotations) etc. Your code is self-explanatory only to you. Not everybody thinks your way. 

JCrete 2013

The JCrete 2013 open conference will take place from 19-22 August and there are still a few empty seats. So don't wait. Book now.

This is the only conference where you can:

• meet Java Champions and geeks that share the same interests as you
• learn about the latest technologies in the field
• get hands-on experience directly from the experts by the swimming pool
• participate in the organisation of the event (Open Spaces conference or unconference)
• present your project, your experience, your expertise (all presentations are under Creative Commons-Attribution-ShareAlike 3.0 license)
• explore Crete and enjoy the Mediteranean sea and sun
• discover the unique Cretan hospitality and taste the most delicious Cretan cuisine
• make friends

And as the best things in life, it is FREE!

This year again we have some top participants/speakers like Java Champions Heinz Kabutz and Kirk Pepperdine, Maurice Naftalin (λ), Martin Thompson (Mechanical Sympathy), Sven Reimers just to mention a few.

It is going to be an unforgetable event. GUARANTEED!

UPDATE (5 Sep 2013)! Well, the event is over. It was the best of all we have organised till today. See you next year!