When you create a domain with --portbase 30000 option, you get the following ports:
Using port 30048 for Admin.
Using port 30080 for HTTP Instance.
Using port 30076 for JMS.
Using port 30037 for IIOP.
Using port 30081 for HTTP_SSL.
Using port 30038 for IIOP_SSL.
Using port 30039 for IIOP_MUTUALAUTH.
Using port 30086 for JMX_ADMIN.
Using port 30066 for OSGI_SHELL.
Of course, you may use different port bases (31000, 32000…) for different domains.
File locks control access to a file or a range of bytes within a file. This is necessary in situations where multiple simultaneously executing programs need to modify the same file.
File locking functionalities are provided within the NIO API, or more specifically in the java.nio.channels package.
The two most important classes for file locking are java.nio.channels.FileChannel and java.nio.channels.FileLock.
Several methods provide file locking:
lock() acquires an exclusive lock on the entire file, and blocks until the lock is acquired, tryLock() is identical but returns null if the lock cannot be acquired.
The methods with parameters lock only regions of a file, the shared parameter is true for a shared lock and false for an exclusive lock.
A shared lock prevents other concurrently-running programs from acquiring an overlapping exclusive lock, but does allow them to acquire overlapping shared locks. An exclusive lock prevents other programs from acquiring an overlapping lock of either type.
Once you don’t need the lock anymore, release it with FileLock.release().
That seems to be a great solution, but there are limitations, related to the operating system the JVM runs on:
MappedByteBuffer to access file.This post is a reply to Kent Tong’s post about scala’s getters and setters: http://agileskills2.org/blog/2010/01/applying_scala_to_solving_real_1.html:
You may also use the @BeanProperty annotation to generate Java-compatible getters and setters instead of weird methods with space and equal signs:
http://www.scala-lang.org/docu/files/api/scala/reflect/BeanProperty.html
In this post I share the list of my usual Maven documentation resources. I know there are much more resource available on the web, but these are the ones I use most of time. They contain any important information for Maven first-time users as well as a lot of useful stuff for everyday users.
If I had to choose one resource and recommend reading it, it would be the POM reference. The POM is the key to Maven, knowing how to use it is absolutely necessary. Effective project management can only be achieved if one knows how the POM elements should be used.
Better builds with Maven: http://www.topazproject.org/trac/attachment/wiki/MavenInfo/BetterBuildsWithMaven.pdf?format=raw
Maven definitive guide: http://www.sonatype.com/download_action.php?sid=kjvmqburc1ah86oeptk2iiuit2&file=books/maven-definitive-guide.pdf
Maven POM reference: http://maven.apache.org/pom.html
Maven settings reference: http://maven.apache.org/settings.html
Maven Handbook: http://www.sonatype.com/books/mhandbook/reference/
Maven Scala plugins: http://scala-tools.org/mvnsites/maven-scala-plugin/
Wicket with Maven: http://wicket.apache.org/getting-wicket.html
m2eclipse: http://www.sonatype.com/books/m2eclipse-book/reference/
This post is an answer to the post Dependency Injection Makes Your Code Worse
To me, Spring and other DI frameworks are only integration frameworks.
What I like about Spring? It’s simple AOP features, especially for transaction design. It’s integration with unit testing framework and the simplicity to write unit tests. And much more, but these are the features I use most.
When I develop, I always – I’m pretty sure it’s a key to good API design – imagine that I won’t use the code with DI. It always must be running fine in any other environment.
I often see programmers develop simple classes where they in fact should develop singletons (or factories or anything else), with the excuse that Spring makes singletons out of them (because only one instance exists in the application context). HAHAHA! To me this is an inexcusable mistake, and frameworks like Spring tend to make developers a bit too lazy or even unaware of some real problems.
Once my modules (simple JAR files, I think well designed from the point of view of OOP with Java) are developed, I use Spring (or not, but most often I do) to wire all these modules into one single application.
I also agree with the fact that XML application contexts are code as well as any other Java source code. But XML is easier to change than compiled code – especially in bureaucratic environments with heavy procedures.
As I consider Spring as an integration framework, I still recognize the flexibility it provides : develop, compile and package all your modules once, then wireframe them using some integration framework and package this new application. The modules may even be deployed to some Maven repository. For tests, I simply take the same modules, wire them differently and launch the tests.
The fact that we call Spring, Guice,… “DI frameworks” is something I dislike. It kinda sounds: if I have a dependency, use a DI framework. That’s not correct. If we’d call them “integration frameworks”, it would be clearer that we only should use them for module integration.
I totally agree that lazy programmers are too easily using Spring to try to solve issues that would be much more complicated with Java. And that’s not good for reusability. But it’s probably very efficient to deliver code on time. And that’s principally what programmers are paid for. Not for quality. Not for reusability. Not for good design.
Note that everytime I said “Spring”, I could have named any other similar DI framework.
What do you think about this?
To solve Eclipse 3.5.1′s strange button behaviour in wizard on Linux, execute:
export GDK_NATIVE_WINDOWS=true
before launching eclipse or add it to /usr/bin/eclipse
The object oriented programming paradigm involves developers to design code as classes. Classes associate data and behavior into one single abstraction.
That’s OK, but… how should one design code that only has behaviour or that only has data?
Is the class abstraction still the good one for cases where there is only behaviour? In this case, provided I use the Java language, I would design behaviour as static methods of final classes which cannot be instantiated. Is it then still OK to talk of classes? I think it’s not. The Scala language gives two answers to this problem: objects and functions. Objects are real singletons, and should be used to define behaviour or processes. Functions are like methods, but they are member of nothing, they are not associated to any class.
Is the class abstraction still the good one for cases where there is only data? A C-like structure would suffice in this case. And for people who want to benefit of encapsulation, use simple classes like JavaBeans. Without any other method than getters and setters. Or some immutable classes.
With respect to separation of concerns, is it right to put behaviour and data in the same abstraction? Doesn’t this make the OO design difficult? Most people fail to think correctly about behaviour when they design subclasses. They only think about the data. For more insights about this, see the real implications of the Liskov Substitution Principle (which is, IMO the most important principle of OO design).
And, if having to associate behaviour, why wouldn’t I design a ‘data class’ and a ‘static methods class’? Wouldn’t this make it easier to adhere to better OO design rules?
Today was a quite long day at Jazoon in Zurich.
In the morning I assisted to James Gosling’s Sun Opening Session. My opinion is that he didn’t say much. From such a personality as his one in the Java universe, I would have expected some vision of what Java’s future will be. He didn’t say much more than enumerate all devices where Java (or the JVM, which to his eyes is the key technology) is used.
I must say that I was surprised that he’s that tall. That was my only real surprise, lol.
Alois Reitbauer presented the difference between performance (caracteristics -latency, precision, response time, or whatelse – of an application systems) and scalability (the aptitude of an application to conserve its caracteristics under heavy load), than showed different ways to achieve scalability and showed how to determine if an application has performance or scalability issues. The conclusion, of his speech was that it’s important to determine during design phase exactly what kind of scalability must be achieved in the application. It’s the work of software architects and it’s up to them to determine this before the development takes place. Taking such decisions after development are impossible or very hard because the scalability goal of the application will have deep impact on the code.
Neal Ford made a review of several well know design patterns, most of them being ones from the GOF (Gang of four, Gamma et al.) and showed how easily or elegantly the issues they tackle may be solved using dynamic languages, mainly Groovy. Depending on the programming language, the solutions are more or less elegant. As the JVM supports a lot of programming languages, it’s possible to find ones providing elegant solutions to common problems.
Hans Dockter, the creator of Gradle, presented us this tool and compared it to popular build systems, like Ant or Maven. It looks like Gradle is somehow very powerful and learned from Ant’s or Maven’s limitations. Gradle seems to be well integrated to IntelliJ IDEA and provides some compatibility with Ant and Maven. I really can’t judge this tool much better, but I’m curious and willing to try it and see if it’s worth adopting.
This presentation covered the evolutions of Maven and showed what functionalities Maven 3 would have. It seems like Maven 3 is deeply rewritten et re-engineerd, when compared to Maven 2. I have several questions concerning this evolution:
This is kind of very obscure to me and I’m looking forward seeing what Maven3 will become.
Raed Haltman summarized what rules engines do, compared the commercial iLog to the open source Drools (which are only two of many other rules engines out there). He insisted in the fact that most SOA solutions are built upon rules engines, or at least that there exists evidence to this. Then he tried to show what rules engines are good for using his own experiences. And that’s when I was bored enough to leave. I’m really really really not interested in the details of someone’s experience. I’m only interested in concepts, rules, general lessons from experience. This does not give less interest to rules engines, which I believe are not enough well known by developers. It’s a paradigm that’s really often ignored by developers, if they even know its existence.
This was quite interesting, as there were some discussions about the evolution of the Java language. It seems like Sun won’t try to change the Java language to anything really different. The reason is: there is the fantastic tool that is the JVM, it enforces exception handling (unlike the CLR/C# – I have no idea if it’s true, it’s what was said), and there are many other languages available for the JVM, so it’s up to the developer to choose the best one. No need for a big company to support the language: Scala for example has support from a renowned university and that should be enough to convince clients and companies that Scala may be the best language for their developments.
My opinion is that the Java language sometimes really sucks, and does not always imply quality or productivity. And as long as no other big organisation will do real marketing around another language for the JVM, the Java language will remain the one that is most used, although Sun really seems to see no objection in the use of other languages.
Well, Neal Ford told a lot of things with a lot of humor and references to the Terminator (as well as some other movies about robots) movies. Well, what’s the point between science fiction and Java? Java is everywhere (confer James Goslings Opening Session this morning), Java or the JVM never were great innovations, but both have a really huge success in the past and still will have in the future. He predicts that robotics are going to become a technological trend in the future. He also predicted many other things, of whose I don’t remember all. I think he’s a crazy but brilliant person. He also predicted that the Clojure language will have some great success story on the JVM, as a LISP-like language. Maybe this will be the first real success of LISP. Oh, yes, I’ve almost forgotten: he mentioned that Samsung (at least that’s what I understood) builds killer robots (which are deployed at the border between South- and North-Korea), which I absolutely don’t like – I’ll try to avoid buying Samsung stuff from now on, and he mentioned that Apple (you know, this little computer company) is the biggest internet music retail company, and that they created a new trend using the iPhone.
This was not technical at all, but I must say that what I expected from James Gosling (some vision of Java’s future) was given to me by Neal Ford. I think it’s really important in a community/society to have people who are able to give some directions of thought, some ideas, and finally some visions to people, and Neal Ford does this quite well. But he’s really crazy. Robots still aren’t taking over the world. =)
I agree that I’ve never been told this at school. I more often heared: Learn more! Ivar Jacobson explained very simply how a lot of situations are making developer’s lives too complicated. He reminds us that software is developed by people, not by machines. That’s the most important point. He insisted on the point that doing refactorings and applying methods and now procedures and again refactorings won’t always save us, that software development is a question of trends (scrum – xp – rup – cmmi – …) and that no trend is really the ultimate one we need. The conclusion of this is that instead of refactoring from the beginning, we should try to tackle our problems one by one and sequentially reduce them, until we achieve to obtain good processes, good code quality, good design etc etc.
That’s all fine and it’s still not the end of the day.
BOF with Antonio Goncalvez (he’s written a book which you should definitely buy about JEE6 with Glassfish 3), Ludovic Champenois, Roberto Chinnici, some other people I still don’t know. We made a review about new features of JEE6, commented and discussed those, and that’s it. There are really a lot of interesting features in JEE6/Glassfish: profiles, beans validation, JAX-RS, Async, blablabla
Discussing future features is really interesting, but without some more implication in the community, I don’t think it’s worth more. I prefer concentrating on what’s already usable and released and to learn about new technologies once they are ‘real’.
It was a dense day. I’ve already taken a look to Scala, I’ll do with Groovy and Clojure, which seem to be quite elegant languages. My only question concerning different languages is about the compatibility with the Java language.
I’m definitely happy to have won the free entrance ticket for Jazoon at the Yajug (http://www.yajug.lu), and I’d like to thank them as well as my employers (Pragma Consult, Luxembourg – http://www.pragmaconsult.lu) for permitting me to be here at Jazoon in Zurich these days.
Tomorrow will be my last day here – I still have no idea of what presentations I’ll be attending to.
I’m bored of having to use different environments for development, testing, integration and production. Either I must have the complete production stack on my development computer – this uses a lot of resources, or I must use different tools.
For example, when I develop Java web applications, I often test my applications with either Tomcat or Jetty, then deploy on a production-quality JEE server, like Glassfish, WebSphere, WebLogic etc. And in many cases, it doesn’t work well, because the web containers of these JEE servers are not always the ones I used for development.
I believe there should be a Java WebContainer Embedding standard API which should be used in JEE servers to embed JEE web containers. This API would provide all services a JEE container needs to manage web containers.
Using OSGI, it would even be possible to use, in one single JEE server and for each web application, a web application specific web-container. I’d find it very useful to be able to tell the application server what web-container should be used for each of my web-applications.
Such applications would permit one to use the same web container through the complete development cycle.
This principle may also be used for any other JEE service providing container.
I strongly believe that any method or procedure should test the application state before and after its execution, to ensure that it had no side-effect. This also means that the method’s arguments should be validated.
In some previous posts, I stated that it’s at least difficult if not impossible to implement pre- and post-conditions in Java: you simply cannot force the JVM to execute pre- and post-conditional testing on methods declared in interfaces (except with tricky solutions like using agents or AOP with and specific classloaders, but this always relies on the developer). As such, the user of your API or framework still is free to validate parameters and pre- and post-conditions the way he wants. He’s also free to interpret the API documentation like he wants.
This really really really is someting I hate about Java, because you cannot, as an API developer, force the API user to use it the way you want (I admit flexibility sometimes has high value, but I only value flexibility which has a real sense for the developer community or for software design!).
This morning I think I’ve found a solution for Java API and framework developers who want to ensure that parameter validation and pre- and post-conditional testing are done correctly. I got the idea while reading pages of this website: http://www.discursive.com/books/cjcook/reference/book.html.
There are two distinct cases:
As an API does not control the code sequence (that is one big difference with frameworks), it’s code is called directly by the API users. Which means that the user usually does not redefine operations. For example, when using Apache Commons Lang, it’s really rare that a developer must override some method before calling it.
Thus the rules to apply pre- and post-conditional testing, as well as parameter validation are simple:
Using framework often means implementing interfaces. This is the real issue for pre- and post-conditional testing as well as parameter validation.
But the solution is simple. The user often has to implement some interface and then give it to the framework. Once the framework is started, it calls the implemented interface.
When the developer gives his implementation to the framework, the framework should simply instantiate a wrapper which implements the interface and which performs pre- and post-conditions tests as well as parameter validation before and after delegating to the implementation given by the user.
One may argue that it’s still possible to call the user implementation directly, but that’s usually not the intended use of the framework…
The rules to apply pre- and post-conditional testing, as well as parameter validation:
I added sample code in the following jar file: http://yannickloth.be/blog/wp-content/uploads/2009/05/prepostcond.jar
When I define new APIs or frameworks, I try not to forget that their users are not always good developers or do not always have the time to implement pre- and post-conditional testing as well as parameter validation. I also try to restrict the API documentation to one single interpretation. By doing so, I hope that the different implementations of my APIs and frameworks will remain as much interchangeable as possible.