Posts Tagged ‘java’



18
Jul

Why Do I Hate Eclipse?

As a consultant, I’m very often forced to use Eclipse as a development environment, and every time I do, it’s such a pain for me that I can’t help complaining about the poorness of this thing. And every time I do, most of my team mates, who have been brainwashed by the monopolistic propaganda of Eclipse, just keep asking me what’s wrong with it. And sometimes it’s hard to explain because it’s really a matter of user experience. And each time I find a specific example, I get answers like “yeah, but that’s just one thing”, or “I’ve never had that, you’re not lucky”, or “this is just because you’re not used to the Eclipse way of doing things”, or even the worst one “maybe yes, but it’s free!”. Since when is “free” a feature?

Right now, I’m reading the SpringSource dm Server getting started guide, and I was very surprised to read that SpringSource guys, who aren’t exactly stupid, and seem very experienced with Eclipse itself as they have based all their development tools on it (Spring IDE, STS, etc.), talk about what they call the “Eclipse Dance”. I didn’t know about the expression but I’ve definitely danced it more than once: every now and then, Eclipse views get all mixed up, some views indicate errors in a file, while other views on the same file say everything is OK. Or you get a message saying that it cannot find a class where you have the source in front of your eyes. Or like now, I have 2 maven projects at the same level referencing the same parent POM, and one of the projects says it can’t find the parent artifact, whether the other one seems to find it without problem. And when that kind of things happen, the only thing to do is to try a combination of closing all projects and reopening them, clean all projects to force a clean build, or even restart the whole Eclipse workbench. WTF?

How can SpringSource support such a poorly designed environment while admitting such unacceptable bugs? Oh yeah right! It’s free, so everybody uses it. This is really the perfect example of when Open Source can also kill innovation instead of fostering it. It’s free so everybody uses it, including corporate customers, so all tool vendors base their tools on it (Spring IDE, Flex Builder, Weblogic Portal Workshop, etc.), so even more people use it (even if they have better tools in their bag), and we’re screwed.

I would love that framework vendors focus first on command-line integration with tools like Maven and Ant, and then provide IDE integration for a few popular environments, including Eclipse, Netbeans, and my personal choice, IntelliJ IDEA. This would reinforce competition between IDE vendors instead of killing it while considerably lowering the barrier to entry to their frameworks. Right now, SpringSource is lucky I really need to understand more about dm Server, because if it had been only for cusriosity’s sake, I would have given up already just because of the tight integration with this crappy Eclipse thing and all the pain I have to make it work consistently.

So if you’ve already been in that situation, and you start to think there’s gotta be a better way, try out IntelliJ IDEA.

PS: I’m not related to Jetbrains in any way. I just happen to be a very happy customer of theirs, happy to pay a few hundred bucks every year to get their latest version, because as a Jetbrains guy said it last year at Devoxx, “IntelliJ iDEA is the only IDE worth paying for.”

1
Nov

Talk Less, Do More

I’ve been a Java developer for almost 8 years now, I’ve used many frameworks and tools, Spring, Hibernate, EJB’s, Swing, etc. And a few years back, I started to look for a less verbose way to express concepts like business entities, services, workflows and so on. For some time, Model-Driven Architecture (MDA) has been the best answer I could find. But the learning curve and the difficulty to customize transformation patterns for specific setups, like a Flex front-end on a Spring back-end for example, have made me realize that this approach was somewhat limited by its UML foundation.

So I started looking for a better answer, and I thought I had found it with Language-Oriented Programming, the idea to decouple the structure, the syntax and the semantics of a language and ease the creation of Domain-Specific Languages in a very generic way. Unfortunately, as promising as it looks, it’s still in early stages of research and development and I needed a more immediate way to improve my productivity, my ability to do more with less words.

So I came back to something I had totally pushed aside till then: scripting languages. I’ve been “raised” with strongly and statically-typed languages since day 1 of my programming carrier: first Pascal, then Delphi, C++ and Java. And I always thought that scripting languages like PHP, and later Ruby were just tinkerer stuff for lazy hobbyist programmers, that didn’t take into account constraints like maintainability, robustness, readability, performance, etc. All those constraints I faced as a professional consultant. But a few weeks ago, I started to question my certainties and began wandering around PHP, Ruby, Python and others.

PHP, I’m using it at work on You And The World, it’s too hard to debug in a Flex/AMF setup and it’s really too permissive. As for Ruby, I like the ability to design DSLs but the syntax is definitely not intuitive enough for me. So now, I’m trying to learn more about Python, whose syntax seemed more familiar and maturity is reassuring. Everything seemed good until I read this single sentence in the documentation:

[...] classes in Python do not put an absolute barrier between definition and user, but rather rely on the politeness of the user not to “break into the definition.”

Come ooooon! Politeness of the user? You must be kidding right. In a corporate environment, when your code is likely to be reused and shared and refactored? I thought “hey, that’s probably just a provocative way to say that we Java developers tend to overdesign, and I know it’s true… so let’s read on…”. But unfortunately it proved to be much more than just a provocative sentence, since a few lines later:

In fact, nothing in Python makes it possible to enforce data hiding — it is all based upon convention.

OK. It took me a while to accept the argument that static typing can be too much of a cost in terms of verbosity compared to the poor protection it offers in terms of code correctness. But I said “OK, we’ll see how it looks when we come to real code”. But now they want me to forget about encapsulation too! What is the purpose of even writing a class then? What are you describing? A library of functions with a hidden first parameter? Is that it?

I mean, typing might be a unnecessary hurdle when writing unit test becomes much easier, but giving up on the behavior/state balance, the ability to describe what a class can do AND what it looks like, this is too much to ask.

So now what? Am I stuck between two extreme alternatives: either describe everything and waste energy doing it, or describe nothing a pray/ask for politeness?

And then I thought about LOP, and this interesting idea to decouple structure, syntax and semantics. After all, programming languages have entangled those three aspects for decades. And now both mainstream platforms (Java and .Net) are offering a variety of languages running on the same Virtual Machine. Isn’t that a first step in decoupling syntax on one side, structure and semantics on the other side?

Suddenly I’m starting to dream of a new syntax, far less verbose than the one of the Java programming language but with the same rigorous Object-Oriented structure, and the ability to run on all runtimes with different semantics…

What if the following Java code:

{code type=java}
public class TodoItem extends Item implements Synchronizable{
private String title;
public String getTitle(){return title;}
public void setTitle(String t){title=t;}

protected boolean done;

public TodoItem(String title){this.title=title;}

public void check(){done=true;}
}
{/code}

Could be rewritten like this:
{code}
+ class TodoItem > Item @ Synchronizable
- title
+ <-
return title
+ -> t
title = t

#done

init t
title = t;

+ check
done = true
{/code}

…or something similar ;o)

The key ideas being:

  • Keep all the key concepts of OOP: encapsulation, inheritance, polymorphism, composition
  • Remove static type declaration: I don’t care that my hammer has a wood or a steel handle, but I need to know it has a handle.
  • Replace long keywords by well-identified signs
  • Replace “{}” and “;” by indentation (Python-like)
  • Add simple property syntax (I love the way ActionScript does it)

In other words, I’m looking for a middle-path alternative between Java and Python, between waste and pray, between overdesign and politeness. Does anyone know of a language that offers that kind of compromise? Does anyone know if it has already been tested but has proven to be a dead-end for some reason?

22
Jul

The Flex, Spring and BlazeDS full stack on Adobe Developer Connection

The last part of the reedition of my article series about Flex and Spring has been published on the Adobe Developer Connection. This episode is the last one in this improved series so if you haven’t read it yet on my blog, I think the version I gave to ADC is better.

Episode 1
Episode 2
Episode 3

Enjoy!

6
Jul

MobiMap 1.0-RC2

I just released version 1.0-RC2 of MobiMap library. Amongst the features I’ve added are:

  • better icons for screen controls
  • better support for touch screen devices with a new zoom slider
  • all strings are now internationalized in French and English
  • a help screen with all the active shortcuts when you hit 5 numeric key
  • it is now possible to customize all shortcuts programmatically

More information on the official site.

And if you want to test a demo application using MobiMap component, just point your mobile browser to http://mobimap.epseelon.org/mobimap.jad

We’d love to hear your feedback.

8
May

My OSGi Learning Path (Part 1)

I’m more and more convinced that OSGi is going to change the way we develop enterprise applications. In a sense it’s funny because it’s been around for a while in embedded and client-side environment, and it’s only been reaching to us server-side developers for a few months. I think that the fact that the most popular Java component framework, ie Spring, jumped in with Spring OSGi (now Spring Dynamic Modules) has a lot to do with this new awareness. That and the growing interest for modularity and reusability encouraged by the Service-Oriented Architecture fashion. Yes, I agree that SOA has become yet another buzzword encompassing everything and nothing, depending on what software vendors sell to their naive customers. But if customers are ultimately willing to believe false promises, it might be because there is a gap in current technologies. Some see this gap as an opportunity for sales, developers see it as an opportunity for technology improvement. And I really see OSGi as THE technological answer to that and many other problems. Yes, OSGi might be server-side development’s 42!

Now, once you realize the importance OSGi is going to have in the years to come, the question is… sorry, the questions are why, what and how? Of course you could read the entire OSGi specification, but it would be like using a bulldozer to plant a flower. Fortunately for us, there are plenty of articles, blog posts and documents out there to help us understand how to deal with our delicate flower. Here is a possible learning path that will take you through a journey in OSGi world, why it’s useful, what it is, and how you can use it in your own projects.

Why is OSGi interesting?

Kirk Knoernschild wrote two excellent blog posts with sample code that is as simple as it can be and really gives a practical idea of what OSGi is all about.

  • The first one introduces the notion of a service in OSGi
  • The second one shows how you can really decouple the interface and its different implementations and dynamically switch from one implementation to another one
  • What I really like about those articles is that they use no external tools like Maven or Eclipse. Just plain text and Ant to compile. Just one thing that can be useful: you might want to download the latest version of Felix (1.0.4 at the time of this writing) and customize osgi/HelloWorld/config.properties (lines 31 to 34):

    felix.auto.start.1= \
     file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.shell-1.0.1.jar \
      file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.shell.tui-1.0.1.jar \
     file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.bundlerepository-1.0.3.jar
    

    Those are my own modifications because I downloaded Felix and installed it in /Library/Apache/felix-1.0.4 on my Mac. And of course you will have to adapt startfelix.sh (or startfelix.bat) as well:

    java -Dfelix.config.properties=file:./config.properties -jar /Library/Apache/felix-1.0.4/bin/felix.jar
    

    Finally, in the second article, at the time of this writing there is a mistake in the code of the manifest for service2. I’ve left a comment and hopefully Kirk will fix his code in the repository. HelloWorldSpec/service2/META-INF/Manifest.mf should look like this:

    Manifest-Version: 1.0
    Bundle-ManifestVersion: 2
    Bundle-Name: Hello Service Impl 2
    Bundle-SymbolicName: helloserviceimpl2
    Bundle-Version: 1.0.0
    Bundle-Activator: com.extensiblejava.hello.service2.impl.HelloServiceImpl
    Import-Package: org.osgi.framework, com.extensiblejava.hello.service
    

    Then, following those two articles, Kirk modified HelloWorldSpec to integrate Spring Dynamic Modules and show what it brings to the table. More specifically, you can see that Spring Dynamic Modules makes it possible to externalize service registration and consumption in Spring configuration files and have service and client classes as simple POJO’s.

    That’s it for the “why?”. I guess you understand why it can be interesting to use OSGi on the server-side by now. In the next article, I’ll try to give you a few links to identify what elements can make up your OSGi development environment.

1
May

You dreamt of it? SpringSource did it!

3 months ago, the day SpringSource announced their acquisition of Covalent, the company behind Tomcat, I knew they were up to something. I even talked about it with Andrew Glover for JavaWorld. And now it’s real: SpringSource has just announced SpringSource Application Platform.

First off, a few links around this announcement:

Now this is very exciting. That’s the kind of inspiring technologies that make me think of tens of ideas for new projects, new tools that were just impossible before and that could now become reality. Adobe Flex had the same effect of unleashing my software artist imagination. Now I’m starting to think about combining the user experience of Flex applications on top of the ease of management, deployment and extensibility of OSGi with SSAP. Jeez, we’re living an incredible period!

20
Apr

Flex, Spring and BlazeDS: the full stack! (Epilogue)

Thanks to Brian E. Fox, I managed to avoid duplication of Flex remoting configuration files in this project. It requires a bit of additional configuration and I hope that Maven will soon provide a simpler way to do this simple resource inheritance thing. But in the meantime, this one will work.

I’m going to update my four-article series to include those modifications, but for those of you who have already gone through it before the update, here are the exact modifications you need to make to the project you got at the end of Part 4.
Click to continue…

15
Apr

Flex, Spring and BlazeDS: the full stack! (Part 4) [updated]

[UPDATE] This article series has been reedited on the Adobe Developer Connection. For more information, see this post.

In the previous articles in this series, we did the boring stuff of setting up Spring, Hibernate and MySQL on a sample todo list server on one side, and we wrote a small useless Flex UI on the other side. In this article, we’re going to write the final UI and connect it with the Spring backend using BlazeDS. Let’s go!
Click to continue…

13
Apr

Maven, Flex and GraniteDS: another full stack!

For those of you looking for alternatives, it appears that the main diffuculty I had with Israfil’s maven-flex2-plugin, that is how to specify the contextRoot compiler argument, is not really a difficulty after all. I don’t know if it works with BlazeDS, but the guys behind Igenko apparently made it work with GraniteDS. I have to thank Tim O’Brien for pointing that out.

Their solution to the configuration file duplication is at least as ugly as mine, but if you’re looking for the right configuration for israfil, you can try that:

<plugin>
	<groupId>net.israfil.mojo</groupId>
	<artifactId>maven-flex2-plugin</artifactId>
	<version>1.3</version>
	<extensions>true</extensions>
	<configuration>
	<flexHome>${flex.home}</flexHome>
<dataServicesConfig>../igenko-backoffice-server/src/main/webapp/WEB-INF/flex/services-config.xml</dataServicesConfig>
		<main>Index.mxml</main>
		<useNetwork>true</useNetwork>
		<debug>true</debug>

		<extraParameters>
			<parameter>
				<name>compiler.context-root</name>
				<values><value>igenko-bo</value></values>
			</parameter>
		</extraParameters>
	</configuration>
</plugin>

Maybe I’ll give it a shot after I finish my series. But anyways, Adobe if you can hear me, it becomes urgent for you to propose an official and well-documented Maven support for Flex 3.

13
Apr

Flex, Spring and BlazeDS: the full stack! (Part 3)

[UPDATE 2] If you are still having version issues with the sample application featured in this article, you can get a fully upgraded version here

[UPDATE] This article series has been reedited on the Adobe Developer Connection. For more information, see this post.

In the previous article in this series, I described the creation and configuration of a classic standalone Flex module built with flex-compiler-mojo. In this article I’m going to describe the creation of our back-end module, made up with Spring, Hibernate and MySQL. I’ll keep the most interesting part for the fourth and last episode, that is how to connect the frontend with the backend using BlazeDS.
Click to continue…

Celadon theme by the Themes Boutique