niceideas.ch
Technological Thoughts by Jerome Kehrli

Entries tagged [java]

Bytecode manipulation with Javassist for fun and profit part I: Implementing a lightweight IoC container in 300 lines of code

by Jerome Kehrli


Posted on Monday Feb 13, 2017 at 09:30PM in Java


Java bytecode is the form of instructions that the JVM executes.
A Java programmer, normally, does not need to be aware of how Java bytecode works.

Understanding the bytecode, however, is essential to the areas of tooling and program analysis, where the applications can modify the bytecode to adjust the behavior according to the application's domain. Profilers, mocking tools, AOP, ORM frameworks, IoC Containers, boilerplate code generators, etc. require to understand Java bytecode thoroughly and come up with means of manipulating it at runtime.
Each and every of these advanced features of what is nowadays standard approaches when programming with Java require a sound understanding of the Java bytecode, not to mention completely new languages running on the JVM such as Scala or Clojure.

Bytecode manpipulation is not easy though ... except with Javassist.
Of all the libraries and tools providing advanced bytecode manipulation features, Javassist is the easiest to use and the quickest to master. It takes a few minutes to every initiated Java developer to understand and be able to use Javassist efficiently. And mastering bytecode manipulation, opens a whole new world of approaches and possibilities.

The goal of this article is to present Javassist in the light of a concrete use case: the implementation in a little more than 300 lines of code of a lightweight, simple but cute IoC Container: SCIF - Simple and Cute IoC Framework.

Read More

Comet: having fun with the Java HTTP Stack

by Jerome Kehrli


Posted on Tuesday Nov 01, 2016 at 11:54PM in Web Devevelopment


Wikipedia's definition does a pretty great job in introducing comet:

Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it.

This says it all. For a long time, Comet - which is more an umbrella term regrouping several techniques - was pretty much the only way to get as close as possible to Server Push in Web application, plain HTML/Javascript applications on top of the HTTP protocol.
All methods have in common that they rely on browser-native technologies such as JavaScript, rather than on proprietary plug-ins.

History

In the early days of the World Wide Web, the browser would make multiple server requests: one for the page content and one for each page component. Examples of page components include images, CSS files, scripts, Java applets, and any other server-hosted resource referenced in the page.

Ajax - Asynchronous JavaScript and XML - went a long way towards making this model evolve. It allowed far greater control over page content by providing the ability to send server requests for as little, or as much data as the browser needed to update. In addition, its asynchronous nature supported multiple simultaneous calls - even while other elements downloaded.
One problem that Ajax did not adequately solve was the issue of data synchronization between the client and server. Since the browser would not know if something had changed on the server, Web applications typically polled the server on a periodic basis to ask if new information was available. The only possible way as to use Polling where the browser would poll the serve rat regular intervals to find out about new events and updated data.

To circumvent this very limitation, developers started to imagine techniques aimed at getting closer to server push, either using the Forever Hidden iframe technique or the Long Polling XMLHttpRequest technique. Both these techniques are grouped under the umbrella term Comet or Bayeux Protocol.
Now of course these techniques have respective advantages and drawbacks that I will be discussing later in this article.

Comet

For many reasons, mostly robustness and universality of the solution, I am favoring the Forever Hidden iframe approach and I have designed quite some time ago a Comet framework making use of this technique to provide Server-Push to Plain HTML/javascript web applications.

The forever hidden iframe technique is the one I found most seducing for one very good and essential reason : it's the most robust one from a technical perspective. It has drawbacks of course in comparison with other techniques, but I still deem it the most solid one, and in some situations it was even the only one I could make work.
Its principle is straightforward to understand: an iframe is opened on a server resource and the HTTP response stream is never closed by the backend. The iframe keeps loading more javascript instructions as the server pushes them in the response stream.
Having said that, I have to admit ... It blocks a freaking amount of threads in the java backend, it shows the annoying loading icon on the browser, managing errors is a nightmare ... but it always works, in every situation, and at the end of the day considering the kind of business critical applications I usually work on, this is what matters the most to me.

Now of course, WebSockets tend to rend all Comet tecnniques kind of legacy.
But still, I end up deploying comet techniques instead of WebSockets in many circumstances. You may wonder why ?

WebSockets are no magic silver bullet

  • Most importantly, when we have to support plain HTTP connection and bad HTTP proxies which let a WebSocket being opened but don't let anything pass through
  • Implementing WebSockets efficiently on the server side is more complicated than Comet and requires most of the time specific libraries, sometimes pretty incompatible with some Application Servers
  • With WebSockets you are forced to run TCP proxies as opposed to HTTP proxies for load balancing
  • When I have to support old version of Internet Explorer, such as IE9, in banking institutions that have a bad tendency to use pretty old version of software
  • Many other reasons I am detailing below ...

The first problem above is the darkest one regarding WebSockets in my opinion. This proxy server issue is quite widespread.
Nonetheless, "You must have HTTPS" is the weakest argument against WebSocket adoption since I want all the web to be HTTPS, it is the future and it is getting cheaper every day. But unfortunately there are some context where we have to integrate our web application on plain HTTP and one should know that weird stuff will definitely happen you deploy WebSockets over unsecured HTTP.

lightweight, simple and robust Comet framework

This is the main rational behind the Lightweight and simple Comet Framework for Java that I am introducing here. I am using this framework, that I've designed long ago and somewhat maintained over the years, each and every time I encounter issues with WebSockets.
To be honest, I always consider it somewhat a failure since the standardization of the WebSocket specification should prevent me from reverting to this Comet Framework so often, but surprisingly it doesn't and I end up returning there pretty often.
Again, the forever hidden iframe Comet technique always works!

Anyway, this Lightweight and simple Comet Framework for Java is pretty handy and I am presenting it here and making the sources available for download.

Read More

niceideas-commons 1.1-beta-0.1

by Jerome Kehrli


Posted on Sunday Dec 26, 2010 at 10:03AM in Java


Following the initial release of the niceideas-commons package here : niceideas-commons 1.0-alpha-0.7, The niceideas-commons 1.1-beta-0.1 is released today.

Major changes are :

  • Basic relation mapping support added to the DAO framework
  • More helper and utilities related to resource finding and loading
  • More utilities of various kinds
  • Various bug fixes

Read More

Java rocks !

by Jerome Kehrli


Posted on Wednesday Nov 03, 2010 at 08:40AM in Java


I've been facing an interesting problem with string manipulation in Java lately at work. The requirement was the following :

We have a field on some screen where the user can type in a comment. The comment can have any length the user wants, absolutely any. Should he want to type in a comment of a million characters, he should be able to do so.

Now the right way to store this comment in a database is using a CLOB, a BLOB or a LONGVARCHAR or whatever feature the database natively provides to do so. Unfortunately that's not the way it was designed. Due to legacy integration needs, all these advance DB types are prohibited within our application. So the way we have to store the comment consists of using several rows with a single comment field of a maximum length of 500 characters. That means the long comment has to be split in several sub-strings of 500 characters and each of them is stored in a separate row in the DB table. The table has a counter as part of the primary key which is incremented for each new row belonging to the same comment. This way we can easily spot every row part of the same comment.

Now another problem we have is that under DB2 a field defined as VARCHAR(500) can contain 500 bytes max even though the strings are encoded in UTF-8 in the database. That means we might not be able to store 500 characters if the string contains one or more 2 bytes UTF-8 characters. Working in a french environment, this happens a lot.
So we had to write a little algorithm taking care of the splitting of the string in 500 bytes sub-strings.

The very first version of our algorithm was quite stupid and ended up in splitting the string in a quite naive way: we converted the string to a byte array following an UTF-8 encoding and split the byte array instead of the string. Then each of the 500 bytes arrays was converted back to a string before being inserted in the database.
Happily, we figured out quite soon that this doesn't work as it ends up quite often splitting the string right in the middle of a 2 bytes character. The byte arrays being then converted back to strings, the split 2 bytes character was corrupted and could not be corrected any more.

Before writing as smarter version of the algorithm which would manually test the byte length of the character right at the position of the split, we took a leap backward and wondered : "Can it be that Java doesn't offer natively a simple way to do just that ?"

And the answer is yes of course.

Read More

niceideas-commons 1.0-alpha-0.6

by Jerome Kehrli


Posted on Saturday Feb 06, 2010 at 11:51PM in Java


The company for which I am working currently is the fourth for which I am a Java developer / architect. I am mostly programming in the Java language for quite a long time now, and I have to admit that I have my way of doing things and my little habits. I know a large amount of java libraries and use almost always the same sets for the same needs, with little variations.

But even with the very large set of java libraries available out there, there are a few classes or utilities that I keep re-developing myself again and again each time I start a new job. Not that most of these utilities are not already available somewhere but I dislike the implementations, or want something simple, or anything else. A few of these classes though are really unique by nature.

Well, lately I found myself tired of re-writing the same sets of classes again and again so I wrote them once more ... once and for all. I made from them an open-source and freely available project released under GNU LGPL license so that I can freely use them in my current company as well as for any future employer I might be working for.
Having done this I thought I could share them here.

Read More

hibernate's not-found="ignore" is buggy as hell

by Jerome Kehrli


Posted on Wednesday Jan 27, 2010 at 07:52PM in Java


I'm working on a java application which makes an extensive usage of hibernate's relation mapping system. The later offers several ways to define association mapping. We mostly use many-to-one relation declarations. The problem comes from the database. It's a pre-relational, pre-transactional, legacy database running on a prehistorical IBM zSeries host. The data on this database is very often dumb or corrupted. The lack of a proper referential integrity support and the foolish design make us end up quite often following non-existent relations.

Happily, hibernate provides a semantic which allow the application not to bother when a relation is missing, just as the legacy app does. This semantic is the not-found="ignore" parameter on the relation definition.

However, the usage of this semantic resumes to open very wide the doors to oblivion.

Read More