buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Odelya Holiday <ode...@alicanto.com>
Subject Re: Java class is being compiled differently with buildr - java 1.6 than with javac command
Date Mon, 27 Aug 2012 14:35:51 GMT
What do you mean by 

> provided the same arguments are passed in).

?

I am just calling the build command
Odelya

On Aug 27, 2012, at 5:26 PM, Alex Boisvert <alex.boisvert@gmail.com> wrote:

> On Mon, Aug 27, 2012 at 7:11 AM, Odelya Holiday <odelya@alicanto.com> wrote:
> 
>> Hi!
>> 
>> I have the following a java class with the following method:
>> 
>> public class HibernateCampaignDBImpl implements CampaignDB {
>>        private Filter getVIPClientsFilter(Campaign campaign) {
>> CampaignTarget campaignTarget =
>> CampaignTarget.lookup(Integer.valueOf(campaign.getClients()));
>> switch (campaignTarget) {
>> case ALL:
>> return new Filter(); // empty filter (no effect)
>> case VIP:
>> return new Filter("vip", true);
>> case NON_VIP:
>> return new Filter("vip", false);
>> // TODO handle case LIST
>> default:
>> throw new IllegalArgumentException("Unknown campaign clients target
>> value");
>> }
>> }
>> }
>> When using buildr, it compiles the method class, to another sub class:
>> 
>> HibernateCampaignDBImpl$1
>> 
> 
> Are you sure?  javac never compiles method to a different class unless they
> are defined in a separate class.
> 
> 
>> 
>> and fails on:
>> 
>> HibernateCampaignDBImpl$1java.lang.NoClassDefFoundError:
>> HibernateCampaignDBImpl$1 at HibernateCampaignDBImpl.getVIPClientsFilter
>> 
>> However, if I do javac it doesn't compile an extra class - and there is one
>> class:  HibernateCampaignDBImpl for all the code.
>> 
>> 1. Why is the compilation different with buildr? are you using javac?
>> 
> 
> Buildr uses the standard javac.   So the result should be the same
> (provided the same arguments are passed in).
> 
> 
>> 
>> 2. How come it doesn't find the class if it's located in the same folder?
>> 
> 
> I would revisit your assumptions.   Maybe you have an inconsistent set of
> jars on the classpath... or something else... it's hard to tell without
> being able to dig into it.
> 
> alex

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message