tag:blogger.com,1999:blog-20975090.post8033589621548222311..comments2024-03-11T10:18:55.852-05:00Comments on Headius: More Compiling Ruby to Java TypesCharles Oliver Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-20975090.post-44854301761088257242009-10-23T07:58:05.290-05:002009-10-23T07:58:05.290-05:00I am working on an integration where my JRuby code...I am working on an integration where my JRuby code needs to call Java framework code. A Java framework then needs to load a custom class and invokes method on it. <br /><br />Using compiler2 seemed perfect. I can compile my Jruby code and the Java framework can load the plugin as it is loading any java class.<br /><br />When I tried that, I kept getting 'Illegal type in constant pool'<br /><br />class RcmSyncSource<br /> def helloWorld<br /> return "Hello from Ruby"<br /> end<br /> signature :helloWorld, [] => Java::java.lang.String<br />end<br /><br />java -classpath c:\dev\jruby-1.4.0RC1\lib\jruby.jar;. RcmSyncSource<br /><br />Exception in thread "main" java.lang.VerifyError: (class: RcmSyncSource, method: getName signature: ()Ljava/lang/String;) Illegal type in constant pool<br /><br />I am using JRuby 1.4.0RC1 and JDK 1.6.0_07<br /><br />Looking at the article, I only see the primitive types. Does compiler2 support compiling methods that return java objects? Also does it support compiling Jruby classes that implement Java interface?Anonymoushttps://www.blogger.com/profile/11410629666225339224noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-7113750970570054962009-03-26T16:22:00.000-05:002009-03-26T16:22:00.000-05:00Jonathan: I'd love to have you collaborate on it. ...Jonathan: I'd love to have you collaborate on it. I think I'm going to spin this off as a separate project today so others can start to contribute to it, and we'll plan to just release it as a gem.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-8666849037844205842009-03-26T15:25:00.000-05:002009-03-26T15:25:00.000-05:00This work is fantastic. I've modified compiler2 a ...This work is fantastic. I've modified compiler2 a bit to load up some gems-in-jars and now I've got Ruby files in my Java web service that are being compiled by the same ant task as everything else. <BR/><BR/>What's the work that's required for subclassing, or perhaps I should ask what the strategy is? I'm unsure how one might wrap the Ruby guts to expose a class as anything other than extends RubyObject. I'd love to fiddle around and maybe get onto this work. My dream is to write Wicket in Ruby....Unknownhttps://www.blogger.com/profile/08047039732639435558noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-90096998128583932962009-03-17T18:13:00.000-05:002009-03-17T18:13:00.000-05:00Herve: Hey thanks! Looks good to me!Herve: Hey thanks! Looks good to me!Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-8875740986615290372009-03-17T17:54:00.000-05:002009-03-17T17:54:00.000-05:00I follow you on Twitter regularly but I don't have...I follow you on Twitter regularly but I don't have a Twitter account ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-81157235852981771962009-03-17T16:22:00.000-05:002009-03-17T16:22:00.000-05:00Fabio Kung: Yes, you can add the signature info an...Fabio Kung: Yes, you can add the signature info anywhere, any time in your application, so long as it's present for compiler2 to inspect and emit the Java type information. That's what makes it so much nicer than any options that required syntax changes, "special" structured classes, or offline inspection of an AST to get the compiler information.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-31254098859138145642009-03-17T14:24:00.000-05:002009-03-17T14:24:00.000-05:00Great stuff! Am I able to add signature info later...Great stuff! Am I able to add signature info later, reopening the class?<BR/><BR/>That way, we could conditionally add this information in separate .rb files, only when running on JRuby, to build portable apps.<BR/><BR/>I guess it could be done, as the compiler works with the "runtime version" of classes.Unknownhttps://www.blogger.com/profile/00118441573042961263noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-19025549466620605472009-03-15T11:32:00.000-05:002009-03-15T11:32:00.000-05:00Great work! Yours spurs my enthusiasm too; I can e...Great work! Yours spurs my enthusiasm too; I can even imagine myself working with Java again, after I got bitter over its blown-uppedness.<BR/><BR/>Of course people like me will also start to demand type-inference-assistance further down the road. But given the facility of type annotations that may very well be done by a different project.Seanhttps://www.blogger.com/profile/11775073504625809969noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-64199369973969392412009-03-15T01:13:00.000-05:002009-03-15T01:13:00.000-05:00Daniel: Yeah, I don't think there's even a need to...Daniel: Yeah, I don't think there's even a need to produce a Java class for every Ruby class in the system, and really you don't need to lock yourself into Java types except where you intend to present an API. Of course, I don't see that there are any limitations to this means of compilation, so in theory you *could* annotated every API in your system. But I doubt that's desirable.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-25060746320974509512009-03-15T01:11:00.000-05:002009-03-15T01:11:00.000-05:00JoergWMittag: I sympathize, and that's why I've le...JoergWMittag: I sympathize, and that's why I've left signature specification intentionally vague. The only requirement that would be set in stone is that there be a way for the compiler to get signature data; how that signature data is attached to the class is up for debate.<BR/><BR/>So, for example, someone could take any one of those other type-annotating schemes and tweak them for compiler2. I wouldn't mind at all. The syntax here, with the "signature" method, is just something simple to get the compiler itself working.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-59735926430956150232009-03-15T01:08:00.000-05:002009-03-15T01:08:00.000-05:00dvae: The reflection ordering doesn't convince me ...dvae: The reflection ordering doesn't convince me but determinism does. I'll see what I can do to get the methods generating in the same order every time (probably alphabetical).Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-45227894776439971322009-03-15T00:58:00.000-05:002009-03-15T00:58:00.000-05:00Ken: Not a bad thought. And of course patches are ...Ken: Not a bad thought. And of course patches are accepted; but that sounds like a good way to do it, and I'll probably get around to that soon. I'm really hoping more people will have a look at the code, since it's just Ruby and pretty simple to figure out. tool/compiler2.rb in JRuby repo.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-63089684536432703802009-03-14T22:55:00.000-05:002009-03-14T22:55:00.000-05:00Allow me to suggest that if you want to overload a...Allow me to suggest that if you want to overload a method, you should consider skipping the aliasing, and just do it by providing multiple calls to "signature", for that same method. The programmer will have to decode the parameters themselves, but anyone doing that with Ruby method calls is used to that by now.<BR/><BR/>e.g.<BR/><BR/>class MyRubyClass<BR/> def overloaded *args<BR/> if args.size==0<BR/> #implement the no-args version here<BR/> elsif args.size==1 and args[0].is_a? String<BR/> #implement the String version<BR/> end<BR/> end<BR/><BR/> signature :overloaded, [] => Java::void<BR/> signature :overloaded, [java.lang.String] => Java::void<BR/>endAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-69495658288036349562009-03-13T15:23:00.000-05:002009-03-13T15:23:00.000-05:00There is one thing I am a little worried about: th...There is one thing I am a little worried about: the proliferation of static type annotations in Ruby:<BR/><BR/>While RDoc itself does not have support for type annotations (and its current maintainer has made it very clear that it never will – I believe his exact words were "Over my dead body"), the core and standard library documentation that is part of MRI and YARV, actually includes a lot of static type annotations in a semi-formal, semi-consistent format. See <A HREF="https://GitHub.Com/RubySpec/MatzRuby/blob/ruby_1_8/string.c#L1613-1618" REL="nofollow">String#[]</A> for an example.<BR/><BR/><A HREF="http://WWW.CS.UMD.Edu/projects/PL/druby/" REL="nofollow">Diamondback Ruby</A> uses annotations that are inspired by the RDoc annotations in the MRI core libraries, but are much richer, since DRuby's type system is much richer than the imaginary type system used by the MRI documentation. They also have slightly different markup, to differentiate them from normal RDoc comments. See <stubs/1.8/basetypes.rb#L1102-1104> for the same example as above – note that because of DRuby's richer type system, it only needs 3 annotations instead of 6.<BR/><BR/><A HREF="http://YARD.Soen.Ca/" REL="nofollow">YARD</A> supports type annotations but uses a completely different syntax than MRI or DRuby. Instead, its syntax is essentially the same as JavaDoc's.<BR/><BR/>Then there is <A HREF="http://People.FreeBSD.Org/~eivind/ruby/types/" REL="nofollow">Eivind Eklund's type library</A>.<BR/><BR/><A HREF="http://Blogs.Sun.Com/tor/resource/ruby-types.png" REL="nofollow">NetBeans</A> and <A HREF="http://SapphireSteel.Com/" REL="nofollow">Ruby in Steel</A> actually seem to share the same syntax for type annotations, which is at least a start, although this syntax is different from all the others in this list.<BR/><BR/>And, of course, we have Duby, which differs from the above five versions in that it is not constrained by backwards-compatibility, thus its annotation syntax is actually much nicer since it can afford to be illegal Ruby syntax.<BR/><BR/>Now, JRuby introduces yet another syntax for type annotations, which is actually pretty similar to the type library's, but not identical.<BR/><BR/>So, if I want my code to work with JRuby and DRuby, and want to have nice documentation and IDE support, I need to annotate my methods four times with the exact same type information. I'd much rather have just one annotation syntax. It would be nice if the designers of those projects (and other projects that might be interested, presumably pretty much all Ruby implementations that provide tight integration with the underlying platform like XRuby, Ruby.NET, IronRuby, Ruby Red, but also projects like SWIG and Ruby-FFI, API documentation projects, other IDEs, projects with heavy data marshaling needs like DataMapper, Sequel and ActiveRecord) could come to an agreement on both a unified object model and syntax for annotations.<BR/><BR/>Of course, the best way to solve this would be to add annotations to Ruby, like Python 3.0 did, but unfortunately the specification for Ruby 1.9 was frozen 5 months ago and Ruby 2.0 is still another 5 years or so out. Also, every mention of type signatures seems to be met with a Pavlovian reflex to tell the proponent to fuck off and stay with Java, without even so much as looking at what was actually proposed. (Hint: it has nothing to do with static typing.)Jörg W Mittaghttps://www.blogger.com/profile/00256138278314986180noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-71406255839150942672009-03-13T12:10:00.000-05:002009-03-13T12:10:00.000-05:00I'm impressed! I didn't think there was any way y...I'm impressed! I didn't think there was any way you could create a Ruby compiler which produced real JVM classes. The downside is that I don't think this could be practically applied to *every* Ruby class in a project, but since an API is generally defined by a few "outer" classes, I don't think that will be a problem.Daniel Spiewakhttps://www.blogger.com/profile/17323566514229790079noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-41071527059565883762009-03-13T10:09:00.000-05:002009-03-13T10:09:00.000-05:00The "signature" method is great--no new Ruby synta...The "signature" method is great--no new Ruby syntax, and provides all the hinting necessary (and opens up new possibilities as a bonus).Dave Newtonhttps://www.blogger.com/profile/13420113088393527059noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-52193999437303191292009-03-13T07:51:00.000-05:002009-03-13T07:51:00.000-05:00Your awesomeness knows no bounds :-) Great work. ...Your awesomeness knows no bounds :-) Great work. Looks like a very natural way to add the meta data necessary to interface to the Java world.sundoghttps://www.blogger.com/profile/07992544959392470882noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-18651096927085039192009-03-13T04:03:00.000-05:002009-03-13T04:03:00.000-05:00I think method order is important.Only because a c...I think method order is important.<BR/><BR/>Only because a compiler should be deterministic. For the same input the output should always be the same. Down to the last byte!<BR/><BR/>If not then the md5sum of your project maybe different each time!<BR/><BR/>If you are reliant on hashcode to order, then as some strings may get interned, the order can change.<BR/><BR/>Also note that in Maven 2.0.10, many of the main uses on HashMap have been replaced with LinkedHashMap to avoid non-deterministic dependency orders.<BR/><BR/>Sure it doesn't matter to reflection, and compilation. But why introduce non-determinism when you don't have to?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-43217643212067724412009-03-13T01:42:00.000-05:002009-03-13T01:42:00.000-05:00I think method order is insignificant. You can obs...I think method order is insignificant. You can observe it when iterating over the methods of a class using reflection, but at least for Java the Javadocs explicitly say that you must not assume any specific order.<BR/><BR/>This has bitten me once as IBM's JDK behaves different from Sun's in that place.Anonymousnoreply@blogger.com