Java 8 is released since 2014. If you are working in an enterprise oriented company, chances are you are only now getting experience with usage of Java 8. You may ask yourself what this warning is telling you.
VM warning: ignoring option MaxPermSize=128M; support was removed in 8.0
Why is PermGen gone? An article of infoq.com tells you something of the reasoning behind this change.
Infoq.com has a nice little intro and tutorial to reactive programming in Java with the RxJava library.
Key takeaways
- Reactive programming is a specification for dealing with asynchronous streams of data
- Reactive provides tools for transforming and combining streams and for managing flow-control
- Marble diagrams provide an interactive canvas for visualizing reactive constructs
- Resembles Java Streams API but the resemblance is purely superficial
- Attach to hot streams to attenuate and process asynchronous data feeds
Also you should checkout the RxMarbles website which interactivly visualizes the reactive functions.
Erich Gamma shares the lessons learnt being deeply involved in the development of the Eclipse platform over the years. From being a platform in closed development, Eclipse turned into an open source one supported by a large and growing community. Erich also talked about Jazz, IBM’s software development platform which incorporates the lessons learnt from Eclipse.
You can find the video (1 hour) on InfoQ.com
JEditorPane pane = new JEditorPane("text/html", html);
String plainText = pane.getDocument().getText(0, pane.getDocument().getLength());
Yes, you can use the Swing JEditorPane to convert HTML into plaintext. Weird but true.
Source: DerKoe
If you are managing a big java project and you use maven changes are high that you are running test coverage and code quality reports.
Analyzing this multitude of reports can be quite exhausting. At work we use Sonar, which uses data from a lot of maven reports (code coverage, pmd, …) and creates an overview on your project. AND it can be setup in about 20 minutes.
SONAR is a code quality management platform, dedicated to continuously analyze and measure technical quality, from the projects portfolio to the class method.
You can read here about the features of it. It even has a time machine to let you investigate the changes of your project over time.
I’m not a big fan of Regular Expressions. Mostly because I’m so inexperienced of using them. But even I see the oppurtinity to replace complex IF statements with RegExps (for example: has a number the form of a positive decimal number with 1 or two decimal places).
To ease the use of RegExps, there are myriads of online RegExps Testers. My favorite is
RegEx
Go ahead and try it, simple but powerfull.
There is an article on the Legolas in Minas Tirith blog which is about Unit Testing. The posting state that Unit Testing (in the form of JUnit or TestNG) is kind of flawed because it tests implementations of an interface.
So if you create a new implementation of the interface, you have to create a new test.
So the suggestion is to talk something from Design By Contract and connect it with Unit Testing. So Unit Testing is concerned with testing the Contract definied by an interface. So every implementation has to fullfill the contract of the interface.
With TestedBy, tests declared on an interface (or a superclass) can be run upon all implementers to verify they’re respecting the behaviour and contract defined in the super type. IOW the API designer not only provides the interfaces, but also a set of test classes verifying expected behaviour. Then every implementer would supply its own implementation and run the tests provided by the API designer against its concrete classes to verify they are respecting not only type safety but also beahviour/contract safety for which the API was designed. TesteBy here invokes a test defined for an interface passing to test class a concrete instance of class implementing the interface under test.
More on this topic can be read in A new approach to unit tests.
Exceptions are difficult to handle. Java Exceptions aren’t different.
Elliotte Rusty Harold tries to remove the confusion.
Perhaps the continuing confusion over the difference between checked and runtime exceptions in Java is because we haven’t named them properly. Mosts texts and teachers, including myself, have traditionally focused on how and when you handle the exceptions (compile time or runtime) rather than on what causes each. I propose a modification, not in code, but in terminology and teaching. Specifically I think we should should start calling checked exceptions “external exceptions” and runtime exceptions “internal exceptions”.
After some examples and explanations he concludes
If the exception is caused by problems internal to the program, it’s a runtime exception. If it’s caused by problems external to the program, it’s a checked exception.
Source: The Cafes
InfoQ.com has an article explaining the benefits of using apache tapestry as an webframework for your projects.
In this article we are going to introduce you the version 5 of the framework. We will develop a simple Create/Read/Update/Delete application using Tapestry 5 and show a few of the productivity benefits provided by Tapestry.
We will describe different aspects of Tapestry applications, such as page navigation, dependency and resource injection, user input validation and application state management. You will also see how to use the Ajax functionality built in to Tapestry and how to create your own Ajax-capable components.
Source: InfoQ.com
Adrian Colyer talks about OSGi and what benefits comes with using it.
Development time benefits
- Strict development time (and runtime) enforcement of module boundaries
- A service-oriented architecture that works for managing service dependencies between modules.
- Better ability to structure development teams the way you want to
- Faster team-based development
- Faster testing cycles
- Support for versioning as part of dependency management
Runtime benefits
- Full information about the installed modules and their wiring is available at runtime – a level of insight operations teams have never had before
- Isolate changes
- Share dependencies
- Use just the server facilities you need
All this assumptions are backed up with arguments in his article.
Source: SpringSource
Stefon's Blog 