A simple application for printing file contents as hexadecimal.
Wednesday, 30 April 2008
Tuesday, 29 April 2008
C#: Hello, World!
using System; public class HelloWorld { public static void Main(String[] args) { Console.WriteLine("Hello, World!"); } }
Labels:
C#,
Hello World
Tuesday, 22 April 2008
Java: using EL outside J2EE
${example.expression.language.expression}
If you have done much JSP programming, you will be familiar with the Expression Language (EL), also now known as the Unified Expression Language. EL is used in JSPs to help remove business logic from the view while keeping the data content dynamic. Uses for EL can go beyond J2EE platforms and it is relatively easy to incorporate it into your own applications.
Labels:
EL,
Expression Language,
Java,
JUEL,
Tomcat,
Unified Expression Language
Monday, 14 April 2008
Java: finding binary class dependencies with BCEL
Sometimes you need to find all the dependencies for a binary class. You might have a project that depends on a large product and want to figure out the minimum set of libraries to copy to create a build environment. You might want to check for missing dependencies during the kitting process.
Labels:
BCEL,
byte code engineering library,
dependencies,
Java
Wednesday, 9 April 2008
Java: finding the application directory
EDIT 2009/05/28: It has been pointed out to me that a far easier way to do all this is using this method:
URL url = Location.class.getProtectionDomain()
|
...which makes everything below here pointless. You live and learn!
Labels:
Java
Tuesday, 8 April 2008
Java: synchronizing on an ID
If you are a
For example, there is nothing in the Servlet 2.5 MR6 specification that says a
Java
programmer, you will be familiar with synchronized
blocks.
Object myObject = //some instance synchronized(myObject) { //do some thread-sensitive //work on myObject }Sometimes, you want to synchronize on a transient object - a resource that isn't going to stay in memory.
For example, there is nothing in the Servlet 2.5 MR6 specification that says a
HttpServletSession
instance can't be recreated as a facade object every time it is requested. That makes the session instance a poor candidate for a synchronized
lock. There is nothing in the specification that prevents the container implementer from always serializing session attributes as soon as they are set either. That makes session attributes poor candidates for synchronization
locks. Note: existing implementations may support either of these approaches in practice, but lets say our imaginary servlet container doesn't. However, the session ID will be consistent across requests.
Labels:
concurrency,
Java,
mutex,
synchronization
Java: Hello, World!
public class HelloWorld {
|
Labels:
Hello World,
Java
Subscribe to:
Posts (Atom)