The only time I have *had* to resort to using to using a non-Java
library was when I needed to decode MPEG4 video data in an existing
Java Swing application. In that instance there was no suitable Java
MPEG4 decoder library available and I ended up using the native cross-
platform FFMPEG library using JNI.

Since then I've looked separately at changing parts of the application
to use JavaFX and Scala and came to exactly the same conclusions as
Charles. In order to make the integration with Java "nice", you have
to define the interfaces in Java and implement them in the non-Java
language, which often defeats the object of using the non-Java
language in the first place. For me it started to look very much like
integrating with native code all over again. Granted, there weren't
the problems of compiling the library for all the platforms, or of
finding a nice way to package it up, but there was still enough
additional overhead to cancel out the advantage of being able to write
in a different (and more concise) language.

I really couldn't believe that Sun didn't create a simple wrapper
class for a JavaFX Scene that could be used in a Swing application
from day one. It seems they were so busy closing the stable door after
the horse had bolted (going after Adobe Flash), they completely
ignored the audience that was begging to be won over (existing Java
Swing developers). I think the JavaFX language has a lot going for it
but I think it's probably going to be overlooked by most Java
developers in favour of languages like Scala, Clojure, JRuby, Jython,
Groovy etc. because of the way it's been marketed. Perhaps this will
change under Oracle?

The conclusion I came to was that non-Java languages are better suited
to application development rather than library development, unless you
are only targeting consumers using the same non-Java language. If you
want to create a general purpose library for the Java community at
large, you still have to write it in Java, which reinforces the view
of Java becoming the new C or systems level language.

On Feb 16, 5:25 pm, Wildam Martin <[email protected]> wrote:
> On Tue, Feb 16, 2010 at 04:04, Michael Neale <[email protected]> wrote:
> > I could be wrong, but I don't know of any libraries at all myself in
> > common use.
>
> I think to break through language borders and accept the additional
> dependencies coming along with that, there must be really good
> reasons. This applies for Java libaries also I guess. I already have
> chosen to implement a few things myself rather than using a separate
> library. Even worse, when it comes to bigger frameworks. They are
> usually coming along not only with additional dependencies but also
> with additional constraints.
>
> I have seen people writing everything in PHP but to get fulltext
> indexing in their applications they crossed the language border over
> to Java and use Lucene. - And I also seen .NET programmers using
> .NET-ports of iText and the like. There are those big libraries that
> are very powerful in a specific realm. Many of them are in Java. For
> my own needs I would would rather cross border to .NET rather to Ruby
> or Scala for thick client development to get the Windows stuff
> integrated. This because there is (maybe) no other way to get the
> particular stuff baken.
>
> So I think to make me using a third-party non-Java library (JVM or
> not), that library must be really good in doing a particular stuff
> (where no alternative exists in Java) to make me accepting the
> appropriate drawbacks. So the question is rather: Is there an
> outstanding library in a non-java language that can do something
> particular very good that one wants to implement in his application
> "at any cost"?
>
> --
> Live long and prosper,
>
> Martin Wildam

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to