Posts Tagged java

Java performance myths

Awhile back I posted a link to some good Java performance basics. Today at the office I saw an incredibly outdated JavaTM Performance Tuning and Java Optimization Tips from 1999 being circulated as a good read (that’s JDK 1.2!) and it made me cringe. I was inspired to dig up some Urban performance legends and then more Urban performance legends, revisited. A lot has changed in 10 years, and many things we used to lament over (think inlining source code) are far better left to the modern compiler.

,

No Comments

Spring4gwt, or Spring’s harmony for GWT

I’ve had an idea itching at me for awhile now, which started shortly after building a complex enterprise application using GWT connected to Spring services on the server. There are countless blogs out there describing various ways to wire up Spring with GWT, and Google’s own Gin is quite adequate for client-only dependency injection. But what I’d really like is something that ties this all together, and in the true spirit of GWT, makes it easy for a seasoned Java developer to apply proven, consistent DI practices in both the client and server using the Spring knowledge they likely already have.

My vision is basically this:

@Component
public class SomeGWTComponent {

	// Some other client-side component
	@Autowired
	private MyWidget widget;

	// A remote service proxy to a server-side Spring service
	@Autowired
	private MyService service;

	public void doSomething() {

		widget.doClientStuff();

		...

		service.doServerStuff("data", new AsyncCallback<String>() {

				public void onFailure(Throwable caught) {
					...
				}

				public void onSuccess(String result) {
					...
				}
			});
		}
	}
}

It’s important that MyService is a vanilla Spring service on the server – no extension of RemoteServlet required – and that MyWidget is any other GWT component. Injection should occur when the component is created, potentially with varying scopes just like on the server, and potentially also with @PostConstruct support for code to be executed after injection, leaving the constructor available for any pre-injection initialization. And finally, as much work as possible should be done during GWT compile minimize the run-time cost.

The approaches to GWT lookup/injection I’ve seen out there have at least one the following gaps:

  • They’re client-only (Gin)
  • They’re largely run-time, and slow (MVC helpers in component libraries like GXT)
  • They involve SpringMVC or other unnecessary server-side complexity (most blog guides)

So I’m going to try to bring this altogether in one simple library with the following goals:

  • Simplicity: Access Spring services from the client through a generic exporter; no service-specific mappings in web.xml, forced type hierarchy (services should be existing Spring POJO’s), or dependency on SpringMVC. In other words, when a new Spring service is added to the server it should require zero configuration changes to be accessible in the client if desired.
  • Consistency: Client-side dependency injection with native Spring look and feel; freedom to inject private members, via constructor, or via getters/setters with same Spring annotations and conventions that are already familiar.
  • Performance: Do all the heavy lifting with GWT generators to keep the client lean.

Behold, spring4gwt where I’ll do my best to make this a reality! The initial version captures objective #1, bringing together a generic servlet for exposing Spring services without turning each into its own RemoteServlet mapped in web.xml. Up next: accessing those services with Spring DI in the client!

, , , ,

13 Comments

Java performance basics

A good reminder of some little things in Java that can make a big performance difference, but are easy to forget:

Java Performance: The Return of the Usual Suspects (Updated)

,

No Comments

Mojarra Scales

The other day I was looking for a good UI charting package that plays nice with JSF and stumbled on Mojarra Scales, one of those cool little projects that reminds me why JSF seemed like such a good idea at the time. Basically it’s a wrapper for YUI charts that lets you bind them to a backing bean as the data source via JSF and configure many of the attributes declaratively through EL. For example, I created a chart showing min/max/average HTTP request time like this:

<sc:chart id="requestThroughputChart" type="line"
     value="#{charts.totalRequestThroughputChartData}"
     seriesDef="[{ displayName: 'Rate', yField: 'rate' }]"
     horizontalField="time" width="100%" />

For the backing bean it’s a little old-school in that it uses a simple string-property map:

public List<Map<String, String>> getTotalRequestThroughputChartData() {
     List<Map<String, String>> list = new ArrayList<Map<String, String>>();
     for (Summary s : result.getSummariesByTimeSeq()) {
          Map<String, String> map = new HashMap<String, String>();
          map.put("time", timeIndex(s));
          map.put("rate", s.getStatistic().getRate().toString());
          list.add(map);
     }<
     return list;
}

But hey, it works and is super easy to use – a good thing since their examples are sparing and the site has practically zero documentation. The result looks like this:

chart

It always feels like JSF could have gone farther if more things like this fit together: I think the haphazard piling of the API, differing implementations, renderkits, and component libraries by separate vendors always made things a little sticky, and to the uninitiated, often a configuration nightmare. There’s something to be said for frameworks that package it all up in a nice shiny box. But, projects like this still make me smile and appreciate being able to throw a good-looking chart on my site in minutes without touching Flash or JavaScript (or mutiliated Java – I’m still a little bitter towards GXT!). Keep up the good work.

, ,

No Comments

Simple Hibernate/JPA mapping of enums to columns

I was mapping a Java 5 enum to a database column in a JPA-annotated Hibernate class today and almost created a UserType (ugh!). Then I remembered that it’s much easier! You can just use @Enumerated to convert between the enum’s toString() and a text (varchar, text, etc.) column transparently. There’s also support for more complex types which I have not had a chance to explore. The usage looks like this:

@Entity
public class MyClass {
     ...
     @Enumerated(EnumType.STRING)
     private MyEnum myCol;
     ...
}

See the JPA docs for a full example.

, ,

1 Comment