Posts Tagged ‘java’

Brave new EJB?

March 4, 2005

The new specification of Enterprise Java Beans (EJB) version 3 came out a little while ago. Now this may be an early draft, but the contours are already in place. It’s going to be different – very different. In this article we take a close look at every little detail… not. Rather, we attempt to take an overall view and check out some code!

The story so far….

Within J2EE, EJB has been seen as one of the heaviest technologies – not just for its complexity, but also from the point of view of the various factors involved in doing something. The list of “points for improvement” could be long. Onto the stage came Microsoft with its Dotnet, and began to use words like architecture. Sun, which still is used to sing in the final scene when it comes to creating major systems, realized that it had to be easier to develop with EJB, preferably without losing power. Cur- tain up! Enter EJB3 stage left!

Objectives

There were several objectives behind the new version.
New simpler configuration. Only state what is different – configuration by
exception.

  • Encapsulate the beans to reduce dependency and knowledge of the world around. No artificial methods which are used, etc.
  • Simpler persistence through simpler Java objects – ”Plain old java object” (Pojo).
  • Support for lightweight modelling, easy to test outside the container (no need for heavy application servers).
  • Support for inheritance, polymorphism, etc. Yes, that’s right! Actual object orientation!
  • No checked exceptions, e.g. RemoteException.
  • …and a whole pile of improvements.

In other words: easier, simpler and neater! Let’s take a closer look to see how successful they were.

Metadata

One of the first simplifications was to make use of the metadata which comes with Java 5 (JDK 1.5). To put it simply, it is a way of describing the code from a more comprehensive point of view. For example, why write long XML files when it should be enough just to say, “This method must be accessible from all machines.”

In our example, this will be ”@remote” in front of the method name. Obviously much simpler!

However, this has some unexpected effects. Now there are many new different meta settings and above all their default values. You don’t need to use all of them, but what is needed is new knowledge. Nevertheless, I still think it is better. The alternative would be to do as in the current version of EJB, where one is forced to always state values for all settings.

A simple bean

So let’s look at some code! A stateless session bean is the closest we get to “Hello World” with EJB.
Do you remember all those methods, for example ejbCreate, which had to be implemented despite being empty? And don’t forget the various interfaces and a description file with lots of XML.
Why not like this?

@Stateless
@Remote
public class FooBean {
    public void printBar() {
        System.out.println( ”Bar” );
    }
}

Much better the way I see it. Stateless indicates that this class is a stateless session bean. “Remote” indicates that it must be capable of being called from an- other machine. In reality more settings are needed but these either have standard values or are retrieved from the code. In the example we quote above, for instance, an interface file is generated, which we can later use in e.g. a client program which will call up the server.

And a session bean that saves its state isn’t all that much more difficult.

@Stateful
public class BarBean {
    @Tx(TxType.REQUIRED)
    @MethodPermission(”guest”)
    public void orderSomething( String aDrink ) { ... }
}

This time we had both transaction management and security. Note that it is just as easy to order an alcohol free alternative ;-).

A wilder bean

However, the great challenge with EJB 3 isn’t the session beans but the entity beans (CMP/BMP). The principle for saving these in a database has seen a real change. Gone are the monoliths that were connected to the mother ship, the application server.

An entity bean is marked with ”Entity”.

/** Our customer Pojo. */
@Entity public class Customer {
    private Long id;
    private String name;
    // A customer has one address.
    private Address address;
    private Set orders = new HashSet();

    // Our primary key
    @Id(generate=SEQUENCE)
    public Long getID(){
        return id;
    }
    protected void setID (Long id){
        this.id =id;
    }

    // A customer has zero or many orders.
    @OneToMany(cascade=ALL)
    public Set getOrders(){
        return orders;
    }
    public void setOrders(Setorders){
        this.orders =orders
    }
    ...

All fields in the class are saved unless otherwise stated. Access to these fields is typically based on get and set methods in precisely the same way as for ordinary JavaBeans.

Both the name of the table and the columns are calculated in this case from the names we gave them in the code. Naturally, we can specify something different, but for the sake of simplicity we take a straightforward approach here. It is also possible to put the configuration in separate files – as previously – and in this way we could override the meta settings.

The first reference to another class is ”Address”. If it is marked as persistent, these instances are also read and written automatically.

Our primary key is “id”, which also contains information on how to generate new IDs.

We have also generated an Order pojo in a similar manner. The relation to this is written with “OneToMany”, as a customer has several orders. Order relates back to our Customer in the same way as the Address field above, thus the relation is two- way, which differs in outlook from a relational database. You will find an example of this further down in the article.

If we have read in a customer from the database, we have also automatically received that customer’s Orders. This will be an object tree where the root is the customer with his primitive values and references to the other sub-object Address and the list with Order.

Finally, the relation from customer to order is set as “cascade=ALL”, which speci- fies how events such as “save”, “delete”, etc are to be propagated. In the example we send all on to all order objects in the list.

Read a little, write a little

Let’s move on to retrieving a customer from the database. Therefore we insert a ses- sion bean that does just that. First we must acquaint ourselves with what replaces the application server – “EntityManager”. In a loose sense this class represents our database/session and manages the lifecycle for our pojos. It also contributes to gene- rating our queries (Query) to the database.

First a session bean:

@Stateless
public class OrderEntryBean {
    @Inject private EntityManager em;
    //...
}

Inject allows us to manage our pojos, i.e. get into the database – search, generate, etc. EntityManager can come from anything; it need not be an application server, but maybe a somewhat simpler test bench.
Now we can insert a method for searching for customers who have a certain name.

public List findByName (String name) {
    Query q = em.CreateQuery ( “SELECT c FROM Customer c ” + “WHERE c.name LIKE :custName ” );
    q.setParameter(“custName ”,name);
    q.setMaxResults(10);
    return q.listResults();
}

The result is a list of the customers which matched the names we included. Re- trieving the value of these is quite simply a matter of looping over the list and calling up get and set methods.
Now we’ll make it a bit more difficult and add an order.

public void enterOrder(int custID, Order newOrder){
    Customer c = em.find(“Customer ”,custID);
    c.getOrders().add(newOrder);
    newOrder.setCustomer(c);
}

The relation is two-way and therefore they both require a reference to each other.
As yet the object is not in our database. Somewhere we have to tell our Entity- Manger to do the job and save our customer “c”.

em.create(c);

The customer is already in the database and will therefore be ignored. The event “save” will be sent on to sub-object (cascade=all) and the order we had stored in the database.

EJB QL

The new specification does not just involve simplifications. We also have entirely normal improvements to EJB QL, for example:

  • bulk processing of delete and update,
  • group by, having,
  • sub and dynamic queries,
  • and more functions (UPPER, CURRENT_DATE, etc) and so on.

One of my favourites is probably a polymorphism, which can already be used here:

SELECT avg(e.salary) FROM Employee e

So if Manager now inherits from Employee, we will obtain an calculated mean value for everyone – both ordinary employees and managers. Though maybe it is a less interesting example to mix up salaries like this ;-).

When and how?

If we use the number of pages in the specification as a mark of how much more needs to be done, then there is a lot. EJB 2.1 weighs in with a brave 646 pages. The draft of version 3 is more modest with 93. Moreover, many aspects invite discussion. At the time of this writing a second draft has been released. It is now divided into two documents – persistence is kept seperately. Combined they land at nearly 200 pages.

It’s going to take time. I hardly dare guess where the horizon lies. Shall we say a year before the specification is ready? And should we add another year until it is generally available? True enough, this is my pessimistic side talking – I hope. There are already some versions which, so to speak, comply with the standard. That’s why “now” is a good time to prepare for what is to come.

Would you like to have a deeper understanding of what it’s like to develop such a solution? Trying out a Hibernate/Xdoclet combo is good idea since it is so similar EJB3 persistence. If you are interested in experimenting, JBoss has a beta version of the EJB specification based on Hibernate.

Brave new EJB?

Yes, in fact. Sun has chosen the right path to take. And for that they deserve praise. It requires courage to break with old doctrines. The “old” EJB was a heavy affair which hasn’t exactly made life any easier for us programmers. But – and there’s always a but – the new specification is both simpler and more complex. The complexity is tied up with the new power that object orientation, pojos, etc gives us. But extra
power tends to require extra learning. There are going to be quite a few more ups and downs before we can set the “pedal to the pojo”.

Resources
JSR #220 http://www.jcp.org
Hibernate http://www.hibernate.org
Jboss http://www.jboss.com

Originally published in JayView.

Personligt: JavaOne 2004

August 4, 2004

Från varje stor och viktig konferens så måste det finnas en objektiv och heltäckande rapport – det här är inte den artikeln. Istället får ni mina personliga iakttagelser kryddat med diverse spekulationer och tyckanden.

Med denna varning ur vägen och utan eftertanke, låt oss dyka in i Javavärldens största konferens för programmerare – JavaOne 2004.

EoD

En av de viktigaste drivkrafterna på sistone hos Sun är EoD, Ease of Development. Denna idé om att det måste vara lättare att jobba med Java har fått starkt fotfäste. Tack Microsoft! Tack för Dotnet och för att ni tvingade Sun att konkurrera på nya villkor.
Ta till exempel Sun Java Studio Creator (SJSC) 1.0 som presenterades under dagarna. Det är en vanlig utvecklingsmiljö förklädd till Visual Basic. Detta låter kanske inte så häftigt, men faktum är att både gränssnitt och den genererade lösningen ser bra ut – till och med om man tar hänsyn till demons glittriga yta. Listan med förkortningar, JSP, JSTL, JSF, etcetera är precis så vanlig Java som man kunde hoppas på. Sun kan mycket väl lyckas med att attrahera f.d. VB-programmerare, och kanske även gamla härdade javaiter, som vill köra J2EE med krockkudde.

Tänk er att kunna skapa en prototyp i SJSC för att sedan rycka ut olika lager och ersätta det med något mer industriellt. Jag håller tummarna för att Sun gör det rätta. Lite rita-dra-ochtesta-kod skulle inte skada för en gångs skull.

Mer EoD – EJB 3

Men det finns andra mer långtgående effekter av EoD. Ta metadata, dvs. att man kan berätta saker om koden. Man skulle enkelt kunna ange att en metod är ”remote” och vips så genereras de filer som behövs för att skapa en web service. Bästa exemplet är nog EJB 3.0 som hade en del riktigt enkla powerpoint-slajds – de var helt enkelt tomma. Det lilla som fanns kvar var uttryckt som metadata i koden. Applåderna lät inte vänta på sig.

Jag får erkänna att jag aldrig tyckt om EJB och framförallt inte CMP. När jag talat om bristerna har jag ibland känt mig ganska gnällig. Expertgruppen för EJB har gjort en rejäl sväng och skapat en bra mycket mer elegant lösning. Tänk er enkla Java-bönor med metadata (typ Hibernate med XDoclet) så får ni en rätt bra bild. En så pass ny kurs innebär att gamla sanningar utsätts för hårda prövningar. Vad sägs om följande citat från konferensen ”You shouldn’t have to be a rocket scientist to be an EJB-developer” eller ”the Data Transfer Object [DTO] anti pattern”? Det sista innebär inte mindre än en dogms död för vad god EJB-programmering har inneburit.

Något oväntat kanske, så hamnade de nu i samma säng som JDO – Java Data Objects – en av Suns andra persistenslösningar. Diskussionerna både bakom och framför ridån var intensiv under dagarna. Resultatet har tack och lov inte väntat på sig. De två expertgrupperna har precis kommit ut med ett öppet brev där man lovar att arbeta ut en gemensam lösning. Det lär ta tid, men det är definitivt ett steg i rätt riktning. Jag får erkänna att jag antagligen inte kan gnälla länge till.

Det finns långt fler exempel och gemensamt för dessa nyheter är EoD. Vi kommer att få se mer av denna katalysator.

SOA, nu med XL hajpfaktor

Det verkar finnas en naturlag som alla konferenser måste följa – minst ett ämne måste trissas upp. Flosklerna ska flöda och en exakt förklaring saknas. I år vågar jag mig på att utnämna SOA till huvudkandidat. Service Oriented Architecture var på många föreläsares läppar och tanken på en sorts gemensam arkitektur är lockande. Jag kunde dock inte förstå exakt vad det är som skiljer SOA från web services, möjligtvis är den senare ett specialfall av SOA. Nåja, gräv ner fötterna i jordmyllan och var beredd på att höra mer om detta begrepp. Det finns många intressanta tankar, men också en hel del floskler som vi hört förr. Det lär ta tid, men chansen är att det kommer på en server nära dig.

Klienter, feta som mobila

Vi har fått leva i flera år med anorektiska klienter (läs: webbläsare med uselt gränssnitt som bara en mamma kan älska;-) men det verkar förändras nu. Det är inte längre självklart att en klient måste vara tillgänglig överallt på bekostnad av användargränssnitt, funktionalitet etc. Under konferensen fanns det flera exempel på varierade klienter – det var allt från att löften om att kunna generera feta klienter ”i nästa version” till skräddarsydda mobila varianter.
Står dina användare fortfarande ut med tunna skal som blinkar och fladdrar? Jag gissar att de närmaste åren kommer fler av oss att rycka fram de gamla böckerna om gui och Swing för att vi glömt vad vi redan kommer ihåg.

Femfemfem

PR-avdelningen på Sun har slagit till igen. Förra gången detta hände fick de för sig att använda både 1.2 och 2 som nummer för samma release – den första var JDK och den senare det mer övergripande och luddiga Java 2 Standard Edition. Nu räknar vi upp hela härligheten till Java 5.0 eller var det JDK:n? Och vad var det nu J2SE skulle heta…
Vi tar det igen; 1.5 är det interna numret, 5.0 är det externa. Och tvåan i J2SE blir då det utomjordiska numret?

Far out

Första kandidaten i denna klass är Nasa och deras Rover – Marslandaren. Både den och program runt omkring använder sig av Java. Det var roligt att höra om deras lösning med robotarmar och allt som fanns på deras bilder. När de fick frågan om vilken databas de använt för att spara all bilddata, så spred sig ett förtjust fniss bland åhörarna – MySQL. Man behöver tydligen inte så mycket mer om man bara ska till Mars.

Den andra kandidaten är Groovy som är ett nytt språk från veteraner som James Strachan (Geronimo, jelly, dom4j, maven, Jakarta commons etc.). De hade lagt märke till att mycket kodande går åt till att limma ihop olika komponenter. Varför inte uppfinna ett nytt språk som gör detta och mycket annat lättare? Född var Groovy. Några absolut minimala exempel:

str = ”testing”
// Notera inget semicolon!

c = str[-1]
// c är nu lika med ’g’

s1 = str[3..1]
// s1 är nu lika med ”tse”

v=[1,2,3].find{it>1}
// v är nu lika med 2

I listan ”1,2,3” så letar vi efter den första posten som uppfyller villkoret vi skickat med (”it” är en sorts standardparameter). Vi kan alltså skicka med kod som ska exekveras!
Man behöver många fler exempel för att förstå hur häftigt det är, så jag ska inte ens försöka göra det rättvisa här. Groovy fick dock det att klia i mina programmerarfingrar.

Siffror och visioner

När Suns ledning talade var det många siffror. Det var antalet Java X, antalet miljoner dollar, antalet… ja, ni förstår. Allt var förvisso intressant och visionen var också ”Everything and everyone connected to the Internet”. Och jag fick onekligen en känsla att Java är med överallt. Scott McNealy uttryckte det mer subtilt när Sun fick en utmärkelse för sin marknadsledande Java Card och dess dominans:
We prefer ’interesting market share’.

Var fanns då den rena råa visionen, passionen? Mestadels hittade jag den i de olika grupperna, allt från expertgrupper inom Sun till, och kanske framförallt, olika kommuniteter (”communities”). Här fanns de galna idéerna, de lovande framtida teknologierna och de intressanta verktygen. Det gör säkerligen inte våra liv lättare på kort sikt, men jösses vad roligt jag kommer att ha det!

Originally published in JayView.

Ytterligare en Aspekt på din kod

January 20, 2004

Har du någonsin kopierat vissa snuttar kod – om, om och om igen? Trots att du redan har en snygg objektorienterad arkitektur? Trots att den är full med de bästa design-mönster som går att uppbringa? Trots att du valt de bästa verktygen och ramverken? Lika förbaskat så sitter vissa rader, som loggning, både i ryggraden och i varje klass. Vad är fel? Och hur kan man undvika det? Aspektorienterad programmering (AOP) kan vara svaret – om inte annat så är det ett paradigmskifte värt några hjärnceller.

Trots att vi anstränger oss till det yttersta att modellera våra system intill perfektion, nåja i alla fall väldigt, väldigt nära, så är det fortfarande svårt att fånga strukturen hos ett problemområde. Detta märks t ex genom att vi kopierar välbehövliga små bitar kod och lägger in dem överallt. Inte nog med detta, de klasser som helst bara skulle behöva lösa en uppgift, tvingas att känna till säkerhet, databas, loggning osv. Allt detta leder till system som är svåra att underhålla och förändra.

Vad skulle hända om vi kunde plocka ut all loggning i våra projekt och lägga dem i en separat klass – en aspekt? Istället för att sprida ut en viss lösning i vårt system, kan vi nu underhålla den på ett enda ställe. När programmet kompileras så förs koden tillbaks ut där vi hade den innan.

För att bättre förstå vad aspekter är tittar vi närmare på AspectJ, som är en variant av AOP baserad på öppen källkod. Den har flera år på nacken och skapades på Xerox PARC som ett forskningsprojekt med stöd av DARPA.

Ett exempel: Var finns egentligen koden för loggning?

En vanlig syn är loggningen som ligger utspridd över ett helt system. När vi inför en aspekt så får vi ett enda ställe att underhålla den på.

Kodpunkt, punktsnitt och direktiv

I aspektorienterad programmering kan man samla alla dessa små bitar kod på ett enda ställe. Men vi måste ju fortfarande kunna köra dessa på givna ställlen i programmet? Lösningen i AspectJ är att identifiera punkter i exekveringen av ett program – så kalllade kodpunkter (joinpoints).
Det finns flera olika typer av kodpunkter man kan identifiera; metodanrop, skapande av objekt, att sätta attribut, utlösning av undantag (exceptions) osv. Ett punktsnitt samlar en omgång kodpunkter och ger dem ett namn.
Genom att ange kod, direktiv (advice), som ska köras vid dessa kodpunkter kan vi samla tvärgående intressen (crosscutting concerns) i en enda fil – en aspekt. Eller annorlunda uttryckt:

aspekt = punktsnitt(kodpunkter) + direktiv

En aspekt består av en omgång identifierbara punkter i programmet där extra kod ska köras.

Vad kan man göra mer?

Vi har bara gått igenom ett hyfsat enkelt exempel till höger, men det finns många saker man kan använda AspectJ:

  • Olika former av loggning och debugging.
  • Design-by-contract, d v s att man kollar inoch utgående tillstånd och parametrar. När man är nöjd att systemet uppfyller kraven kan man ta bort dessa aspekter.
  • Testa optimering, alternativa lösningar etc.
  • Cachning, synkronisering, accesskontroll etc.
  • … och fler tekniska aspekter som inte har med vårt problemområde att göra.

Innan har vi endast talat om dynamisk förändring av ett program, d v s att påverka arbetsflödet. Men det går också att ändra den statiska strukturen genom att lägga till t ex klassvariabler, metoder, ändra arv. Här uppstår fler möjligheter:

  • Multipelt arv som t ex mix-in i C++
  • Genomförande av kodstandard. ”Ingen får ändra en variabel direkt”. Denna koll kan t o m göras vid kompilering!

Listan kan göras mycket längre. Vi befinner oss bara i början av vår förståelse om var och hur vi bäst använder aspektorienterad programmering. Även om denna inte kommer att ersätta objektorienterad programmering (OOP) så kommer den att vara grunden för AOP på samma sätt som funktioner utgör grunden för OOP.

Ett enkelt (nåja) exempel

Vi skulle kunna gå igenom ett enkelt ”Hello Aspect World”, men jag väljer iställlet att dyka i lite djupare. Jag vill mäta hur lång tid det tar att anropa databasen i vårt hemmasnickrade modelllager.
Vår modellkod innehålller en abstrakt klass som definierar ett gränssnitt för att arbeta mot databasen. Personklassen representerar en post i person-tabellen och implementerar själva anropen med SQL mot databasen i metoderna dbSave, dbUpdate och dbRemove. I ett anfall av hybris lägger jag in mig själv i databasen. Demokod:

Vårt enkla modell-lager som kapslar in databasen.

DBObject tPerson = new Person();
tPerson.setField("firstName", "Björn");
tPerson.setField("lastName", "Granvik");
tPerson.dbSave();

tPerson.setField("company", "Jayway");
 tPerson.dbUpdate();

Du gamla vanliga lösning

Låt oss nu göra en enkel tidtagning. På det gamla sättet så blir det till att kopieraoch-klistra, så mycket som vi nu orkar. Till exempel skulle Person.dbSave kunna se ut som följer:

void dbSave() {
    long tTime = System.currentTimeMillis();
    // Do something...
    tTime = System.currentTimeMillis() tTime;
    System.out.println( thisJoinPoint + ": " + tTime );
}

Och på samma sätt för de andra metoderna dbUpdate och dbRemove. Även om vi förbättrar situationen genom att introducera en tidtagningsklass blir det bara marginellt bättre – det är fortfarande korkad kod! Dessutom så kommer den att ta tid att exekvera. Inget vi vill ha kvar i en produktionsversion.

Du sköna nya aspekt

Låt oss titta på hur man skulle kunna lösa problemet med hjälp av aspekter. Vår nya lösning innehåller en del nya ord som tillägg till Java-språket, se fetstil nedan, men är inte så svår som det först verkar.

/* A timing aspect on DBObject.db methods */
public aspect DbTimerAspect {

    /* Public DBObject methods starting with 'db',
     * taking no parameters and returning anything. */
    pointcut dbMethods() : execution( public * DBObject.db*());

    /* A simple timer advice to be called instead
     * of the original method. */
    void around() : dbMethods() {
        long tTime = System.currentTimeMillis();
        proceed();    // Proceed with call to DbObject.
        tTime = System.currentTimeMillis() tTime;
        System.out.println( thisJoinPoint + ": " + tTime );
    }
}

Vår aspekt DbTimerAspect innehåller dels de metoder som vi vill mäta och den tidmätare vi vill ska köras.
I kodsnittet dbMethods (pointcut) väljs de publika metoder i DBObject och dess subklasser som börjar på ”db”. Vi anger också att det är när metoden körs (execution) som är intressant. Här kan man välja på fler varianter; när metoden anropas, när ett attribut ändras, när ett objekt skapas och många fler sorters kodpunkter.

När demokoden anropar Person.dbSave så är det vårt direktiv som körs istället. Nyckelordet som anger detta är around. Vi hade naturligtvis kunnat ange att den skulle köras före, efter osv. Det första vi gör är att ta reda på tiden. I nästa steg anropar vi originalmetoden med ”proceed”. Nu körs Person.dbSave som vanligt.

Efter att vi kommer tillbaka räknar vi ut den tid som tillbringats i anropet och skriver ut den på konsolen. Lägg märke till att vi har tillgång till den kodpunkt som vi befinner oss i m h a thisJoinPoint. Resultat
När vi kompilerar vår kod gör vi det med kompilatorn från AspectJ. Den genererar ren Java ”byte code”, dvs. koden kan köras precis som vanligt.

Resultatet på konsolen blir:

execution(void se.jayway.jayview.aop.Person.dbSave()): 111
execution(void se.jayway.jayview.aop.Person.dbUpdate()): 30

Ganska mycket det vi förväntade oss.

Slutkläm

Denna artikel räcker egentligen inte för att förstå hela vidden av det man kan göra med aspekter. Jämför vi med en vinprovning har vi bara hunnit titta på etiketten. Men, likväl, vårt lilla exempel pekar på de stora möjligheter som finns med aspekter.
När och var bör man då använda AOP? Än så länge är aspekter inte ”bevisade”. Hur kommer de att skala? Hur påverkas arkitekturen i skarpt läge etc?
Däremot så är det mycket intresssant att förbättra hur vi utvecklar dessa system. Mitt råd blir därför; Skapa aspekter som stödjer din kodstandard, testar varianter av din lösning utan att behöva modifiera koden, gör verktyg som t ex loggningsaspekter, etc.
Om jag ska våga mig på en gissning tror jag att vi inom några år kommer att ha sådana ”tekniska” aspekter som öppen källkod. Fast jag kan ha fel – de kommer kanske redan om ett år eller så 🙂

Termer

kodpunkt (joinpoint) En punkt i exekveringen av ett program, till exempel i anropet av en metod i en klass.
punktsnitt (pointcut) En samling utvalda kodpunkter.
direktiv (advice) Kod som körs vid utvalt punktsnitt under angivna omständigheter, t ex kan man logga ett anrop innan det körs.
tvärgående intressen (crosscutting concerns) Ett system har oftast flera mål som det försöker uppfylla. Förutom att lösa grundproblemet (t ex lönehantering) så finns där också uppgifter som t ex loggning, säkerhet etc. Dessa uppgifter, eller intressen, är typiskt utspridda i systemet – de går på tvären genom strukturen.
OOP Objektorienterad programmering en programmeringsteknik och synsätt som gör det möjligt att öka komplexitetsgrad och återanvändning.
AOP Aspektorienterad programmering att göra fristående moduler som hanterar tvärgående intressen på ett sådant sätt att de kan sömlöst kan föras in i koden igen vid t ex kompilering.

Resurser
AspectJ
Eclipse, AspectJ plug in
JavaWorld: I want my AOP!
AOSD – Aspect Oriented Software Development

Originally published in JayView.

Applets för vuxna

August 4, 2001

Java Web Start (JWS) är en teknik som tillåter automatisk distribution av Java- applikationer via webben. Dessa applika- tioner kan antingen köras i en begränsad miljö, likt appletar, eller om så krävs få fulla systemresurser till klientens dator. Applets – fast denna gång för vuxna.

JWS-applikationer startas första gången typiskt från en länk på en html sida, applikationen laddas då ner till klienten. I fortsättningen kommer den dock bara att titta efter uppgraderingar från servern. Men JWS- applikationer är ingalunda kopplade till webbläsaren, de körs helt fristående vilket innebär att de även går att starta som van- liga applikationer.

En annan intressant funktion är den dyna- miska resurshanteringen. Första gången en applikation körs laddas ett minimum av den ner, vid behov laddas sedan ytterligare data ner under körtid.

För att tillhandahålla dessa funktioner lig- ger det under JWS ett api som heter Java Network Launching Protocol (JNLP). Den innehåller en rad olika services som tillåter sandlådsapplikationer att spara och öppna fi- ler, komma åt clipboard och skrivare med mera. Användaren måste dock via en dialog godkänna sådana operationer.

Vad krävs?

Så vad krävs för att köra JWS-applikatio- ner? Klienten behöver Java Runtime Environment 1.2.2 eller senare och Java Web Start 1.0.1 eller senare – inget utöver det vanliga. Dessutom behövs en standard webbserver som kan registrera nya MIME- typer.

För att utveckla JWS-applikationer behövs ingen speciell kod, exekveringen börjar på samma sätt som vanliga applikationer. Utvecklandet innebär följande steg:

  • Skapa applikationens kod.
  • Paketera applikationen och dess resur- ser till en eller flera jar-filer.
  • Signera jar-filer(na).
  • Skapa en XML-fil som beskriver applikationen, kallas JNLP-filen.
  • Lägg upp allt på webbservern, tillsammans med en lämplig html-fil.

Första gången måste du även se till att din webbserver känner igen .jnlp filer genom att registrera den som en ny MIME-typ.

En fet klients räddning

När man läser rubrikerna från tiden då applets skulle rädda världsfreden är det svårt att låta bli och le. Java Web Start känns som client/server med rätt anslag. Om man har behov av av feta klienter är det klart intres- sant att kolla upp – annars lär man utveckla exakt samma kod själv.

JWS används med fördel av utvecklings- intensiva applikationer eller av applikatio- ner vars uppgraderingar snabbt måste ut till ett antal användare. Ett annat behov kan vara att bryta de bindningar som en traditionell applet har med sin webbläsare. Eller om man bara vill vara bekväm av sig.
Originally published in JayView.

JRockit – en svensk JVM

May 4, 2001

JRockit från Appeal Virtual Machines, en svensk JVM specialanpassad för servrar. Kan det verkligen vara någonting? Kan en sådan produkt hävda sig i konkurrensen mot bransch jättar som Sun Microsystems och IBM? I denna artikel presenteras grundidéerna i produkt- en och vad som skiljer JRockit från vanliga JVM:er.

Innan arbetet med JRockit inleddes gjordes en undersökning av vad ut- vecklare av serverapplikationer egentligen ville ha för egenskaper i en JVM. Denna lista har legat till grund för det som är JRockit idag:

  1. Pålitlighet/Robusthet (24×7)
  2. Skalbarhet
  3. Korta pauser
  4. Kodprestanda

Pålitlighet och möjlighet att kunna köra sina system dag ut och dag in, vecka efter vecka, var den i särklass mest efterfrågade egenskapen i en server-JVM. För att, som ett litet företag, kunna erbjuda detta är det Appeals målsättning att se till att så många som möjligt får möjlighet att testa JRockit och att bugrapporter besvaras och åtgärdas så snart det går.

Skalbarhet eller möjligheten att kunna hantera en stor mängd samtidiga användare och att utnyttja tillagd maskin- vara så effektivt som möjligt står näst högst upp på listan.
Trea på listan är korta pauser. Allt för många serversystem lider fortfarande av skräpsamlingspauser som är flera
sekunder långa.

Vad som kanske är mest anmärkningsvärt med denna lista är att kodprestanda kom först på fjärdeplats. Det är ett av de mindre problem man har i ett serversystem, något som kanske är värt att komma ihåg när man står i valet mellan en svårdebuggad men snabb C++ lösning mot java.

JRockit – en JVM med siktet inställt på mer än bara kod och skräpsamling
Sun och IBM ser på JVM:en som någonting vars uppgift är att exekvera kod och att skräpsamla, d v s kodexekvering och minneshantering är de områden som man optimerar. JRockit har en annan filosofi: Ett av de viktigaste underliggande designvalen i JRockit är att JVM:en inte bara ska kunna förbättra kodexekvering och minneshantering, utan att även trådhantering, fil och nätkommunikation ska ingå bland de områden JRockit optimerar.

Varför skiljer sig då JRockits optimerings- områden från de andra JVMernas? För att förstå detta måste vi gå tillbaka i tiden till Javas födelse: När Sun i början av 1997 gjorde en analys av prestandaproblemen, kom man fram till att för en godtycklig applikation låg 75% av tiden i kodexekvering och 20% av tiden i skräpsamling. Naturligtvis valde man att satsa på optimerad kodexekvering och skräpsamling i sin kommande JVM, HotSpot. Ett problem med analysen var att de applikationer man undersökte var typiska klientapplikationer. Användandet av Java på serversidan låg fortfarande i sin vagga.

JRockit har tagit fasta på att fördelningen mellan de olika områdena på serversidan inte är alls likadan. En typisk serverapp- likation kan tillbringa 25% av sin tid i kod, 25% av tiden i skräpsamling, 25% av tiden i trådhantering och de resterande 25% med nätverkskommunikation. Att inte optimera tråd- och nätverkshantering för sådana system resulterar i att man bara kan förbättra 50% av applikationen, och då teoretiskt maximalt halvera exekveringstiden. Genom att ge JVM:en bättre kontroll över tråd- och nätverkskom- munikationen kan dessa områden väsentligt snabbas upp utan förbättringar i det underliggande operativsystemet.

Vad det gäller tråd- och näthantering har man på Sun fortfarande åsikten att de största förbättringarna inom dessa om- råden inte kommer ifrån JVM:en utan från utvecklingen inom operativsystemavdel- ningarna.

Dynamisk Optimering
Dynamisk optimering är ett annat av huvudkoncepten i JRockit. Dynamisk optimering innebär att det körande programmet förbättras under körningens gång, JVMen anpassar exekvering av programmet till hur det används och vilka delar som används. Dynamisk optimering möjliggör ointuitivt nog högre exekveringshastigheter än traditionell kompilering för stora komplexa system. För att förstå varför måste vi först förstå vilka egenheter stora system har. För det första så är systemen ofta flerlagersarkitekturer, en nödvändighet för att skapa abstraktion och få överblick över systemen.

Det är bra för människans förståelse av systemet på en övergripande nivå, men för datorn som exekverar systemet leder det till att man måste passera genom fler lager, vilket tar mer tid. För det andra så bygger man vanligtvis nya system ovanpå andra system (t ex applikationsservrar) eller med hjälp av andra komponenter (skrivna av andra eller i tidigare system). I allmänhet är dessa komponenter generella, dvs de är byggda för att lösa en mängd olika uppgifter, varav endast en del utnyttjas i det aktuella systemet. Givetvis är det bra att systemutvecklare lär sig att inte hela tiden uppfinna hjulet på nytt, men ur en prestandasynvinkel så skulle antagligen systemet exekvera snabbare om man använde mer specialiserade komponenter.

Dessvärre kan statisk kompilering inte hjälpa till speciellt mycket om språket är dynamiskt som t ex Java: det är svårt, för att inte säga omöjligt att veta vilka komponenter som kommer att finnas i systemet innan man startat det. Detta på grund av att Java tilllåter ny funktionalitet att laddas in under körningens gång (klassladdning). Genom dynamisk optimering kan JVM:en under körningen skala bort de lager som bara fyller en abstraktionsfunktion för människan och dessutom kan de komponenter som används på ett specifikt ställe i systemet specialiseras till hur de används på det stället. Dynamisk optimering ger alltså, åtminstone i teorin, människan en möjlighet att bevara i stort sett all abstraktion utan att förlora allt för mycket prestanda. Kritik har dock riktats mot att själva optimeringsprocessen tar tid från exekveringen. Detta kan förvisso vara sant men om optimeringar görs under systemets första tio minuters drifttid och systemet kommer att vara uppe i flera veckor i streck är det en försumbar kostnad och dessutom kan man tänka sig att det optimeringsarbete som görs sparas för att återanvändas.

Konfigurerbarhet

Ytterligare en unik filosofi hos JRockit som andra JVM-tillverkare först på senare tid börjat titta på är baserad på det faktum att ingen applikation är den andra lik. Det finns inga patentlösning. Finns inte en perfekt konfiguration av en JVM som kommer att fungera lika bra för alla applikationer.

JVM:ens konfiguration måste kunna anpassas till olika applikationer. Detta kan göras på två sätt:
1) JVM:en analyserar applikationen under körning och justerar sina parametrar för att kunna exekvera applikationen så effektivt som möjligt. En del av denna process är den dynamiska optimeringen som beskrevs ovan,
2) Utvecklarna av systemet kan själva konfigurera JVM:en både vid uppstart och under körningen. Konfigureringen under körningen ska kunna göras ifrån Java.

Tanken är att JVM:en på bästa sätt ska anpassa sig men även bli anpassad till applikationen för högsta möjliga pre- standa.

Installera och testa JRockit

Den nyfikna läsaren har nu börjat fråga sig ”kan jag jag pröva JRockit”? Ja, du kan ladda ned en fullfjädrad version för Solaris, Linux eller Win2000 från http:// http://www.jrockit.com.

Framtiden

Vad händer med JRockit i framtiden. Ett av de viktigaste områdena man arbetar med är licensiering: att få applikations- servertillverkarna (BEA Weblogic, IBM Websphere, ATG Dynamo, Orion m.fl.) att ta upp JRockit som en rekommenderad JVM för sina applikationsservrar.

För den första versionen av JRockit satsade man på att bli avsevärt mycket snabbare än de andra JVM:erna inom tråd- och nätverksprestanda, någonting man lyckades med. Detta visades genom den oslagbara skalbarhet man lyckas uppnå på det välkända Volano-testet: http:// http://www.volano.com/report.html .

Vad det gällde kod och skräpsamlings- prestanda var man dock för den första versionen av JRockit tvungna att inse att avståndet till de andra JVM:erna var för stort. Därför pågår nu intensivt arbete inom dessa områden för att bli bättre än de andra även här. Lyckas man? Svaret återstår att se senare i år.

Originally published in JayView.

Juxtaposition

March 3, 2001

Ytterligare en het förkortning är här JXTA. Uttalat blir det “juxta” och kommer från det engelska ordet juxtapose att placera saker bredvid varandra med en underförstådd länk eller för att betona kontrasten. JXTA är Suns öppna lösning för plattformsoberoende system byggda med peer-to-peer teknik.

Det finns ingen hård definition av peer-topeer (P2P). Det finnes inte ens en bra översättning till svenska “jämbördig kommunikation” låter inte riktigt bra. Viktiga delar är dock att datorerna pratar direkt med varandra utan att gå via en central server.
Ni har säkert hört talas om eller använt ett sådana lösningar förr Gnutella (dela filer), Groove Networks (groupware, gjort av mannen bakom Lotus Notes), Search for extraterrestial life SETI@home (distribuerade beräkningar av radiosignaler), etc. Går vi tillbaka i historien hittar vi fler exempel; Usenet (diskussionsgrupper) och AppleTalk (nätverksprotokoll).


Figur: I en P2P-lösning så är alla medverkande jämbördiga, ingen skillnad görs på kapacitet eller storlek. Egenskaper som tillgänglighet, svarstider, resultat och tillförlitlighet blir helt annorlunda jämfört med hierarirkiska system som client-server. Resultatet från sökning blir olika beroende på tidpunkt, men vid tillräckligt stora grupper av pärer får man alltid svar.

En tjänst som brukar nämnas i samband med P2P är Napster, som är en hett debatterad webbsajt för att dela musikfiler. Strikt talat är det inte äkta P2P då den inte fungerar utan en server. Något som faktiskt gjort det möjligt för musikindustrin att väcka åtal. Detta är mycket svårare med en äkta P2Plösning utan någon centraliserad del överhuvudtaget. SETI faller lite på samma grepp trots att det är distribuerad teknik så sitter det en server som binder ihop lösningen.

Ett problem med alla dessa lösningar är att de är sinsemellan inkompatibla, ingen grupp kan utnyttja den andras tjänster. Varje tjänst är en egen del av sajberspejs och aldrig ska de två mötas förrän förhoppningsvis nu.

Vad är JXTA?

Bill Joy, Sun “Chief Scientist”, har initierat JXTA som en öppen plattform för att bygga nätverksbaserade och distribuerade system för P2P. JXTA-plattformen standardiserar sättet som noderna i P2P-system:

  • hittar varandra
  • berättar om sina resurser
  • kommunicerar med varandra
  • samarbetar för att skapa säkra grupper av jämbördiga noder

Tanken är att JXTA ska stå för en plattform som gör det snabbare och säkrare att skapa distribuerade och jämbördiga system som kan skala bättre. Helt enkelt en kickstart för P2P-lösningar. Till skillnad från andra verktyg från Sun, som till stor del är baserade på Java, så är detta inte något bibliotek med kod. Utan det är baserat på protokoll och XML alltså inte en omgång api:er. Dessa protokoll gör det möjligt för andra miljöer, som C/C++ till exempel, att ta del av denna arkitektur oberoende av nätverksprotokoll. Faktum är att det håller på att bildas en JXTA-del med öppen källkod för just C.

I JXTA kan man dessutom se drag från Unix. Den har till exempel ett pipe-begrepp för att kunna stapla kommandon ovanpå varandra. Kombinera detta med begrepp som group och peer så får vi ett sorts distribuerat operativsystem. En generell tummelplats för att dela allt från fildelning till processorkapacitet. Man kan till exempel köra kommandon som “peers” i en grupp för att se vilka som är tillgängliga. “Öppen” är ett viktigt ord och betyder att projektet är tillgängligt för alla. Man kan under Apache-liknande licens både använda och ta del av källkoden utan att betala något. (www.jxta.org)

Arkitektur

JXTAs arkitektur är indelat i tre lager:

  • JXTACore Kärnan är själva plattformen för JXTA. Den innehåller det minsta stöd som behövs för att skapa en P2P-lösning (nod (peer), grupper, att hitta andra noder, nodkommunikation, nodövervakning och andra säkerhetsdelar.
  • JXTA Services Detta lager innehåller inte väsentliga delar men är antagligen önskvärda sökning, indexering, lagring, fildelning, distribuerade filsystem, resurs aggregering och uthyrning, protokollöversättning, autenticering, etc.
  • JXTAApplications I detta lager hittar vi saker som meddelandehantering, hantering och leverans av underhållning, distribuerade auktionssystem. Gränsdragningen mellan en service och en applikation är inte klart definierad utan kan skifta beroende på synvinkel.

Man kan faktiskt prova hur det är att använda redan nu genom att ladda ner och experimentera med JXTA Shell. Det är en sorts testbänk för att bygga upp JXTAlösningar korsning mellan chattens struktur och kommandoprompten.

Till sist

Sun har ett trumfkort på sin hand. Eftersom JXTA redan är här och dessutom baserat på öppna protokoll så kan det bli den brygga som länkar ihop olika grupper på tvärsen över barriärer som programmeringsspråk, teknologier, plattformar etc. Har jag tur kommer det snart ett projekt i min väg som bara måste ha JXTA i sig,
Med tanke på Suns hårdsatsning de senaste åren på “tunna klienter”, namnet antyder just en server, så är detta i all tysthet ett steg bort från den strategin. JXTA kommer dock antagligen att bli en del av Sun One. Det ska bli intressant och se hur Microsoft med sin .Net-strategi kommer att reagera. Jag har mina aningar 😉

Main Entry: jux·ta·po·si·tion
Pronunciation: “j&k-st&-p&-’zi-sh&n
Function: noun
Etymology: Latin juxta near + English position
Date: 1654 : the act or an instance of placing two
or more things side by side; also : the state of
being so placed Ur MerriamWebster.

Resurser:
JXTAs webbplats
Collabnet, öppen källkod
Groove Networks:

Originally published in JayView.

Java på kisel

January 2, 2001

Cjip – inte vet jag vilka associationer ni får, men jag kommer närmast att tänka på en handle för en holländsk kryptopunk. Eller något man kan hitta sprayat på ett tunnelbanetåg. Missförstå mig rätt, jag tycker om namnet. Men inget är rätt – ”the Cjip” är faktiskt något så pass exotiskt som java på kisel.

En av min första frågor när vi dök upp hos Imsys i Upplands Väsby var hur man uttalar namnet – rätt och slätt som engelskans ”chip”. Förutom min dimmiga uppfattning om namnet hade jag en annan förutfattad mening att bli av med. Jag förväntade mig ett brådmoget Java- chip med ett leveransdatum i snar futurum. Den föreställningen skulle jag snart bli av med.

Men låt oss ta det från början. Cjip är så mycket som en implementering av en Java- motor (JVM) på kisel – lite förenklat, ett chip med Java inbyggt. När man tänker efter så är det naturlig lösning, Bytekod, alltså det man får när man kompilerar java-källkod, är ju en sorts assembler så varför inte välja det som maskinspråk direkt?

Gör man det behövs ingen virtuell motor (JVM) som interpreterar den bytekoden, dvs översätter den till den CPU som finns till hands. Det som Imsys har skapat är ett litet chip som kör Javas bytekod direkt i hårdvaran. Detta gör att man helt kan hoppa över en JVM – något som gör att deras lösning blir billigare (inga licensavgifter).

Dessutom har den få transistorer vilket gör den billigare att producera och strömsnål. Fördelarna med Cjip enligt Imsys är just Javas portabilitet kombinerat med att den är billig och strömsnål.
Prestandan går dock inte att jämföra med till exempel en modern Intel x86 processor, typ Pentium. Den senare är fortfarande snabbare trots att den kör en motor (JVM) som interpreterar bytekoden. Enligt Stefan Blixt, Cjips konstruktör, är the Cjip lika snabb som en Pentium 133-processor men effektförbrukningen är mindre än 5 procent.

The Cjip in comparison.

Cjip stödjer J2ME (Java 2 Micro Edition) som är en delmängd av Java 2. I J2ME finns själva Java-språket och en hel det av biblioteken. Imsys säger att det är världens första kompletta implementation av Java på kisel.

Just nu kan man hitta Cjip i bläckstråleskrivare som tillverkas av Array. Framtida produkter som Imsys säger sig fokusera är t ex mobiltelefoner, skrivare, terminaler, bilar etc.

Kameleont

Hur har man implementerat stödet i Cjip för Java? Likt en kameleont har den en förmåga att byta utseende, alltså byta den assembler som den kan exekverar. I botten i Cjip så finns det mikrokod som exekverar de maskinkoder som kommer. Det är denna mikrokod som tolkar de bytekoder som kommer.

Genom att byta ut dessa styrkoder kan man implementera olika sorters assembler. Man kan på det sättet också optimera delar direkt i mikrokod och på det sättet rejält höja prestandan.

Utvecklingsmiljö – Developer

Utvecklar gör man i Imsys egen programmeringsmiljö – Developer. Den som jobbat med Microsofts Visual C++ lär känna igen sig. I Developer programmerar man i C/ C++/Java eller assembler som laddas ner i Cjipet, antingen via PCI eller den parallella porten. Inifrån miljön debuggar man också (dock ej i C++ ännu). Programmet kör i dagsläget på Win 95/98/NT men ännu inte på Windows 2000.

Olika utvärderingskit

Tack vare att chipet har funnits ett tag finns det också olika varianter av utvärderings/ utvecklingskit att tillgå. Till exempel finns det en PCI-variant som man helt enkelt sätter i en slot på sin pc (om den nu har plats för ett PCI- kort). Ombord finns det Cjip (naturligtvis), MMC (multimedia-kort), RS232-port (seriell port) och RJ-45 (TCP/IP över Ethernet).

Nästa steg upp är LCD-versionen som kopplas in typiskt via en parallell kabel. Den innehåller dessutom en färg LCD-skärm, en knappsats, IRDA (infraröd sändare och mottagare), audio (”CD-kvalitet”), dubbla seriella portar och en omgång andra saker som LEDs och realtidsklocka. Ungefär som att se en personlig digital historia utplattad på ett grönt kort.

Ett annat kit som Imsys utvecklat för ABB är modulärt på ett finurligt sätt. Tänk er ett kort cirka 10×5 cm, längs med långsidorna sitter det kontakter. Grundkortet innehåller Cjip och lite grundläggande i/o. Andra kort innehåller t ex Ethernet-access. Genom att bara sätta ihop korten ovanpå varandra, ungefär som Lego- bitar kunde man sedan sätta ihop sitt eget utvärderingspaket!
Kan man tänka sig ett kort med Bluetooth?

Konkurrenter

Det finns konkurrenter även om ingen av dem implementerar en Java-lösning direkt i kisel. Crusoe är ett omtalat chip som dock inte konkurrerar direkt med Cjip eftersom den inriktar sig på bärbara datorer och att tolka maskinkode som t ex Intels x86.

Motorolas DragonBall, medlem av 68K- familjen, och som används i Palm drar mer ström och har sin egen assembler och därmed inte blir portabel på samma sätt som Javas bytekod. Zucottos mikroprocessor, Xpresso, är dock en direkt konkurrent, men den implementerar Java-stödet blandat med en del i hårdvara och en del i mjukvara.
Bland stickspåren, verkar det som, hittar vi också Suns Microjava 701 som likt the Cjip kör java direkt i maskinvaran. Enlig uppgift ligger detta projekt dock i malpåsen.

Slutkläm

Jag förväntade mig att finna en intressant framtidsprodukt med betoning på framtid. Det vi fann var en lovande produkt som redan finns här och nu. Om du har behov av bygga ett inbäddat system med Javas fördelar och där ström är premium kolla in Cjip. Det kan vara väl spenderad tid.

Originally published in JayView.

Sun Java Tech Days London 2000

November 4, 2000

I början av hösten drog Sun upp bopålarna och drog ut på en världsturné med Java i bagaget. Även om Stockholm var med på resrutten kunde vi inte motstå frestelsen att istället åka till London dels skulle James Gosling tala och dels var det billigare.

Sun Java Tech Days är det något långa namnet för Suns världsturné där de sprider och evangeliserar Java för oss tekniker. I två dagar skulle vi dels få oss till livs diverse nyheter, översikter och kontakter allt med Java-smak.

Moderna sagor

Konferencier var Max Goff – tänk er en lastbilschaffis i läderjacka och slokmustasch. Det första talet hölls av Javas fader, James Gosling. I t-shirt och slitna jeans svarade han slumpmässigt på de frågor som vi i publiken hade lämnat in. Jag har visserligen hört Gosling tala förr – den gången rörde det problemen med att bygga en 10 000-årig klocka (just det, fyra nollor) så jag var inte inställd på någon bländade retorik. Det hela utvecklade sig till en trevlig sagostund med farbror Gosling. Den enda frågan som jag kommer ihåg med säkerhet var min egen:
What’s the meaning of Java? (as in “What’s the meaning of life?”)
Efter några hjärtliga skratt gick vi vidare till nästa fråga.

Bland dessa var hur Java fått sitt namn. Att det hette Oak från början känner de flesta till, men efter varumärkesproblem var de tvungna att byta. Utifrån en önskelista så var Java bara på fjärde plats. De första tre föll ifrån på samma sätt och kvar blev Java. Om jag inte missminner så var Goslings egen favorit ”Lyric”. Jag vet inte, men jag tycker nog att det är tur att den inte var tillgänglig.

Konferensen

Den stora delen av konferensen bestod av olika översikter, allt från micro (J2ME) till mega (J2EE) med däribland insprängda sessioner från olika sponsorer. Det senare kunde ha blivit en ren reklamövning men höll sig på en vettig nivå med praktiska genomgångar av produkterna. Eftersom vi som var där, Björn Granvik och Peter Dagsberg från Jayway, bland annat var ute efter en sammanfattning så fungerade genomgångarna överlag mycket bra.

J2ME

Genomgången av J2ME, Java 2 Micro Edition, som är Suns ramverk för små handhållna produkter som, var välbalanserad mellan genomgång av generell struktur och API:er. Ramverket verkar vara inne på sin ”andra andning”. Det vill säga strukturen har genomgått en version med efterföljande förbättringar. Strukturen är uppdelad i konfiguration som beskriver en grupp av enheter, säg mobiltelefoner, och vad som ska finnas i stöd för dessa (minne, storlek, battery, tillgängliga api:er). En konfiguration delas sedan upp i profiler som beskriver en enskild telefon. En första version (1.0) finns redan nu att ladda ner, men.
För att kunna passa in Java i ett begränsat minne så saknas en del saker – trådar, reflektion, begränsat stöd för i18l (andra språk än västerländska) etc. De har också skrivit om Java nätverksfunktionalitet eftersom den tog helt enkelt för stor plats.
Dock fick jag uppfattningen att de inte kommer att komma några faktiska J2ME-baserade mobiltelefoner förrän början på nästa år. Ett sista frågetecken är kopplingen till WAP från och till Java. En lösning är att ha Javataggar i en wap-läsare, en annat att helt enkelt ha en wap-kompatibel Java-baserad läsare. Man arbetar just nu på båda spåren.

Summa summarum: J2ME verkar genomtänkt, men det saknas en del i strukturen kring den vad det gäller kopplingar till omvärlden och faktiska produkter. Min slutsats blir att J2ME tillsvidare är mest intressant för t ex enheter som Palm, inte förrän om ett tag för mobila telefoner.

Java och XML

För en del är det här nog vardagsmat, inte för mig. Det verkar finnas två huvudsakliga tekniker: SAX (händelsebaserad tolkning av xml-data) och DOM (inläsning av xml-data till objekthierarki).
Dessa kändes vettiga, även om området som sådant verkar spretigt (läs det händer mycket).

J2EE

Java 2 Enterprise Edition, känns nu mogen för scen. Tekniken har nu gjort flera varv i vemstödjer-vad och stabilt-nog-för-ett-sentfredags-hack – det vill säga det har mognat tillräckligt för att det till exempel ska finnas applikationservrar som är J2EE-kompatibla etc. Det var med spänning som jag såg fram emot presentationerna för att se hur långt enterprise edition har kommit.
Förra gången som Sun talade om EE för min del (JavaOne 1999) så hade man precis börjat tala om den som en egen produkt, men ännu inte börjat skeppa något.

Det fanns små tecken som talar mer om mognad än alla evangeliserande presentationer tillsammans:

  • bland utställarna talade man om ”vi var först med J2EE” eller ”vi gör J2EE bättre än X”
  • att det inte finns någon t-shirt
  • tekniken är för dåtid och fungerar faktiskt
  • tekniken har spridit sig till leverantörer som börjar att pressa priser (t ex Allaire/Jrun, JBoss)
  • eller den genomgång (codecamp) som hölls en eftermiddag där presentatören lyckades med konststycket att bli klar en dryg timme tidigare. Vi fick helt enkelt lotta ut Java-jackorna tidigare.

Summa summarum: J2EE verkar så pass intressant och stabilt så att nu dyker i alla fall jag i och börjar använda tekniken fullt ut.

Raka rör

En föreläsning som föll utanför den gängse ramen var Suns senior staff engineer, Robert Demb. Vad titeln innebär är lite luddigt, men man kan kort beskriva hans föreläsning som en uppstädad version av det han brukar berätta om Suns olika tekniker inför styrelser och ledningar som har skrivit under en ”nondisclosure”-avtal. Jag skriver ”uppstädad” då han inte kunde berätta allt (det fanns journalister där:-) men det han berättade var rakt på sak och utan förskönande omskrivningar.

Till exempel beskrev han svagheterna med Jini. Det var så pass rakt på sak att folk efteråt frågade rakt ut om han menade att vi programmerare inte skulle utveckla för Jini. Nu var inte det hans poäng utan snarare att frankt berätta om läget.
Ibland är det svårt att ta för mycket uppriktighet, själv har jag svårt att värja mig om en säljare använder uppriktighet som vapen. Det hela blir mer troligt.

Mycket intressant föreläsning om jag nu bara kan få tag i bilderna han använde under presentationen….
Förresten, den presentationen gavs bara i London och Prag vilket kan vara något att tänka på då schemat för konferensen verkar vara lite olika för olika ställen.

Utställarna

Det fanns ett dussintal utställare – de flesta med någon typ av applikationsserver. BEA, Oracle, iPlanet, Iona, WebGain, eXelon, etc och naturligtvis Sun. Dock fanns inte IBM där. Utställningen var inte stor men den fyllde sitt syfte, även om det ibland hade kunnat vara lite högre teknisk inriktning bland utställarna så att man kunnat få en demo av produkterna.

Till slut

Kort: Konferensen var väl värd min tid. Likväl – jag undrar fortfarande vad meningen är med Java – fast en svarslös James Gosling är nog det närmaste jag kommer sanningen 😉

Originally published in JayView.