Follow-up: Why I consider these features missing in Java

Some time ago I created a list of features I consider missing in the current Java implementation. As I recently realized it makes sense to provide reasoning for some of them to be in the list.

Oracle: PL/SQL vs Java - one unconventional question

All the time since the introduction of Java engine within Oracle RDBMS people have been wondering how performance of Java stored procedures compare to orthodox ones written in PL/SQL. There are lots of performance tests demonstrating where things stand. Surprise! I am not going to discuss it here. What I am really curious about is what we may expect in future. Might it happen that one day PL/SQL will be fully replaced with the Java engine?

Servlets vs Messaging

Being kind of not a big fan of Web development I wonder what is so special about Servlets that requires a separate API to use them?

My list of features missing in Java

It is a very common question on interviews about what features you consider missing and would like to add to Java. Here is my list:

• C#-style properties accessible as such via reflection;
• C#-style yield keyword;
• C#-style as keyword;
• Get rid of java.util.Date hell - will require changes in java.sql as well;
• Function objects, specifically for bulk processing on collections; implies C#-style delegates;
• modularity, e.g. OSGi-like bundling - no jar-hell;
• Annotation-based configuration for JavaBeans, again, like it is done in .NET System.ComponentModel; extensive support in Swing;
• Something similar to org.springframework.util.Assert class for common runtime checks;
• Human-oriented Generics;
• Byte-code emitter API;
• Unified interfaces and compiler support for events like in .NET, free of known problems;
• One more feature would be nice to have - a user-defined context reference in java.lang.Class object. This would let keep all class-related extensions, e.g. persisters, serializers, validators, type descriptors, etc, acessible by simple navigation as opposed to keeping multiple mappings.
• Extremely useful feature - C#-style verbatim string literals (@"...") = multiline strings in Scala ("""...""");

UPD: I think I'd better provide some explanations why I deem these features to be missing.:-)

IBM eXtreme Scale vs ORMs

Ah, that's a solution I have also been thinking over for quite long time. Distributed object caching - that's the next generation platform for most applications. I am sure this is one of the most interesting areas to work in. Shall I seek for opportunities with IBM, maybe? :)

From Java constructors to domain-driven design concepts

Interestingly, a constructor in Java can be thought of as a callback method which is to be invoked upon instance allocation.

Entity metadata: Java vs XML

The architecture of the last multi-tier project I worked for included a bunch of C# frontends connecting to a few Java services. There were a number of business domain entities. The state of almost every entity was continuously mutated.

Gory details of java.lang.String interning

While exploring through the JDK source code today I came to some degree of understanding of how interned strings are treated by garbage collector (GC).

In the first versions of java interned strings were not collected at all. They were accumulated in the PermGen so it was quite possible to very quickly end up with OutOfMemory (OOM) exception when abusing intern() call. The current version of JVM uses a smarter way to maintain the string cache.

Opposed to some people saying that strings are kept as weak references the actual approach is different. During the first part of mark-and-sweep phase GC delegates to the static string table (a specialization of Hashtable) to get rid of all non-alive entries. These entries are not deleted but relinked instead from the hashtable bucket (the linked list they reside in) to the linked list of free entries (revise

   BasicHashtable::free_entry(BasicHashtableEntry* entry)← 
   void Hashtable::unlink(BoolObjectClosure* is_alive)←
   StringTable::unlink(BoolObjectClosure* cl)

call chain for details)
One important observation here is that memory taken by a freed entry is not deallocated. That means the more non-identical strings are interned by the application the more PermGen memory is consumed. Correspondingly if the JVM string table is too intensively used, for example, by attempting to cache too many non-identical strings it is easy to cause OOME. While in a case where the cached strings are known to have big percentage of duplicates interning along with fine tuning of PermGen may significantly reduce the overall memory consumption.

Enterprise Data Fabric is what we need?

I have just watched this presentation on Coherence by Cameron Purdy, a vice president in Oracle. Well, I think it is the very right direction they have been moving at so far. I encountered similar but custom solutions at least in three big projects at different companies. I must admit that no other architecture can fit equally well to the modern business requirements where delivering the most recent values across the enterprise is important (this is true for almost every modern application).

Frankly, I feel incredibly envious about the work they have been doing in Tangosol(now Oracle) :-). Quick search in Google and Wikipedia yields that there is a term for the technology and it is Enterprise Data Fabric (EDF) which sounds good to me.I feel like writing my own implementation of EDF based on experience I have got with that kind of systems.

Nowadays the biggest problem is that integration of systems has typically been done in a totally chaotic way. Even while some enterprise applications are using Coherence (or GemStone GemFire, or similar), others are not and will never be able to due to major architectural flaws making them incompatible with EDF. There are still so many applications designed on top of a relational database, for example. Honestly, almost every such system is cr*ppiest legacy nightmare, - totally inflexible, hard to maintain, so far away from low latency data delivery - and thus very inefficient.