Showing posts with label java. Show all posts
Showing posts with label java. Show all posts

Sunday, 5 December 2010

A very interesting conference of James Gosling

Happened on November 17, 2010, so it's really fresh. And the fact that Gosling has resigned from Oracle sometime ago and is still unemployed makes it free of a lot of corporate language.

One of the problem of most Fortran code is a) It's doing something really important b) The person who wrote it is probably dead.



Multicore. what can we do about it? What's the right thing to do with Hava? It feels like there's an unbounded supply of PHD thesis topics in there. The problem is that it has been a really rich source of PHD thesis topics for about 30 years.


One of the things about generics is that, you wander around the world, you talk to language designers, 15 years ago, and they would all say, Generics, really really good idea, you got to do it this way, but they all had a different version of this way.


I know that there had been some conversations between Google and Sun to do something early on, that was all just spectacularly weird(..).) Some sort of cooperation should have worked out a whole lot smoother than it did(...) It was weird. I'll leave it there.


(about CLR). They deleted all security feature to allow C pointers, because they wanted to do C. That's like the dumbest thing they have ever done. The instruction set, they added registers to it, that adds nothing, they just wanted to be different.(...) The biggest problem I have with the CLR is that they haven't put nearly as much energy on it(...) We were running at least a factor of two on almost everything. Their code generators are not very good, mostly because they were being lazy(...) Microsoft, in their harder parts, doesn't care about CLR that much because all their real meat and potatoes projects are not that. Word and such are still fundamentally big bags of C code. So they have not really had to depend on it for their own products.

Sunday, 4 January 2009

XUL for Java: stucked (for the moment)

Remember This post: I just created a new java.net project to allow to use XUL declarative scripts out of the box with Java, and allow to bind them at will with Java code or even other scripting languages as well. The code comes from another project were it was working very well, but after extracting it from this project, I still have a big big problem with accessing some Javascript code from the XUL script (which makes the whole thing unusable of course for the moment). I know it's a trivial problem because the same use case works like a charm in the original implementation, I must have deleted the wrong line of code somewhere...

Saturday, 27 September 2008

Type erasure and autoboxing in Java

I'm using Java 5 (and 6) for some time now, and I don't really understand all this hatred about type erasure and autoboxing in Java. But I really think that the Java guys were right at the end:

Generics can be easy to use, but they are never easy to implement at the library level for programmers. I don't think that they are really useful for VM languages, except for type safety. I agree that C++ STL could not have been implemented easily (or at least in a manner that would allow to use them easily) without templates, but templates are hard to understand when you need to develop libraries using them.

So for me I'm using Java generic a lot, but as a user of the collections library (which is the main area were they are useful IMHO, and in every language), and I'm perfectly OK with that. When using generics like that, they are very easy to understand. See this example:

public Map<String, String> getMap() {
...
}

It is a really cool here to know what is returned by the method, and also to be sure that types mistakes on the content of the Map will be detected at compile time.

Sunday, 8 June 2008

Have fun with ARINC 661, XUL, Javascript, beanshell, and Java

One of my project is a Client-Server ARINC 661 framework which use a lot of socket-bound activity from the Client (called User Application in the standard, it handles the logic here) to the Server (which perform the graphic rendering).

The communication protocol in ARINC 661 is specific and a bit complex (no SOAP, no REST, no CORBA, not RMI, but purely specific binary messages on top of the lower-level bus-level layer protocol). So to ease development of Java clients, I developed a generic API to handle this.

I thought it could be cool to allow users to prototype the logic of the Client. Using beanshell for this was the logic thing to do (pardon the pun), because it is very close to Java, so transcoding from beanshell to Java is straigthforward.

The second step was to be able to add scripted control panels for the Client. I don't want to recreate the wheel, so I decided for the use of XUL. One cool side-effect is that users would be able to debug their scripts using Firefox.

OK, it's one thing to create control panels in Java by parsing XUL scripts, but if you are not able to wire the widgets commands to the logic, it's no use. I decided for using Javascript (by using Rhino). Then I had to wire beanshell methods to Javascript. It involved a bit of code to be able to do that, but it was possible.

But getting or setting widget attributes at the Javascript level is also mandatory ! With some amount of work (in fact not a lot of work, I only had to use the right approach to do it), it was also possible.

So basically now I have a framework where I can script ARINC 661 logic in beanshell, and wire these scripts to commands in XUL declarative files. I have a purely scripted ARINC 661 Client.

In this process, I found that Rhino is really a very good Javascript engine, but that there is few informations or tutorials when you have to perform specific things like I had to do (hmm, it's no so specific). I will blog about what I discovered about Rhino specificities in some days (there's not much to say about beanshell / Java, it just work, but as it is so close to Java, there's no surprise). I thing it can be useful to others.

Monday, 28 May 2007

Performance of Batik under Java 6.0

As I use it a lot, I tried to measure the possible boost of performance of Batik, the pure Java library which handle SVG files, under Java SE 6.0, compared to Java 5.0. I decide to create a small benchmark, similar to the one Dave Gilbert, the creator and maintainer of JFreeChart, did, some times ago.

To make it simple, I decided to benchmark the time spent by Batik from the parsing of the SVG file, to the rendering of the associated image on a JFrame. To measure the performance, I call the method 100 times (yes, maybe not enough times), and measure the elapsed time.

Finding good SVG images is not so simple, because time is not only linked to the size of the file, but also to what it contains (for example, complex renderings like gradients take much more time to compute).

And of course, I used Batik 1.7 Beta 1 and rebuilt it for Java 5.0, then 6.0, before doing all this.

Here are the results on my XP box:

Average performance boost is approx. 20%, this is good !!

For some more informations about the different SVG files that were used, they are all coming from the Batik samples library. You can get these samples either by downloading the snapshot here, or much simpler by getting them from the SVN viewer on the trunk here. For more informations about them:

  • asf-logo size is 100 Ko, and it uses a lot of gradients

  • batik3D size is 104 Ko

  • anne size is 86 Ko

  • strokeFont size is 70 Ko

  • moonPhases is 95 Ko, and uses a lot of gradients

  • sunRise is 67 Ko, and uses a lot of gradients

  • mapWaadt is 260 Ko


If we skip those which use gradients, and the big mapWaadt image, the boost is closer to 35%. Not bad...

Sunday, 11 March 2007

First real post

OK, so here is the first real post of this blog. Humm, but about what ? OK, let's dive in.

As you surely don't know, I created an open source project on java.net called MDIFramework. This is a full java framework for easing the creation of multithreaded swing applications.

When you create an application, you soon discover that :
  • you need to execute the lengthy methods in separate threads to avoid "freezing" of the GUI, but then, it quickly becomes a nightmare to deal correctly with the communication between the main event thread, an even using SwingWorker is not enough (for example, what to do if you want to be sure that two actions launched by the user will be executed one after another, for example ?)

  • You would like to ease the configuration of the application, an store it in the most automatic way when you close

  • You want to deal with several types of files in the application, each providing different possible actions, so you would like to have some sort of metadatas associated with each opened file

  • And what if you want to be able to use easily plugin with your application ?
So as I always copied and pasted the same sort of code to do the things above, I created this framework.

If you are interested, go check to tutorials here.

By the way, JSR 296 is already an upcoming Java JSR that aim to provide a simple application framework for Swing applications. I did not knew that when I created my project (but also JSR 296 is still very young), but I think that what this JSR provides (you can check the still evolving open source implementation here) is different. I should try it, and maybe add some JSR 296 capabilities to my own framework... (yes I know, why recreating the wheel when it is already existing ?).