This is a almost live blog of the OCI internal Java lunch. Today our speaker is Ryan Withers. He is talking about Jini.

First person is Ryan now.

Why the reintroduction

Jini has been introduced seven years ago by Sun. At the time it had focus on devices. The product was mis-marketted and the device-orientation didn't work.

Jini is now an Apache incubator project named River.

I started investigating Jini from version 2.1, for an SOA initiative.

Jini does have impressive features. It's been in existence since 1999 and is very service oriented many years before SOA became a popular phrase.

Getting it

You can get the Jini 2.1 starter kit from jini.org under an Apache 2.0 license.

he Jini name does not stand for anything, but is rumored to be an acronym of "Jini is not initials".

Architectural goals of Jini

• Infrastructure for services, possibly federated
• Simplified sharing of services and resources
• Ease of access; location transparency
• Painless administration and maintenance

These goals parallels those of SOA to some extent.

Known uses of Jini

• Rubean A.G
• Magneti Marelli
• Nedap N.V.
• Orbitz
• Orange

Books

Apress book "Fundamentals of Jini 2". Also available online.

What's in Jini Spec

• Architecture
• Core services: Discovery/Join, Entry, Leasing, Event, etc.
• Utilities
• JavaSpaces, etc.

(Brian Coyner asked about the relation between Jini and ZeroConf and Apple's Bon Jour.)

The Demo

Two windows were brought up. One is the Service Browser. The other is a Converter application that uses one of the services.

The Service Browser now shows several services, all in a list box with names resembling full Java class names. One of them is the Registrar. Another one is a sample UppercaseConverter. Double click on a service brings up a metadata inspector for that service.

The Converter application has a data entry field and a convert button. Typing something into the entry field and then click the button will cause the text of the entry field to be converted and printed on an area below the entry field. There is also a menu that allows the user to choose the type of the conversion. At this moment, there is only an "Upper" menu item that corresponds to the UppercaseConverter service. The conversion does the obvious thing.

Another service is started from NetBeans. And the ServiceBrowser now shows one more service—MorseService. The Converter application's conversion type menu now has one more menu item "Morse". Select "Morse" and then click the button causes the text to be converted to Morse code and printed.

The MorseConverter service is shutdown now. It disappears from the Service Browser. A moment later, the "Morse" conversion type also disappears from the Converter application.

What is interesting is that all of these happens without restarting the application.

When the MorseConverter starts up, it makes its implementation classes available to any application that wishes to use it. The Converter application has registered with the Service Registrar its interest in services that implements the Converter interface (which apparently both UppercaseConverter and MorseConverter do). The Registrar notified the Converter application of the newly available service and the Converter application retrieved the classes of the MorseConverter. When it did the conversion, it is running the Java classes from its own JVM. There were no remote calls.

Of course, the service implementer may choose to implement a service as a remote service and export only a stub to the service registrar. In that case the service calls will be remote calls.

(Brian Coyner asked about the relationship between Jini and OSGi.)

Code

The server and the client uses the same code to talk with the Discovery service and the Lookup service.

public class Foo implements DiscoveryListener {

  public void doIt() {
    LookupDiscovery discover = new LookupDiscovery(LookupDiscovery.ALL_GROUPS);
    discover.addDiscoveryListener(this);
  }

  public void discovered(DiscoveryEvent e) {

  }

  public void discarded(DiscoveryEvent e) {

  }
}

Jini services are just interfaces:

public interface Converter {
  public String convert(String input) throws RemoteException;
}

public interface MorseConverter extends Converter {
}

public interface UppercaseConverter extends Converter {
}

Some other interesting classes

RemoteEventListener, ServiceRegistrar.

The events are fired because we specified a ServiceTemplate:

lookup(template, MAX_MATCHES);

where the template was constructed with parameters that contains the Converter interface.

Discussion

(First person is Weiqi now.)

Dean Wette commented that what is presented today is significantly simpler then Jini 1.0.

Eric Burke commented on the Swing code for the Converter applciation emphasizing the importance of wrapping the menu.addMenuItem() call with SwingUtilities to ensure its execution on the EDT.

I asked a question about the order in which various Jini services should be started. The answer is that it mostly doesn't matter. It's more like a peer-to-peer thing in that reguard.

I asked the question about the maturity of Jini. The answer is that Jini is indeed a technology that can be put into production use right away by people who know how to use it. Dean added that any infrastructure that can support telemetry transmission from a Formula One pit (Magneti Marelli) is mature.

Responses[2]

Posted by Weiqi Gao on September 28, 2007 4:52:15 PM CDT #

Kevin IM-ed me yesterday with the following question:

How come foo.getBar() == expectedBar is true yet foo.getBar().equals(expectedBar) is false?

I'll make that today's Java quiz: Have you encountered a situation in non-play code where obj1 == obj2 is true yet obj1.equals(obj2) is false?

By non-play code I mean a code base where all equals() and hashCode() overrides honor their contracts. In other words, there are no silly code like

public boolean equals(Object other) {
  return false;
}

Responses[13]

Posted by Weiqi Gao on September 28, 2007 6:06:16 AM CDT #

The new and improved It's Just a Bunch of Stuff That Happens—which went off the air briefly, as I noted 37 days ago—is back with renewed, focused energy and is as penetratingly insightful as ever.

In a post yesterday, Eric gave a concrete example of the drawback of lack of static typing in Ruby:

The second bug took me far longer to understand and was more insidious. In Ruby you don’t even have to say “return” at the end of a method. Instead, the result of whatever expression happened last is automatically returned. Invisible magic is the quintessential example of a feature that saves the original coder a few extra keystrokes but makes every downstream programmer pay the continuous tax for years to come.

I made the problem worse by adding a simple “if” statement to the end of the method, thinking I could explicitly change a bogus error message to nil. But now the method didn’t even return a string any more…I inadvertently changed the return type from a string to a boolean.

To which I commented without too much thinking:

Had you made a similar return-type-altering change in Java, the compiler would have caught it as an error. In that regard, the static typing works just like unit tests—it prevents you from breaking your code.

This post became the topic of discussion at OCI North this morning. Brian mentioned that he has been bitten by the same problem in a Ruby script he wrote recently. He also pointed out that no amount of unit tests will guarantee that a function will return data of a specific type.

Suppose you want to write a function that takes a string and return a boolean in a dynamically typed language, and you want the function to return true for inputs like "yes", "true" and for inputs like "no", "false". So you write your unit tests stating these requirements. And you may choose to implement this function like this (in pseudo-code):

def foo(input) {
  if input is "yes" return true
  if input is "true" return true
  if input is "no" return false
  if input is "false" return false
}

However, you cannot write a unit test that will make sure this function always returns a boolean. You can write a specific test that prevents the following code from spoiling the function:

  if input is "weiqi" return "gao"

But that test cannot prevent the next spoiler, and the next, and the next, ...

In this sense, a statically declared return type of boolean for the function can be thought of as the equivalent of an infinitely many unit tests.

The conclusion:

Responses[5]

Posted by Weiqi Gao on September 26, 2007 11:20:16 PM CDT #

The .NET Meets Java panel at the St. Louis .NET User Group meeting yesterday was interesting but did not change too many people's minds, in my opinion.

There are two kinds of people there: the regular .NET User Group members who are VB6-turned-VB.NET programmers and C# programmers working at Microsoft shops (about 80%), and consultant/contractor programmers who have worked on both Java and .NET projects and a few Java people who have an interest in .NET technologies (about 20%). Microsoft (David Schmidt) was present as usual.

iBridge was the food sponsor and the fried chicken dinner was delicious. And, get this, they gave away<drum roll/>an iPhone. Steve Jobs would be pleased.

Jeff Brown, who was scheduled to appear as a Java expert, couldn't make it, so we are left with a 2-to-1 .NET vs. Java panel—Jeff Grigg, Adam Esterline, and Robert Fischer. It's not surprising that all three have experience in both the Java world and the .NET world and had I not known these people, I can't tell who's the advocate for Java and who's the advocate for .NET. As a matter of fact, one of the .NET panelists is working on a Java project with some heavy Ruby on Rails mixed in.

The leading question went like this:

I am the CIO of a company whose critical business system is a 25-year-old one maintained all these years by a single guy. Cecil is retiring this year. And I have decided that the system need a rewrite. The question is, what technology choice should I make? Java or .NET.

The panels answers are pretty much what you can expect from experienced consultants: it depends. It depends on the nature of the business and the existing infrastructure. It also depends on the size and quality of the talent pool. Robert reported that there are more Java jobs than C# jobs in the U.S (2 to 1) or even .NET jobs (5 to 4).

Jeff pointed out some intrinsic qualities of .NET and Java that might sway the decision: .NET is a one vendor product and therefore provide a more cohesive set of tools. .NET also has better multi-language programming support. And Java has a very active Open Source community that brought us such tools as Spring and Hibernate.

The .NET guys added that some of the Java Open Source tools have been ported to .NET, Mark Balbes cautioned the .NET developers to be mindful of the style/concept mismatch such ports will bring to a project.

On the runtime environment front, Microsoft claimed that everyone who wants to develop .NET applications can just download the .NET Framework for free while to develop in Java, you'd have to buy expensive IBM or BEA application servers. It is interesting that one of the .NET panelists pointed out that capable Open Source application servers and application frameworks exist and are being used in production environments. However navigate the Java frameworks scene and making an intelligent choice is more of a challenge.

On the client/GUI applications front, there is a consensus that for a Windows only environment, developing the GUI in .NET makes a lot of sense. For cross platform GUI applications, Jeff pointed out that there are Swing and SWT.

On the developer tools front, NetBeans and Eclipse were mentioned as very good Java IDEs that you can get for free. IntelliJ IDEA was mentioned by one of the .NET panelists as a superb IDE. It is interesting to see the nodding of heads from the Java developers in the audience when IDEA is mentioned. I also sensed the unfamiliarity to things like refactoring and intelligent code completion and searching from some of the Visual Studio users.

When the interoperability between Java and .NET question was asked, the standard Web Services answer was given. (About a dozen of the new book from Sun about Java and .NET interoperability is given away at the meeting. I've gotten a copy.) Jeff gave some fair warnings about the pitfalls of the ".NET GUI frontend talking to a Java backend" projects and emphasized that such projects need heavy communication between the .NET guys doing the front end and the Java guys doing the backend. Ted Neward was mentioned as the thought leader for Java/.NET interop issues. An audience member brought up IKVM as a way to make Java libraries available to .NET applications.

In response to a question "I have a .NET product, how do I expand my market to make it available to non-Windows users?" Mark Balbes suggested using VMWare to deliver the application as an appliance.

In response to a query "What happened to Rotor?" David Schmidt mentioned the story about Rotor. Back in the days when Microsoft was trying to make C# an ECMA standard, they contracted another company (Corel?) to implement the language on the BSD platform purely based on the paper specs that Microsoft gave them. Afterwards, Microsoft made the implementation, all 7 million lines of code, freely available with a read-only license. David did not waste anytime in stressing that both C# and the .NET framework are ISO standards while Java was not.

In response to a request to compare Java and C# at the language level, Jeff Grigg used the line "When programming in C#, we Java programmers have to remember to use Capital letters as the starting characters of method names." Everyone agreed that the languages are very similar.

Overall, it was an evening of civil conversations.

Responses[4]

Posted by Weiqi Gao on September 25, 2007 2:34:53 PM CDT #

The St. Louis .NET Users Group will feature a Panel of Local Experts: .NET meets Java event for this month's meeting:

St. Louis DotNet User Group: Are you a Java person and have always wondered what this .NET thing is? Are you a .NET person and never really understood why Java was something more than a drink? This is your night! Come broaden your horizons and learn from our panel of local experts. It should be an enlightening and entertaining evening!

Here are potential panel members listed in no particular order:

• Jeff Grigg - Member of the Saint Louis Java User Group; involved in the java community for the past ten years, professionally in the industry for over twenty years. Experienced in a wide variety of platforms and languages from eight bit CP/M and assembly to mainframes, Smalltalk, LISP, Prolog, Java, VB, .Net and others. Currently working in Java, and always looking for better ways to satisfy business needs for information processing.
• Jeff Brown - Jeff is a Principal Software Engineer with St. Louis based Object Computing Inc. and is a member of the steering committee for the St. Louis Java Users Group. For almost 10 years Jeff has been a Java instructor, consultant and mentor. Jeff is a member of the Grails development team and is speaking about Groovy, Grails and other JVM related technology on the 2007 No Fluff Just Stuff Symposium Tour.
• Adam Esterline - Adam currently works for St. Louis-based Asynchrony Solutions, Inc. developing software in .NET and leading agile teams. Prior to Asynchrony, Adam worked in a range of technologies and industries for the last six years, the latter half of which has been focused on .NET development. During this time, Adam has led teams developing and deploying internet and intranet web applications. Adam also enjoys the give-and-take of the classroom and has taught courses on web-site development, Java and web strategies for the last five years at Washington University in St. Louis.
• Robert Fischer - Robert Fischer has been using Microsoft’s .NET framework since version 1.0 in 2002. He holds multiple Microsoft Certifications. He is also a Sun Certified Java Programmer. He has experience integrating a wide variety of systems using the .NET framework. Most recently, he has been an early adopter and subject matter expert in Microsoft’s 3.5 release.

iBridge Solutions, LLC is sponsoring the “Homecoming Picnic” for this meeting. It's time to send out summer, send the kids back to school and get focused on .NET again!

This meeting will offer an excellent buffet dinner including fried chicken, salad, potato casserole, dinner rolls and cookies for dessert! Great food, great information and AMAZING attendance prizes including a BRAND NEW iPhone and Best Buy gift certificates.

Tell a friend and let’s start out the season with a BANG!

Since this event is being held at a regular .NET User Group location and time slot, I would like to encourage the Java programmers around St. Louis to attend this event to lend moral support to our brave Java panelists.

Add a comment

Posted by Weiqi Gao on September 24, 2007 12:42:53 PM CDT #

Obie Fernandez: I'm not really much into evangelizing Ruby and Rails much nowadays. You know, since we won, I have to admit that it became boring and besides the point. However, this FUDdy discussion on the Hibernate blog got me riled up and I'm in a playful mood tonight. Therefore, mostly for old time's sake, here is a list of the top 10 reasons that anything (and probably everything) related to Java sucks ass in comparison to Ruby and Rails.

... Fuck compilers ... Java Programmers are Morons ... they all suck ass ... Jimmy Gosling? Hahahahahahahaha...

Let me just remind everybody that it's exactly three years ago this month when the Ruby on Rails hype started. With a post like this, the Ruby on Rails hype shall end.

It started with a claim of a ten to fifteen-fold productivity gain, and ended with nothing but name-calling. They have lost it.

All I have to say is that I'm glad I did not jump on that bandwagon.

Have a nice day.

Responses[3]

Posted by Weiqi Gao on September 20, 2007 7:33:57 AM CDT #

In the August issue of the OCI Java News Brief (JNB), Charles Sharp gave a pretty detailed prescription for migrating from JUnit 3 to JUnit 4. Besides the normal "this is what changed" material, Charles also points out some of the new features in JUnit 4.4. One of them is described thusly:

Charles Sharp: JUnit 4.4 introduces a new assert, assertThat, and some assumptions: assumeThat, assumeNotNull, assumeNoException, and assumeTrue. The 4.4 release notes give credit to Joe Walnes for the assertThat assertion mechanism. Those familiar with the jMock project will probably recognize it.

The assertThat assertions require a parameter of org.hamcrest.Matcher type. JUnit 4.4 provides several of these Matcher classes by including a third-party package, org.hamcrest.core as well as including some in the package, org.junit.matchers. According to the release notes, this is the first time a third-party package has been shipped with JUnit. A good start on using this assertion is found in a blog post by Joe Walnes, in which he explains the rationale and intended usage of assertThat.

That's something I would not have paid attention to. If you haven't figured out, I have a tendency to do the old thing. I would have been perfectly happy using JUnit 4 with just the @Before, @After and @Test annotations. Now I'm curious about this assertThat thing. And I wrote the following test:

import static org.hamcrest.core.AnyOf.anyOf;
import static org.hamcrest.core.IsSame.sameInstance;
import static org.junit.Assert.assertThat;
import org.junit.Test;

public class Foo {
    @Test()
    public void foo() {
        Object o = new Object();
        Object o1 = new Object();
        assertThat(o, anyOf(sameInstance(o), sameInstance(o1)));
    }
}

Hmmm, my unit tests can become a lot more interesting.

Got your attention? Go read the whole thing.

Responses[2]

Posted by Weiqi Gao on September 18, 2007 5:27:56 PM CDT #

Alex Miller: I was happy to see that InfoQ took up the JSR 277 / JSR 291 stuff again and did a pretty good job weaving together the recent activity (including my own call to interest on the subject).

...

So I then have to ask whether JSR 277 is re-inventing the wheel (to some degree) only to split the market and hurt the overall community. This is a somewhat rhetorical question of course. I believe that everyone involved here is truly trying to build something great. But sometimes I think we need to step back and see the bigger long-term picture and ask some questions about our goals.

Somehow I feel I've heard this story before:

• Some feature was developed outside the JDK to fulfill a need. And then a similar but different feature is incorporated into the JDK. The first example of such a feature is the Collections API. It offered functionality similar to a commercial product whose name I can't even remember. A second example is the Java Logging API, which in theory should have eclipsed Log4j by now. But Log4j is still being used.
• A component system is introduced into the JDK with the hope that it will create a vibrant third party component market. The promise is always the same: you can go out and buy a commercial package of ready made components and just plug them in to your project and development time will be cut in half. On top of that, you can assemble your applications with a GUI and a hundred drag-and-drop monkeys. The JavaBeans specification is the first attempt at this. (But how many JavaBeans did you buy last year?) The EJB specification is the second example. It is a huge win—for IBM and BEA—for a few years (and we are all saved by JBoss and then Spring and Hibernate). But did anybody sell any ready made EJBs that can be just dropped into any application server and just worked? And did you remember to turn off the light when your stateful session bean passivates?
• And then there is the entity bean vs. session bean story. I've heard this story in one of the earlier NFJS symposiums from Bruce Tate. In the early days of the EJB specification creation, there are conflict proposals for how an EJB should be implemented. One proposal, by Oracle if I remember Bruce's story right, is centered around a relational database. Another propose, I forgot by which company, could be Sun or IBM, has a different proposal that does not involve a database. And the EJB 1.0 specification included both as a compromise. And neither was adequate.
• The Java Generics feature was debated heatedly back in the days just like the current debate, with erasure at the center of the debate. And the wrong side won. As a result, the JDK now contains a Generics feature that is less elegant than the similar feature in C#/.NET.
• The JDO people yelled and screamed at the EJB people when JPA (EJB 3) was being proposed. To a lot of JDO user's mind, EJB 3 was reinventing a lesser round wheel. But EJB 3 prevailed.

I have no doubt that both sides of the current debate are trying to make Java based systems more modular. But I don't know how the current debate will play itself out. I just wish those involved, especially the big vendors (Sun and IBM, etc.) would put the interest of the community in front of the interest of their company and produce something that's unifying and useful.

Responses[7]

Posted by Weiqi Gao on September 14, 2007 8:41:51 AM CDT #

I have heard of the Sapir-Whorf hypothesis in the context of programming languages, usually in the form "Visual Basic will rot your brain" or "Java programmers will never 'get' the beauty of Ruby".

However, I was exposed to a series of social psychological experiments that seem to affirm the hypothesis in the 2003 book The Geography of Thought: How Asians and Westerners Think Differently...and Why by Richard E. Nisbett, a psychology professor at University of Michigan.

The most interesting experiment is the following:

Richard E. Nisbett: We presented participants with sets of three words (e.g., panda, monkey, banana) and ask them to indicate which two of the three were most closely related.

The surprising findings of the experiment (to me, at the lest) is that the answers to the question are dependent on the language the question is being asked in. When I tried a similar question on myself, I did give different answers:

Q: Which two of the three words: panda, monkey, banana are most closely related?
A: panda and monkey.

问：以下三个词中哪两个关系最近：大熊猫，猴子，香蕉？
答：猴子和香蕉。

Both answers, though different, feels pretty natural to me.

How about you? If your first language is not English, would you answer the question differently if the question is translated into your first language?

Responses[2]

Posted by Weiqi Gao on September 10, 2007 8:32:35 AM CDT #