Go (golang.org) has pretty good Unicode support on the Windows command line. I've written about Unicode and cmd.exe before in the context of C++, C# and Java.
Versions: Windows 7 (64-bit); go1.1.1 windows/amd64; Java 1.7.0_21
Miscellaneous Computer Code
Go (golang.org) has pretty good Unicode support on the Windows command line. I've written about Unicode and cmd.exe before in the context of C++, C# and Java.
Versions: Windows 7 (64-bit); go1.1.1 windows/amd64; Java 1.7.0_21
JSON documents are generally encoded using UTF-8 but the format also supports four other encoding forms. This post covers the mechanics of character encoding detection for JSON parsers that don't provide handling for them - for example, Gson and JSON.simple.
EDIT: 2014; a version of this library has been published to Maven central.
The Eclipse JavaScript Development Tools allow step-through-debugging of JavaScript files using a provided Rhino instance. The Wiki describes how to utilise Eclipse plugins to connect your own embedded Rhino context to Eclipse.
Versions: Java 7; Rhino 1.7R4; Eclipse Juno (4.2) SR1 (Eclipse IDE for Java EE Developers).
The simple task of trying to match strings without regard to upper or lower case is surprisingly hard when you try to take into account different language conventions. Things get more complicated when you start to consider accented letters and the legacy of typography.
This post discusses the Java 7 implementation which is documented to suport Unicode 6.0.0.
Note: graphemes will vary based on rendering engines and system fonts.
Mozilla's Rhino engine includes a step-through debugger. It is relatively easy to embed this in your own Java application.
Versions: Rhino 1.7R4 on Java 7.
Java doesn't support regular expression literals like some other languages. Still, you can get half way.
Dojo supports Mozilla's Rhino engine for things like headless DOH tests and builds. This post demonstrates how to bootstrap Dojo using an embedded context.
This information pertains to Dojo 1.7.2, Rhino 1.7R2 and Java 6. Knowledge of JavaScript, Dojo and Java is assumed.
The Asynchronous Module Definition (AMD) API provides powerful modularization options to JavaScript developers. But this introduces its own problems when it comes to dependency management. As this post demonstrates, Mozilla's Rhino engine offers developers a means to analyze these dependencies.
Java 8 introduces the concept of default methods to interfaces and this post looks at the cost of adding state to them.
This information pertains to the pre-release version of Java 8 mentioned in a previous post.
Update: Java 8 has been released and I've implemented a library with a more elegant approach to exception handling than the one described in this post: details + downloads; source code; blog posts.
This post looks at the effect of lambdas on checked exception handling.
This code uses a pre-release Java 8 build. See the previous post for more.
Pre-release builds of Java 8 with lambda support are available for download. This post looks at lambda-8-b50-linux-x64-26_jul_2012.tar.gz.
The Contexts and Dependency Injection (CDI) API introduced in Java EE 6 complements the JSF framework. There are good reasons to favour it over JavaServer Faces (JSF) managed bean mechanisms.
CDI doesn't do everything and there are edge cases where you might want to make use of Expression Language (EL) bindings during dependency injection. Fortunately, the gaps between these APIs are easy to fill.
Some users can run afoul of Portal's user-agent rules. Symptoms include the inability to log in and form submissions just causing page refreshes where all the form data is lost.
The problem is an intersection of two things:
See Technote 1441915 for IBM's support analysis.
define(["dojo/text!./path/some.txt"], function(textData) {
Dojo's AMD loader has some useful contextual loading features.
Note the exclamation mark in the dependency.
dojo/text!
can be used to load character data;
dojo/has!
can be used to load different modules based on
environment.
Writing your own plugin is relatively trivial.
A short post about setting up a trial WebSphere Portal Express server on the (unsupported) CentOS operating system.
Like many programmers, I like to run virtual machines to isolate development and test environments from everything else I do on my laptop. My Lenovo ThinkPad didn't support all the virtualization features I wanted out of the box, but it was relatively trivial to enable them.
Errors from virtualization software manifest as complaints about missing VT-x support or a failure enabling long mode. Virtualization support needs to be enabled in the BIOS. Instructions are provided in the user guide.
This post demonstrates a way to use the Dojo 1.7 AMD loader to provide mock/stub/fake/dummy artefacts in place of the defined dependencies.
Along with a few other JavaScript libraries, Dojo is making the transition to the Asynchronous Module Definition (AMD) API. This post presents a few minimal files written to make use of it.
A previous
post discussed how to inject the FacesContext
into managed
beans using a
broker. This post demonstrates how to build on that approach with
greater levels of abstraction.
It is generally possible to remove direct JSF dependencies from managed bean code. You might want to do this to reduce coupling, improve cohesion or in the interests of writing testable code.
The code was written against Java 6, JSF 2 and JUnit 4 but the approach could be adapted to earlier versions of all of these.
Referencing the FacesContext
directly in Java classes makes managed beans more difficult to unit
test. This post discusses how to mock the context for testing outside
the application container.
These examples use Mockito with JUnit. Familiarity with JSF and unit testing Java is assumed.
I've used thejavax.faces.bean
annotations but the
techniques apply for other bean management mechanisms (e.g. using faces-config.xml
or Spring).