El mar, 29-04-2008 a las 12:56 +0200, Alexander Klimetschek escribió: > Am 29.04.2008 um 09:04 schrieb Santiago Gala: > > You might have heard that jython runs faster on C# than natively. This > > is only true for a small microbenchmark. I have tested application > > level > > code and it is 2-3 times slower. > > Then simply use the language with the most optimized compiler for the > JVM: Java ;-) > Basically my problem is having a key resource for a company being a proprietary platform under control of a single provider, i.e., my problem is precisely the use of the JVM while I don't have freedom to implement and release it independently of Sun Microsystems. And, as far as I can tell, OpenJDK is only open if and while it is the one that Sun has the copyright of.
Fight against lock-in in computing has been the leit motif of the last 20 years, and we are getting into a new level. And given the switching costs of programmer/architect training and tools procurement/learning, it is even more dangerous for development platforms than for Operating Systems... > No, just kidding. But using native scripting languages for webapps and > spawning a new process for every request isn't effecient either (see > http://martin-probst.com/blog/2008/04/09/memory-usage-java-vs-rails) > . > > > Yeah, the same used to be said about Windows, IBM or Cobol, back > > when I > > was young :) > > I like cool new stuff. I like Ruby, too. But there are other factors > in the world than pure cool, productive hacking. You cannot simply > replace everything. And there are many ways to make Java better (OSGi > for example). > Productivity is a key concern, specifically for front-end programming, the area where rails or django excel, or where PHP is still leading most of web development. > > I disagree: having each object having writable locations plus one > > writable semaphore/lock for every, say 20 bytes of memory really plays > > very badly with cache coherence and the memory subsystem in general. > > So > > badly that they are rehearsing solutions such as transactional > > memory to > > overcome this severe limitation, one that cannot be solved in the OO > > model of java or C# without basically re-inventing it. > > Hmm, what are you doing? I never came across such a problem in Java. > Webapps in Java can be really fast. > I'm studying and thinking about the long term evolution of computing. With 4 core computers becoming entry level, this is an increasing concern. Take a look into scientific bibliography to know that this is a hot topic. > > We are supposed to be speaking infrastructure here (shindig is an > > infrastructure project, and most Apache ones are too). For > > infrastructure development complexity is not such a big deal. > > No! We are talking about open source frameworks here (and Shindig is a > classic framework, since you will have to plug in your own container > and stuff). And as those frameworks are tightly integrated with your > code, the complexity will meet your code directly - it will mostly be > in the same programming language anyway. And you often need to debug > deep down into the framework to understand problems in your code. > Which is why Open-Source frameworks are so great: the source is > completely open for such activities. > huh? shindig is almost pure backoffice. It delivers javascript and gadget definitions, and provides services for them (proxying, rest calls, etc.) An Apache module would probably be able to do all of this more or less with the same efficiency. Even a thin javascript layer on top of CouchDB could probably do most of an OpenSocial container easily. Gadgets are developed completely independent of shindig, it just serves them, gives (open social) services and proxy their requests, etc. So I don't see it as a framework any more than tomcat is a framework, which it isn't, IMO. > Complexity in a framework (or at least in understanding the framework) > is the major factor for adapting it. Rails is a good example, since > its convention-over-configuration + a whole lot of scaffolding scripts > make it very easy to start. And classic Java frameworks with a lot of > weird XML configurations and thousands of MVC-classes are complex, > because you have to modify so many places. > We are in a different page here, as I don't consider shindig a framework, but a container for service provision. I view data integration as the main way to integrate shindig in any backoffice. > > The ASF hosts a lot of java projects historically, I joined it on a > > java > > project in 2000, so I know about it. Still, ad authoritatem is very > > damaging for computing in general, specially when a language is not > > maintained by the community and hsa the potential of being pulled > > behind > > your legs. We are winning the first battle about having a free > > foundation for computing, with POSIX/linux/BSD (even the proprietary > > OS/X has an almost free foundation. We need to win the next one: > > freeing > > development platforms and languages from single vendor lock in. > > Well, I don't think we have a single vendor lock in with Java. Since > most stuff is outsourced by now and many big companies would give Sun > a hell of a punch to keep working on Java, I don't care about this at > all. > I care a lot. The ASF has been waiting one year for a response from Sun to a contractual issue: http://www.apache.org/jcp/sunopenletter.html and there has been no response to it. And I think that most of the other companies members of the JCP care too. > > Historically make/autoconf/autotools has not been used in java because > > of two reasons: > > Because Java people like it that hidden chars (tabs vs. spaces) are > not crucial for success :-) > Well, I have been already bitten a number of times by native2ascii (Latin-1 in author names in javadocs, basically) to feel java as successful in this area either. As I said, make is routinely used to build The World, I bet even windows and I bet higher about the javaVMs included. > > the java VM is damned slow to startup, which makes > > spawning subjobs very slow, > > That is true. That's why Java desktop apps and browser applets failed > (for consumers). But on the server-side you can leverage the platform > of the VM for longer-running processes. And mvn itself is still fast > enough to be useful. > agreed > > and it doesn't run too well on windows > > without complex extra installs. On top of this, all the linux/ports > > distribution systems are excellent build systems. For instance, I use > > gentoo in my laptop and I build routinely a thousand packages from > > sources, coming from different developing teams (including things like > > eclipse, openoffice.org, glibc, erlang or xorg). The java builds are > > the > > ones giving more problems, typically. I have very few binary > > packages in > > my system: all java VMs except classpath, flash, acrobat, realplayer > > and > > maven, IIRC. I have wondered a lot why maven can't bootstrap itself > > nicely enough to get into the gentoo build system. > > What does the build of maven itself on the gentoo platform say about > maven as a build system? > A lot of people specialized into building from sources can't get a build tool to bootstrap itself from sources... This says something IMO. > > I just rant because I find the "all-the-world-is-java" point of view > > very arrogant and damaging, specially with Sun bullying the Open > > Source > > world and trying to hold Harmony in jail. > > Never said so. But in Java "maven" is a standard - it's not perfect, > but in the end it's better than anything else for building Java. And > it wouldn't be good to force maven for the non-Java language projects > in Shindig - it just has to be integrated. > > BTW, shouldn't there be separate projects for the different languages? > What else besides some static files and Javascript is shared among the > projects? > I don't think anything else, except probably, in the future, DB schemas for services if there are demo service implementations, etc. The way I see it, different language containers would probably be released separately from each other, using a "common" set of javascript and static files and DB scripts or OR mappings for "demo" services. Still having them together eases interoperability testing and ensures common "idioms". Regards Santiago > Regards, > Alex > > -- > Alexander Klimetschek > [EMAIL PROTECTED] > > >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ << > > > > -- Santiago Gala http://memojo.com/~sgala/blog/
