Correct me if I am wrong, but the current compiler output is all technically legal Java class files, right? In other words, classes/bytecode that can be natively-compiled, instrumented, profiled, obfuscated, optimized (strip of symbols, etc.), even decompiled (as much as it may not make sense to)?
If we switch to a different output extension, we instantly lose all of that support. To me, it makes no sense to be a citizen of the Java platform, yet not try to take advantage of the abundance of Java class files tools available (unless the JRuby compiler output is illegal bytecode, which I don't get the impression of). In fact, I would go one step further and suggest that we produce conventionally named Java classes (e.g. "module/foo.rb" => module.FooJRubyOutput). I seem to recall obfuscator (or some other tools, can't remember) that choke on legal but lower case class names. I would agree with Dean that if there is another compiler coming, switching to a different extension may make sense. However, we should be cognizant of the fact that we will lose all that tooling support. Peter -----Original Message----- From: Dean Wampler [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 8:25 PM To: [email protected] Subject: Re: [jruby-dev] Compile to .rbj instead of .class? FWIW ($0.02??), my feeling is that too many people (or tools) will be confused if they see a .class file and it isn't really exactly that. At least a different extension will help to avoid such confusion. You mentioned plans for a compiler that will generate class files. Will it translate the output from this compiler or be different? If it will be the backend for this compiler, then having a different extension would also help avoid confusion. dean On 10/18/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: Peter K Chan wrote: > Charlie, > So, I see the semantic mismatch, but what is the technical reason for > having a separate extension? > > I see some benefits of using the standard .class extension, such as > being able to compile JRuby compiled bytecode into native code (e.g. using the > JET compiler), or to run an obfuscator on the class files (imagine how > confused if someone were to try to decompile JRuby code to Java...). Besides, > wouldn't this require a separate classloader to load the byte code? But we already need a separate classloader to allow classes to be loaded and defined at runtime (generated invokers, JIT-compiled stuff, etc), so that's not a big requirement. The benefits you state are pretty good ones though...which is why I'm waffling on this. I feel like there should be better identification for the files as being compiled Ruby rather than "normal" compiled Java, but there's not really any good technical reasons for a different extension. It just feels more right to me for some reason. - Charlie --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email -- Dean Wampler http://www.objectmentor.com http://www.aspectprogramming.com http://aquarium.rubyforge.org http://www.contract4j.org --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
