During the development of eosgi-e4-plugin, the following question was raised: How can we shut down the started OSGi container in the way that shutdown hooks are called?
I did a lot of searching, but could not find a satisfiable solution. Let’s see what I have found.
Executing kill command
There is the option to call kill command on Unix systems and send SIGINT or SIGTERM to the JVM. The problems with this:
- I do not want to execute one more process just to kill another one if not necessary
- There is no such command on Windows. There is no command in windows that can send SIGINT or SIGTERM to a process
Using JNA and Native calls
Another option is to use JNA. This works pretty well in Linux, but Windows is still a problem. One can call WM_CLOSE on every window of an application or send a Ctrl+C event to the console…
View original post 241 more words
In the last couple of years, I developed all of my codes in the way that all members and statics of every class were sorted by Eclipse. I recently joined a new project and it was surprising to me how much the other members of the team were against sorting the members. As always, I tried to understand their motivation and find the differences in our opinions.
Their main reason was the following:
I want to put the functions and variables that belong together next to each other, so I can see them together.
I saw their point. However, I did not agree with it and I could not convince them about my right. I told them:
If you used Git and code review before accepting pull requests, you would find it very annoying if non-fucntional code changes would divert your attention. By non-functional, I mean changing the order of functions or doing some code formatting.
That was not enough. How do you explain the benefit of code reviews and the drawbacks of non-functional changes in the code to someone, who has never used Git neither code reviews?
I still felt that there was something else, too. What did I miss in the argument? Why do I not care if the functions that are called from each other are not close to each other in the source code?
You can call me uppish, but in every development team in my life, I was much faster at code investigation than others. It had one reason. While the other programmers started to analyze the code as a book, I wanted to know only what I had to.
Imagine you are looking for the reason why a label has a specific value on the screen. While the others see the code snippet below:
I see only the following:
You see the difference? I care only about the code I need to know. After I find this code snippet, I will push CTRL+ALT+H to see where the current function is called from. I do not care if the caller function is before or behind this one. I will jump there and continue my investigation.
I look around myself, and see that most of the developers do not even know the most basic keyboard shortcuts of Eclipse:
- CTRL+SHIFT+T: Open a type
- F3: jump to definition
- CTRL+T: Type hierarchy in a pop-up. This is very useful during an investigation if we want to know where a method of an interface is implemented.
- CTRL+ALT+H: Call hierarchy. Where is this variable used or where is this method called from?
- CTRL+L: Jump to line. Very useful if we have a stacktrace and we want to start investigating the issue by line number.
I might have missed a couple of useful shortcut keys. What I wanted to express is that the ones who do code investigations without these, cannot call them experts. Their effectivity is way beyond the ones who know the tricks.
As soon as you start reading the code effectively, you will not care about the grouping of variables and functions at all. However, it will be very annoying if you see that others spend much energy on grouping, instead of concentrating on the business logic they want to implement. If you start thinking of grouping, you waste time and effectivity. You will never be as effective as others.
So why do I care about sorting the members at all? Why should I sort the members if it does not matter during code investigation? Because I want to make only those changes visible in my commits that have actual functional meaning. Without automated-sorting and very strict automated code-formatting in my IDE, I should spend a high amount of energy on reviewing my own commits before pushing them for code review.
We are happy to announce the first public release of Blobstore components. Blobstore allows the programmer to read and write binary large objects within atomic transactions.
Everit Blobstore has in-memory and JDBC-based implementations. While the in-memory implementation can be used to write unit tests, the other one supports several relational database types: Apache Derby, Hsqldb, MySQL, PostgreSQL, Microsoft SQLServer, Oracle
As always, the artifacts are available on maven-central.
For more information, see the site of Blobstore: http://www.everit.org/blobstore.html
After lots of work, ECM (Everit Component Model) is finally released. In the scope of the project several modules were developed:
- org.everit.osgi.capabilitycollector: A simple library that helps tracking references (currently OSGi services and Bundles). ECM uses this library to be able to track the references of components.
- org.everit.osgi.ecm.util.method: Helper methods to generate and parse method signatures and to locate methods based on the 112.9.4 Locating Component Methods chapter of OSGi Compendium specification.
- org.everit.osgi.ecm.metadata: To create a component, the engine needs a Class type and metadata that belongs to it.
- org.everit.osgi.ecm.annotation: Annotations of ECM, that can be used to describe the component functionality of a class
- org.everit.osgi.ecm.annotation.metadatabuilder: A simple utility library that can be used to generate Metadata (that can be passed to ECM Container Factory) from annotated classes.
- org.everit.osgi.ecm.component.api: API for ECM based Component development. This module contains interfaces like ComponentContext.
View original post 187 more words
Code generation improvements
- Property renaming possibility in lqmg xml files
- schema name is generated into metadata classes
- schema parameter is renamed to be capability
- unsatisfied wires can be modified to be optional during code generation (hackWires)