We can also see how stable the core is from changes, ie will we keep adding features at that layer - or will it end up being static over time... only time will tell. Obviously if changes/additions are being made, IKVM is by far the easiest way to keep up.
Also, some of the eclipse tooling may be made reusable as an eclipse RCP - which can be jsut a regular install program, nothing java specific. Michael. On 4/21/06, Mark Proctor <[EMAIL PROTECTED]> wrote: > > That sound sensible to me. Get it working first with real clients, and > then when we have resources we start to replace IKVM parts with native c#. > This will also give core more time to mature and stablise before you attempt > the full port. > > However I'm still not sure what the problem is with IKVM, if we are only > talking a few percent here. > > Mark > > Ritu wrote: > > For now I also think that IKVM is the way to go. This will be faster and > won't require a lot of effort. Since we do not have enough resources working > on Drools.NET full-time, it will be dificult to keep up with Drools. I agree > with Denis, that right now having rule authoring support in Visual Studio is > more important than porting the entire Drools from java to .NET. Once we have > a working project that is being used widely then, as Mark said, JBoss could > put a full-time resource on it. Then we can think of porting the entire > Drools to .NET. > > -Ritu > Denis Ahearn <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: > I also vote to continue with the IKVM approach for > Drools.NET. I especially like the fact that by being > based on the same binaries as Drools, Drools.NET > benefits from any new features added to Drools, and > also benefits from all the testing and QA work that's > gone into a Drools release. A native Drools.NET would > have to do all that stuff itself, not to mention the > work required to keep a native Drools.NET in sync with > Drools as it continues to evolve. I would rather see > the extra effort put into things like adding rule > authoring support to Visual Studio, similar to what > the Drools team has added to Eclipse. > > As far as the issue about exception handling being > slower under IKVM, is that really an issue? > Exceptions shouldn't be used for normal flow control. > If a program error occurs, the last thing a user > probably would care about (in my opinion) is the extra > time it takes for the exception handling to execute. > > Denis > > --- Mark Proctor wrote: > > Yes we can turn certain parts of core into > factories, to make it work > better with .Net. One of those will need to be > PackageCompilationData - > which is responsible for the compiled code and > classloaders. Someone is > going to need to do some research on how we can do > runtime compilation > of code, wiring it up via reflection, and then > making sure we can drop > it - without getting memory leaks. I still think we > should leverage JCI > to try and promote a common parser API, this later > work will benefit > other java/c# integration projects. > > 3.0 works much like 2.5. In that we compile a Class > for the rule. Each > predicate, returnvalue, eval and conseqeunce is a > method in that Rule. > Each method then has a generated and compiled > Invoker class. The invoker > class is wired up to the Rule with reflection. So if > I want to call a > consequence I call the Invoker which is generated to > prepare the data > and call the consequence. If I want to drop the rule > I simply delete > those classes and reload the classloadser - all > classes, the byte[], are > in memory, so no disk work. if I update a rule it > drops the classes, > reloads the classloader and then re-wires the Rule. > > Mark > Chinmay Nagarkar wrote: > > I'm sold! :) > > If you really get right down to it, we making a > > design choice with > > incomplete data and no comparitive examples of > > success/failure. > > We have to stay flexible and minimize risk of > > failure (to deliver and > > maintain Drools.NET). Keep one foot in IKVM, one > > foot in .NET. We can always > > shift the weight to stay balanced. > > I feel that continuing interest and coordination > > across the .NET and Java > > teams will be critical. > > -----Original Message----- > From: Mark Proctor [mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>] > Sent: Wednesday, April 19, 2006 8:18 PM > To: Chinmay Nagarkar > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; > > Michael Neale; [email protected] > Subject: Re: .net support > > I've been chatting to the IKVM guys. dynamic > > > classes is a one time hit, > > so no problem there. The overhead is in the > > exception hangling, most > > other areas are fine; .Net has slower exception > > handling than Java > > anyway, IKVM adds further overhead to this. > > However we have minimal > > exception handling in the core runtime which I > > feel is management; > > jereon has shown some ways to avoid the really > > large hits. The one > > caveat, and this is true even with a native port, > > .Net 1.0 has an > > infexible ClassLoader system compared to Java you > > cannot reload classes > > - you have to dump the entire appdomain - which > > isn't doable. .Net 2.0 > > apparently allows you to add/remove methods, so > > maybe we could work > > around that. > > Jereom has more work planned on speed, so IKVM > > will only get better; if > > performance is only 5% on averag worse - I don't > > think that justifies a > > native port - which will be a huge undertaking, > > especially as our > > platform grows. > > Mark > > Chinmay Nagarkar wrote: > > We should investigate moving additional > > code/components to .NET that are > > deemed to be performance killers. Unless that's > > impossible within the > > constraints of the technology and available > > resources, my vote is to > > leverage IKVM. > > > > -----Original Message----- > From: Mark Proctor [mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>] > > Sent: Wednesday, April 19, 2006 1:50 PM > To: [email protected] > Cc: [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: .net support > > I havea updated the blog with some thoughts on > > .Net support and IKVM. > > > http://labs.jboss.com/portal/index.html?ctrl:id=page.default.blog&project=jb > > > ossrules&from=1&link=http://labs.jboss.com:8080/projects/jbossrules/blog/sta > > > tus_of_IKVM_and_Drools.html#http%3A%2F%2Flabs.jboss.com%3A8080%2Fprojects%2F > > jbossrules%2Fblog%2Fstatus_of_IKVM_and_Drools.html > > Mark > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > >
