I have harped on Java for some time to add language support for delegation. Well, Java is not headed that direction anytime soon. But Kotlin delivers!
Saying:
class Derived(b : Base) : Base by b
forwards method calls on "Derived" to "Base" through the instance of Base named "b". Nifty!.
Kotlin is so full of good ideas it's hard to know where to start.
ThoughtWork's Neal Ford posts a great discussion of object-oriented vs. functional style for coupling and composition. Functional is where it's at. Read Neal to see why.
Steve Yegge's rant really describes how to make SOA work at full-on scales. This is pure gold:
[M]onitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'm fine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, roger roger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it's indistinguishable from automated QA. So they're a continuum.
As a long time Linux user, this quote from MSDN nearly spilled my coffee (emphasis mine):
Fundamentals such as memory usage represent a key engineering tenet of Windows 8. In building Windows 8 we set out to significantly reduce the overall runtime memory requirements of the core system. This is always good for everyone and especially in a world where people want to run more and more apps at the same time or run on systems with only 1 or 2GB of memory.
I'm happy to read this post and see engineering has a seat at the table for Windows 8. Funny world where memory is next to free.
Peteris Krumins publishes the World's best introduction to sed. And he's right.
On the power of laziness from Australian CIO Magazine:
'Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.' Robert Heinlein (1907-1988)
Well, Java has not been around 105 years, but it feels like that sometimes.
David Polak explains why Scala is too hard to replace Java. I laughed at this true description of JEE programming:
Junior developers who are asked to maintain code written by senior developers have to understand the idioms and patterns in the code. While Scala makes putting business logic at the forefront of the code (rather than distributed through a bunch of for loops and complex if statements), depending on the idioms used, decoding that logic is non-obvious. This is a variant of the lack of idioms issue, but at the end of the day, you need a team with a mind-meld to grok some Scala code. … In Java, the patterns are vomited out of the IDE, so developers grow up being able to spot the patterns. That's not true of Scala where the idioms are diverse and team/framework specific.
How to know if Scala is right for you?
- Your company has speakers at JavaOne, OSCON, Strangle Loop, QCon: Scala will be easy
- Lunch-time discussions involve the criteria for moving from a developer to a senior developer: Scala will be hard
- Your developers can write code in NotePad if they have to: Easy
- Your developers stare blankly or say 3 "Hail Marys" when they hear the name "Zed Shaw": Scala == Hard
- Developers all follow Dean Wampler on Twitter: Scala Easy
- Your developers come in at 9:15 and leave before 6 and don't check work email at night: Hard
Given Dave's solid criteria in the posting, my organization will find Scala hard to adopt. I am saddened, because Scala looks fun, productive and intelligent. But my foremost job is to help my organization succeed.
Which brings me to Kotlin (emphasis in the original):
"Project Kotlin" is the codename for a statically-typed JVM-targeted programming language developed by JetBrains and intended for industrial use.
On the Java to Scala scale Kotlin lies solidly between, more like Java in some areas, more like Scala in others, unlike either in yet others. Overall Kotlin looks like a winner for organizations looking to bail from Java but find Scala and friends daunting.
Kotlin may prove a winner.
Tony Arcieri rants on bad suggestions from Node.js folks. His catch phrase, "It gets worse". I love his conclusion:
Clearly the next logical steps are to store previously computed Fibonacci numbers in MongoDB. Or you could build a system with Socket.IO which caches previously computed Fibonacci numbers client-side using a distributed hash table. Then you'd be well on your way to a multimillion dollar cloud-based Fibonacci number service. Eventually you'll probably want to build in an OpenMP C++ native extension to calculate Fibonacci numbers across multiple CPU cores. That way you'll have a truly roflscale Fibonacci web service.
I run into this kind of thinking occassionally at work, but it is quickly tamped down before real money gets burned.
Yaron Minsky of the quant prop shop, Jane Street, promotes OCaml in the ACM Queue with OCaml for the Masses. His writing is exact, his code example illuminating and short.
Looking ahead to Java 9 and beyond, he explained, Oracle is already identifying key areas of development: a self-tuning JVM, improved native integration and big-data support, reification, adding tail calls and continuations, a new meta-object protocol to improve cross language support, multi-tenancy, resource management for cloud applications, and the building of heterogeneous compute models.
If they deliever this will help poor Java. 60s & 70s technologies 30 years later is better than a poke in the eye with a sharp stick.
I just finished with my first github fork, the maven-protoc-plugin. David Trott's original works great, but does not provide all the options available to the protoc program. I added --descriptor_set_out and --include_imports. Enjoy!
Rob Williams describes his maven woes. His solution is nexus, which is great software. But why is this Rube Goldberg set up required? Again, maven.
Sean Hull posts a punch list of do-nots for web application scalability:
A good introduction for intermediate web developers looking to broaden their perspective: read the whole thing.
Jakub Holý posts a first-rate introduction to code injection in Java. As Jakub points out, The coolest thing is that it enables you to modify third party, closed-source classes and actually even JVM classes.
My personal experience with AOP and code injection is mixed, I generally prefer code generation and classpath fiddling, but Jakub is right that one should use the best tool for the job. If a tool is unfamiliar, it's an opportunity.
Oh, yeah... The "_np" suffix means "non-portable". The pthread_getattr_np(3) function is available on glibc and bionic, but not (afaik) on Mac OS. But let's face it; any app that genuinely needs to query stack addresses and sizes is probably going to contain an #ifdef or two anyway...
I haven't posted code in too long. In part I am enjoying work so much these days I don't need this blog as an outlet for my creativity. Still, I feel a touch of guilt.
In a trivial context this came up: How to represent a database record efficiently and generically in Java? By efficiently I mean close to the efficiency of standard Java beans. By generically I mean without the custom writing of standard Java beans. The traditional map representation is certainly generic and simple to write but is not efficient in time or space.
With one condition a nice solution arises: generically applies only to compile-time; that is, I know at compile-time the types and labels of columns read from the database record. That solution: EnumMap.
Some code:
interface Field<R, X extends Exception> {
<T> T get(final R set) throws X;
}
class EnumRecord<R, X extends Exception,
E extends Enum<E> & Field<R, X>>
implements Field<E, RuntimeException> {
private Map<E, Object> fields;
EnumRecord(Class<E> enumType, R set) throws X {
this(enumType, getKeyUniverse(enumType), set);
}
EnumRecord(Class<E> enumType, E[] values, R set)
throws X {
fields = new EnumMap<E, Object>(enumType);
for (E field : values)
fields.put(field, field.get(set));
}
EnumRecord(Class<E> enumType, Iterable<E> values, R set)
throws X {
fields = new EnumMap<E, Object>(enumType);
for (E field : values)
fields.put(field, field.get(set));
}
@Override
public final <T> T get(E value) {
return (T) fields.get(value);
}
@Override
public boolean equals(Object o) {
if (this == o)
return true;
if (null == o || getClass() != o.getClass())
return false;
EnumRecord detail = (EnumRecord) o;
return fields.equals(detail.fields);
}
@Override
public int hashCode() {
return fields.hashCode();
}
private static <K extends Enum<K>>
K[] getKeyUniverse(Class<K> enumType) {
// Copied shamelessly from EnumMap
return SharedSecrets.getJavaLangAccess()
.getEnumConstantsShared(enumType);
}
}
class ResultSetRecord<E extends Enum<E>
& Field<ResultSet, SQLException>>
extends EnumRecord<ResultSet, SQLException, E> {
ResultSetRecord(Class<E> enumType, ResultSet set)
throws SQLException {
super(enumType, set);
}
ResultSetRecord(Class<E> enumType, E[] values, ResultSet set)
throws SQLException {
super(enumType, values, set);
}
ResultSetRecord(Class<E> enumType, Iterable<E> values,
ResultSet set) throws SQLException {
super(enumType, values, set);
}
}
enum SampleSQLEnum
implements Field<ResultSet, SQLException> {
nick_name() {
@Override
public String get(ResultSet set) throws SQLException {
return getString(set);
}
},
lucky_number() {
@Override
public Integer get(final ResultSet set)
throws SQLException {
return getInteger(set);
}
};
@Override
public abstract <T> T get(final ResultSet set)
throws SQLException;
protected String getString(ResultSet set)
throws SQLException {
String value = set.getString(name()).trim();
return isBlank(value) ? null : value;
}
protected Integer getInteger(ResultSet set)
throws SQLException {
int value = set.getInt(name());
return set.wasNull() ? null : value;
}
}
class SampleRecord
extends ResultSetRecord<SampleSQLEnum> {
SampleRecord(ResultSet set) throws SQLException {
super(SampleSQLEnum.class, SampleSQLEnum.values(), set);
}
String nick_name() {
return get(SampleSQLEnum.nick_name);
}
Integer luck_number() {
return get(SampleSQLEnum.lucky_number);
}
}
public class SampleRecordMain {
public static void main(final String... args)
throws SQLException {
SampleRecord record = new SampleRecord(readFromSomewhere());
System.out.println(record.nick_name());
System.out.println(record.luck_number());
}
private static ResultSet readFromSomewhere() {
throw null;
}
} UPDATE: Some have had trouble importing SharedSecrets. I used it as a convenience to avoid reflection. As an alternative you could reflect over the enum to implement getKeyUniverse yourself.
An interesting take on state by Tony Arcieri summarized here. My favorite passage is on immuability:
In mutable state languages, performance problems can often be mitigated by mutating local (i.e. non-shared) state instead of creating new objects. To give an example from the Ruby language, combining two strings with the + operator, which creates a new string from two old ones, is significantly slower than combining two strings with the concatenating >> operator, which modifies the original string. Mutating state rather than creating new objects means there's fewer objects for the garbage collector to clean up and helps keep your program in-cache on inner loops. If you've seen Cliff Click's crash course on modern hardware, you're probably familiar with the idea that latency from cache misses is quickly becoming the dominating factor in today's software performance. Too much object creation blows the cache.
Cliff Click also covered Actors, the underpinning of Erlang's concurrency model, in his Concurrency Revolution from a Hardware Perspective talk at JavaOne. One takeaway from this is that actors should provide a safe system for mutable state, because all mutable state is confined to actors which only communicate using messages. Actors should facilitate a shared-nothing system where concurrent state mutations are impossible because no two actors share state and rely on messages for all synchronization and state exchange.
The Kilim library for Java provides a fast zero-copy messaging system for Java which still enables mutable state. In Kilim, when one actor sends a message, it loses visibility of the object it sends, and it becomes the responsibility of the recipient. If both actors need a copy of the message, the sender can make a copy of an object before it's sent to the recipient. Again, Erlang doesn't provide zero-copy (except for binaries) so Kilim's worst case is actually Erlang's best case.
You cannot pay for an endorsement like this: Linus Torvalds posts the Linux kernel source on github rather than kernel.org, at least for now.
Alan Skorkin writes a paen to the state machine. I've only written state machines for two classes of problems. They are indispensable for scanner-parsers, but I did not do the actual writing: a tool took my grammar and wrote the state machine for me. And for small logic problems I've written trivial state machines around the switch/case statement.
I think Skorkin (and van Bergen, whom he references) overlook the main reason few programmers write state machines: they are hard to reason about which makes them hard to write and hard to test.
Pragmatic Java give a first rate explanation of Maven lifecycles and where and why you use hooks into them.
I am a bit late but more marvel from Trisha of LMAX, Dissecting the Disruptor: Demystifying Memory Barriers. How can one not love this writing?
Compilers and CPUs can re-order instructions, provided the end result is the same, to try and optimise performance. Inserting a memory barrier tells the CPU and the compiler that what happened before that command needs to stay before that command, and what happens after needs to stay after. All similarities to a trip to Vegas are entirely in your own mind.
And with diagrams.