Good enough for me! 1.2 is shaping up to be another great release. Joe On Tue, Feb 17, 2009 at 9:46 PM, Charles Oliver Nutter < [email protected]> wrote:
> I appreciate your position, and I totally agree. Just look at the number of > deprecated methods we have collected. I did a pass during 1.2 to strip that > number down a bit (especially since many were over a year old) but we're > definitely erring on the side of caution when it comes to user-visible > changes. > > In this case, I think it has almost always been a mistake to use "require" > or "load" like this, and in probably every case it would eventually fail in > confusing ways. So I think we're in safe territory here, closing a hole we > never should have left open. > > - Charlie > > Joseph Athman wrote: > >> No, I don't think personally I have any code that would be effected, I'm >> just thinking it might be good to formalize a process for when these kinds >> of issues come up. Since the behavior was never exactly specified I don't >> think this problem can be considered a "bug" that is being fixed. It's more >> of a "this was never good, so now we are completely stopping it". But I >> think it would be nice to give people that are depending on this behavior at >> least 1 official release to fix their code. I'm just trying to be devil's >> advocate a little. >> >> >> On Tue, Feb 17, 2009 at 8:00 PM, Charles Oliver Nutter < >> [email protected] <mailto:[email protected]>> wrote: >> >> Is this going to affect code of yours? I suppose it could be reduced >> to a warning, but it's pretty hard to fix the issue I resolved >> without breaking this behavior. And for what it's worth it was never >> really advocated or recommended, though I know that's little >> consolation. >> >> Joseph Athman wrote: >> >> Is there any way to deprecate the current frowned upon usage of >> require and release a new point release of JRuby before 1.2? It >> seems a little harsh to simply remove something that used to >> work (even poorly) without giving people a nice way of checking >> their code for this problem. Rails seems to do this nicely. If >> you can run the latest minor release of rails without >> deprecation warnings then you can likely upgrade to the next >> major release without much pain. >> >> Joe >> >> On Tue, Feb 17, 2009 at 9:09 AM, Thomas E Enebo >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> On Tue, Feb 17, 2009 at 12:31 AM, Charles Oliver Nutter >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> >> wrote: >> > Stephen Bannasch wrote: >> >> >> >> At 8:38 PM -0600 2/16/09, Charles Oliver Nutter wrote: >> >>> >> >>> I'm working on >> http://jira.codehaus.org/browse/JRUBY-3214 and I >> think we >> >>> need to ratchet down what load and require do when loading >> .class files. >> >>> They've started to get overloaded for loading an individual >> Java class, >> >>> which was never the intended purpose. This generally >> circumvents normal Java >> >>> classloading and classpath and usually causes things to >> break, >> since you can >> >>> easily load in a single class but fail to load its >> dependencies. >> >>> >> >>> So I propose the following: >> >>> >> >>> load and require shall only be used for loading .jar >> files (as >> an analog >> >>> to extensions), .rb files, or .class files that represent >> compiled .rb >> >>> files. >> >>> >> >>> The problem in the bug is that it tries first to do a >> normal >> class load, >> >>> which sees the current directory's "baz" class and loads it >> before the >> >>> "baz.class" in ../foo. When normal Java classloading is >> taken >> out of the >> >>> equation, it works correctly. >> >>> >> >>> This also will affect classloading somewhat; since a given >> classloader >> >>> can only load a given package + class once, and with >> Ruby load >> paths there >> >>> could potentially be multiple compiled .rb files with >> the same >> Java package >> >>> and class, each precompiled .rb file will be loaded in >> its own >> child >> >>> classloader and executed. >> >> >> >> Are you proposing any changes to how require operates when >> loading a jar >> >> that implements BasicLibraryService.basicLoad? >> >> >> >> This service is normally used to add Ruby modules and >> classes. This >> >> technique is used in the java/jruby versions of RubyGems >> like >> hpricot and >> >> redcloth. >> > >> > No, this would remain the same. The only behavior that would >> change is >> > using: >> > >> > require 'some.java.Class' >> > >> > as a way of getting that class loaded and callable. It >> will now >> raise an >> > error saying you should use 'java_import' to load it in (I >> could >> have said >> > "import" but "java_import" is probably more likely to work >> in all >> cases, >> > since rake defines an import method and a few people have run >> into issues >> > with that). >> > >> > e.g. >> > >> > $ jruby -rjava -e "load >> 'build/classes/jruby/org/jruby/RubyString.class'" >> > -e:1:in `load': use `java_import' to load normal Java classes >> (LoadError) >> > from -e:1 >> >> +1 >> >> I am sure someone has tried using it, but for it to still be >> working >> for them they ended up solving the class loading using a >> different >> way. >> >> -Tom >> >> -- >> Blog: http://www.bloglines.com/blog/ThomasEEnebo >> Email: [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> , >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
