Develop Reference

Learning Java so I can get at clojure [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a history of hating Java, having used it pretty regularly in the late 90's during the 'slow as balls' era. As such, I never really learned it well. From what I understand, Java is actually a pretty good language to use these days. I've been thinking about diving into it because of Jython and Clojure. That is to say, I'd like to program in Java and use inline Jython or Clojure where appropriate. But truthfully, I'll probably just be programming in Jython/jRuby and calling up clojure from there.
Which brings me to my question. I know both of these languages can be called from Java, but is that necessarily good practice? Should I even bother learning java if I just want to use Jython as the primary language? Seeing as how that's a large part of my motivations here, I'd like to know that I'm not terribly misguided before jumping in. I'm aware there is a very high risk for projects to become a kludge if done in multiple languages like this.
I'm still learning about the JVM and the like, so I apologize if this question is painfully obvious.

Jython can be viewed as a cross compiler from Python to the Java Virtual Machine. As such, to get the most out of Jython you'll obviously have to learn Python, and probably will need to learn Java.
You can skip some of the Java learning, but at the end of the day, Java and the JVM grew up together. That means that Java code tends to lend understanding of the JVM. It is possible to gain understanding of the JVM without Java, but that's not a path well travelled. Any Jython code that imports a Java library will immediately have you searching Java documentation, so if you avoid leaning Java you're going to learn it piecemeal anyway.
You will have to decide if a piecemeal approach or a formal approach is more appropriate for you and your situation. A lot of deciding which path to take is knowing how you learn best.
As far as the "slow as balls" period of the 90's, that's when I was learning Java. Personally, I feel it is better to describe it as "slow as balls if you did incredibly stupid things with Java". Now I think people have built up a sufficient skill set to avoid translating C directly into Java. That said, I do occasionally encounter the 2000+ line method, so perhaps I'm being a bit rosy in my projection. The entire JVM is laid out in such a manner that good object oriented code runs faster, and if you're constantly trying to go to "other" objects for all the data you need locally, you'll just stack thrash the JVM.
Regardless of opinions, the JVM is now the hot Java item. There has been "other language" support by one means or the other for over a decade now; however, the excitement around Domain Specific Languages seems to have sparked an interest in compilation technologies and the JVM. The other languages benefit from the JVM being an easy target to hit with built-in cross platform support, excellent performance, huge availability of libraries, and generally good documentation. Learning Java and the JVM will help you with a lot of the JVM supported languages, as many of them don't flesh out their library space in favour of hooking into a pure Java library.

I'd say it's worth knowing Java even if you plan on only using other JVM languages. I use JRuby and Scala, and have played around with Clojure. If you are building things to run on the JVM, knowing Java is a bit like knowing C when working natively–you don't have to know C, but if you do, you can write the bits that need speed in C and wrap them in a Ruby or Python library or whatnot.
It's worth knowing the basic principles of how Java works in terms of things like interfaces and annotations and how the classpath works because otherwise you are working with basically a leaky abstraction. What happens when your interop isn't very good? This is especially true if you are planning to do Clojure and Jython!
The other reason to know Java is simply because if you are using code in the Java ecosystem, you have to be able to read and write Java. You need to write a library? Yes, you can probably write it in Clojure, but if you want other JVM language users to be able to use it, you should probably have written it in good, idiomatic Java. Scala is close enough to Java for this purpose; Clojure or Ruby or Python, not so much. Just being able to read and comprehend Java programs is very important too.
The other great benefit is simply that you get more libraries and they are better tested. You need a double-ended queue? Check the Java Collections Framework. Good random number generation? java.security.SecureRandom. UIs? Well, Swing, AWT and SWT are... okay, bad example. Knowing the benefits and shortcomings of these only comes from doing some Java programming and learning the various ways not to suck at Java.

From a couple of years experience of using Clojure (plus many more years of Java...) here is my perspective:
You don't strictly need any Java experience to write Clojure code - Clojure is a full language in its own right and you can write perfectly capable programs without using any Java.
You will need to set up the JVM environment - the Java environment has some rules about where code gets loaded from (i.e. the "classpath") that need to be followed to get a working environment. Not a big deal, and most IDEs will do it for you, but it can be a hurdle for people completely new to the JVM world. I'd suggest careful following of the setup instructions for whichever IDE/toolset you choose.
There are some Java-related concepts that are helpful to understand - for example, Clojure harnesses Java exception handling features with (try ... (catch ...)) etc. so it's useful to be somewhat familiar with the Java approach to exception handling.
Ultimately you will probably want to use Java APIs - bacause a huge amount of the value of being on the JVM in the first place is in having access to the huge diversity of libraries and tools that are available in the Java ecosystem. You don't need to write any Java code to use Java APIs from Clojure, but you do need to know enough Java (method signatures, data types etc.) to be able to read the JavaDoc documentation of the APIs and convert this into an appropriate Clojure function call. Often, this is as simple as (.someJavaMethod someJavaObject param1 param2) but sometimes it can be more complex (e.g. when you need to instantiate a subclass of some Java class to pass as a parameter)
Java isn't a bad language to learn anyway - while I'll readily admit Java has some weak points (as do all languages!), it's still a great, simple, high performance, cross-platform, object-oriented language that has a lot of value. Even if you only do a few short tutorials and never write anything substantial in Java, I'd still recommend it for the learning experience.
I believe most of the above would also apply to Jython.

I can't speak for Jython, but if you want to really get to grips with clojure, you want to understand its trade-offs compared to Java, especially wrt memory/gc and the basics of Clojure/Java interop. You also need at least an abstract understanding of how the clojure collections are implemented unless you really don't care about performance - that's not to say that clojure is particularly inefficient, but more the opposite: the implementation of its immutable collections is fairly unique and tailored to clojure's stance on persistence and performance and it helps to understand the underlying details when you're trying to improve on performance issues.
For all of that, I don't think you actually need a lot of Java knowledge. Being able to read Java fairly well, a basic understanding of the concepts, and a knowledge of where to find the documentation is probably enough.
I think if you want to do a hybrid Clojure/Jython project the interoperation details are most crucial. That probably means you have to know in some detail how classes, interfaces, some of the standard library and (to a minimal extend) generics work in Java and how to deal with all of those in your chosen languages since the interoperation necessarily reduces to the more basic Java constructs. Some of this is tricky and can be confusing, and in clojure's case at least the documentation often refers back to Java concepts and documentation for obvious reasons, so you have to make sure you read both, closely.

I would definitely learn java and learn it well, not only because Clojure is built on top of the JVM but also to get anything done you will be calling Java libraries all the time, and you may even need to dip into Java occassionally.
On another note it would be expand your mind to understand Java's OO concepts and pain poaints too and this will enhance your undersatnding of Clojure too.

Above all, study the Java libraries. Part of the joy of using the JVM is having access to "it's already been done" libraries, as well as to parts of the core language that accomplish certain tasks with optimum performance on the JVM. In addition, some languages (e.g. Clojure) purposefully dip directly into Java and don't completely discourage it in your own code, so if you want to be able to read others' code Java basics are a must.
As for the rest of "learning Java" (design patterns, concurrency in Java, etc.), I wouldn't waste your time unless/until specific projects requirements demand it.

Knowing C++, how long does it take to learn Java? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am a competent C++ developer. I understand and use polymorphism, templates, the STL, and I have a solid grasp of how streams work. For all practical purposes, I've done no Java development. I'm sure some of you were in a similar situation at one point when you had to learn Java. How long did it take you to become a competent Java programmer?

I think that learning the language is not difficult. In fact, I used to be a full time C++ developer, and at some point I started writing Java code. But the thing is that I don't remember ever learning Java, so I guess I just figured it as I went. I've been doing full time Java for a long time now.
If you are well familiar with C++, you may want to read a list of the major differences (e.g., everything is dynamically-bound) and then start practicing on an environment (just download Eclipse). The small differences are the main thing you would have to get adjusted to.
Now that Java supports generics, one of the major switching pains is gone. Multiple inheritance, while not supported, is not a big deal if you get used to interfaces, and in fact having interfaces rather than abstract classes with pure virtual functions (PVFs) improves readability.
To me Java is a nice and friendly and relaxing sandboxed version of C++. I don't have to worry about general protection faults (GPFs), I don't have to worry about memory leaks, I don't have to worry about messing with pointers. However, don't let that confuse you, there are still plenty of opportunities to screw up royally, and they're sometimes even nastier to detect.
Just take the leap. If you have the instinct, it shouldn't be a problem.

I went the opposite way. Started with Java, then moved to C and C++. For my own personal experience, it was much easier to learn Java than C/C++ (C++ especially).
Java in many ways is meant to be C++ with many of the undefined and unnecessarily complicated portions removed or simplified. IMHO, it had great success with that goal. As a result it's a very easy language to learn and use. Especially for someone who is familiar with C++.
The actual time it will take is very dependent upon the person learning the language. However, I think it's safe to say it will take less time to become competent in Java than it did in C++.

Shouldn't be too bad. The syntax and classes should be very easy for you to grasp. There are some differences but none of it is too challenging.
The hardest part is more about learning the packages, since those will be different. The built in Java classes and functions, and then to use Java in a practical manner, you'll need to learn J2EE or whatever you might be actually using it for. The latter part will probably take more of your time than the language itself.

If you're already a competent programmer (especially in C++) then Java doesn't take long to learn at all. The books I would recommend (in order) for anyone who wants to learn Java are:
Head First Java
Thinking in Java
Effective Java
You may find that you zip through Head First Java rather quickly, given your experience. For that reason I suggest you check it out of the library and skim it before moving on to Thinking in Java.
Also check out Sun's Java Tutorials.

C++ to Java: 1 week.
Java to C++: 1 month.

As Tom Hawtin wrote, the key issue is how you define competent.
You'll be able to pick-up the language fairly easily, but it's the idioms and the libraries that you will have to learn. And there are quite a few differences between niches you work in (e.g. embedded or enterprise), and between libraries that supposedly solve the same problems. Here are a few examples:
In business/enterprise apps, you generally work with databases. There you can have:
plain JDBC
SQL mapper (iBatis), wrapper around verbose and repetitive JDBC
ORM solution (Hibernate), with a philosophy of it's own
With desktop UIs, you have two competing platforms:
Swing, a part of JRE
SWT/JFace, from Eclispe foundation, originated by IBM, with native UI support
Web frameworks are too many to mention, with different ideas of representing the UI, configuration, folder/package structure etc.
DI (dependency injection) is common in business apps, either by 3rd party frameworks like Spring, or as a part of EJB3 standard. But, I don't think it is ever used in embedded set-up.
It would be fair to say this is just a tip of the iceberg.

Back in 1995 when I did it, it took me about half a day to get comfortable with the tools and basic ideas, a day or two to get the language, a week to get the more obscure parts of the language (there were less of them at the time) and a month to get the libraries (there were WAY less of them at that time).
Now I would guess that the tools and basic language will take as much time, a couple of weeks to a month for the obscure parts of the language (depends on what parts you hit, and when). The basic libraries will be a month to two months (java.lang, java.util, and a few others). The remaining class libraries 6 months to forever depending on what you need to learn and how often the keep updating them :-)

I know C++, and had to work with Java once and picked it up in 2 weeks. Of course there were quite a few surprises but it's easy.

I have C++ background. Picking up Java took me few days - the language seems really simple - at least its basis. I still consult my Java guru - google quite a bit, but it's usually a matter of exploring API and standard libraries. Java has some annoyances, but you should spot most of them them easily and quickly.
I was recommended Thinking in Java (there's an ebook for free), but was never persistent enough to read through it. I don't write rocket-science code in Java and to do it, my skills are sufficient.
Having said that, it would be good to have better formal knowledge of the language. At the moment I'm thinking about studying for SCJP, which seems a sensible way of learning, plus you will get well-recoginized programming certificate once you pass it (I've heard it's not worth much, but still it may be a motivation...).
You can also try Java Black Belt - the answers frequenty surprises me. After taking few tests I wonder how my programs even compile, which suggests I'm probably not the most competent Java programmer around :)

How would you define competent? For my money, most professional (as in they do it for money) Java programmers never manage to reach competent.

These days, a programming language derives much of its power from its libraries and accepted idioms.
While it takes relatively short time to learn the Java language, learning to use the available libraries (collections, io, etc.) effectively will probably take significantly more time.

I think there are two approaches to meaning of term "competent Java programmer".
If it is about lexems, syntax and terms of OOP I began to completly understand Java before 2 (two) days of learning.
But firstly you will be charmed by impossibility to shoot your own leg ;)
But if it is case of embeded class system (i.e. packages), APIs references, tips-and-tricks and etc., it takes about half-year to feel yourself friendly with Java. I think.

I too learnt C++ first and then Java. It took very less time as I was already familiar with OOPS concepts. In the initial phase of learning I was really happy with new concepts in Jave like garbage collector. I referred The Complete Reference by Herbert Schildt and it did help me to get the syntax quickly.

I started from C++ and learned C#/.NET. That didn't take long.
As C#/.NET is developed very near to Java (they used many of Java's base techniques such as GC, reference classes, JIT, ...) I think it is not that hard to learn Java.

I would go with six to eight weeks.

Shouldn't take you more than a day or two to learn the language, but you might have to spend a few weeks on the class library: how to use collections, the concurreny package, reflection, logging, swing/awt, dynamic proxies, MBeans etc.

i learned c++ at a small age of 15 and became a professional software programmer. But when i searched for job there was only job available for java developers.I thought it was hard to change my language.So just for trial i Downloaded java compiler and just for fun typed some code and i found it is not much different than c++. and only after 6 hours of research and learning i became a java developer .so it is very easy to switch between c++ to java.

Open source managed programming languages [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Are there any good, portable, open-source, high-level, statically-typed, imperative, object-oriented, garbage collected, safe languages/runtimes with reasonable performance besides Mono and Java? Mono is nice, but it is a Microsoft technology, and I'm kind of afraid of using it (I'm not sure how rational this fear is). The problem with Java is that it is just too simple (no unsigned data types, no structs, etc.).

Mono isn't a Microsoft technology. .NET is, but Mono isn't - Mono is an open-source implementation of the ECMA-334 and ECMA-335 international standards. Yes, they originated from Microsoft, but Mono itself is not Microsoft technology.
Not that Mono is a language, of course - C# is the language. But then languages aren't really open-source or not - implementations are.
It does sound like you've probably got an irrational fear of C# - and likewise of Java. There are certainly things I'd like to see in Java (and I significantly prefer C#), but it's still perfectly possible to write very significant applications in it.

I'd like to point out Vala, which is a language based on the syntax of C#, but which targets a C compiler (similar to Eiffel) and a lightweight, self-hosted runtime. It lacks garbace collection, though.

Eiffel fulfills all your requirements

On the CLR, there is Boo.
Boo is a new object oriented
statically typed programming language
for the Common Language Infrastructure
with a python inspired syntax and a
special focus on language and compiler
extensibility
The Boo Manifesto is a good starting point.

C++ with a garbage collector? Though you issues with Java are not all that much of a show stopper (unless you can detail why you need those things, on the face of it those arguments are usually not very sound, but sometimes they are).

Well, having no unsigned data type in java is rarely considered as a problem.
But what about Lisp - it was the language to introduce garbage collection, and probably the most powerful language at all.
Check the performance comparison by Peter Norvig (the google's research director). You might be surprised that Lisp beats even C++ in some areas and Java in all.
However Lisp seems not to be a main stream language - I'm wondering why's that?
Because it is kind of minimalistic - it probably could not be beaten in power by any current or future language to come.
(I guess what makes C# or Java so popular is not just the language but the libraries.)

How can you say that java is too simple?
Ok, one of the reasons for developing Java is to make it less complicated than C++ which has a 900+ page of specification. However, it's much more complicated than C.
About 10 years ago I attended a course by Les Hatton and he did research on making your C program safer to use. He argued that almost no-one could remember the 140 pages of C standard, so it would be exceptionally hard to understand something like C++.
Of course, your target may not require safety, but if you do it's something to remember.

scala is less verbose than java and it runs wherever java runs, as it compiles to java bytecode. twitter reimplemented some of their core infrastructure in scala.

There's always Python and Ruby

First of all, Mono is not Microsoft technology.
At second, there are only two serious Virtual Machines (VM) with mentioned features - .Net/Mono and Java. But, setting aside requirement of statically-typed language, you can draw an attention at newcoming Parrot Virtual Machine (Wikipedia article about Parrot).
And, of course, Ruby, Python Erlang, etc. are also crossplatform VM (for single dynamic language)

You may take a look on the D programming language.
But to be honest? I'd suggest to stay away of mono/C#. Why? Many reasons...
Also, for practical puroses take Java or C++.
Java is as good as C# even it is little bit different. C++ is as good as well because 99% of problems of GC are solved using reference counting so...

If you want to learn this in order to be able to be more suited for a job, I suggest you consider either .NET (if you want to go for a Microsoft platform) or Java (if you want to go for platform independence), and do a lot of coding. Both are very large platforms!
Anything else would be niche languages being used in only a few places, which can be very nice but is unlikely to land you a job anywhere but in those few places.

Can Jython replace Java? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
So many server side and the mobile Java applications use the native Java language for Java. Can we use Jython instead to build the enterprise applications, e.g. websites, application servers etc.
Also what do you feel about Java ME applications in Jython.
P.S. Comments on question also welcome.

No, Jython is not a suitable replacement for Java. Consider, for instance, that it provides no way to implement interfaces without writing the interface in Java and then writing a class leveraging it in Jython.
What's needed is a JVM-targeted equivalent to Boo. Boo is a language targeting the .NET CLR which is roughly inspired by Python but not compatible, and which fully exposes the CLR's functionality (thus being feature-equivalent with C#). There presently is no Pythonic language with feature parity with Java -- and such a language would necessarily be incompatible with Python, as Python simply doesn't provide a way to express some of the relevant concepts (such as interface typing information).
Since there have been some questions about this, yet me clarify:
Jython is not a replacement for Java in the sense that you can't take an arbitrary Java project, decide to implement a random subset of that project in Jython instead, and not have anyone else on the development team know or care. Certainly, Jython is suitable for many of the same classes of projects that Java is, except when you're building an interface which will be called from Java, rather than the reverse. Given as "enterprise applications" tend to have a lot of components which operate closely with each other, being able to build a class with an arbitrary external interface is important... and is something which isn't readily done in pure Jython.

It depends largely what your requirements are. All languages have their strengths and weaknesses. There is no perfect language and making intelligent decisions about language choice is an important skill for a programmer.
I disagree with Charles that Jython can't replace Java because you can't implement Interfaces. In dynamic languages, it's seen as a feature that you don't need Interfaces (see duck typing).
Jython takes the great language features of Python and combines it with easy access to huge collection of Java libraries. However it does have a price in terms of overhead, and being a fairly new language you have less programmers and support to back you up.
The nice thing about Jython is that you can rewrite individual modules in Java if performance is a problem. The speed issue is less notable on servers where you can throw hardware at the problem. On mobile phones, performance is still key and I can't see Jython making a big impact there in the near future.
So will Jython replace Java? No, I don't think it will - the momentum behind Java is too great. But we will see increasingly more software with parts written in Jython and other languages targeting the JVM.

No, Jython cannot replace Java, because Python is dynamically typed. Yes, Jython can be used for server applications.
Jython is not good for Java ME, because Java ME has very limited resources. Maybe several years later.
Edit: dynamically typed, not weakly

Yes. The Dynamic languages are the future. I heard this from SUN representatives about one yar ago. The amazing part about Jython is "native" usage of java libraries.
Services and other components may remain in Java but integration layer will move for sure in the dynamic languages direction.
I think Python is natively object oriented like Java that's why they match so good.
I don't expect something like that from other scripting languages like Perl but for sure Ruby and Groovy are also good alternatives.

You can use Jython for that domains.
Obviously, the world for web development is moving towards dynamically typed languages as Python or Ruby. Jython is nice in this domain, since it allows to use the complete "Java stack" (App server, Tomcat, deployment and testing infrastructure,...) in enterprises. You can also implement your business logic in Java.
However, Jython is not a replacement for Java as it is C#. You (may) gain programmer productivity, but you lose performance and compile time checks. The languages are really different and are "optimized" for different tasks. I would propose to evaluate Jython for smaller, non-critical tasks, e.g. by starting to implement some test cases in it.
I doubt that Jython is useful for Java ME development. The reasons are given in the other posts: Resource constraints.

Java Developer looking for a 2nd'ary language to play with [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What is best language to learn next to Java?
Criteria for this secondary language are:
High potential of being the "next big thing". e.g. If the market for Java open positions hypothetically dies/dwindles, what is the next programming language that will have a bigger market for open positions? Another way to frame this question is: If I own a small company that implements solutions in Java, what is the other language that I should use?
Can produce web applications.
Can produce desktop applications.
Easy and fun to learn.
Wide range of available libraries and frameworks (free or open source) that enhance and speed up your solutions.

Python almost meets all of them, but I don't know about being "the next big thing", but hey, Google uses it, and I think its popularity is raising.
It's a scripting language, btw.
I use it for web applications (using django), and you can definitely create desktop applications with it (although I haven't done that myself).
It is easy and fun! (although this is quite subjective, but it's tons easier and "funner" than Java)

For employability: Any of the .Net languages, probably C#. Then you're well set for most potential customers.
For stretching yourself: something functional (F# to cover .Net too?), or something Lisp, or Smalltalk - was once the next big thing but it probably never will be again, but still a language that changed signficantly my approach to programming in other languages.

If you are expert in java, you will probably really enjoy groovy.
It is backwards compatible with java and has a lot of the nice features of ruby and similar dynamic languages. It also has what is shaping up to be a nice rails-a-like in grails, and a good object-relational mapping framework in GORM.
What is really nice about it is you can mix and match groovy classes and java classes. So if you find yourself forgetting the groovy syntax, you can just drop into Java. And of course you can get at any Java library from it. At the same time you can benefit from groovy's really concise idioms for things like Beans properties.
(By the way it meets all your criteria listed above, too)

Learn a language that will probably not be the Next Big Thing™. Learning a new language usually means learning new concepts (unless you learn one that's very similar to another one you already know).
Learning new concepts has great advantages, no matter which language you program in, so it's a pretty good thing to do.
If you limit yourself to a language that's going to be the Next Big Thing™, then chances are that you'll find a lot of familiar concepts and only relatively few new ones (the IT world is conservative like that).
Learn something that looks interesting to you. Not only will you be able to learn faster, if it's interesting, but you'll also have more fun doing so!

How about Scala or JavaScript? Functional paradigms will stretch your thinking further and will be of benefit whether they are "the next big thing", or not.

Go for a different paradigm : functionnal, lisp, haskell, ocaml, erlang, scala, etc.

If you don't have any religious issues with Microsoft, I would argue for C#.
The only downside I can see is that it's not cross-platform. Otherwise it fits your requirements as far as I can see

Your criteria fairly closely matches Python and Ruby, they both have a growing market base in Web development, and are fully capable of producing desktop applications as well. Whilst they are fairly closely matched, Python has a slightly larger library of re-usable code modules, whilst Ruby's strength leans more to it's well-established frameworks.
As a side-note, You should ensure that you don't stop at 2 languages. Start learning a second one, then pick up a third and even fourth as you progress. Learning new programming languages becomes a more trivial task as the general learning curve evens out.

I must second Gilles here; to learn a different paradigm is very rewarding, and functional programming is [not unlikely to be] the Next Thing.
Erlang is great both in flexibility, ease of use (once you grasp the basic ideas) and - the best of all - it it very well suited for the high parallelism of future and current hardware. It also covers all your five criteria, though it might be more of a "server" language than a "desktop" language.
If you are interested, I suggest the book Programming Erlang by Joe Armstrong.

Personally, I'd go with Ruby and focus on running your Ruby scripts under JRuby. this way you get the expressiveness of Ruby with the JVM running your code. I've seen Rails and Merb running under Glassfish. Might seem odd, but you get all the nice instrumentation of Glassfish with your Ruby code. Things like JMX, RMI, etc. work well with JRuby.

Squeak by Example