Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
User Journal

Journal Journal: Java initialization recipe

I, like many other developers used to more dynamic languages, have often been frustrated with code that first initiales something, then goes through a long sequence of steps to get it into the initial state.

Map data = new HashMap();
data.put("Hello", "world");
data.put("Spam", eggs");

In Python, Perl, Ruby, JavaScript, and many other languages you can logically create a mapping and set its values in a "one-liner". Even if this actually spans several lines, this "initial state" code is cleanly separated from any business logic within the same method. Inline definition also helps for setting up complicated objects as static values or class properties, without relying on a constrcutor or other bootstrapping at a separate location in the code.

One interesting solution for Java I recently saw on a mailing list uses a feature that has been present in Java since 1.2: anonymous inner classes. Our example now becomes:

Map data = new HashMap() {{
put("Hello", "world");
put("Spam", "eggs");
}};

Note that this technique works for almost any Object, so it is also useful for "initializing" a Java Bean:

Example e1 = new Example() {{
setHello("world");
setSpam("eggs");
}};

Once you are familiar with the recipe, this is actually much more clear and informative than multi-argument constructors in Java.

This actually works by defining a new class inline as a subclass of HashMap or Example or whatever. Within the anonymous subclass you can override the contents of that class - usually by overriding methods. This technique is usually used in AWT programming to create event handlers.

Additionally, you can provide "initializers" - which is where the extra set of curly braces come from. Initializers are rarely used in Java - they are anonymous blocks of code within a Java class that are executed AFTER the class constructor but BEFORE the class instance is returned to the caller. Theoretically, any constructor code that is not dependant on Constructor parameters can be moved out into an initializer, allowing that code to be reused for every constructor, but I hardly ever see Java code use this feature.

I wish I had seen this a year or two ago. It probably would have saved Lana from trying to maintain some of the hacks I wrote at Pharmacy OneSource.

User Journal

Journal Journal: This is Halloween

We're going to go see the Nightmare before Christmas 3D at the Supermall theatre this afternoon at 2:35. Is anybody interested in coming along?

User Journal

Journal Journal: End-game

So, the first D&D game I've tried to run since Junior High is wrapping up, after a little over two years. The current estimate is two or three more sessions, which might take us into mid-December. There doesn't seem to be a consensus yet which potential game is going to be "taking over the slot". I've learned a lot, and I think the next time I run a game I'll be able to do it with a bit more feel, and a lot less "roll for initiative".

I have a few other projects going on that can use some of the time I've been shunting into "preparing game", and I've ordered myself a copy of the latest Final Fantasy game. I'll also be taking a class at the U again this fall, so that will eat a few more hours out of my week come New Years'.

I'm starting to notice the side effects of walking to work and eating better; my legs are regrowing muscles and regaining definition, and my waistline is starting to shrink. I'm definitely to the "I must wear a belt" stage, and am pretty close to the "I need new pants" stage.

Kyna and I are still doing the tango thing. It's hard, and sometimes it's hard to get motivated - especially when she doesn't have quite enough energy and enthusiasm to push me into going out. Still, it's getting a little less overwhelming, and is more fun than I expected. There is a vague worry in the back of my head that I won't have enough time for Tango once I start going to school again, but that sounds a little silly when Kyna makes it work with her work, skating, and ballet schedules.

User Journal

Journal Journal: Hit a manic endpoint today

You know that feeling of energy when you are nearing a toxic overdose of sugar? The buzz where you know you have to do SOMETHING, preferable something COMPLICATED, or your head will collapse into a massive headache, as if some unnamed gods are punishing you for not using this gift? That special state of mind where you start to imagine in a thousand horrid directions if you don't keep busy with a problem?

I'm not much of a manic depressive, but I sure feel it on these days where I'm at one extreme. I ended up putting in nearly eleven hours at the office today, with one short break. I love having interesting problems.

Sill no good costume ideas for the party this weekend.

Java

Journal Journal: Adventures with Java and Scripting

One of the larger projects I use at Healthprolink is a Java web application where much of the logic is in an embedded Jython interpreter. In many ways, this is beautiful. The edit-compile-debug loop is much smaller, allowing me to test and implement new features and bugfixes with remarkable speed. In practice, I tend to think in Python and translate into whatever language I am working with. Also, the Jython syntax often expresses business logic that in a way that is significantly more terse than the corresponding Java code, while still increasing readbility.

Unfortunately, I am starting to run afoul of the problems in this solution. I've made the mistake of implementing some incredibly useful APIs entirely in Jython, so these libraries are entirely unavailable when I have to work in pure Java, meaning that there are often two completely different days of doing what is effectively the same thing. Using an additional programming language raises the barrier-to-entry for any developers joining our team, making the source code as a whole substantially more obscure. Finally, we have run into some strange issues under heavy load that may be partially attributal to the classes dynamically generated by a long-running scripting interpereter. I'm not sure whether anybody has used this interpreter like I am.

The Java memory model uses a special section of memory called "Permanent Generation Space" for JVM and dynamically generated classes. It is noted that tools which dynamically generate a lot of classes (like JSP containers and NetBeans) should tune the size of this memory region to be larger than the standard default of 32 MB. I am not certain that this is an issue with Jython, but it sounds likely.

"Runtime stability" is a higher priority than "uses kewl technology"; "accessible to all developers on the team" might outweigh the "Sean can develop extremely rapidly" factor.

Recoding everything into Java in a month-long hacking run seems like a bad idea, but it might be worthwhile to at least migrate the libraries so that I at least overcome the "fractured API" problem. Once I take care of all Jython modules that are called from other Jython modules, I should be able to compile the remainder with invocations to jythonc, which will get us around the dynamically-generated-classes problem. I am willing to tolerate the barrier-to-entry problem; ability to pick up new languages quickly is one criteria I require of developers to earn the title of "competent". Any reduction in the number of classes we define in Jython should help with the PermGen Space issue.

User Journal

Journal Journal: Managing your application's performance into production

Goal: spent less time fixing old code, more time writing new code.

Why monitor? J2EE is ridiculously complex. Over-engineered solutions can be very slow.

Brief history of tools:
log-based analysis: flexible, fast, human resource intensive, limited application visibility.
code profilers: Great visibility, resource intensive, not designed for production use, deluge of data, no multi-tier visibility.
Synthetic transactions: solid uptime infrastructure, automated test cases, cannot monitor production.
Byte-code instrumentation, flexible, fast, tedious, limited multi-tier.

Goal: monitor production without affecting production. Bytecode instrumentation is the tech of choice, but needs better manageability.

Heisenburg. If you add too much monitoring, you can easily affect production. Visibility vs. Overhead dilemna.

Instrumentation tends to be a manual, iterative process.
Instrument everything and scale back.
Instrument everything and scale up.

Desire: base instrumentation on real usage patterns, minimize developer time, adjust without constantly having to bounce application.

Adaptive instrumentation: collect real, meaningful usage information, adjust as needed without restart.

Instrument slow methods, service requests, frequently used components, methods that do a lot of owrk, things that acces external resources, and frequently-used custom code.

Avoid all methods that will add significant overhead without real analytical value.

User Journal

Journal Journal: JavaOne: Scripting for the Java platform.

JSR 223 implemented in Mustang.

Javax.script in mustang.
Javax.script.http depends on servlet so not in Mustang.
PHP extension. Wrappers for Java objects. Embed PHP in servlet container. Availabilty TBD.

JavaScript included, based on Rhino, with Third-party implementations, BeanShell demonstrated. Snapshot build 40 and later.

Use cases
stand-alone script interpreter
script uses Java objects
java calls script engine.
Scripting framework.

Scriptin frameworks:
BSF, ActiveX, JSR223. Jsr241 Groovy JSR273 BeanShell.

ScriptEngine: ScriptEngine, invocable, compilable.
ScriptContext: bindings, stdout, stderr, namespace
ScriptEngine: metadata, threading, script generation.
ScriptEngineManager

Command-line script shell jrunscript. Rhino has no Java bytecode compilation. Needs JavaAdapter to implement Java interface.

User Journal

Journal Journal: JavaOne: Taking the hype out of hypertext UIs

The Google lesson: advanced UI concepts work best with clear, minimal applications. Combining the level of hackery that goes into Google maps with a substantially larger application would result in a steaming, unmanageable, mess.

Autogenerated UIs become ugly messes of code you never want to touch, that get in the way of cool algorithms. If you want to do somethign the code-generator didn't intend, you often have little recourse.

Model-View-Component is a good idea in theory, but people cut corners and mix MVC layers, putting everything in the View.

UI code grows out of hand. When project managers/salespeople/customers see soemthing they want to change about the product, they describe what they want to change in terms of the UI. These revisions are often implemented as quick hacks in the UI layer that break clean MVC separation. Changes in flow and layout often impact application layer.

One way to avoid (or at least minimize) this trend is to err on the other side during the initial design phase: build large, generic Controls. Use a solid data model. Keep the view logic as minimalistic as possible.

UI packages have screens, widgets, threads, and events.

HTML has response/request, forms on a per-page basis. Linear, coarse, synchronous flow.

HTTP heavy, stateless.

Classic UI: many paths, each screen only needs to know it's own data.
Web UI: each page needs to understand every path.

Each request contains WHERE to go and information about the screen that you just left.

Oject-oriented UI model more intuitive for design, management.

Model DOM objects as server-side Widgets with subclassable event listeners. Provide a way to plug these event listeners into the form handler.

His implementation has a Processing Thread for each user session, with which the event handlers are registered. Doesnlt allow parallel browsing of multiple screens, doesn't scale well. Works on embedded devices.

Slashdot Top Deals

UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker

Working...