Site Sponsors:
Source Code as a Resource 

Loading Lately?


When it comes to programming, we all know that the term "resource" can mean just about anything. For the purpose of this post however, the term is herein being used to refer to any local file outside of those executable classes we need to run our application.

Simple Concepts


From Images to Resource Bundles, Java has three ways to locate & load classpath-relative resources: Class, Container, and System.

When it came time for me to include a stand-alone code template however, none of the tried-and-true resource loading techniques did the job. Why? Because rather than allowing the IDE to include all of the source code (so as to use the Class or Thread loader strategy for example), I simply wanted a way to resource a single custom source-code resource; A default template; A simple, single file. --One that that I desperately needed to include so as to better create a soon-to-be-released ENJO-Generaiton Tool.

Better than Television


So - bored almost to tears in the evening - while marooned at a client site last week I created a new tool. One designed to help me 'resource that single file.



Packing up the encoder & decoder API into a GUI Tool (yes, I was THAT Bored!) the overly ambitions project name I came up with so as to better share the locus with you is "OmniLoader."



Circulating as YASFP (Yet Another SourceForge Project) please allow me to share both the tool, as well as the simple technique with you now. Designed to generate a class that can hex-encode + embed ANY resource file, depending upon your requirement the technique could easily be expanded to resource-share arrays of bytes, class-named images, sounds, certificates, as well as any other resource we might realistically want to shove into a hex-dump.

Indeed, depending upon your need for stark efficiency, let me know if you would prefer a Base64 encode / decode option: The garbage-way American television is going these days, surely the next time I am marooned in a hotel room with only Cable as a companion you will probably get your wish. ... I will probably even write it twice.



Remember: For any professional, the Journey HAS ALWAYS BEEN the Destination, =)


-Rn


[ add comment ] ( 38 views )   |  permalink  |  related link
POJO or ENJO? 
All Java software developers know that the term "POJO" is an acronym stand-in; For quite some time now we have been using that P.O.J.O moniker whenever we wanted to let others know that we wanted to manage a "Plain Old Java Object."



Often data-laden, the job of the POJOs is to typically "get" and/or "set" ("read" / "write") information around our objects.

A massively popular concept, simplicity has surely been a key to success: From automatic code generation to simple coding standards, the humble POJO has provided data-centric couplings for everything from Dependency Injection to Hibernate; There are POJO refractory procedures for every popular Java IDE.



Yet POJOs have one key shortcoming: Their tight coupling to a localized method signature.

In short, when using POJO members (such as "String getName()" or "setGovernmentIdentifier(String SSN)"), we are hammering application-centric dependencies into our code. Dependencies that can make a generic frameworks far more difficult to change.

Of course the use of adaptors, polymorphism, and object factories can help us manage our POJO dependencies. All well and good. But the point of this article is to discuss how Java Developers also have a unique weapon in our language-arsenal: The humble Enumeration.

Enumerated Data Type (EDT)


We have discussed the power of Java Enumeration in our blog before. Yet far from allowing us to better manage return types, those of us who have been marvelling over Java improvements should next add the concept of data management to the list of enum-marvels.

Over the Top


Why use the word "marvel", rather than a less dramatic word?

I'm glad you asked! :-)

Enum Marvel: Simple Syntax


The first thing to note is that an 'Enum in Java is very simple to understand.
public enum MightyEDT {
edtName,
edtAddress,
edtIdentityTheft
}

For those familiar with C/C++, we will recognize the source of the syntax. One might even feel the need to suppress a African-cat-sized yawn. While valid syntax, note the missing ";" in the above?

Enum Marvel: Member Functions


Unlike in C/C++ or .NET however, once we complete the syntax (i.e. add in the semi-colon), we are setting the stage for amazing things.
public enum MightyEDT {
edtName,
edtAddress,
edtIdentityTheft ;

public static void main(String ... args) {
for(MightyEDT ref : MightyEDT.values()) {
System.out.println(ref.ordinal());
}
}
}

In Java - and unlike everywhere elsewhere at the time of this writing - an enumeration can have member functions. Just like a class.

Enum Marvel: Data Indexing


Running the above example (yes, it is a demo folks), one should note that - by default (and much like C/C++ and .NET) - that Java enumerations begin with the index of "0":
    public static void main(String ... args) {
for(MightyEDT ref : MightyEDT.values()) {
System.out.println(ref.ordinal());
}
}

Much like .NET (an unlike C/C++), each enumerated value itself is an Object.... complete with it's own set of common, as well as special 'enum members:
    public static void main(String ... args) {
for(MightyEDT ref : MightyEDT.values()) {
System.out.print(ref + ": " );
System.out.println(ref.ordinal());
}
}

Next, as we consider that the entire world of data management is about tagging data with known, human-palatable values, then we should consider that our newly enumerated-values might become as important to us as is their numerical offsets:
edtName: 0
edtAddress: 1
edtIdentityTheft: 2

Data Tagging


If you know Java, then you might be familiar with the above concepts... You might also be in the middle of likewise stifling an overdue jungle-cat-yawn, as well.

Yet - as Shakespeare might say - here is the rub: What if - rather than moving data about via brittle & breakable POJO signatures, that we instead use a tagged-data value-approach? By using enumerations, might we be able to create an object that will neither break over time, nor create queer signature-dependencies throughout our applications? Even when adding (or removing!) those data-laden getters & setters?

ENumerated Java Objects (ENJO)


Consider what happens when we combine the POJOs 'getters and 'setters with Java's Enumeration.
public enum MightyENJO {
edtName,
edtAddress,
edtIdentityTheft ;

private String[] data = new String[MightyENJO.values().length];

public String get(MightyENJO tag) {
return data[tag.ordinal()];
}

public boolean set(MightyENJO tag, String value) {
if (value == null) {
value = "";
}
data[tag.ordinal()] = value;
return true;
}

}

Adopting the simple get / set pattern shown above, we now have a plausible global convention. A practice we might ever use across all application frameworks. An easy-to-use signature designed to manage the read/write/update of 'stringifiable data types.

Better still, when applied across all data-laden frameworks we might be working on, the above enumerated get/set strategy need never change one framework at the expense of another. All we need do is to either (1) save+parse the .name() as a data prefix (a personal favourite), (2) map the .name() to a column-meta, or (3) simply add/remove enumerated types from the end of the 'enum.



Viva Homogeneity?

Ultimate Marvel: Associating Metadata


By this time in our little presentation you should rightly be asking yourself "so what the heck is the point of all this?"

The point is this: The nature of all data-laden interfaces is to relate stored values to human-consumable meta. Specifically, once armed with an ENJO we are free to associate far more than an enumerated-name to a data-field. -Through the miracle of private enum construction, each enumerated Java-type can optionally store even more meta-data:
public enum MightyENJO {
edtName("The name of your client"),
edtAddress("The address of your client"),
edtIdentityTheft("The Mark of the Beast") ;

public final String toolTip;

private MightyENJO(String toolTip) {
this.toolTip = toolTip;
}

public String get(MightyENJO tag) {
return "looke up the data here";
}
public String set(MightyENJO tag, String value) {
return "assign the data here";
}
}

Decidedly our own polymorphic type, the above signature is far more framework-friendly: In addition to being able to quickly re-factor tags such as "Identity Theft" to "Government Provides For Family", we can also just as rapidly update any associated GUI-displayable meta-data as well.

Type Conversion


We should certainly feel free to overload our 'setter to manage the to-stirng conversion for any requisite data types.

public boolean set(MightyENJO tag, String value) {
if (value == null) {
value = "";
}
data[tag.ordinal()] = value;
return true;
}
public boolean set(MightyENJO tag, float value) {
data[tag.ordinal()] = "" + value;
return true;
}
While human interfaces invariably favor strings, when it is time to do the math (pun intended), native type conversions can just as easily be included:
    public Integer getInt(MightyENJO token) {
return Integer.parseInt(get(token));
}
public BigDecimal getDec(MightyENJO token) {
return new BigDecimal(get(token));
}

How ENJOs Work for Me


To ultimately understand why I took the time to write this article, allow me to relate that I stumbled upon the need for the EDT/ENJO while working on a personal information manager. Starting out as a simple way to manage my bookmarks, this single CRUD-management application has been updated over the years to manage flashcards, invoicing, email, taxes, and even collections of photographs & other files...

While working to store a single Data-Access-Object (DAO) in as many formats as possible (XML, CSV, TDF, SQL ...) I simply got tired of perpetually updating the tool tips, column names, data-dictionary definitions, and the related GUI & Database 'Meta.

When using an Enumerated Data-Type (ETD) however, I discovered that a single ENJO could provide a Java-standard way to change (for example) the "Name" column across all JTables. --In very deed I discovered that from forms & tool-tips to Databases and XML Documents alike, morphing an entire application away from collecting "Names" to something like "Files" or "Email Address" can take but a very few moments.

So while each application was destined to manage far different data over time, at the framework-level each application pretty much managed the exact same brittle set of POJO-empesterd CRUD activities.

Conversely - rather than relying upon unique signature - not only will a single 'enum for Name rapidly re-factor to Email without ripple effect, but even when we added / removed multiple data values efficiences may by now perhaps be obvious. -Having a single opaque, asignature data type even allows cross-format serialization / deserialization routines (XML, CSV, etc.) to update automatically. -One may even choose to name-mangle metadata to support enumerated version identifiers (etc.)

Abstractions


While we may achieve a similar independence with a properly designed abstraction, over time I have found the use of an EDT to be far more forgiving. -Certainly when the goal is to create a deeply embedded cross-application codebase. When requirements change so as even my well designed signature-laden frameworks break, my ENDO Framework can continue to evolve as fast as agility demands.

From a cross-application framework vantage-point therefore, ENDO's can be even more generic (if not easier to manage!) than designing frameworks that rely upon adaptors and / or Generics. Over time I have discovered that enumerated data frameworks are allot less time consuming to both create, as well as to re-purpose.

Conclusion


Of course unlike when using Template<T> the creation of an E.N.J.O remains uniquely Java-ish at the moment. Unlike the Enumerated Java Object however, an Enumerated Data Type can be created for just about any language (even PHP.)

So even though technologies such as C/C++ and .NET lag far behind the way Java enumeration has evolved - allow me to offer up this new EDT/ENJO concept. I do so in the sincere hope that you will find the pattern useful in your cross-framework re-purposing efforts, as well.

[ add comment ] ( 87 views )   |  permalink  |  related link

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next> Last>>