Explore Posterous

Java's Future Lies In FOSS

I wrote this back in 2004 while living in Australia. It was published in CNet's Builder AU. It predated Sun's decision to release Java as an open source product, and in the end, many of the claims I made in this article turned out to be spot on.

Recently, much of the buzz in the software development community has been about one question: Should Sun Microsystems release Java under a free software license like the GNU General Public License (GPL)?

There are many valid reasons why Sun should. In fact, I predict that if Java is to survive in a world dominated by Microsoft for the long term, it must become Free Open Source Software (FOSS), where "free" means freedom, not zero-cost.

Currently, the source code for the classes that make up Java is mostly available for developers to view, but modifications of any kind are expressly forbidden (see the licence included with the Java SDK, in the "Supplemental License Terms", subsections B and D). This is the key reason why Java is not considered "Free Software". Being able to simply view the source to something does not make it FOSS, since creating modifications so that the software can evolve and adapt is more important to developers than simply reading about how existing code works.

It should also be noted that there are several third-party licences in the SDK, due to the fact that the SDK includes several technologies developed by entities outside of Sun. Converting Java to FOSS will require ensuring that these licences are compatible with a FOSS distribution model, or replacing the technologies with ones that are.

The benefits of a FOSS Java to developers will be enormous. Sun's "Bug Parade" is populated with thousands of unfixed bugs, many of them more than five years old. Even the simplest of bugs often goes unfixed, presumably because Sun lacks the manpower to fix everything, and must prioritise. There are, at the time of this writing, more than 7,500 open bugs filed against the SDK alone. An open source approach will not suffer from this. Bugs will be fixed almost as quickly as they are reported. The backlog of bugs will quickly disappear, as well. The quality of Java as a platform will instantly be boosted.

Not everyone, however, agrees that the benefits are worth the perceived risks. James Gosling, widely recognised as the "Father of Java", has played an important role in the development of this debate. In the April 12, 2004, entry in his blog he writes:

GPL software is not "free": it comes with a licence that has a strong political agenda. Like GPL software, the Java platform is "free" in many senses: you don't have to pay anything for the runtime or developers kit and you can get the sources for everything. Unlike GPLd software, the Java sources don't come with a viral infection clause that requires you to apply the GPL to your own code.

Gosling seems to feel that "freedom" requires absolutely no restrictions be present. On the contrary, those of us who live in modern western societies know that the presence of laws (that is, restrictions) is what enables us to remain free. This is the concept of "greatest liberty". The important thing is what those restrictions are. The same is true with the GPL, which grants very specific freedoms.

Gosling also implies that if Java were released under the GPL, that its so-called "viral infection clause" would require that all Java code written would automatically be under the GPL. This is a complete misunderstanding of how the GPL works. Linux, for example, is under the GPL, but programs written to run on it and use it need not be. Gosling is confusing the concepts of "program linking" and "writing for a platform".

Beyond these technical points, one might ask, "What is the big problem with making Java FOSS?" It's a complex question, and many in the Java community have provided excellent coverage of the issues. Joshua Marinacci is one that has covered this in his blog on java.net. He has covered many of the details, however, I believe he has made some critical errors in his argument, which must be refuted to understand why Java must become FOSS if it is to survive.

Marinacci points out four major "problems" that he claims would result from making Java FOSS. Probably the most important one is the first one on his list, which is echoed by the anti-FOSS Java camp worldwide: Java would become chaotic, and incompatible versions would pop up everywhere. Apparently there is a belief that only Sun's heavy-handed spec enforcement can keep this from happening (though it clearly failed to do so in a timely manner against Microsoft).

We already have good evidence that this will not happen. Linux is a platform under the GPL, and is based on a set of standards collectively called UNIX. UNIX is valuable mainly because of the uniformity of implementation of these standards on all flavours of UNIX, just as Java is valuable for the same reason. We do not see incompatible versions of Linux everywhere, though, even though there are many different and diverse distributions of it available. Most people see this diversity (read: freedom) as a good thing about Linux.

Similarly, the extremely popular database software called MySQL is available under the GPL, and the company makes no secret of this. MySQL is rapidly growing in the industry, and is creating a serious threat to purely commercial databases like SQL Server. Despite the fact that MySQL is GPL, nobody forks the code. Why not? Simple: doing so would create an incompatible code branch, and nobody stands to gain anything by doing that. The community is better served by working together to make MySQL better.

So there we have two spectacularly successful GPL products, both of which are giving Microsoft major headaches, and both of which depend upon standardisation. One has many distributions, the other only a few. This is why the fear that making Java FOSS would cause it to degenerate into chaos is unwarranted. It is more about paranoia than reason, more about control than progress.

FOSS works because it allows software to evolve like a biological organism, changing and improving in unpredictable ways over time to find solutions to seemingly intractable problems. If Java becomes FOSS, it will find ways around threats like Microsoft. If it does not, then those threats may eventually send it the way of the dinosaur. After all, having the comfortable predictability of being big and cold-blooded doesn't help you when the surprise meteor hits. Only being adaptable can keep the species alive.

Recenzja: Hibernate w Akcji

Książkę kupiłem jakiś rok temum gdy postanowiłem poznać bibliotekę Hibernate, tak szeroko stosowaną w świecie Javy. Skończyło się jednak na przeczytaniu o ile dobrze pamiętam niecałych dwóch rozdziałów. Z racji upływu czasu zatarło się wspomnienie dlaczego właściwie jej nie przeczytałem, ale problem pozostał: trzeba się w końcu tego Hibernate nauczyć, bym bardziej że używam go w praktyce często "na czuja" , niby jakoś ile ale porcja konkretnej wiedzy na pewno nie zaszkodzi.

No to zacząłem czytać:
1 rozdział: Wprowadzenie w ORM'y. Ok, standard.
2 rozdział: Hello World! Próba odpalenia Eclipse i testowania kodu. Moment iluminacji, już wiem czemu poprzednio jej nie przeczytałem!

Książka mimo iż wydana początkowo przez Manning i należy do serii "* in Action" to jednak ta strona książki jest bardzo niedopracowana! Z tego co przeglądałem Amazon i Manning dostępne jest już drugie wydanie "Java Persistence with Hibernate" która to jest prawie dwukrotnie grubsza od pierwszego wydania, domyślam się że przykłady są już lepiej wytłumaczone.
W każdym bądź razie książka zawiera tylko krótkie fragmenty kodu, poszatkowane i w żadnym razie nie nadające się do uruchomienia!
Jeśli ktoś poszukuje bardziej praktycznego podejścia do Hibernate polecam: http://vaannila.com/ gdzie można poczytać także o Spring oraz Struts.
Generalnie polecam tą stronę każdemu kto nie miał jeszcze do czynienia z Hibernate a chciał by się go nauczyć. Nie dość że omawiana jest konfiguracja to omawiane są Adnotacje których nie ma w Hibernate w Akcji. Nie jest to wina jakiegoś zaniedbania, po prostu książka była wydana dla wersji Hibernate 2.1. Adnotacje nie były wtedy wspierane.
Zdałem sobie sprawę że próby uruchamiania kodu nic nie dają poza irytacją i to pozwoliło mi docenić inne zalety książki.
Można się z niej nauczyć bardzo wiele nie tylko o ORM ale i o podstawach tworzenia aplikacji i kilku dobrych praktykach programistycznych.
Jeśli ktoś woli czytać po polsku albo po prostu kupił już tą książkę(jak ja) to polecam ją przeczytać. Jednak dla osób które mają wybór polecam raczej coś co zawiera już opis użycia Adnotacji: choćby druga edycja o której już pisałem a przez wielu jest uważana za "Biblię Hibernate".

Ocena: 6/10

Osobiście zamierzam przeczytać drugie wydanie: "Java Persistence with Hibernate" http://www.manning.com/bauer2/ wersja PDF to koszt ~$35 dolarów więc nie tak znów dużo jak na książkę o 880 stronach nawet w Polskich księgarniach.

Google Wave, Apache Shindig, and OpenSocial development in Eclipse

QwebIRC: a worthy open-source alternative to Java IRC chat-boxes

To all of you people out there who are still using a clunky old Java IRC chat-box on your site - I urge you to switch to QwebIRC.

QwebIRC uses Ajax, is light on resources, is open-source and can easily be embedded on your website.

Check QwebIRC out here:

http://www.qwebirc.org/

Monitoring Tomcat with Java VisualVM

One of the best kept secrets that's bundled with your Java 6 JDK is VisualVM. VisualVM is an absolutely fantastic, free monitoring tool for Java that you may not realize is right under your nose.

In a nutshell, when you fire up VisualVM it provides you with a ton of monitoring tools for everything running on the JVM. By default VisualVM will monitor the VM from which it's launched, so if for example you launch VisualVM from the bin directory of jdk1.6.0_17, then anything using that JVM will show up as a process in VisualVM that can be monitored. Note that in some cases certain processes will not appear in VisualVM, which is the real point of this post; I'll get to that in a moment.

I'm attaching a few screenshots to this post. The first shows what VisualVM looks like when I fired it up just now on my Linux laptop, the second shows a snapshot of the main monitor screen (in this case I'm monitoring Tomcat), and the third shows a snapshot of the thread monitoring screen (note the Open BlueDragon threads!). VisualVM can also take and load snapshots so you really hone in on problems at the VM level quite easily.

One major point I'd like to make is that VisualVM will monitor any Java application running on the JVM. So in the CFML world this means if you have OpenBD, Railo, or ColdFusion running, they can all be monitored quite nicely using VisualVM.

VisualVM can also monitor remote JVMs via JMX (Java Management Extensions), so if you're having trouble on a remote server and want to see what's going on, as long as the JMX ports are open and accessible you can launch VisualVM from your local machine and connect to the remote VM. Note that monitoring is a very lightweight process so VisualVM can be used to monitor production servers with virtual no impact. Visual VM also does profiling, however, which is a much more heavyweight process. It provides a huge amount of useful information, but should be used only when absolutely needed on production servers since it will have a noticeable impact on performance.

Now to the real point of this post. When I launched VisualVM on a Windows 2003 server today I was surprised that Tomcat didn't show up as a process running under the VM. Turns out that if you install Tomcat as a service, even if it's running under the same user account that you used to launch VisualVM, Tomcat won't appear by default in the VisualVM process list.

Luckily it's easy enough to resolve. Simply open the Tomcat Configuration application and add the following in the Java Options box on the Java tab:

-Dcom.sun.management.jmxremote.port=8086
-Dcom.sun.management.jmxremote.ssl=false
 -Dcom.sun.management.jmxremote.authenticate=false

After making this change you do have to restart Tomcat.

This will enable JMX in Tomcat and allow VisualVM to connect to it. You can choose any port you like, and note that if you want to use SSL or authentication you would set those options to true. I haven't personally messed with authentication so I'm not sure what that authenticates against, but know that if you want to have JMX available on a production system that you can secure it this way, or of course through firewall rules.

With JMX enabled in Tomcat you then go into VisualVM, add a new JMX connection, and point it to localhost:8086 (or whatever port you set JMX to run on). That's it--you're now monitoring Tomcat!

VisualVM is a great, free tool that you likely already have on your machine, so you really owe it to yourself to check it out.

javamelody: monitoring of JavaEE applications

http://code.google.com/p/javamelody/

The goal of JavaMelody is to monitor Java or Java EE applications servers in QA and production environments. It is not a tool to simulate requests from users, it is a tool to measure and calculate statistics on real operation of an application depending on the usage of the application by users.

JavaMelody is opensource (LGPL) and production ready: in production in an application of 25 person years. JavaMelody is easy to integrate in most applications and is lightweight (no profiling and no database).

JavaMelody is mainly based on statistics of requests and on evolution charts.

It allows to improve applications in QA and production and help to:

* give facts about the average response times and number of executions
* make decisions when trends are bad, before problems become too
serious
* optimize based on the more limiting response times
* find the root causes of response times
* verify the real improvement after optimizations

It includes summary charts showing the evolution over time of the following indicators:

* Number of executions, mean execution times and percentage of
errors of http requests, sql requests or methods of business
façades (if EJB3 or if Spring)
* Java memory
* Java CPU
* Number of user sessions
* Number of jdbc connections

These charts can be viewed on the current day, week, month or year.

JavaMelody includes statistics of predefined counters (as of today http requests, sql requests and methods of business façades if EJB3 or if Spring) with, for each counter :

* A summary indicating the overall number of executions, the average
execution time, the cpu time and the percentage of errors.
* And the percentage of time spent in the requests for which the
average time exceeds a configurable threshold.
* And the complete list of requests, aggregated without dynamic
parameters with, for each, the number of executions, the mean
execution time, the mean cpu time, the percentage of errors and an
evolution chart of execution time over time.
* Furthermore, each http request indicates the size of the flow
response, the mean number of sql executions and the mean sql time.

It also includes statistics on http errors, on warnings and errors in logs and on data caches if ehcache.

An optional and independent collect server may be used if necessary to unload the application of storage management, and of reports generation and to centralize the data of clustered applications or of several applications.

Testable Java (C#)

悪文:[ECLIPSE][ANT]Unable to find a javac compilerエラーの解決 - livedoor Blog（ブログ）

Running Tomcat as a Service on 64-Bit Windows

I'm replacing one of our ColdFusion 8 installs with Tomcat 6.0.20 and Open BlueDragon, and this is on a 64-bit Windows 2003 server. Easy enough conceptually, but it turns out running Tomcat as a service on 64-bit Windows has a small trick involved.

A couple of potential solutions are outlined on StackOverflow (and numerous other places), but it still involved a bit of hunting around, so I thought a step-by-step with specific links would be helpful both to others and to myself when I forget how to do this next time. ;-)

1. Install a 64-bit JDK if you haven't already.
2. Download and run the Windows Service Installer of Tomcat.
1. Make sure and point to your 64-bit JVM at the appropriate spot in the install process.
   
2. At the end of the install, uncheck the box to start Tomcat. It won't start anyway at this point since the startup script included in the download is 32-bit.
   
3. Grab the 64-bit versions of tomcat6.exe and tomcat6w.exe from the SVN repository. Even though it says "amd64" in the URL these files work on Intel chips as well.
4. Replace the tomcat6.exe and tomcat6w.exe in Tomcat's bin directory with the new 64-bit versions you downloaded.
5. Start up Tomcat!

That should be all there is to it. The one thing that doesn't work for me is the "Monitor Tomcat" application, but that really isn't a big deal since it doesn't do or tell you anything you can't get from the Services panel. I haven't dug into that at all so if anyone knows why that doesn't run I'd be curious to know.

After this is all installed make sure and go into the Tomcat Configuration app to take advantage of all the RAM you need or want to for your applications.

Quickly change an imported project to a Java project in Eclipse

To quickly change the type of an Eclipse project to a Java project all you need to do is copy and paste the buildSpec and natures XML nodes into the .project file. As a result you get the code below in EasyEclipse Expert Java 1.3.1.1:

<projectDescription>
    ...
    <buildSpec>
        <buildCommand>
            <name>org.eclipse.jdt.core.javabuilder</name>
            <arguments>
            </arguments>
        </buildCommand>
    </buildSpec>
    <natures>
        <nature>org.eclipse.jdt.core.javanature</nature>

    </natures>
    ...

</projectDescription>