views:

126

answers:

6

Is there anything simple Java can't do that can be done in a similar language or vice versa?

Lets say you have a piece of software in language X and you rewrite it entirely to Java (or the other way around), what are the little things that would seriously hamper the translation?

At first I was thinking of comprehensions or multiple exit loops, but these are easily rewritten with a for_each loop with an if statement and a local variable respectively.

Maybe Exceptions? But which language does not have a similar construct?
Polymorphism? But I don't see how I could show that in a few lines.

I'm looking for a short and sweet example, that would give some serious headache to work around.

EDIT

There are some issues regarding the similarity requirement. I don't think I can explain it better because it is a very theoretic question. The intention was to prevent answers critics would dismiss out of hand because the languages are so different.

For example, I especially like the Lisp conditions answer, although Lisp is a very different language the construct seems similar to Java exceptions but with a twist that cannot be translated. Something like that in C/C++,Fortran,Ruby even, would be even better.

+3  A: 

Normally, you'd never attempt a 1:1 translation. Each language has different idioms, so the same algorithm or program structure might look very different when rewritten "properly" in another language.

That said, I think list comprehensions and other functional concepts are utterly lacking in Java. For example, the idiomatic Haskell solution to this question:

cart = sequence . map (enumFromTo 0 . subtract 1)

That would take many more lines in Java to implement, and that only after you've wrapped your head around how it even works.

Thomas
Functional languages aren't "similar" to Java.
Steve Emmerson
@steve-emmerson Many languages exist that provide functional capabilities while still being similar to Java. JavaScript, Groovy and Scala for example, where similar functionality requires significant boilerplate code in Java but are simple and easily understood capabilities of those other languages. That said, lambdaj has helped Java in this area.
nicerobot
isn't this just a for and an if?
NomeN
@NomeN: No, not quite. An if, two `for`s, and a recursive method, if I'm not mistaken. See also http://stackoverflow.com/questions/2616265/what-do-you-do-when-you-feel-you-need-a-variadic-list-comprehension/2616354#2616354
Thomas
@Steve Emmerson: Sorry, overlooked the word "similar". But @nicerobot makes a good point. I would like to add C# to his list of examples.
Thomas
+1  A: 

C has no concept of exceptions, but you could use setjmp. C++ has exceptions, thankfully. I think anything Java to C is rough (the other way, not as much... though function pointers have tripped up a few people). GObject has been used in C to do OO in C, but really, if you want OO, use C++.

Really the thing that gets you when moving from Java to another language is the library support Java provides. There's a lot of stuff taken for granted.

Also, going from Java to C/C++ requires the coder to do some memory management. You could use boost shared_ptr, but it's not the same, and you still have issues with cyclical dependencies. Consider a bi directional tree where you have cyclical references to child/parent. You need to use weak_ptr in one of the directions w/ boost to make sure things get cleaned up properly.

SB
Also, C++'s multiple inheritance might be something one would have to work around.
Steve Emmerson
+4  A: 

I'm looking for a short and sweet example, that would give some serious headache to work around.

You're looking for a simple example of something that would be trivial in one language and difficult to do in Java?

How about this one-liner of inlined assembly (inside a C program)?

static inline void cpuid(int code, dword *a, dword *d) {
  asm volatile("cpuid":"=a"(*a),"=d"(*d):"0"(code));
}

Good luck Mr Java ;)

Webinator
Note that, sure, you could write some JNI or Runtime.Exec some exe or whatnots. The point is not that it cannot be done. The point is that because it's low-level hackery and Java offers no low-level hackery facility, it's a major pain in the arse to low-level hack in Java: what takes one line of C here would take a *lot* of lines of codes and hooplas in Java. So, for example, writing device drivers in Java is probably not a very smart idea.
Webinator
He specified a language that's similar to Java. Assembly languages aren't.
Steve Emmerson
@steve-emmerson C is similar to Java, at least, syntax-wise, and C provides the capability of inline assembly which is difficult in Java. So @wizardofodds is correct in that respect. In other words, it isn't just this particular assembly that's difficult, it's assembly in general, in comparison.
nicerobot
+1  A: 

What about this:

typedef union {
    struct rgba {
        unsigned char r, g, b, a;
    }
    uint32 packed;
} unpacker;

unpacker x;
x.packed = some_input();
return x.a;

OK, that might still be easy; but try translating java code, that uses reflection to anything else. especially if reflection is used to generate classes on the fly ...

Bendlas
nice one. The workaround would not be too difficult though.
NomeN
+1  A: 

I like the example of unions given by Bendlas for code in C/C++ that doesn't exactly translate to Java. An example the other way around:

   public class example {

      public example(int a, int b)
      {
         ...
      }

      public static void main(String args[])
      {
         try {
           Class cls = Class.forName("example");
           Class partypes[] = new Class[2];
            partypes[0] = Integer.TYPE;
            partypes[1] = Integer.TYPE;
            Constructor ct 
              = cls.getConstructor(partypes);
            Object arglist[] = new Object[2];
            arglist[0] = new Integer(37);
            arglist[1] = new Integer(47);
            Object retobj = ct.newInstance(arglist);
         }
         catch (Throwable e) {
            System.err.println(e);
         }
      }
   }

This uses reflection to construct a Class from a String, which doesn't translate to C++.

Justin Ardini
+1  A: 

It's a trick question: if you identify such a feature, then it just means the other language wasn't "similar" after all!

But if you relax the similarity requirement, the most obvious one to me would be conditions. In Common Lisp, conditions are like a more flexible form of exceptions. You can call a function, which signals a condition (like throwing an exception), but the caller can then say "go ahead and continue anyway". In Java, once an exception is thrown, there's really no way to continue execution at the point of throwing.

(I know I could say "macros", too, but that's an area of CL that's arguably not similar to Java at all.)

Ken
You're answer is best so far. Lisp is indeed very dissimilar, but the construct seems very similar, I will have to investigate this!
NomeN