Discussions

News: Sun warms to Dynamic Languages: Summit Held

  1. Sun warms to Dynamic Languages: Summit Held (56 messages)

    A part of the community has been pushing Sun hard to think of Java the platform, more than Java the language. Tim Bray managed to get a summit together with leads from Perl/Parrot, Python, Jython, Groovy, and the Java team itself to really sit down and discuss things. This is a huge leap forward, and there is even early talk on how an opcode here and there could really help out.

    Excerpt
    The Summit Even if Sun didn’t approve of other languages on the Java platform, they’d happen anyhow. I approve, and when I started going around Sun asking, it turned out that everyone I asked did too. So I asked Graham Hamilton, who’s kind of at the centre of the Java universe, if he thought it would be a good idea to bring in a roomful of dynamic-language experts to help us figure out how Java could be made a better home. Graham thought that was a good idea, and also pointed out that since we just shipped the 1.5 “Tiger” release and were early on in the planning phase for the next, right now would be a good time.

    So I talked to Juan Carlos Soto, who’s our director here at Sun’s Software CTO office, and he thought it was a good idea too and agreed to fund it.

    The Players We had, from the Java team, Graham Hamilton, who’s a VP and Sun Fellow and lead architect for J2SE, Gilad Bracha, who handles the language and JVM specifications, and Martin Buchholz, a senior Java maintainer (and at one time XEmacs maintainer).

    On the Perl side we had Larry Wall, who’s currently engaged in defining Perl 6, and Dan Sugalski, who’s writing Parrot, the new Perl VM.

    From the Python camp we had Guido van Rossum, Samuele Pedroni, currently Jython lead, and Sean McGrath, whose company Propylon employs a small tribe of programmers actually building and shipping real Jython applications for real paying customers right now.

    Groovy was represented by its lead James Strachan.

    They gave us a teeny little conference room and it was crowded. I have never claimed to be the world’s best programmer, but it’s not very often that I’m in a room with a bunch of people talking about software issues and they start going right over my head. But that happened a couple of times, which was a problem since I was supposed to be taking notes.

    For a touch of flavor, here’s just part of the list that of things to discuss that Larry had prepared: anonymous code/closures, lvalue methods/functions, variadic call/return, constant/rw/copy/ref/lazy parameters, wrappers/AOP, eval, exception handling/undef/nil/unthrown exceptions, exception handlers with lexical access, temporization/hypotheticality, efficient regex with complete semantics, access to dynamic context/want/caller, redispatch of methods (fallback upon "fail"), efficient switch statement?, versioned modules/classes, virtual classnames, continuations.

    Tim Bray on Dynamic Java

    Great stuff. Let Sun know that you also care about opening up the platform!

    Threaded Messages (56)

  2. Nice, but...[ Go to top ]

    Of course it is nice to use the virtual machine for languages other than java.
    But I guess the true problem of java is not the Java language itself but the restrictions the VM induces - interoperability with systems other than Java - e.g. COM, Win32 etc. is absolutely rudimentary. Java still follows the 'Pure Java' approach - which is nice but often just not not applicable.

    Plus, I think even more languages that do exactly the same thing as java (they are limited to the Java opcodes, so they cannot be much more powerful) is not what we really need - there are far too much languages on the market already...

    It is good to know Java, but which employee cares if you know Groovy?

    /Jo
  3. Nice, but...[ Go to top ]

    I think even more languages that do exactly the same thing as java (they are limited to the Java opcodes, so they cannot be much more powerful)

    Taking your argument to it's logical conclusion, why not write the opcodes directly? My point is, the language can make a huge difference to the speed and ease of development. I picked up jython a couple of years ago, and for many tasks, it makes my life a _lot_ easier.

    If your opinion is based on experience of using jvm scripting languages, I'd be interested to hear more.
  4. Opcodes don't matter[ Go to top ]

    Plus, I think even more languages that do exactly the same thing as java (they are limited to the Java opcodes, so they cannot be much more powerful) is not what we really need - there are far too much languages on the market already...

    To say the (hopefully) obvious: Java opcodes are turing-complete, so you can write any algorithm with Java opcodes that a computer could do in another way.

    Replace "java opcodes" with "pentium instructions" and see what you are saying.

    A powerful language is a language that makes it easier to solve the problems that you want to solve, and that has very little to do with opcodes and much to do with the expressiveness of the language. (for a particular purpose)
  5. No need for such a mess[ Go to top ]

    There is no need for new languages in java platform.

    I've been programming in .net a long time before doing a hello world in java. All i see is a complain vs what dotnet has and java doesn't. It is only in java communities that you see too much benchmarks and polls(.net vs java, etc...)
    One should better look at the best way to achieve his goals by choosing the language best suited for the job. For text processing, the first thing that crosses my mind is perl, not java. For silly/simple GUI, visual basic. For quick and simple webservices .Net, for something more complicated i have to think about perl, php, python,java and others.

        Sure, there are things that can be done in vb, c#, perl that can take hundred lines more in java! Why don't you use .Net then if you want all .Net stuff in java.

    .Net is attractive to people, because it is simple, even a crappy programmer can feel great, a perl programmer can take advantage of .Net features such as web forms, etc... without learning too much. A vb, asp programmer switch to .Net winforms or ASP.net and not java because what he already know isn't lost. JSF is not the perfect answer do .Net web forms. It is coming slow and is not yet really accepted.

       As someone said there are many scripting languages out there. I myself use jelly(from jakarta commons) sometimes, might try out groovy or jython one day.

       The best move i think, would be to see how to call different programming language from java, something like JNI for C/C++.
  6. Follow KISS[ Go to top ]

    IMHO, there no need to juggle all things at once. Just KISS.
    No need for more complicated solutions. I think java universe is already saturated with too many things.
    What programmers/developers want is simple tools to make their life simpler. I think we are going in reverse direction.
  7. Follow KISS[ Go to top ]

    I mean people are laready struggling with speed and good tools (like lightweight and faster IDE). Why complicate further?
  8. No need for such a mess[ Go to top ]

    .Net is attractive to people, because it is simple, even a crappy programmer can feel great, a perl programmer can take advantage of .Net features such as web forms, etc..

    VS.Net is simple (well, not always). .Net is not. Pick the proper Java IDE/APIs and Java is easy too.

    And when something goes haywire in .Net/VS.Net/IIS/... have fun trying to get a good answer.

    Try this in VS.Net - Find all references to a method of an object. And don't include any comments or any other textual references.

    Got more
  9. Re: No need for such a mess[ Go to top ]

    .Net is attractive to people, because it is simple, even a crappy programmer can feel great, a perl programmer can take advantage of .Net features such as web forms, etc..
    VS.Net is simple (well, not always). .Net is not. Pick the proper Java IDE/APIs and Java is easy too. And when something goes haywire in .Net/VS.Net/IIS/... have fun trying to get a good answer.Try this in VS.Net - Find all references to a method of an object. And don't include any comments or any other textual references.Got more

    FYI(For your information)
    I've been programming in .Net, used to work with IIS and know working as a java programmer with Eclipse IDE or text editor+Ant/Maven and most popular tools you might have played/or not with.

    I myself don't find java complicated but ask .Net programmers folks. Ask them if they find good documentation
    (in general) for java projects. Ask your junior programmer to code a Web service, to create a swing GUI faster than a VB programmer for a simple task...
  10. Re: No need for such a mess[ Go to top ]

    Ask them if they find good documentation (in general) for java projects. Ask your junior programmer to code a Web service, to create a swing GUI faster than a VB programmer for a simple task...

    With the right Java IDE they can. (Ok maybe not a simple VB GUI).

    Now ask them to do it without VS.Net or VS6. Ask a senior developer to do it.

    I don't think what you said really disagrees with what I said (I did say that VS.Net was mostly easy). The problem is that VS.Net hides alot from the developer and if they need to anything outside the box - and I end up doing a lot of that - it is very difficult. The time lost there is not worth the easy stuff in the long run. I spent hours yesterday trying to figure out a class not found issue in VS.Net. Oh for a simple classpath. I finally came up with a workaround.

    FYI - I've programmed in VB3-6, ASP, VS.Net, Java, COBOL (plus a myriad of others) - and still am. :)
  11. No need for such a mess[ Go to top ]

    And when something goes haywire in .Net/VS.Net/IIS/... have fun trying to get a good answer.

    I couldn't agree more. This is the biggest frustation I found my self in .NET or MS environemnt. I mean once you stuck some where that needs deep understanding to resolve an issue, you don't find much material on the issue. E.g How security really works in COM+, how .NET interop marshalling works when you call it fom CCW, what are the versioning issues when you call a .NET component from COM etc etc. I amazed lot of time when I searched internet for these issues, no body seems to no nothing for surity, every body seems to have some opinion, if it works for you; you are lucky, other wise keep looking baby. It seems to me things are not properly exposed in MS world when it really comes to nut and bolts of how some thing works. I don't find these kind of issues in Java world, becuase things are quite clear and well explained and almost all of the specifications are public.
  12. I don't find these kind of issues in Java world, becuase things are quite clear and well explained and almost all of the specifications are public.

    I think Java is a completely different beast in this respect. Java is meant to be platform agnostic in most cases, so that means Java's functionality is clearly laid out, so that every platform can conform to that functionality.

    .Net on the otherhand is tied to its platform, and large portions of it's functionality stem from that platform. So if you've done Win32 or rolled your own COM then you'd have a much much better idea of what .Net is doing. It also doesn't hurt to look at the source for the runtime and the class libraries. I think all to often the issue is that many people that come to .Net either come from a non-MS platforms and know very little about Windows. Or, they come from a VB background and know very little about Windows.

    I'd bet that people that come from a Win32 or MFC background don't have a hard time drawing conclusions on how functionality is implemented at lower level.
  13. I think all to often the issue is that many people that come to .Net either come from a non-MS platforms and know very little about Windows. Or, they come from a VB background and know very little about Windows.I'd bet that people that come from a Win32 or MFC background don't have a hard time drawing conclusions on how functionality is implemented at lower level.

    I agree that most of the time this is the case. You learn things on MS platform by trial and error or on your own observation. You can't learn it from manuals. But it frustates senior programmers who just want to get the jist of some thing very fast, not every body (fortunately) coding in the win32 environment, and you don't expect every one to go back 5 years and start learning under the hood of win32 descrepencies; and learn the issues like DLL hell and then start appreciating .NET versioning; unless that is what the genius of MS architects wants:-)

    And yes there is one more thing that make MS platform frustating for learners, and I don't know why I am iterating it again, becuase every boy knows it except MS; and that is the sporadic behavior of windows itself. And even the seasoned Win32 developers are clueless on most situations, if you want I can shed some light on it, but lets don't make this forum a bashing ground on MS platform...
  14. .Net is attractive to people, because it is simple, even a crappy programmer can feel great, a perl programmer can take advantage of .Net features such as web forms, etc... without learning too much. A vb, asp programmer switch to .Net winforms or ASP.net and not java because what he already know isn't lost.

    This quote really made me laugh!! Especially the section, 'even a crappy programmer can feel great'. So by this we can say that crappy programmers feel great when they code .NET but don't feel great when they code something like Java. So I assume your company's interview technique would be along the lines of... give candidate a problem, get them to solve it in Java, ask them how it felt (ohhh... it was horrible!), get them to solve it in .NET, ask them how it felt (ohhhh.... it was great!). Don't offer them the job.

    .NET is a great framework, as is Java - however don't confuse the fact that good software = simple solution, with the statement good software = easy to build.

    Java and .NET are a paradigm shift from VB - equal in size, as one of my previous senior architect's was very keen on telling me. Learning either requires a different way of looking at software, so the whole 'what he already knows isn't lost' is a load of rubbish. If .NET is developed like VB or ASP - why bother writing it in .NET? So you can clog up the already blocked artery of programmers claiming to be able to develop .NET or OO systems - when they only really know functional programming?!

    Don't mean to rant, but I'm fed up interviewing rubbish coders.
  15. A Remarkable Step....[ Go to top ]

    I live in the jordan where most people don't have that free "Computing-Sole". Most programmers here tend to use Microsoft technologies blindly without spending any time to know what other technologies provide for them (e.g. Java Technology for instance).
        Most people I meet use .NET without even knowing what is .NET all about, for instance ask any C# programmer about CLR(Common Language Runtimes) which is a vital part of .NET
    and he will respond that doesn't know what you are talking about.

        The bottonline is attracting people with very weak computer experience and people who are dazzeled with Microsoft technology whould be a huge step for developers freedom of choice.
  16. C#[ Go to top ]

    It would be great if Java platform would support C# and some real dynamic language. I think only C# without .Net.
  17. C#[ Go to top ]

    It would be great if Java platform would support C# ... . I think only C# without .Net.
    Hmm. So basically Java then.
  18. C#[ Go to top ]

    It would be great if Java platform would support C# and some real dynamic language. I think only C# without .Net.

    I can't really see any reasons to support C# in the JVM without the .Net libraries. The differences, in syntax, between C# and Java are minor.

    It would be interesting if the java platform and .Net could interoperate at byte-code level, but this is an entirely different topic.
  19. C#[ Go to top ]

    - Events
    - Properties
    - OUT parameters
    - Overloaded operators
    - Unchecked block

    IMHO, these are helpful features.

    Axl
  20. Sure, the JVM should allow other programming systems. The panel is focused on other languages. I would expand this to other programming systems like rules-based programming (including fuzzy rules), LISP type programming and Prolog type programming. Java is a little behind on the AI/Soft Computing front. I agree it should be a platform. Furthermore, Sun should officially endorse and encourage expansion into well-established AI programming systems.
  21. JRules, JESS & DROOLS[ Go to top ]

    If you are interested in Rule engines for Java, check out iLogic JRules, JESS (The Java Expert System Shell) and DRools. These are all RETE based (and in the case of JESS support for both backwards and forwards chaining) rule engines which run on JVMs.
  22. JRules, JESS & DROOLS[ Go to top ]

    If you are interested in Rule engines for Java, check out iLogic JRules, JESS (The Java Expert System Shell) and DRools. These are all RETE based (and in the case of JESS support for both backwards and forwards chaining) rule engines which run on JVMs.

    Drools has done a great job and the latest beta 18 has come a long way. I would like to point out Drools implements a modified RETE which bob calls RETEOO. From the sound of it, it seems similar to RETEII, which is patented, so I can't make a direct comparison. From what I know, it does sound similar.

    The other thing to be careful of is the manners test in the current beta release is not the same as the original manners test. It is considerably easier and should not be used as a direct comparison to JRules, Blaze Advisor or JESS. It is a useful benchmark to measure drools progress. Eventually Drools will get there, but it will take time.
  23. JRules, JESS & DROOLS[ Go to top ]

    It's "ILOG JRules", but thank you for the mention! JRules JITs high-level business rules (decision trees, decision tables, or IF-THEN-ELSE statements) to Java bytecode. I therefore disagree with the statement (made elsewhere in the thread) that the JVM is for Java.

    I think we're seeing generally that the richness of the JVM instruction set is a key feature for many types of "agile" applications: AOP, scripting, declarative monitoring, business rules etc.
  24. oops, error on my part[ Go to top ]

    I guess I should have been more clear, since not everyone know's this stuff.

    ILog - JRules
    Sandia Labs - JESS
    Codhaus - Drools
    Blaze - advisor

    Errors due to brain (my brain that is) on vacation are common place :)
  25. PHP[ Go to top ]

    Personally I look, longingly, over the fence at the PHP community. They have an incredible number of high-quality applications ready to install (groupware, forums, CMS). Comparatively the Java community hasn't offered much much than frameworks. Now if I could get php to run in an app server and avail of the same services ...
  26. PHP[ Go to top ]

    Personally I look, longingly, over the fence at the PHP community. They have an incredible number of high-quality applications ready to install (groupware, forums, CMS). Comparatively the Java community hasn't offered much much than frameworks. Now if I could get php to run in an app server and avail of the same services ...

    I wouldn't want to have to maintain any of those PHP apps. And since they are open source ... .
  27. also Rulesharp[ Go to top ]

    Rulesharp - Rulesharp Corporation www.rulesharp.com randy
  28. JVM is for Java[ Go to top ]

    I have one simple request for Sun:

    Keep Java Virtual Machine for Java language only and not waste time on scripting languages.
  29. too late[ Go to top ]

    there's already a half dozen scripting languages out there for java. people have been using them for a while already, so it's not new.
  30. too late[ Go to top ]

    I have no problem people inventing new scripting languages and using them. I just don't want that get mixed up with Java and JVM.
  31. Re: too late[ Go to top ]

    I have no problem people inventing new scripting languages and using them. I just don't want that get mixed up with Java and JVM.

    The problem is that there are some basic problems with the JVM that can make developing implementations of dynamic languages more difficult, or at least makes those implementations less efficient than they would otherwise need to be.

    While the JVM is turing complete, it's still basically a stack machine and there are other details that make implementing these kinds of languages more difficult than if you were implementing them on top of a modern CPU architecture. For one, the idea of a "Class" to the JVM may well be different from what a Class is in the dynamic language (particularly if the language supports multiple inheritance). Generic CPU's don't have such high level objects coded into their model like VM's can.

    CLR is facing similar issues.

    If the dynamic language folks can get some tweaks into the JVM that lets them do what they need to do, and if those tweaks don't affect current bytecodes, then more power to them.
  32. too late[ Go to top ]

    I have no problem people inventing new scripting languages and using them. I just don't want that get mixed up with Java and JVM.

    I don't think there's any chance of getting stuff mixed up in the Java language. Its more about making the JVM more reusable to implement scripting languages faster while integrating cleanly with existing Java bytecode.

    Don't be afraid, it'll be fine - Sun's got a very tight reign over Java the language to ensure that noone breaks backwards compatiblity.

    James
    Protique
    Enteprise Open Source
  33. too late[ Go to top ]

    there's already a half dozen scripting languages out there for java. people have been using them for a while already, so it's not new.

    I agree. And at least in theory (I don't claim to be an expert) JVM is language agnostic. You can port languages using the java opcode or instrcution sets if you want to. Yes if you need some tweaking (adding more instrcution sets) here and there do that. But I bilieve SUN should pay more attention on how to make JVM more robust than get into languages issues. Ironically they are spending too much time competing with C#, but they never pick the most important and valuable concept from CLR, the concept of application domain.. In my personal opinion it is very essential to write robust servers..
  34. Are you sure?[ Go to top ]

    Having used application domain, I actually don't like it. Not only do you have to serialize between app domains, but using app domains to load dynamic classes feels ugly to me. Using class loaders to handle unload/reload dynamic classes feels much easier to me, but I'm bias.

    in terms of encapsulating an application within it's own compartment, how is that different than starting two different VM's? I probably don't understand the benefit of AppDomains and the full extend of the usage. When I looked into it, it was to load classes that are dynamically compiled and be able to unload/reload them.
  35. AppDomain + Logical Process Spaces[ Go to top ]

    When I looked into it, it was to load classes that are dynamically compiled and be able to unload/reload them.

    Kinda off topic, but ya asked... so.

    An AppDomain is a logical process space that the CLR creates to host your application. So the benifit comes from the fact that I have have multiple AppDomains being hosted by the CLR all inside one Win32 process. This is help say in a server environment, where I might want to have servaral applications isolated but still running inside one OS process.

    So, yes, that's why everything is serialized when you do cross AppDomain communication, because it crosses over logical processes. The CLR enforces rules on an AppDomain which are somewhat like the rules Windows put on a Win32 process.

    I suppose its funny though because a Win32 process is realy also "logical" since if I have kernal access I can walk over everything in memory regardless of process.

    So, its analgous to each executing Win32 app getting it's own process space, etc.
  36. AppDomain + Logical Process Spaces[ Go to top ]

    When I looked into it, it was to load classes that are dynamically compiled and be able to unload/reload them.
    Kinda off topic, but ya asked... so.An AppDomain is a logical process space that the CLR creates to host your application. So the benifit comes from the fact that I have have multiple AppDomains being hosted by the CLR all inside one Win32 process. This is help say in a server environment, where I might want to have servaral applications isolated but still running inside one OS process.So, yes, that's why everything is serialized when you do cross AppDomain communication, because it crosses over logical processes. The CLR enforces rules on an AppDomain which are somewhat like the rules Windows put on a Win32 process.I suppose its funny though because a Win32 process is realy also "logical" since if I have kernal access I can walk over everything in memory regardless of process.So, its analgous to each executing Win32 app getting it's own process space, etc.

    That description matches my current understanding. So here are my random thoughts on this, some of which will likely be wrong. Having an AppDomain is good because n appdomains != n VM instances. I can definitely see cases where an AppDomain is useful. Say I'm buidling an ASP where I want to host each client's application within it's domain to make sure there's a clear boundary.

    The equivalent to this might be a webapp in a servlet container. Both Appdomain and webapps can be unloaded/reloaded without restarting the VM. Where I fail to see the benefit is outside of an ASP hosted scenario. If I was writing a rich client application, I can't think of a good case for using AppDomain outside of dynamic code.

    Now that there's DynmaicMethod in 2.0, that negates the need to use AppDomain in many cases. In other cases, where you really do consume a XML schema, produce classes and then use the assembly, an AppDomain is still needed. Or if you are actually emitting code and building a new assembly, you'll still need to use AppDomain. This is really a personal preference thing, but a general purpose AppDomain doesn't really seem that useful outside of writing server applications in a hosted ApplicationServiceProvider model. This is my own bias. How do other .NET developers use AppDomain on the client side? I'm asking because I don't know.
  37. AppDomain + Logical Process Spaces[ Go to top ]

    a general purpose AppDomain doesn't really seem that useful outside of writing server applications in a hosted ApplicationServiceProvider model. This is my own bias. How do other .NET developers use AppDomain on the client side? I'm asking because I don't know.

    I have to admit I haven't used AppDomains in production. I just figure appdomains are also helpful for plugin architectures with dynamic (un-,re-)loading --- provided the interface is not too fine-grained. ASP in Java is a difficult beast; it's way too easy to shoot yourself in the foot. I understand CLR goes a long way to really get rid of a domain when asked to. In contrast, in Java, you have no chance to get rid of a misbehaving component, even if loaded in your own classloader. It's easy too leak threads or memory. One hard reference left, and the whole classloader stays around. Bugs like that have haunted Tomcat until very recently.

    Matthias
  38. AppDomain + Logical Process Spaces[ Go to top ]

    a general purpose AppDomain doesn't really seem that useful outside of writing server applications in a hosted ApplicationServiceProvider model. This is my own bias. How do other .NET developers use AppDomain on the client side? I'm asking because I don't know.
    I have to admit I haven't used AppDomains in production. I just figure appdomains are also helpful for plugin architectures with dynamic (un-,re-)loading --- provided the interface is not too fine-grained. ASP in Java is a difficult beast; it's way too easy to shoot yourself in the foot. I understand CLR goes a long way to really get rid of a domain when asked to. In contrast, in Java, you have no chance to get rid of a misbehaving component, even if loaded in your own classloader. It's easy too leak threads or memory. One hard reference left, and the whole classloader stays around. Bugs like that have haunted Tomcat until very recently.Matthias

    You proved me wrong. In .NET, I believe if one wanted to make an application that can dynamically unload/reload plugins, you would have to use AppDomain.

    I'm familiar with the classloader and unload/reload webapp issue in Tomcat. I believe that specific issue of reloading a webapp repeatedly has been fixed. The problem was actually rather complex. I still prefer classloader to DLL, but that's a preference.
  39. AppDomain + Logical Process Spaces[ Go to top ]

    The CLR enforces rules on an AppDomain which are somewhat like the rules Windows put on a Win32 process.I suppose its funny though because a Win32 process is realy also "logical" since if I have kernal access I can walk over everything in memory regardless of process.So, its analgous to each executing Win32 app getting it's own process space, etc.

    And that is why I never understand why we have to go through marshalling and unmarshalling in terms of Appdomains cross calls. Is it becuase of some legacy from the COM+ cross context calls? Can't we use some kind of shared memory approach to shared data between two Appdomains?
  40. AppDomain + Logical Process Spaces[ Go to top ]

    You can share native memory. Or use a memory mapped file, but you'll still end up serializing that way.

    But otherwise there's no way that I know of to share memory between two AppDomains.

    As for their reasons for doing it... I'm not 100% certain. Maybe they wanted to enforce strict isolation rules like they do for processes.
  41. Are you sure?[ Go to top ]

    Using class loaders to handle unload/reload dynamic classes feels much easier to me

    In CLR 2.0, you can load individual chunks of bytecode "functions" into the current app-domain and they are gc'able. Very lightweight and cool. See http://blogs.msdn.com/joelpob/archive/2004/03/31/105282.aspx for example.

    Matthias
  42. Are you sure?[ Go to top ]

    Having used application domain, I actually don't like it. Not only do you have to serialize between app domains, but using app domains to load dynamic classes feels ugly to me. Using class loaders to handle unload/reload dynamic classes feels much easier to me, but I'm bias.in terms of encapsulating an application within it's own compartment, how is that different than starting two different VM's? I probably don't understand the benefit of AppDomains and the full extend of the usage. When I looked into it, it was to load classes that are dynamically compiled and be able to unload/reload them.

    Instead of me reiterate every thing why don't you read this faq http://www.gotdotnet.com/team/clr/AppdomainFAQ.aspx

    BTW running different instance of VM VS running isolated application in a one process (VM) has huge advantage in terms of memory... Think of App domain as leight weight threads with the isolation level of processes
  43. Are you sure?[ Go to top ]

    Having used application domain, I actually don't like it. Not only do you have to serialize between app domains, but using app domains to load dynamic classes feels ugly to me. Using class loaders to handle unload/reload dynamic classes feels much easier to me, but I'm bias.in terms of encapsulating an application within it's own compartment, how is that different than starting two different VM's? I probably don't understand the benefit of AppDomains and the full extend of the usage. When I looked into it, it was to load classes that are dynamically compiled and be able to unload/reload them.
    Instead of me reiterate every thing why don't you read this faq http://www.gotdotnet.com/team/clr/AppdomainFAQ.aspxBTW running different instance of VM VS running isolated application in a one process (VM) has huge advantage in terms of memory... Think of App domain as leight weight threads with the isolation level of processes

    Thanks for the link, I think I read that before, but it doesn't hurt to re-read it. I agree 100% having AppDomain is way better than starting a new VM. the memory requirement for running 10 apps with 10 VM's would be horrible.

    my knowledge of AppDomain is very limited, so any inaccuraries are due to laziness. I'll just apologize in advance.
  44. AppDomains and Isolates[ Go to top ]

    Well, there is ongoing work of adding Isoaltes to Java, see
    http://bitser.net/isolate-interest/

    It was ment to be done in Tiger, but Sun kinda dropped the ball. Now it seems they are half officially targeting Mustang (6.0) release with simple API specification (in Suns 6.0 VM islolate will probably fork another VM), but work is being done on other more exciting possibilities (see research.sun.com, Barcelona project, Muluti User VM), I think SAP has done something within those lines with their new VM/app server. Doug Lea is on board, and a Public review draft is online on JCP, so, cmon, share your thoughts where it counts!
  45. JVM is for Java[ Go to top ]

    I have one simple request for Sun: Keep Java Virtual Machine for Java language only and not waste time on scripting languages.

    Why?

    As someone mentioned above, what you can do with a language is different from how easy it is to do it.

    Regards
    Kit
  46. JVM is for Java[ Go to top ]

    I have one simple request for Sun: Keep Java Virtual Machine for Java language only and not waste time on scripting languages.

    Oh, yes. That is wonderful idea. I fully agree. We should absolutely freeze Java and never ... oh, look, tiger has annotations, just like ... oh, never ... and type erasure, but I guess we can make a little exception ... oh, and of course, having lists and hashes as native would certainly be ... uhhh, say, we are almost to Jython/JRuby/Groovy.

    Excuse me, the heretic police are knocking at my door ...
  47. JVM is for Java[ Go to top ]

    I have one simple request for Sun: Keep Java Virtual Machine for Java language only and not waste time on scripting languages.
    There are plenty of scripting languages available already.

    What troubles me is that it looks like Java heads in the direction of more and more alienating itself from the rest and instead of improving interoperability with other components and technologies it tries (re)implement everything.

    I interpret this as a sign of upcoming announcement of JavaOS as a way to go :)
  48. JVM is for Java[ Go to top ]

    bingo!

    I'd rather see an improvement in interoperability with other systems rather than having to rewrite everything in java. Saying that, I'm not against the idea of scripting languages, it can be much quicker to put some applications together using groovy than it is with java.

    Also, the dynamic loading of scripts is very appealing. As a server side developer, I spend ages waiting for servers to stop and start to see the effects of changes to the classes. I'd like to be able to turn on/off on-the-fly classloading with a single JVM switch.
  49. It would be great if the JVM made it easier for languages like JPython and JRuby to work with the JVM. I like everything about those two languages except that they are not typed. The trade-off required for not being typed in terms of speed and not catching errors at compile time is not worth it.
    If Sun needs to do anything to keep Java from becoming overly complicated it should be more along the lines of removing deprecated classes from Java. The backward compatibility is great but once every ten years Java should clean house.
  50. I have one simple request for Sun: Keep Java Virtual Machine for Java language only and not waste time on scripting languages.

     I can just disagree. Java language (and .Net C#) are "OLD" languajes that still bear the desing issues of C/C++ in many areas. You can't just use it for many IMPORTANT tasks. For example, if you read pythoneers speaking about XML you will notice it is "sinfull" to use in Python. ¿Why?. Because whatever you can do with XML and XSLT can be done with Python, but just much more easely (various orders of magnitude faster). It would be much more productive to use python scripts for deployment descriptors and configuration files than XML in Java/J2EE. It would be much more productive to use Python for parsing/checking input that plain Java (various orders of magnitude faster again). The reason is that Python syntax provides dictionaries, lists and tuples as standar types as well a well tought sintax to work with them easelly -the python tutorial is just a few hours far away to read and you will discover many usefull features on it you just can't get with Java sintax at this moment-. Other script features also provides extra power. (Just see http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/355045 to see how you can prototype and functional spreadsheet in 8 lines of python code -no extra libs, just plain python-). Many other tasks can also be prototyped/developed with scripting languages much more easely and faster than with plain Java (scheduling, text processing or administration tasks come to my mind at this moment but many others exists).

     In think people still have old prejudices against scripting technologies because of the first "old" scripting languajes (perl, basic, cobol, JavaScript, unix shells flavours, ...). But new moderm scripting languajes (Python, Rubby,...) deserve a much more serious treatment. They have no relation with the "old" ones appart from its dynamic language nature and (maybe) slower speed. Just take a look at well known apps developed with Python (Plone, ReportLab, Gadfly, "Google", Mailman, Nevow, Twisted, ...). The change is comparable to the one between first 3Tons unix monsters and new multimedia 1Kg iMacs.

     I also think that for small development groups (3 or less developers) scripting languages ought to be the rule not the exception.
  51. Versioning...[ Go to top ]

    ... versioned modules/classes ...

    May be off-topic... but I think this is needed in Java/JVM. It's one of the things that .Net provides and Java lacks.

    It's common to have problems because different libraries need different versions of a third library.

    Maybe something like RubyGems in Ruby?
  52. Aren't we ignoring some important folks here?[ Go to top ]

    A colleague pointed out the following sad point. I can't say it better so here's the direct quote:

    > Prophets are never respected in there own homeland. Pity they didn't
    > see fit to invite Guy Steele or Dick Gabriel.
    >
    > It is sort of how they manage to overlook and forget the contribution
    > David Ungar made to java by way of Self.
    >
    > Now Sun thinks they know who the dynamic language guys are. Somtimes
    > I really hate those Java guys.
  53. I think this is a great idea. Personally, I have no interest in languages like Jython or Groovy, and I dislike writing in PERL (just not my style). However, the side-benefit of improving the VM to support other languages would be worth it. The perspective gained by getting non-Java languages to work well in the JVM could easily result in a number of improvement that the JVM developers simply would not think of if the JVM stayed pure Java.
  54. Waah?[ Go to top ]

    No ruby guys :-(

    Meatheads who think "Java the Language" is all you'll ever need are living in LaLa land.

    There is a reason that java has java native system programming type libraries ( XML Dom, XSLT etc ) and scripty languages like php/python/perl and ruby dynamically load C/C++ implementations.

    Thats because java is more a systems programming language than
    an application programming language. Nice features like GC and Strings nowithstanding.
  55. And the point is... ?[ Go to top ]

    I guess I don't see what the point is...

    Is Sun just trying to gather more communities and support around Java as a platform? Because I don't see this a giving a Java developer more bang for their buck. Instead it seems like another way for Java to compete with .Net. And give Sun a little more clout by hosting other popular languages like Perl and Python.
  56. Hello,

      allow me to highlight the Java Republic poll asking "What is Your Scripting Language for Java of the Year 2004?"
     
      Nominations include:

      o Groovy
      o Jython (Python for Java)
      o BeanShell (Dynamic Java)
      o Jacl (Java Command Language)
      o Rhino (JavaScript )
      o JRuby (Ruby for Java)
      o Bistro (Smalltalk for Java)
      o Kawa (Lisp/Scheme for Java)
      o Jelly
      o Pnuts

      You can cast your vote online @ http://jroller.com/page/viva/20041210
          
        - Gerald

    PS: You can find last year's results online @ http://viva.sourceforge.net/republic/2004/01
  57. Hi Dion,
    I would recommend one feature which could help java (I am talking of envrionment not the language)to ship some other fields. Java provide System and Runtime components to run any command level operation (e.g. .exe files, .dll etc). I have not been exposed to anything like .dll which can be generated in Java Envrionment reusable in other non java envrionements. For instance, we can argue with Jar Concept but it also do not provide such extensibility as any .dll type concept do.

    So, my point is, Java provide grat feature to call/invoke non java operations (using System, Process and Runtime components), but how about other side of coin i.e. providing platform nuetral components which can be called from C++/C#.

    regards
    Rajeev