STUQ.nl » Java

London Wicket Meetup: Wicket 1.5, WiQuery, Brix and more..

Daan — Thu, 26 Nov 2009 23:05:45 +0000

On November 21st the London Wicket meetup took place in “The Gallery” at the central London Foyles Bookshop. At the venue some well-known Wicket-related speakers made their entrance and held talks about Brix, Wicket 1.5, WiQuery, and how having a baby compares to writing a book.

This is the summary of that afternoon. You should have been there…

Keep an eye on this page for when the next London Wicket event is scheduled.

Overview

Click on an item to jump down (same page) to the notes from that presentation.

(Unfortunately Alastair Maw couldn’t make it as he was sick. Hope you will soon be better!)

Cemal giving the introductory talk

Cemal Bayramoglu: Introduction

As usual, the London Wicket Meetup is kindly hosted by Cemal Bayramoglu of jWeekend. Thanks Cemal!

Jeremy Thomerson showing some code

Jeremy Thomerson (USA): Custom JavaScript Integrations with Wicket + Auto Resolvers

Jeremy Thomerson started his talk with an example of how to do client side validation in Wicket. He showed abstract validation behaviors that validated form input with jQuery.

The remarkable thing was that by adding just one behavior to a component, validation was added for both the server side and the client side. This makes it very easy to keep client and server side validation in sync.

The Javascript behavior is added by letting the behavior implement iHeaderContributor and adding the script in the onRenderHead method call.

Auto component resolution

The next part of Jeremy’s presentation was about the AutoComponentResolver. The AutoComponentResolver makes it possible to wire components directly in HTML, without adding the component explicitly in Java. His demo showed how to use an AutoComponentResolver.

Matej Knopp commented that it is not really recommended to use automatic component resolving, because it has a limited use. The main purpose of auto component resolvers is for simple components that do not have a long lifetime on the page. For example the tag is handled by automatic component resolving and is replaced by a Label with a ResourceModel. More complicated use cases are not supported nor recommended.

Components added via auto-resolving are not serialized or stored in the session and lose all state.

Lionel Armanet showing us the WiQuery goodness he and his fellow Frenchmen created.

Lionel Armanet (FR): Announcing WiQuery 1.0: Introduction & Demo

The presentation of Lionel Armanet was an impressive demo of what WiQuery is capable of. WiQuery integrates jQuery with Wicket, with clever tricks that ease development. WickeXt was merged with jQuery4Wicket and changed its name to WiQuery. Last week was the 1.0 release, and the library is available under the MIT license.

The rationale behind WiQuery is that to build rich internet applications, you need rich behaviors and components. jQuery is simple, unobtrusive and powerful, there are tons of plugins and jQuery UI has fancy components. So, let’s get jQuery, integrate it with Wicket and have the best of both worlds!

WiQuery has standard components and behaviors like the resize behavior, drag and drop behavior, datepicker component, etcetera. By simply adding Java components, WiQuery generates the Javascript for you and imports the required libraries.

Setting up WiQuery

There are two ways to setup wiquery:

With a WiQueryCoreInstantiationListener:

addComponentInstantiationListener(new WiQueryInstantiationListener)

Or by extending the Abstract class WiQueryWebApplication.

Demo

After the theory, Lionel showed an impressive demo with a drag-and-drop Scrum taskboard. The task board had three columns (new, in progress, done), from which task items could be dragged and dropped around. Double clicking an item showes the details for that task.

The double click action is easily added with:

add(new WiQueryAjaxEventBehavior(MouseEvent.DBLCLICK){
   ....
});

With the IThemableApplication interface you can make your application themable, like the themes that jQuery UI has.

Matej Knopp talked about Brix and Wicket 1.5.

Matej Knopp (SK): BRIX CMS + Wicket 1.5 Developments Q&A

Matej Knopp showed what the content management system Brix is all about. Brix is based on Wicket and is a component based content management system based on JCR for storage.

Brix is meant for integration with Wicket web applications and looks very interesting. The basic building blocks in Brix are Tiles, Pages, and Templates.

In Brix, Tiles are like a factory for embedding Wicket components. So any Wicket component can be added to a Page which is nearly impossible in ‘regular’ CMS systems. More information about Brix can be found on the Brix website.

Wicket 1.5

Matej also talked about some new developments that can possibly be shipped in Wicket 1.5:

New RequestCycle
New RequestMapper
New Ajax implementation

New RequestCycle and RequestMapper

One of the areas where improvements can be made is the RequestCycle. The RequestCycle in Wicket 1.4.x is big and complicated, and hard to step through while debugging. Matej worked on an improved RequestCycle.

Matej talked about the drawbacks of the Wicket 1.4 code for handling requests and mapping requests to URL’s:

Complicated, huge code base
Many abstractions, most of them on wrong level
Complicated class hierarchy, hard to find proper extension point

He proposed a new RequestMapper that handles Request mapping in a different way.

RequestMapper Interface

The RequestMapper will get the following interface.

public interface RequestMapper {
int getCompatibilityScore(Request request);
RequestHandler mapRequest(Request request);
Url mapHandler(RequestHandler requestHandler);
}

With the RequestMapper interface you can implement your own Request Mapping behavior for various URL’s.
There can be a hierarchy of RequestMappers. When there is more than one RequestMapper, the compatibility score can be used to choose which RequestMapper will be used.

Calculating RequestMapper compatibility score

The compatibility score is calculated by counting how many URL segments match the mount point.
For example, having an application where two RequestMappers are defined with these URLs:

/mounted/page
/mounted/page/that/is/different

When there is a new Request on “/mounted/page/that/is/”, the second RequestMapper gets a higher compatibility score (4) than the RequestMapper matching only the first two parts of the URL (“/mounted/page/”).

New AJAX implementation

About a year ago, Matej created a new Ajax implementation for Wicket. The new Ajax implementation is way better than what is now in Wicket 1.4. It is faster, simpler to use and will be based on a standard library. There is only one problem, the new Ajax implementation Matej built uses YUI. It seems that the world prefers jQuery over YUI. Matej told that rewriting it to jQuery will be a lot of work.

The focus of the new Ajax implementation is removing browser inconsistency code. The custom-written Wicket Javascript will be swapped for more standard Javascript (like the YUI or jQuery libraries).

The API for working with Javascript will be different and much cleaner according to Matej. Also, the generated Javascript is nicer: code is not put directly in the onclick of a UI control, but separately. This looks like how WiQuery does stuff. This means that the Javascript handlers are much shorter, so the page loads faster.

There is an experimental branch in source control, so if you want to try it out or convert it to jQuery, you are welcome to check it out.

Problems with implementation Wicket 1.5

There are some challenges with the implementation of Wicket 1.5. Matej touched a few and gave some insight in what needs to be done. The big question is: how to build this without breaking anything? How can we undo the universe?

One point was the use of global state during the 1.4 Wicket RequestCycle. This makes it difficult to implement the new RequestCycle in core, because much code and unit tests rely on this global state.

Another challenge is keeping the WicketTester in a workable state. The new RequestCycle breaks WicketTester, which is problematic because many people are using WicketTester. Fixing WicketTester is not really easy, because it is a big class with much functionality. It can simulate a lot of actions, like file upload and form submission.

Sven Meier encouraged us to not refrain from writing custom Javascript.

Sven Meier (DE):

Sven Meier showed us his implementation of a TreeModel. He argued that Swing’s TreeModel is not suitable for implementing a tree in Wicket: “The treemodel is ugly, and there are many methods you don’t need in Wicket.”

His implementation allows hierarchical markup in the tree. This makes it easier to use and extend. It uses simple and known patterns. Partial update is not there yet.

Google Code hosts the Wicket Tree project.

Drag and drop

Sven also created Wicket drag and drop functionality, which is also hosted at Google Code.

This project enables you to drag and drop between any Wicket component. It supports common desktop metaphors with ‘MOVE’, ‘COPY’ and ‘LINK’ operations and is fully themable.

Sven’s closing remarks were: “Don’t fret from developing custom Javascript. It’s really easy with Wicket!”

Martijn Dashorst compared having a baby to writing a book.

Martijn Dashorst (NL):

Martijn’s presentation was titled “Writing Books vs Making Babies” and was a hilarious story with good slides. We have been informed of all the gory details of writing a book (finding the publisher, writing, editing, checking, etcetera) and learned something about having a baby as well!

Wicket Q&A

There were not many questions about Wicket, which is proof for the developer friendliness of Wicket

Were you there?

If you were at the London Wicket meetup (presenter or attendee) or plan to go there next time, please comment below!

If you send me links to the presentations, I will add them to the article.

Read the original at London Wicket Meetup: Wicket 1.5, WiQuery, Brix and more.. or go to the homepage of STUQ.nl

Automatically test your Wicket panel HTML markup

Daan — Sun, 01 Nov 2009 20:03:04 +0000

Are you testing your HTML markup automatically yet? If your markup does not match the Java code, your Wicket panel does not work. It’s easy to get early feedback when your panels are broken: just unit test them!

In this blog post I describe a way of automatically verifying that the HTML markup of Wicket panels match the Java code. Scroll down to download the demo project!

Unit test

I created a JUnit test that you can add to your project to automatically test as much Wicket Panels as possible. Automatic testing works by resolving all panels on the Java class path and feeding them to the WicketTester. When a panel has invalid markup, the WicketTester will give an error: early feedback!

How does it work?

The Wicket panels that can automatically be tested should have a ‘default’ Wicket constructor, like this:

public DemoPanel(String id)

Resolving all panels is done with Spring 2.5’s ClassPathScanningCandidateComponentProvider (don’t you love those names! How can they stay below 120 characters per line?)

The ClassPathScanningCandidateComponentProvider is a component provider that scans the classpath from a base package. It then applies exclude and include filters to the resulting classes to find candidates.

Testing panels

@Test
    public void testAllWicketPanels() throws Exception {
        WicketTester wicketTester = new WicketTester(new WicketApplication());
 
    	ClassPathScanningCandidateComponentProvider provider = new ClassPathScanningCandidateComponentProvider(true);
        provider.addIncludeFilter(new AssignableTypeFilter(Panel.class));
 
        Set components = provider.findCandidateComponents("nl/stuq/demo");
        for (BeanDefinition component : components) {
            Class clazz = Class.forName(component.getBeanClassName());
            if(hasDefaultConstructor(clazz)){
            	testWicketPanel(wicketTester, clazz);
            }
        }
    }
 
    private void testWicketPanel(WicketTester wicketTester, Class clazz) {
    	wicketTester.startPanel(clazz);
    	wicketTester.assertNoErrorMessage();
    	wicketTester.assertNoInfoMessage();
    }
 
    private boolean hasDefaultConstructor(Class clazz) {
        for(Constructor constructor : clazz.getConstructors()){
            if(constructor.getParameterTypes().length == 1 &amp;&amp;
               constructor.getParameterTypes()[0].getSimpleName().equals("String")){
                return true;
            }
        }
 
        return false;
    }

The test instantiates a new WicketTester. After that, the ClassPathScanningCandidateComponentProvider is created and configured to scan only for Panel classes in the nl.stuq.demo package and below.
After that, the found components are all checked. If they have a default constructor, the test is executed.

The boolean hasDefaultConstructor(clazz) method checks if the class has a constructor with only one String argument, the Wicket id.

Keep in mind

This is only for lazy people (good developers are lazy in some ways).
You need a dependency to Spring.
Only Panels with a certain constructor are tested.
Only instantiating the Panel is tested, so code coverage has no meaning for this test. Real testing is still needed.

Download demo project

The demo project is a Maven project based on the Wicket 1.4.3 quickstart that contains the test class and an example panel to be tested.
Download demo project.

Extract the zip file and run mvn test to run the tests. Then fire up your IDE and check how it’s done.

You can change or adapt the given JUnit test to also automatically test classes extending from Page or Component.

Join in with your opinions and code! I’m curious to see what clever way you have of testing code.

Read the original at Automatically test your Wicket panel HTML markup or go to the homepage of STUQ.nl

Refcard: Getting started with Wicket released

Daan — Thu, 30 Jul 2009 10:02:56 +0000

Some days ago, Andrew Lombardi released a new Refcard: Getting started with Wicket.

You can get these and more on the DZone Refcardz site.

Read the original at Refcard: Getting started with Wicket released or go to the homepage of STUQ.nl

ApacheCon Europe 2009 community meetup experiences

Daan — Fri, 03 Apr 2009 21:17:56 +0000

In this guest post, Minze Tolsma, software developer at Capgemini shares his experiences attending the ApacheCon community meetups.

This year I went to the ApacheCon community meetups. There were several, but I chose to attend the Maven and the Wicket meetup. I made some short notes on the most interesting things.

Monday 23-03-2009: Maven

The meetup on Maven was about new features and new projects.

Eclipse Integration

The community is working on a new tool for Eclipse Integration called Eclipse IAM (Integration for Apache Maven). The plugin aims at simplicity and will bring the best Eclipse integration for what Maven offers. It will integrate with JDT and WTP. The following features will be in the package:

Direct project import with a POM. Instead of using the Eclipse archetype.
You can setup projects in Eclipse by using predefined archetypes.
You can configure autobuilds so building isn’t annoying.
There will be a FormBased POM editor, just like you are used to in Eclipse.
Dependency search
Dependency management
Dependency graphing and analysis

Eclipse IAM will be worth looking at, it can be found at http://www.eclipse.org/iam/.

Maven 3.0 new features

The community is working on Maven 3.0. Some new features:

Embeddable, so it will be faster
Some improvements to make it easier to use with the repository
New transport mechanism for simultaneous downloads.

Eclipse 3.0 projectpage: http://docs.codehaus.org/display/MAVEN/Maven+3.0.x
After this two subjects and some live demos there was an open discussion. Because it was late in the evening I left. One thing I wrote down is that SourceSense made an Alfresco archetype for Maven.

Tuesday 24-03-2009: Wicket

The Wicket meetup was quite different in comparison with the Wicket meeting. There where several presentations about testing, Scala and Wicket, Wicket and DB4O.

JDave

For testing nothing was really new… Except the following framework for Behaviour Driven Development: JDave. More info on: http://www.jdave.org/.
Presentation of the ApacheCon and examples on: http://www.jdave.org/bdd-wicket/.

DB4O

DB4O is a Object Database for Java and .NET shipped with two different licenses. More detailed information about DB4O can be found on the DB4O website.

You can look at DB4O as a large factory (like the Factory design pattern (GoF)) just for storage. It is a good practice to use some XML storage together with DB4O. For this you can use XStream. Using XML for storage together with object storage offers you a good backup mechanism.

Some disadvantages of DB4O are:

When data is corrupt there are strange exceptions.
Version Management for the objects is hard to do.

Scala and Wicket

The presentation about Scala and Wicket was really a hands-on presentation. The slides, code examples and handouts can be found at http://stuq.nl/weblog/2009-02-04/download-the-basic-and-wicket-scala-talk-materials. Just try it and get introduced to the concepts of functional programming using the JVM and Wicket.

After all I had two nice evenings and learned a lot. I hope this article gives you some nice and hopefully new useful information!

Read the original at ApacheCon Europe 2009 community meetup experiences or go to the homepage of STUQ.nl

Download the Basic and Wicket Scala talk materials

Daan — Wed, 04 Feb 2009 16:37:11 +0000

On February 4th I gave a talk at the London Wicket User Group. These are all the materials that you can download to get started with Scala and Wicket today!

If you want to attend one of the Wicket User group meetings in London, just visit the jWeekend site and register there. It’s really cool to attend, there is a good atmosphere and nice and smart people everywhere…

Downloads

Code samples (5.5 MB)
- Simple HelloWorld Scala demo
- Hello Wicket World demo (Scala and Wicket)
- Hello Wicket World demo built with Maven
Handout (1.9 MB)
Slides (16.1 MB)

Or download everything at once (22.2 MB)

Scala resources

In this separate post you find links to Scala resources on the web (they are also in the slides, but this is much easier to click on).

6 Scala resources for Java programmers

Read the original at Download the Basic and Wicket Scala talk materials or go to the homepage of STUQ.nl

6 Scala resources for Java programmers

Daan — Wed, 04 Feb 2009 16:31:03 +0000

During my Basic Scala and Wicket talk at the London Wicket Event I showed some good Scala starting points for Java programmers. Here they are, clickable and all.

	Scala Homepage The Scala home on the web. Contains reference manuals, tutorials, news, specifications.
	First steps to Scala When you don’t know anything about Scala, start here. Covers the interpreter, variables, methods, loops, arrays, lists, tuples, sets, maps, classes, singletons, traits, mixins.
	Scala for Java refugees Series of 6 great articles covering a lot of Scala. Aimed at Java developers.
	Scala Wiki An ever growing collection of resources on Scala. FAQ, code samples, design patterns, Scala job openings
	Scala for Java programmers Multiple articles covering a feature by feature comparison of Scala and Java.
	Scala Mailing Lists Official mailing lists Subscribe: empty message to scala-subscribe@listes.epfl.ch

Read the original at 6 Scala resources for Java programmers or go to the homepage of STUQ.nl

Why many Java performance tests are wrong

Daan — Wed, 28 Jan 2009 19:58:51 +0000

A lot of ‘performance tests’ are posted online lately. Many times these performance tests are implemented and executed in a way that completely ignores the inner workings of the Java VM. In this post you can find some basic knowledge to improve your performance testing. Remember, I am not a professional performance tester, so put your tips in the comments!

An example

For example, some days ago a ‘performance test’ on while loops, iterators and for loops was posted. This test is wrong and inaccurate. I will use this test as an example, but there are many other tests that suffer from the same problems.

So, let’s execute this test for the first time. It tests the relative performance on some loop constructs on the Java VM. The first results:

Iterator – Elapsed time in milliseconds: 78
For – Elapsed time in milliseconds: 28
While – Elapsed time in milliseconds: 30

Allright, looks interesting. Let’s change the test a bit. When I reshuffle the code, putting the Iterator test at the end, I get:

For – Elapsed time in milliseconds: 37
While – Elapsed time in milliseconds: 28
Iterator – Elapsed time in milliseconds: 30

Hey, suddenly the For loop is the slowest! That’s weird!

So, when I run the test again, the results should be the same, right?

For – Elapsed time in milliseconds: 37
While – Elapsed time in milliseconds: 32
Iterator – Elapsed time in milliseconds: 33

And now the While loop is a lot slower! Why is that?

Getting valid test results is not that easy!

The example above shows that obtaining valid test results can be hard. You have to know something about the Java VM to get more accurate numbers, and you have to prepare a good test environment.

Some tips and tricks

Quit all other applications. It is a no-brainer, but many people are testing with their systems loaded with music players, RSS-feed readers and word processors still active. Background processes can reduce the amount of resources available to your program in an unpredictable way. For example, when you have a limited amount of memory available, your system may start swapping memory content to disk. This will have not only a negative effect on your test results, it also makes these results non-reproducible.
Use a dedicated system. Even better than testing on your developer system is to use a dedicated testing system. Do a clean install of the operating system and the minimum amount of tools needed. Make sure the system stays as clean as possible. If you make an image of the system you can restore it in a previous known state.
Repeat your tests. A single test result is worthless without knowing if it is accurate (as you have seen in the example above). Therefore, to draw any conclusions from a test, repeat it and use the average result. When the numbers of the test vary too much from run to run, your test is wrong. Something in your test is not predictable or consistent. Try to fix your test first.
Investigate memory usage. If your code under test is memory intensive, the amount of available memory will have a large impact on your test results. Increase the amount of memory available. Buy new memory, fix your program under test.
Investigate CPU usage. If your code under test is CPU intensive, try to determine which part of your test uses the most CPU time. If the CPU graphs are fluctuating much, try to determine the root cause. For example Garbage Collection, thread-locking or dependencies on external systems can have a big impact.
Investigate dependencies on external systems. If your application does not seem to be CPU-bound or memory intensive, try looking into thread-locking or dependencies on external systems (network connections, database servers, etcetera)
Thread-locking can have a big impact, to the extent that running your test on multiple cores will decrease performance. Threads that are waiting on each other are really bad for performance.

The Java HotSpot compiler

The Java HotSpot compiler kicks in when it sees a ‘hot spot’ in your code. It is therefore quite common that your code will run faster over time! So, you should adapt your testing methods.

The HotSpot compiler compiles in the background, eating away CPU cycles. So when the compiler is busy, your program is temporarily slower. But after compiling some hot spots, your program will suddenly run faster!

When you make a graph of the througput of your application over time, you can see when the HotSpot compiler is active:

Througput of a running application over time

The warm up period shows the time the HotSpot compiler needs to get your application up to speed.

Do not draw conclusions from the performance statistics during the warm up time!

Execute your test, measure the throughput until it stabilizes. The statistics you get during the warm up time should be discarded.
Make sure you know how long the warm up time is for your test scenario. We use a warm up time of 10-15 minutes, which is enough for our needs. But test this yourself! It takes time for the JVM to detect the hot spots and compile the running code.

Update

From Dries Buytaert I received a link to a paper called Statistically rigorous Java performance evaluation. I highly recommend reading it when you want to know more about measuring Java performance.

Remember, I am not a professional performance tester, so put your tips in the comments!

Read the original at Why many Java performance tests are wrong or go to the homepage of STUQ.nl

76 Events: statistics about Hibernate 3.2.2

Daan — Tue, 30 Dec 2008 20:59:00 +0000

Frameworks are growing with every release. Classes are changed, removed and added. In this series I zoom in on some well known projects and analyze their class names with completely meaningless statistics. This is the analysis of Hibernate 3.2.2.

To get these statistics, I wrote a script that analyzed all classes. They get chopped up on word boundaries, so for ContextAwareFactoryBean the words Context, Aware, Factory and Bean are counted. From the output I generated a Class Cloud.

What is Hibernate?

Hibernate is a free, open source Java package that makes it easy to work with relational databases. Hibernate makes it seem as if your database contains plain Java objects like you use every day, without having to worry about how to get them out of (or back into) mysterious database tables.

Hibernate listens very carefully

What immediately catched my eye was the amount of classes with Event (76) or Listener (52) in their name. There are many events in Hibernate which can be catched. These events can have some related classes, like:

the event itself (for example the AutoFlushEvent)
an interface (the AutoFlushEventListener)
a default implementation (the DefaultAutoFlushEventListener)

It almost surprised me there was no AbstractAutoFlushEventListener or a AbstractAutoFlushEventListenerFactory!

Factories

There are 57 factories, which is quite a lot outside of an industrial park. A lot of stuff can be created using factories, for example the BasicProxyFactory, the CGLIBProxyFactory, the CacheFactory, the ClassicQueryTranslatorFactory and the MapProxyFactory. I would guess this is the most popular design pattern within the Java world. Factories are everywhere.

Types and Collections

Luckily, there is also a lot of stuff directly related to the goal of Hibernate. There are 85 classes with Type in their name, and 54 have something to do with a Collection.

There are basic types like the FloatType and IntegerType. Advanced types like the OrderedMapType and the OrderedSetType. PersistentCollection and BasicCollectionLoader. These class names look quite good!

Class Cloud (click to enlarge)

Top 10 of partial class names

Type: 85
Event: 76
Factory: 57
Collection: 54
Cache: 53
Exception: 53
Query: 53
Listener: 52
Entity: 47
SQL: 39

Longest class name

The longest class name of Hibernate is the CollectionFilterKeyParameterSpecification, with 41 characters!

The API documentation describes this class:

A specialized ParameterSpecification impl for dealing with a collection-key as part of a collection filter compilation.

I thought API documentation was meant to clarify? At least the above contains some pointers (like the ParameterSpecification).
Stay tuned for more useless statistics for other well known projects! If you have suggestions for which projects you want to see, please let me know in the comments!

Read the original at 76 Events: statistics about Hibernate 3.2.2 or go to the homepage of STUQ.nl

37 Factories: statistics about Tomcat 6

Daan — Mon, 29 Dec 2008 07:00:38 +0000

Tomcat is definitely Context-aware

Tomcat consists of 956 classes. Of those, 55 classes contain the word Context, a percentage of 5.75%. Remember that every live object has its own ‘context’, and the word instantly loses a lot of meaning. The API documentation gives some clearance about the subject:

A Context is a Container that represents a servlet context, and therefore an individual web application, in the Catalina servlet engine.

Factories? Sure!

Every self-respecting framework has factories. It nicely keeps the newcomers out and makes it ‘easier’ for the experts. Well, Tomcat has 37 of them. Just like Spring, Tomcat has a BeanFactory. The API documentation say just enough to leave me in confusion:

BeanFactory: Object factory for any Resource conforming to the JavaBean spec.

The AbstractObjectCreationFactory

It was love on first sight with the AbstractObjectCreationFactory. It all comes together in this single class. Every project should have this… until now you created all your abstract objects yourself, this is not needed anymore! All those years!

Unfortunately, I had it wrong. This is an abstract implementation of the ObjectCreationFactory interface. Further investigation revealed that this is part of the Digester package.

The Digester package provides for rules-based processing of arbitrary XML documents.

I have no idea why this is in Tomcat. A leftover? Bad refactoring? Who knows?

Class Cloud (click to enlarge)

Top 10 of partial class names

Context: 55
Factory: 37
Task: 33
Ast: 33
Channel: 33
Rule: 32
Base: 31
Constants: 30
Handler: 30
Jsp: 27

Longest class name

The grand prize goes to: MbeansDescriptorsIntrospectionSource, with 36 characters!

The API documentation does not contain a description of this class, so I have no idea what it does…

Stay tuned for more useless statistics for other well known projects! If you have suggestions for which projects you want to see, please let me know in the comments!

Read the original at 37 Factories: statistics about Tomcat 6 or go to the homepage of STUQ.nl

8.47% is a Resource: statistics about Wicket

Daan — Tue, 02 Dec 2008 19:23:09 +0000

Wicket likes Requests for Pages or Resources

8.47% of the total number of classes in Wicket contain the word Resource. In absolute numbers, 68 classes (of a total of 802) have this word in their name. This is quite a low percentage for the top result, compared to the Spring statistics where the top result Bean is present in 12.31% of all classes.

From the top ten, it’s easy to spot that Wicket is a web framework, with Pages, Web, Ajax and Resources in many class names.

Wicket loves Wicket

A bit remarkable regarding Wicket statistics: about 4.24% of all classes have the string ‘Wicket’ in their name. Relative to the number of Spring classes that have Spring in their name, this is 2.3 times as much!

In general, the class names of Wicket are well distributed. This probably originates in the fact that Wicket is very specialized on one subject and is not a general purpose platform.

Class Cloud (click to enlarge)

Top 10 of partial class names

Resource: 68
Request: 62
Page: 56
Abstract: 42
Target: 37
Stream: 36
Validator: 36
Web: 36
Component: 34
Ajax: 34

Longest class name

The grand prize goes to: BookmarkablePageRequestTargetUrlCodingStrategy, with 46 characters!

The BookmarkablePageRequestTargetUrlCodingStrategy encodes and decodes mounts for a single bookmarkable page class (source).

Stay tuned for more useless statistics for other well known projects! If you have suggestions for which projects you want to see, please let me know in the comments!

Read the original at 8.47% is a Resource: statistics about Wicket or go to the homepage of STUQ.nl