On Aug 13, 6:14 pm, Casper Bang <casper.b...@gmail.com> wrote: > What I admittedly still don't quite understand, is Charles critique > regarding dependencies on heavy and foreign runtime libraries. The > fact that fcode is transformed to CIL or bytecode natives is just an > implementation detail in my head to make use of the most common > runtimes deployed in the field today. > > In theory, when Fan is finalized and have taken over the world, for > all practical purposes you could strip out all libraries of the > underlying runtime and have Fan emit calls to Fan libraries rather > than JRE/CLR libraries. One would only need library classes when > purposely inter-operating with the underlying "native runtime". Or am > I missing something here?
My point is that we've lost sight of the fact that every Java application on the planet has been grossly bloated up in size by more and more runtime librry dependencies. Some percentage of this is a faling of the JDK to adopt improvements quickly enough (the near- universal presence of JodaTime or ASM, for example), but a growing percentage is the aggregate effect of polyglotism where every additional language drags along its own matched luggage. Now, if we want an app that uses JRuby and Scala, we're pushing 15-20MB of library code just to get started, and that doesn't include any third- party libs for each language that you might want. Add Groovy and you might be close to 30MB. Now deploy that aggregation as part of separate apps to the same application server, so everything has to be loaded for each app. Or try to build an app with any of these languages for a mobile device with memory or bandwidth constraints. And of course this ignores that fact that by building "a better JDK" on top of the JDK for each language, over and over again, we're essentially leaving the evolution of the JDK behind while simultaneously dooming ourselves to forever updating our wrapper libraries to new JDK/JVM releases. This is, in fact, the one place where the CLR/DLR/.NET approach is working a lot better. If it turns out everyone needs a better time library, or if there's a better library that can be interface- compatible with the existing one, it can get incorporated much more quickly. If there are common language utilities that all languages end up needing, they get rolled into a future .NET release. I mean honestly...the list of obviously missing libraries in the JDK is growing steadily: bytecode emission and manipulation (ASM), native library invocation (JNA/JFFI), POSIX filesystem operations (jna-posix or upcoming NIO2), common language interop (Dynalang or similar), annotation processing (apt-mirror-api), and so on. How stupid is it that we all end up shipping the same libraries or rolling our own again and again? - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
