k0de

2011-01-22T09:28:00.000-08:00

Emacs vs Vi reminds me of the Iran-Iraq war. A war that went on for ages, in a place that nobody cared about, between two groups that nobody cared about, that stagnated and stunted their development, while the rest of the world left them behind.

"Stormbringer" nails it.

http://news.ycombinator.com/item?id=2125283

OpenJDK and Project Lambda on MacOS X 10.6

2010-09-30T10:56:00.000-07:00

Want to try out the upcoming JDK 7 on your Mac? And closures from Project Lambda, due in JDK 8? There are currently no official binary build available for MacOS X, but it turns out that it's actually gotten pretty easy to build these projects yourself. With just 10 minutes of work and a little waiting you could have a working build! Here's my account of how to do it.

First, install Mercurial and the forest extension. If you have Macports, this is as easy as

$ sudo port install mercurial
$ sudo port install hg-forest

Now check out the OpenJDK bsd-port tree:

$ hg fclone http://hg.openjdk.java.net/bsd-port/bsd-port

You have to download soylatte16-amd64-1.0.3.tar.bz2 from

http://landonf.bikemonkey.org/static/soylatte/#get

and unpack it. This is needed for bootstrapping the build.

Use this build script:

export SOYLATTE_HOME=$HOME/src/soylatte16-amd64-1.0.3
export JAVA_HOME=$SOYLATTE_HOME

cd bsd-port

time env -i PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin \
make \
CC=gcc-4.0 CXX=g++-4.0 \
ALT_BOOTDIR=$SOYLATTE_HOME \
JAVA_TOOLS_DIR=$SOYLATTE_HOME/bin \
ALLOW_DOWNLOADS=true \
ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \
ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \
ANT_HOME=/usr/share/ant \
NO_DOCS=true \
HOTSPOT_BUILD_JOBS=1

This is based on Sam Pullara's Building OpenJDK 1.7.0 post. I just had to add ALLOW_DOWNLOADS=true to avoid this error:

ERROR: Cannot find source for project jaxp.

When you run the script (if all goes well) you should get a lot of output that ends with

Control bsd i586 1.7.0-internal all build finished: 10-09-30 15:37

On my MacBook Pro (Core i7, 4 GB RAM, SSD) this took a little over 20 minutes.

Now move your newly built JDK somewhere more sensible:

$ mv bsd-port/build/bsd-i586/j2sdk-image ~/jdk7

Test the install:

$ jdk7/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-kjetilod_2010_09_30_15_15-b00)
OpenJDK Server VM (build 19.0-b05, mixed mode)

Project Lambda
For bonus points, here's how you build Project Lambda (based on a post by Rémi Forax to the lambda-dev mailing list):

Checkout the source:

$ hg clone http://hg.openjdk.java.net/lambda/lambda/langtools

Build it with Ant (I just used 1.7.1 which comes with MacOS X):

$ cd lambda/langtools/

$ ant -Dboot.java.home=$HOME/jdk7 -f make/build.xml

From Rémi's post:

To run the compiler:

/bin/java -cp classes.jar

com.sun.tools.javac.Main yoursource.java

and to run your code:

/bin/java -cp classes.jar:. YourClass

WAS tip: Application build level

2009-08-12T04:00:00.001-07:00

If you want WebSphere to display "Application build level" for your application, your EAR Manifest has to contain "Implementation-version".

For Maven to add this automatically, add this to your EAR pom:

<project>

    ...

   <build>
   <plugins>
   <plugin>
       <artifactId>maven-ear-plugin</artifactId>
       <configuration>
           <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
       </configuration>
   </plugin>
   </plugins>
    </build>

</project>

IdeaPad FTW!

2009-03-24T14:34:00.001-07:00

Just got a new toy to satisfy my geek needs: a Lenovo IdeaPad S10e. So far, I'm pretty happy with it. Here are some thoughts after a couple of days' use.

It's a decent browsing machine. A 1024x576 screen resolution is just barely adequate for normal web browsing these days. Heavy flash use sometimes make scrolling a bit choppy. But the fantastic portability more than makes up for these shortcomings. (No, an iPhone doesn't really compete.)

The keyboard is not fit for serious development work. I'm typing this on the somewhat smaller-than-usual keyboard and I'm doing ok. However, there is only one Ctrl key, the tab key is tiiiiiiny, and the layout is kind of cramped together which makes it hard to touch type anything else than normal letters. The CPU and RAM might not be particularly impressive compared to your workstation, but for me they're not the main bottlenecks.

I like it. I've never had a laptop this portable. My normal work laptop is a 17" workstation model, which is great for the performance and screen size, but not so much for taking notes in meetings.

Now, to try out Ubuntu Netbook Remix in my copious free time...

Mac Keyboard layout driving you crazy?

2009-03-12T12:01:00.000-07:00

I'm officially giving up adapting to the incompatible Mac keyboard layout. This page explains what you need to do to fix it.

I'm also switching IntelliJ over to the standard PC-style layout, which is trivial to do. Life's too short to make adjustments to this crap.

2009-01-14T08:49:00.000-08:00

Leaving it here so I'll find it later: If RAD complains that an EAR project won't build because
"The deployment descriptor of the module 'xxx.war' cannot be loaded." for WAR or EJB modules, you have to add them to the org.eclipse.wst.common.component file in the .settings directory in the project directory, like this

/">
WebModule_
uses

Found this here: http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=14048396&#14048396

String constructor considered useless turns out to be useful after all (film at 11)

2008-09-23T11:01:00.000-07:00

When you were still a Java neophyte, chances are you wrote some code that looked like this:

String s = new String("test");

Brings back some embarrassing memories, doesn't it? You soon learned that instantiating Strings via the constructor was hardly ever done, and the String constructors seemed to be, well, utterly useless. When do you really ever need to do "new String(oldString)"? Come on, IntelliJ IDEA even flags all occurrences of this as "redundant"!

It turns out that this constructor can actually be useful in at least one circumstance. If you've ever peeked at the String source code, you'll have seen that it doesn't just have fields for the char array value and the count of characters, but also for the offset to the beginning of the String. This is so that Strings can share the char array value with other Strings, usually results from calling one of the substring() methods. Java was famously chastised for this in jwz' Java rant from years back:

The only reason for this overhead is so that String.substring() can return strings which share the same value array. Doing this at the cost of adding 8 bytes to each and every String object is not a net savings...

Byte savings aside, if you have some code like this:

// imagine a multi-megabyte string here
String s = "0123456789012345678901234567890123456789";
String s2 = s.substring(0, 1);
s = null;

You'll now have a String s2 which, although it seems to be a one-character string, holds a reference to the gigantic char array created in the String s. This means the array won't be garbage collected, even though we've explicitly nulled out the String s!

The fix for this is to use our previously mentioned "useless" String constructor like this:

String s2 = new String(s.substring(0, 1));

It's not well-known that this constructor actually copies that old contents to a new array if the old array is larger than the count of characters in the string. This means the old String contents will be garbage collected as intended. Happy happy joy joy.

Sometimes, seemingly useless constructs reveal hidden gems of usefulness. Be sure to check out the source for String to find how this works!

Multiline grep

2008-08-22T01:43:00.001-07:00

I recently needed to do some multiline grepping through some log files. The problem is, the default grep and egrep on Linux systems don't seem to support regex patterns that extend over several lines.

Luckily, at least RHEL come with pcregrep installed, which does Perl-compatible regex matching. And by adding a -M switch you get multiline matching!

So you can just go

pcregrep -M 'a\nb' files...

Easy peasy!

EBCDIC trick

2008-05-15T02:05:00.000-07:00

You can use good old /bin/dd to convert EBCDIC files to their ASCII equivalent.

Just do

dd if=infile.txt of=outfile.txt conv=ascii

Which does the conversion automatically.

Maven 2 help plugin

2008-04-07T07:37:00.000-07:00

(I always forget this bit, so I'm putting it here for posterity.)

The help plugin for Maven 2 can print the possible goals and other info for a plugin:

mvn help:describe -Dplugin=eclipse -Dmedium=true

-Dfull=true gives some more detailed output.

For more info see the help plugin pages.

2007-10-18T13:49:00.000-07:00

On clean code and refactoring

Bob Martin (also known as "Uncle Bob") visited us at BEKK today and gave us a short pep talk on "clean code". Using his argument parser written in Ruby as an example, he showed some refactoring tricks and some nice Ruby idioms (passing blocks as arguments, etc.). His main point was that you should never check in bad code and leave the fixing for later, cause "later" never comes. If you make a mess, you should clean it up, and clean it up now.

I've thought along these lines before, and one of the issues I've wondered about is: Should you refactor just after you write the code or should you leave it until the next time you need to change it? This is really just another way of asking "How do you know where your refactoring should end up?"

On one hand, I agree that you should clean up after yourself if you've duplicated something or in some other way made the code worse than it was. But on the other hand, you don't know now what the best structure is since you don't know what changes you want to make next time. You'll have to guess in what form you'll need the code to be the next time you change it. This might lead you to a "local optimum" of code quality, but when you revisit the code you might need to take in a totally different direction, forcing you to abandon the local optimum for a solution that is better in the big picture.

If you leave the code in its current (messy) state and wait until the next time you have to change it, it could be a lot easier to see in which direction you should go. With concrete requirements for how you want to change the code, you can probably see that "hey, this would be a lot easier to change if the code was structured this way...". You would then have to make the necessary refactorings, before making any changes.

Of course, there's always the chance that you'll be in a hurry the next time, and so you won't really have time for refactoring. Your changes will make the design worse, and all of a sudden you have a big ball of mud. Also, working this way feels a bit like always working uphill. For every change you want to make, you have to refactor something first. It's a bit like having to clean up the kitchen, when you really just want to make dinner.

Either way, I guess I prefer cleaning up after I've written some (messy) code to leaving it for later. You can probably make educated guesses in most cases as to where you should take the design. But, just as you should be ready to throw away some messy code, I think you should be prepared to back out some refactorings if they conflict with the way you feel the code should be going.

Anyway, just some food for thought.

2007-10-04T13:41:00.000-07:00

Spring dynamic proxy problem

I encountered a strange problem at work today: The following test code failed:

ServiceImpl service = applicationContext.getBean("serviceImpl");

The application context looks like this:

ServiceImpl implements the Service interface.

Note that the reference type in the test code is ServiceImpl. I sometimes do this when I need to test drive methods that are not in the implemented interface.

The error was a ClassCastException, which made no sense. Looking at the error, it said that it was unable to cast Proxy-yadayada to ServiceImpl.

It turns out that someone added some AOP stuff to the service classes. Spring then proxies the service implementation in one of two ways: if the class doesn't implement an interface it uses cglib to create a proxy.

But if the class does implement an interface Spring will interject a dynamic proxy which implements that interface between the original interface and implementation, and the above code will fail.

So what's the solution? The only immediate solution I see is to instantiate the service implementation yourself if you need to test drive methods that are not in the interface. Hardly ideal, but easy enough.

2007-09-18T12:52:00.000-07:00

Is the DAO pattern still valuable in the time of ORM?

The DAO discussion is surfacing again (previously), and there's one point I think is lacking from the current discussion: Testing.

It's a lot easier to mock or stub out PersonDao.getPersonByFirstName() method than EntityManager.createNamedQuery() blah blah blah. Don't mock infrastructure. Avoiding the database access is crucial to making your tests run as fast as possible.

The DAO tests themselves should access the database, of course, as well as the end-to-end functional tests. But running every test in the system against the database is simply uneconomical.

2007-09-14T13:35:00.000-07:00

JavaZone 2007: The end

That's it, the conference is over. We can all go home, get some rest and wait for next year (which will probably be even bigger).

Totto, the javaBin's president, noted in his foreword to the JavaZone program that his inspiration came when he attended JavaOne back in 1996. It's really quite amazing how far we've come since then. One can only wonder where we'll be in a couple of years more.

If you arrived here from a another summary of my JavaZone posts, that summary was adopted from the previous blog posts. The blog posts are a bit unpolished (I wrote them live), but may contain a bit more information than the summary, so if you're can look there for details.

After a short holiday, I promise regular programming will resume...

2007-09-13T09:01:00.000-07:00

JavaZone 2007: How to build enterprise applications with Java SE

"The original title of this talk was 'How to make sysadmins love you'"

Trygve Laugstøl from Arktekk, a noted open source contributor and a self-described UNIX lover, talked about considering Java SE instead of EE for building applications.

The motivating thought was to make it easy to admin the solutions we make. By embedding services and making the app runnable from a script, it's a lot easier for operations to admin; they don't have to manage an app server.

This is not a criticism of Java EE, but to make the case for Java SE as an alternative. Java EE 5 is 23 different specs, you have to be a rocket scientist to know it all. Takes a long time to deploy to app server. Dev and production environments are different.

Much faster development cycle. No app server. Test only the bits you need.

Have a main class which starts the entire application, with getters/setters for command arguments (port, location of conf file, etc.). You can now start your entire application from a unit test. Use commons-cli for command-line argument parsing.

Trygve thinks using VMWare for local developing is a waste, but thinks you should still try to develop the app on the same platform it will be deployed on.

A lot of the new and useful technologies in JEE are now in JSE (JPA, JMX, Stax). XFire, Axis, ActiveMQ, Jetty, JNDI work great in JSE. You should embed the features you need. Think UNIX: small, specialized components. You can still include a servlet engine, but this time you control it, it doesn't control you.

Today: Java is the Cobol of the 90's
I'm hoping for: Java is the UNIX for the 90's

Use conventions for file system layout (like in UNIX). Package the app like a standard UNIX app (tarball).

Trygve also recommends to use the appassembler plugin to assemble the app and generating startup scripts (fixes classpath, etc.). Use a separate maven profile for assembly to reduce build time.

Make separate loggers for significant events which operations can use for debugging (connection pool empty, etc.) and pipe them to syslog (UNIX) or the Event log (Windows).

Solaris has Service management facility (SMF) which can integrate nicely with this approach. On Linux, you can create an /etc/init.d script.

Update: Apparently I misquoted Trygve his Java-as-UNIX analogy. Fixed now :-)

2007-09-13T05:57:00.000-07:00

JavaZone 2007: Experiences on using Spring WebFlow with JSF

Holger Zobel from Accenture, who is leading the architecture group for the Norwegian Pension project, gave us a taste of the experiences from that project with integrating WebFlow and JSF.

Spring WebFlow is a very general framework, which can be used with a number of presentation frameworks (including Swing). Flows define a user dialogue.

The project has 40-50 developers and uses an IBM software stack and Myfaces JSF.

SWF 1.0 had buggy JSF support. Difficult to debug errors in flow XML.

SWF is more powerful than JSF flow, but power can be misused. Should be used only for flows. Free navigation is still difficult.

SpringIDE helps development a lot. Be sure to have good exception handling in your code.

Is it worth using SWF? In the beginning, it created more trouble than it was worth. Will probably use it for the next project, since he now knows how to use it. Can be used for small parts of an app, or introduced incrementally. SWF is not invasive.

The problems they faced were mostly from the JSF integration.

2007-09-13T05:01:00.000-07:00

JavaZone 2007: Getting the most out of GC

"GC is automatic memory management; if it was really automatic, we should all really be at the pub instead of sitting here, innit?"
(My crap rendition of Holly's actually funny joke)

Holly Cummins from IBM at Hursley, UK (where they do CICS, MQ and some JVM things, I guess) gave some general info on GC and demoed EVTK (for which she is lead). I think this is the first time I've seen an IBM-er with blue hair :-)

Holly noted that GC can actually be faster for an app than manually using malloc/free. She quoted some numbers where C apps can spend up to 20% of their time in free. GC can also exploit cache locality better by rearranging objects, compaction, etc. Unfortunately, GC can also stuff the cache full of crap when it traverses the heap.

Mean pause time is not a good indicator of performance. Small heaps mean smaller pauses, but can also mean worse performance. Smaller pauses doesn't necessarily mean better response time; if the app has a heavy workload the response time will be dominated by waiting for the CPU. "Real time is not real fast."

What can verbose GC tell you? New IBM diagnostic tools for the IBM JVM: available as plugins to the IBM Support Assistant. Extensible Verbose Toolkit: verbose GC analysis. Actually handles verbose output from Sun JVM also! Creates reports, graphs, etc. Install the Support Assistant and find EVTK as a plugin.

Holly did a nice demo of EVTK showing how too small a heap can make an app spend too much of it's time running GC, throttling app throughput. And a second demo showing how to look for a memory leak. EVTK can show how many weak references are cleared, etc.

Nice overview of the different GC policies, etc. at the end, I'm too busy following it to make notes :-)

2007-09-13T03:40:00.000-07:00

JavaZone 2007: Deploying Maven in the Enterprise

Kristoffer Moum from Arktekk gave us an entertaining overview of how to introduce Maven in a company.

A benefit of Maven is a standardized project structure, which means employees don't have to learn different set-ups.

Start with a company-wide Maven POM with repository references, deployment settings and dependency management.

Set up internal repositories: snapshot, release and third-party repos with Apache WebDAV; set up a Maven proxy which becomes a single entry point to both the internal and the external repos.

Kristoffer uses the Maven Proxy from Codehaus: simple to configure, flexible. Other implementations offer GUI configuration, etc.

All artifacts built by the CI server should be directly deployed to the internal repository (snapshots).

Project experiences

Transitive dependencies: poor third-party POMs add excessive dependencies. One solution is to graph the dependencies and manually exclude dependencies. For instance the maven dependency plugin with the 'tree' goal.

Implicit plugin versioning: version is not specified, so the latest and greatest is downloaded and used. This often turns out to be unstable, which may result in some strange behaviour. Solution: try to control plugin versions manually.

Redeploying released artifacts: causes the new release only to be deployed for those who delete it manually. This can create a really strange situation where half of the developers can't build the project. Should be illegal.

Transitive dependencies can give some problems when you get dependencies to different versions of the same artifact. Solution: add direct dependency.

It's not a good idea to introduce all of Maven at once, it's better to introduce it incrementally.

Can be tricky to find the right module granularity. Be pragmatic when dividing projects in modules; too few or too many are not good.

Everything should be doable through the IDE. Going through Maven every time will be slow.

Too many profiles can make the build hard to understand. Don't try to solve every problem with profiles.

Some good tips here. Maven seems to be used more and more in companies.

2007-09-13T02:10:00.000-07:00

JavaZone 2007: Apache Tuscany

After a good (heh) night's sleep (double heh), another day of sessions awaits. Guys, two mornings in a row of Norwegian Rammstein covers is just brutal :-)

Simon Laws from IBM UK had a session on Apache Tuscany, a SCA implementation.

SCA is a model for distrubuted components implemented in any of a range of technologies (Java, BPEL, Ruby, etc.). Components can be integrated using web services, RMI, etc.

An app is assembled with a XML descriptor. It looks really easy to change component distribution. SCA can easily integrate with existing systems and services.

Tuscany also contains a SDO implementation for data binding.

The Tuscany distribution contains a bunch of demos which is probably the best way to start if you want to learn more than this miserable write-up (sorry, Simon, I'm really not doing your session justice).

SCA and SDO have been mostly acronyms to me till now. This session gave a nice, high-level view and rationale, as well as some nice Tuscany demos.

Tuscany blog

2007-09-12T10:12:00.000-07:00

JavaZone 2007: End of day one

Day one nears the end, at least with respect to sessions.

"Blogging live" about sessions is quite different from normal blogging in that there's more of a deadline: You have to finish one entry before the next sessions begins, or you'll be backlogged. This means some of the entries are more like notes than any deep thoughts. My mind is split on this issue, but I'll try to continue my experiment tomorrow since I think the average quality of today's entries is OK.

Also, it might not always be perfectly clear what is said by the speaker and what is added by me. I'll make it simple for you and suggest you attribute any nonsense to me, and the rest to the speakers.

The ClubZone starts soon, with four different bars open for the attendees. Here's to hoping it will be easy to get up tomorrow!

2007-09-12T10:03:00.000-07:00

JavaZone 2007: Style and Taste in Writing FIT Documents

This session had Steve Freeman (of jMock fame) and Mike Hill tackle common problems with FIT. One of the most interesting sessions today, I think.

Example-driven development

Examples force people to be concrete. The next step is to automate testing your system based on these examples. FIT is one way to do this.

The point of FIT is communicating with the customer. Other tools can be used, such as JUnit with a DSL which is easier for an analyst to understand.

Communication trumps testing

Copy-paste of a procedural FIT table can make it hard to understand what the difference is. Can be converted to declarative table where each row or column is its own example. It's harder to refactor FIT tests since there's no IDE support, this means you must be more disciplined.

Having a mega-table with lots of input and output columns ("Tangled tables") can be practical for professional testers, but doesn't communicate clearly. It can be broken up into different, smaller tables. Abstractions that developers come up with can feed back into the business language. Can also be easier to change smaller tables. As in XP, why is something a comment, instead of runnable code?

Web tests in FIT: should hide implementation details such as field names, "url" lingo, etc. Use a domain language which makes sense for your business instead.

FIT in practice

When you work on a project, you become expert on that project. Experts have their own common language. Build a language within your team to encourage a common understanding.

Make test failure easy to understand. The tests shouldn't just satisfy the business side, but the developer side as well.

Apply all good code practices to the tests also: refactoring, etc.

Collaboration problems can affect test quality negatively; if you're trying to avoid collaboration and skip refactoring because of it, you've got a problem.

Agile teams which adopt FIT documents as documentation can end up in a waterfall-like passing of FIT documents with no real dialog.

If the analysts are not very keen on FIT, try to publish the test result and the documents so it's easy to access.

Word documents vs. Fitnesse: Depends on the organization and the analyst users.

2007-09-12T08:50:00.000-07:00

JavaZone 2007: Using Spring-OSGi in Swing applications

Nils Hofseth Andersen (Capgemini Norway)

The bundle is the main "unit of modularity" in OSGi. A bundle can register services, to be used by other bundles. A bundle is a jar with a special manifest inside. Bundles can have their own lifecycles. Isolation and visibility is achieved through classloaders. OSGi should be very interesting for the people who want to get rid of their app server, as well as thick client (or other standard Java) developers.

Spring-OSGi is a project started by Interface21 to help integration between OSGi and Spring. You get some special OSGi-tags for your Spring config.

Why Swing? If you already have some Swing parts, you don't really want to combine it with SWT in an app (different look 'n' feel, etc.)

Case from Statoil's Java Enterprise Framework. Uses only Swing. Phases of introducing OSGi:

Phase 1: Introduced modules at the code level. Each module has it's own Spring config. Merging these contexts caused several problems (naming collisions, startup time, etc.).

Phase 2: ModuleFactories introduced. Each module is a child appcontext of the app. App still has to know all modules.

Phase 3: ModuleContribution introduced as the interface between the app and the module. Each module packaged as an OSGi bundle.

Planning to open source the JEF framework when it's possible.

2007-09-12T06:14:00.000-07:00

JavaZone 2007: Simplicity - Lessons learned from enterprise application development

BEKK's own Trond Arve Wasskog has a session on doing things the simple way. He has been an architect together with Johannes Brodwall on BBS' NICS project. NICS is a system for moving sums of money between banks.

Simplicity is not easy to define, but there are some ground rules: Fewer are better than many, etc.

Infrastructure

The project used two-phase commit to synchronize a database and a message queue. They needed load balancing and redundancy. The special setup only worked in special server environments, not on the developer machines.

They solved this by dropping JMS and using the database for messages. This required some glue code for sending and receiving messages, but meant they could drop 2PC. It also meant it was now testable on developer machines. As Johannes noted in his talk, they eventually decided to drop WebSphere itself.

Trond Arve thinks the app server itself is a dated concept, and would prefer to mix-and-match features. He now uses Jetty, Hibernate and Spring in his projects.

Process engines are evil! They never work: You need a lot of new knowledge to develop, deploy, support them. In their engine they would need VB-like scripting on misc steps in the process flow. By removing it, they saved a whole lot of complexity.

Deployment: why is it so hard? As Johannes noted, their new application model makes deployment a breeze.

Operations: work early on with IT operations staff.

Design

They designed their own scheduling system using DDD, which turned out only 1 of 5 projects could use successfully. In the end, they opted for a much simpler solution: An existing scheduler which uses JMX on the application. Easier to test since you no longer have to rely on an EJB timer.

Documentation

Process vs. product. Documentation in itself has no value, the communication is the value.

Architecture documents tend to only be shared between architects. Trond Arve used an approach where he intentionally didn't update his architecture documents, but when people asked if they were updated he'd rather take a personal discussion: "What are you trying to achieve?"

Functional testing

User stories should generate functional tests, not unit tests. The spec should mirror the tests. Tools to use: FIT, RSpec, etc. Should be human readable (unlike JUnit :) ).

Instead of a Windows-based automatic test application, they used Fitnesse, which more people knew. It was easier to automate.

Closer integration between testers and developers. No artificial separation.

Technical tests

JUnit test from Hell: A 700-line test case, impossible to understand. When the process engine was removed, the test shrank to a fraction.

No code means no maintenance cost and no bugs.

Development environment

Use a pre-packaged Eclipse version with a number of plugins, etc.

Use VMWare to duplicate complicated environments.

Configuration management

Johannes described the simple application model they now use. It makes it really easy both to deploy and to roll back.

2007-09-12T04:50:00.000-07:00

JavaZone 2007: Real-time web

Jonas Jacobi, a Swede with background from Oracle, has a new company called Kaazing which focuses on real-time solutions for the web.

Comet is a software concept that enables web servers to send data to the client program (normally a web browser) without having any need for the client to request it (quoting Wikipedia).

Polling vs streaming: Polling means more control for the client, but also a lot of load on the server. Streaming (long-timed requests)

Traditional AJAX apps means polling. The server has no way to notify the client if the client doesn't poll.

Jonas compared polling to a child asking "Are we there yet?" a gazillion times :)

Firewalls mean client-server breaks. AJAX and Comet works.

Comet means instant response. That's why traders normally use desktop solutions.

Most browsers (including IE and Firefox) will only open two connections to a server, which is a challenge for Comet. This means we need common request handling.

Both Jetty and Glassfish support the Bayeux protocol. Tomcat 6 will support Comet.

They are trying to get support for Comet in the servlet 3.0 spec. Comet is not currently a standard.

Jonas, with Enterprise Comet, considered translating Java source to JavaScript for the client, like in Google Web Toolkit, but there were upgrade issues, etc. They started Project Chai, a VM which dynamically translates Java class files to JavaScript on the fly, which means there are no static JavaScript files. The generated JS is then sent to the client.

Jonas showed a nice online poker demo in Firefox with Comet on the server.

The main benefit of Comet is the ability to scale (unlike traditional approaches to push).

They are considering open source (discussing with Terracotta and their experiences), but they have to please their investors. They don't necessarily want to make money on the Project Chai engine, but whatever they could build on top.

2007-09-12T03:52:00.000-07:00

JavaZone 2007: The Sun JVM inside and out

Simon Ritter (Sun) took us through the myriad of options that can be used to change the behaviour of the JVM. From 140-something XX options in Java 1.4 to 532 for the newest Dolphin.

GC

useTLAB: thread local

TLABSize: size of thread local allocation blocks

UseParNewGC: parallel copy collector

Parallel compacting collector

Incremental CMS

UseParallelGC: parallel scavenge

Ergonomics

According to Simon, the heuristic the JVM uses include checking for 2 or more GBs of memory, 2 or more processors and whether or not the machine is running Windows :)

Thread priority policy

Increasing threading options for Java can, as Simon says, be "very, very good or very, very bad". Depending on the other workload on the machine.

My vote for best named option: DontYieldALot. Which on Linux means DontYieldAtAll.

Biased locking

UseBiasedLocking: "lazy" lock/unlock for uncontended locks.

Tiered compilation

TieredCompilation: switching between the client and server JIT compiler. I recommend Alex Millers Java 7 page for details.

Random things

Consider disabling explicit GC: Even though the Java docs says that calling System.gc() will cause a GC to happen some time in the future, in Sun Java it will actually run a GC every time. Who knew!

AggressiveOpt: More aggressive optimizations, may change between versions.

Use486InstrOnly: Use only old instructions

DTrace

DTrace which "injects instructions into your kernel, which is pretty scary."

Lots of Java probes available.

Proposal for new Java SE 7 functionality: possible to enter your own DTrace probes, which you can then turn on when you need them.

I'm sure I missed over half of the interesting options Simon mentioned, was a bit busy with other stuff. It was an interesting sessions since I've heard of some of these options, but had no idea there were so many. Nice explanations as well.

Simon Ritter's weblog