Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Java Programming

Don Box: Huge Security Holes in Solaris, JVM 226

Posted by timothy from the so-this-pot-and-kettle-are-in-a-coal-mine-at-night dept.
DaHat writes "Don Box, one of the authors of the original SOAP specification in 1998, now an architect on Microsoft's next generation Indigo platform recently responded to James Gosling's remarks regarding huge security holes within the .NET Common Language Runtime (CLR). Don argues that the same 'flaws' that Gosling noted in the .NET CLR exist both within the Solaris operating system as well as the JVM, both of which support execution of C and C++ code, as well as explaining why this is not necessarily a bad thing."
This discussion has been archived. No new comments can be posted.

Don Box: Huge Security Holes in Solaris, JVM More

Don Box: Huge Security Holes in Solaris, JVM

Comments Filter:

  • On Defense (Score:2, Funny)

    by fembots ( 753724 )
    First instance of Microsoft mehing FUD?

    Next up, Notepad will be the target since it allows any malicious code to be written on it.

  • JNI is an API, not a platform... (Score:4, Informative)

    by patniemeyer ( 444913 ) * <pat@pat.net> on Monday February 07, 2005 @02:46PM (#11599698) Homepage
    Solaris - yes, it's unsafe. That's why my Solaris machine gets attacked if I don't have a firewall in front of it for ten seconds.

    JVM - no, that's safe. JNI is an API, not a platform. For that matter you can say that any language which uses sockets for network programming or can write a file is unsafe. Not to mention that normal programmers never use JNI... It's a very low level integration API.

    Don's comments did not really add anything that wasn't covered in the Slashdot discussion.

    Pat Niemeyer
    Author of Learning Java, O'Reilly & Associates

    • Re:JNI is an API, not a platform... (Score:4, Informative)

      by Rinikusu ( 28164 ) on Monday February 07, 2005 @02:51PM (#11599748)
      Isn't JNI basically what you use when you want to write a "java native" driver for your custom hardware (I'm thinking x10 and what not)? (But then you'd have to port the JNI to every platform you wanted to support, right?)
      • Yes, this is corrrect. The jni allows you to declare "native" methods for Java. This allows you to do stuff like connect to shared memory, process UNIX signals, and do other low-level operations that are platform specific.

        So, you do have to port it, but it's there if you really, really need to do something in C that you can't do in Java.

        As for normal programmers not using it, that's not true. I use the JNI for integrating java with a large software package that's written in C, and runs on AIX or Li

      • Re:JNI is an API, not a platform... (Score:4, Informative)

        by patniemeyer ( 444913 ) * <pat@pat.net> on Monday February 07, 2005 @03:03PM (#11599892) Homepage
        First, technically there's no reason you couldn't build an API allowing pure Java hardware drivers. Sun did it for JavaOS (which apparently went nowhere, but for other reasons). I wish someone would take this idea and port it to Linux, giving us pure Java device drivers.

        But in answer to your question - yes, you can use JNI to talk to unsupported hardware by invoking native routines and, internally, the Java libraries use it to invoke native code on the platform for basic services like talking to the filesystem, sockets, or anything that's not written in pure Java.

        Many people might be surprised though to know just how much of Java is written *in Java*... The vast majority of the APIs are pure Java code. Only the lowest level stuff is delegated to platform specific code. For example, Java does DNS and most crypto in pure Java.

        And finally, most X10 hardware uses a serial API... I have one controlled by Java... also a network of Dallas Seminconductor sensor devices controlled by Java.

        Pat Niemeyer
        Author of Learning Java, O'Reilly & Associates

        • The vast majority of the APIs are pure Java code.

          RTFA:

          In looking at the Indigo code base (which was 1123 C# files as of early last week), only 19 of them use the unsafe keyword.

          Why in the world would one consider the *possibility* of unsafe code in the CLR a security hole? Sure, you can call the use of unsafe a hole. But if (like virtually all .Net developers I know) you never use that, then there's no issue at all.

          Is Gosling complaining that the CLR is so flexible that someone with extraordinary

        • "giving us pure Java device drivers."

          I'm sorry, but that just sounds like a joke...

          I'm not sure though, are you being serious?

        • First, technically there's no reason you couldn't build an API allowing pure Java hardware drivers.

          You are confusing "purity", "safety", and "security"; if you did what you suggest, you would indeed be writing drivers in "pure Java", but if those APIs were accessible, they would undermine safety.

    • Re:JNI is an API, not a platform... (Score:3, Interesting)

      by Anonymous Coward
      For that matter you can say that any language which uses sockets for network programming or can write a file is unsafe.

      Actually, yes that is a true statement which is why the .NET CLR allows you to tweak that out and explicitly deny those rights. (By default these rights are denied for applications running on a remote store.) And, as Don Box said, the unsafe keyword is not meant for daily consumption. To paraphrase, "normal programmers never use the unsafe keyword. It's a very low level integration A
      • the unsafe keyword is not meant for daily consumption.

        Wait... I don't know the answer to this, but - won't all C/C++ code running on .NET be tagged as unsafe? Or is the programmer expected to tag every pointer cast or dereference explicitly?

        Normal programmers do use C/C++ daily... and it is unsafe. I think the point vs. JNI is valid.

        Pat Niemeyer
        • Managed C++ is type and bounds safe. Unsafe C# and/or C++ allow type inference, but not bounds checking, and therefore allow a major class of exploits that aren't possible within the standard portions of the dialects. A call into C/C++ from within CLR requires PInvoke, just as a call into C/C++ from Java requires JNI.

          Normal programmers writing in C#/Managed C++ use C/C++ less frequently than "normal" Java programmers do, actually, because they have access to the intermediate "unsafe" calls, through which
    • And a similar blog entry here:

      http://blogs.msdn.com/adioltean/archive/2005/02 / 07 /368226.aspx

      I am reading now an article in which James Gosling claims that .NET has a huge security hole. The problem seems to be that .NET allows execution of both safe and unsafe managed code in the same process:

      [...], Gosling is concerned about "unsafe" code, which is produced by traditional languages like C and C++. Unsafe code is old code that does not strictly follow the rules of type safety that .NET defines, and thi

      • Re:JNI is an API, not a platform... (Score:4, Insightful)

        by patniemeyer ( 444913 ) * <pat@pat.net> on Monday February 07, 2005 @03:25PM (#11600102) Homepage
        Face it - in Java, whenever you are writing to a file, communicating through a network interface or just handling GUI controls, there is always some unmanaged C++ code being executed in your process...

        Of course... and Java executes RISC instructions that could reveal flaws in the processor design too... but those levels were not written in the course of daily programming. The native drivers in Java are very small (e.g. all of Swing is built on a few AWT calls for opening windows and doing primitive drawing). And those routines presumably get a lot of scrutiny for all kinds of reasons - security being one and performance being another. I have never heard of a common security problem like a buffer overflow in the native libs shipped with Java... It's going to happen someday of course and that's why people created Java and managed code. To minimize the exposure of those regions.

        The futher up the food chain your code goes the more protected it is and the harder it becomes to exploit low level security holes. It's analogous to the way in which you (used to?) gain confidence in the GNU C compiler by having it compile itself and then using the 2nd gen to compile a third... At each step the possibility of simple problems become much more abstract and harder to exploit.

        Pat Niemeyer
        Author of Learning Java, O'Reilly & Associates
        • I understand your point, but I believe that there is potential for many more exploits in Java than you let on. For instance, here's the .so file for the AWT shared libraries on my 1.4.2 JDK:

          3059052 Jun 4 2004 /usr/local/java/jre/lib/i386/libawt.so

          That's 3MB (w/o debug info) of potentially exploitable wrapper code, lots of which depends on complex and (and potentially exploitable) Win32/X/Motif/whatever code. The rest of the shared libs total to about 6MB. Java's native layer is not thin like say, Smallt

    • Re:JNI is an API, not a platform... (Score:4, Insightful)

      by jeif1k ( 809151 ) on Monday February 07, 2005 @03:32PM (#11600158)
      JVM - no, that's safe. JNI is an API, not a platform.

      You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.

      However, the C# solution is better than the Java solution: unsafe code in C# still contains substantially more error checking than equivalent C code linked through JNI, you generally need much less unsafe code in C# than in Java to accomplish the same task, and C# unsafe code doesn't need to be recompiled for different platforms and can just be distributed like other C# code.

      Don's comments did not really add anything that wasn't covered in the Slashdot discussion.

      What do you want? He is responding to an enormously stupid, self-serving comment from Gosling. You have to be clear and keep things simple in order to reach the kind of people who would swallow Gosling's nonsense in the first place.
      • You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.

        You got this wrong too. As Don explained in his blog, if you weren't too busy to have read it, you'd realize that "unsafe" C# is still managed cod
        • It doesn't get "linked" through the CLR's equivalent of a JNI interface.

          Of course, it doesn't get "linked": it's a language construct. That is one of its advantages over JNI: because the compiler and runtime know about unsafe constructs, they can get inlined. Something that may require a complete API and pages of C code with JNI can be done with just a single line of unsafe code in the CLR.

          It's still managed code. There isn't any unmanaged code here to speak of.

          Of course, it's "managed code". Why
    • Not to mention that normal programmers never use JNI... It's a very low level integration API.

      And that's why a whole class of software is not written in Java. Get out of your web services, connect to database world.

      At my previous position, we had a volume renderer that was written in C++, an SDK on top of the volume renderer that was written in managed C++, and applications were written in C#, VB.NET and Python.NET.

      The right tool for the right job.

      Using JNI would have been a pain in the eff-ing ass

      • Actually, when using BSH, it's pretty fun to use it (Java) as a scripting language, and it certainly beats the hell out of JavaScript (or python, but that's just my less te opinion). The JNI interface is pretty simple, but you would have to put it in place of the managed C++ SDK.

        Now if they would only intergrate BSH into Eclipse so you can have completion etc. etc. as well.
  • I can see it now..."Bugs deserve rights too!"

  • I don't think anyone really read what Gosling said (Score:5, Interesting)

    by Anonymous Coward on Monday February 07, 2005 @02:52PM (#11599752)
    Are we just going to have this continuing debate in which every side is inaccurately reduced to one slashdot-blurb-sized sound bite?

    Anyway, JNI doesn't need to be a security hole of the sort Mr. Box mentions; one can concieve of a Java VM which disallows unsafe JNI code from touching the memory of the bytecode-verified safe code, by partitioning JNI execution into a separate process. In fact at least one such JVM implementation exists already. [sun.com]
    • A brilliant point... except that a) the real problem isn't the JNI code messing with the VM, and b) you can do the same thing with .NET.

  • Standards (Score:3, Funny)

    by davidstrauss ( 544062 ) <david&davidstrauss,net> on Monday February 07, 2005 @02:52PM (#11599763)
    Is this the new Microsoft Box model?

  • here we go again.... (Score:5, Funny)

    by kevinx ( 790831 ) on Monday February 07, 2005 @02:53PM (#11599773)
    is this one of those, "your hole is bigger than mine" arguments?

  • FUD (Score:5, Informative)

    by micromuncher ( 171881 ) on Monday February 07, 2005 @02:55PM (#11599792) Homepage
    To use JNI inside of an applet, it needs to be signed with the DLL/shared library pre-installed in lib. So, the topic of "Huge Security Hole in Solaris and JVM" is alarmist and FUD, considering that to get outside of the sandbox, you need to jump through serious configuration hoops.

    • Re:FUD (Score:2, Informative)

      by Anonymous Coward
      You can't use Unsafe/PInvoke inside a .Net hosted control (applet) unless permissions have been explicitly granted beforehand.

      So to get outside that sandbox, you need to jump through configuration hoops.

    • To use JNI inside of an applet, it needs to be signed with the DLL/shared library pre-installed in lib.

      And the equivalent is true for C# "unsafe" code: there are restrictions on where it can be run from and what can run it.

      So, the topic of "Huge Security Hole in Solaris and JVM" is alarmist and FUD, considering that to get outside of the sandbox, you need to jump through serious configuration hoops.

      The FUD is the nonsense Gosling was spewing about C#. Box is responding with hyperbole (he says so expli

  • This just in! (Score:5, Funny)

    by kiwidefunkt ( 855968 ) on Monday February 07, 2005 @02:59PM (#11599842) Homepage
    This just in: Programming languages are insecure. They allow third parties to run arbitrary code on your processor.

    Microsoft will be releasing a patch which fixes this problem soon. Stay tuned.

  • Yawn! (Score:2, Insightful)

    by Z00L00K ( 682162 )
    This seems to be a shit-throwing contest more than actually trying to figure out means to manage security issues in platforms.

    Programs will have bugs, regardless of what programming language that is used, since it always comes down to machine-code or even microcode in the end, and it's not easy to test a large software package for all possible permutations.

    The only way around this problem is a layered security approach, which means that breaking one layer will not cause any critical effects. Unfortunate

  • Inaccurate comparison (Score:2, Informative)

    by shlong ( 121504 )
    Saying that the JNI exposes Java to the same C/C++ flaws as .NET/CLR is techinically true, but not very accurate. JNI was added to Java purely to allow the JVM to operate as a browser plugin. It wasn't something that Sun really liked or wanted to do since they really wanted Java to be a better, safer, and portable language. I think that this point was even discussed in some of the early books on JNI.

    Microsoft, however, is actively looking to extend the CLR with a JNI-like interface. Why? To make it e

    • Inaccurate Inaccurate comparison (Score:5, Informative)

      by steve_l ( 109732 ) on Monday February 07, 2005 @03:25PM (#11600105) Homepage
      JNI is the second edition at a Java to C++ API. It is the underpinnings of every binding from Java to platform there is, not an afterthought for applets (though Netscape were involved). If you don't use it much in your code, it's because other people (i.e Sun) do it for you. They also go out their way to make it hard to do so, whereas MS, with P/Invoke and COM support, make it really easy to invoke native code *from trusted apps*.

      Most .NET code that I know doesn't use unsafe either: MS go out their way to discourage you. You have to compile as unsafe, grab pointers only briefly, and then only ever get to run if your code came from a trusted place. All remote code is blocked, even that on a network share.

      Where MS do care is about COM integration, about platform integration. True, there is only one platform they care about, Windows.

      But consider this: Integration between Java and Linux, especially the GUI, sucks. Want decent Java/Gnome bindings? You need the third party Java-Gnome libs, which use, wait for it, JNI. Want Java KDE bindings, go to KDEJava and get the java libraries plus native code. If you want to integrate with the OS, you need native code, which means JNI.

      The fact that JNI is pretty rare can be seen by the fact that Gnome, KDE and drag-drop integration with the rest of the Linux GUI is pretty much nonexistent.

      I think the FUD Sun are saying about "unsafe" is so bogus. If they want to slag it off, just pick on the .NET APIs, too much of which are thin wrappers around Win32. OR the fact that the .NET runtime needs IE6 installed, and IE6 is the web browser component for .NET apps. OR the fact that ASP.net is built on IIS. Those are security holes. Windows is a security hole. ActiveX is a gaping security hole. IIS is server side disaster. .NET is actually pretty secure, but its just damage limitation on an otherwise dangerous piece of junk. Its like having ABS brakes on a Ford Explorer; not enough on its own to stop you crashing and burning horribly.

      • just pick on the .NET APIs, too much of which are thin wrappers around Win32

        Hey, it beats having GUIs that look like ass and are sluggish (Swing).
      • True, there is only one platform they care about, Windows.

        Yeah, which is why they're implementing all those proprietary technologies like XML, XSLT, SOAP, Web Services and other industry-standard protocols to lock everyone else out.

        Yes, that's sarcasm.

        If they want to slag it off, just pick on the .NET APIs, too much of which are thin wrappers around Win32.

        Too true, but they've got to start somewhere and their "progress" with Longhorn, and their real progress with ASP.NET 2.0 shows they are eliminat
        • OR the fact that ASP.net is built on IIS.
          It's not built on IIS at all, it's built on an ISAPI .DLL called aspnet_isapi.dll. The code for this could be quickly adapted for any other platform (assuming it was open sourced/completed by MS).
          Actully, it's not built on either. ASP.NET can easily be hosted natively within any process you like (including Cassini and Apache) without the need for wrapping the ISAPI dll.

  • Why "managed" == "denial" (Score:5, Insightful)

    by Concern ( 819622 ) * on Monday February 07, 2005 @03:15PM (#11600006) Journal
    When .NET was first announced and the details began to be known, there were a number of lively discussions here about it. The "feature" of running unmanaged code was hotly debated, but the debate seemed to me to be entirely one-sided. It seemed clear unmanaged code is another classic Microsoft mistake - trading sugary convenience today for billions in headaches for their customers tomorrow. I went looking for someone to convince me otherwise and didn't succeed. Maybe now?

    There is great value in a "managed" system like the Java VM. It gives us an extraordinary amount of safety that we are frankly unaccustomed to. People are still gradually learning how to think about it, but you see more and more security-critical projects going "Java only" as they figure it out.

    There is also obviously no way we can do everything that way. For hot code, we work at lower levels, put in more work, and (for now) accept the additional risks. Note that the constant stream of ugly worldwide security problems is gradually but now noticeably decreasing our apetite for doing everything that way.

    As far as I can tell, by allowing unmanaged code in the runtime, .NET gives you only the worst of both worlds.

    You get all the overhead of the VM, but you don't really get safety.

    I know perfectly well you can tell the .NET runtime not to allow unmanaged code. That doesn't matter, because the choice is there, "unmanaged" is still a huge problem.

    Either it is avoided by everyone (everyone recognizes that it's a mistake), or we all begin to use it (it's in XYZ library), and then we all end up allowing unmanaged code, and we are no longer safe.

    • I write a lot of C#, and I almost never use unmanaged code.

      But sometimes I do. I would start far fewer projects with C# if I couldn't be sure I could get out of that particular straightjacket.

      That being said, I am starting to have my doubts about writing huge programs without giving a thought to memory management. It is fun, and it is fast, but there is no way back...

    • You make some good points. Nobody does use unmanaged BTW, its just too painful. There is one thing wore than it: managed C++.

      One thing though, neither Java or .NET have any notion of tainted data. all this security stuff does is let you run untrusted code in a sandbox, or trusted code in a secured zone to slightly limit the damage it can do.

      But neither language has the idea of marking strings or other data that came from an untrusted source, the way Perl does. Which is odd, as both Java and .NET have so f
      • But neither language has the idea of marking strings or other data that came from an untrusted source, the way Perl does. Which is odd, as both Java and .NET have so far succeeded server side.

        Why bother with tainting when you can just do rigorous validation with things like struts? It's been quite a while since I've seen a bug related to inappropriate input handling, and that was in a perl script.

        Compared to Perl, Java is insecure as you can too easily fall to a SQL string attack, either in your web pa

        • Why bother with tainting when you can just do rigorous validation with things like struts?

          Why bother with that when you can do rigorous validation of data without a managed VM?

          Here's a little thing people seem to be forgetting: buffer overruns and smashable stacks aren't being written by applications developers. These vulnerabilities are found (increasingly rarely) in core libraries. Check bugtraq and vulndev: most exploits being found now are not overrunnable buffers and such; they're SQL insertion and

          • Yes, you're right. However, I think part of the parent post's point is that in Struts (and other frameworks), the framework has made it dead-easy to do this validation. Trivial, really. And every book and tutorial I've seen covers it, so really - there's no reason not to do it, even within the managed VM.

            However, per your example, and my experiences, doing the same rigorous validation and manipulations in C is painful, quite.
      • you're correct. but .NET does allow you to have many AppDomains in a single process, each running with different code access security permission sets. One AppDomain could be allowed to write to the local drive, whereas you could load code from the network and run it in an AppDomain that's not allowed to write locally (or only write to temporary storage), run unsafe code, or whatever, depending on the permissions you give it.
    • There is great value in a "managed" system like the Java VM. It gives us an extraordinary amount of safety that we are frankly unaccustomed to.

      Which I'm guessing your misinformation leads you to believe that .NET doesn't afford?


      There is also obviously no way we can do everything that way. For hot code, we work at lower levels, put in more work, and (for now) accept the additional risks. Note that the constant stream of ugly worldwide security problems is gradually but now noticeably decreasing our apet
      • I'm sure you'll gloat about...

        Relax.

        Try running an assembly off a remote store or even run a method through a remote channel.

        I'm aware that the default security configuration in .NET is not Pants Down for remote code.

        I don't want to confuse "attack" with "mistake." What about problems in local unmanaged code that we wrote ourselves?

        Unmanaged isn't any different than writing a program and using JNI to talk to it.

        I don't know how good a comparison this is.

        Any VM must use "managed" code to interfac
    • You seem to have missed the entire point of this article, which is that .NET's unmanaged code facilities are no worse than Java's JNI. Which is probably true. Both allow you to interface unsafe code with safe, but the use of both is disallowed by the environment you typically run untrusted code in when using the platform.

      I fail to see the problem.

  • Hmm.. (Score:5, Funny)

    by vurg ( 639307 ) on Monday February 07, 2005 @03:21PM (#11600066)
    So when will this become a serial exchange of yo momma jokes?

  • Whiny (Score:5, Funny)

    by 5n3ak3rp1mp ( 305814 ) on Monday February 07, 2005 @03:31PM (#11600155) Homepage
    I can't help feeling that some small percentage of this type of back-and-forth is something like a junior-high whiny geek arguing about how the Micro Channel bus architecture is better than ISA and that , incidentally, Apples are utterly irrelevant. ...Oh, wait. That geek was at one time a friend of mine, and this was circa 1985, and this was an actual discussion. ;) (hi, don ulrich! i still use a Mac, and Apple still exists! where's your precious PS/2 micro-channel NOW?!?! nyaaah, nyaaah!!)
    • Did any Mac in 1985 even have an expansion bus?

      I'm not including the XL because it was a Lisa not a Mac, and the Lisa expansion slots were more useless then than ISA is today.

      I'll agree with your main point, though.
      • Yeah, there was no Mac expansion bus until NuBus with the Mac II in '87. (I've seriously been using Macs consistently since the 128k Mac Plus in 12/84.) But my friend's point at the time was along the lines of, "Only REAL computers have expansion buses". My retort of "Duude, but you have to check out this mouse thing, and the windows and menus. And it has a 4 VOICE DIGITIZED SOUND chip!" seemed to fall on deaf ears because it wasn't as buzzword-friendly.

        Even at the tender age of 11-12, REAL geeks are alr
    • Being superior in terms of technical specifications, and market forces, are very different.

      Microchannel Architecture was a 32-bit bus far ahead of its time, it was very fast, but IBM kept the specs so tightly controlled that MCA devices were expensive as hell, and as a result, not widely produced.
      • I totally understand. But while my geeky friend was blabbing about MCA, I was trying to convey my awe because the Mac OS (at the time, and before the onslaught of nubile women started beating down my door*) was THE MOST AMAZING thing I had ever seen in my entire short life. I mean literally, this thing existed when green-on-black terminal-esque interfaces were still in vogue (think: IBM PC XT with DOS)

        I guess I got "Steve'd" REAL early on ;)

        *slight exaggeration

  • Neither is really a security hole.... (Score:5, Interesting)

    by Jaime2 ( 824950 ) on Monday February 07, 2005 @03:46PM (#11600301)
    Let's take a look at how each technology can become a security hole: By remote execution of content presumed to be in a "sandbox".

    .NET: Since unmanaged code is turned off by default for remotely loaded code, it will not be run by an unexpected trip to a web page.
    Java: Since JNI won't work by default under the same circumstances, the newest virus won't be injected into your system by an evil web page.

    Anything else is simply an architectural choice. MS likes to preserve compatibility while allowing you to move forward as quickly as posible. Sun wants you to rewite stuff in Java (for the most part), so the new stuff is more secure, but there will be more old stuff floating around that is still unsecure because we won't yet have found time to port it.

    BTW, Code Access Security in .NET is sophisticated enough to allow some apps to use unmange code, but not others, or some users, or software from a certain publisher, and a bunch of other options as well. You don't have to simply "turn on unmanaged code". They even have a simply way to allow software publishers to communicate these settings to customers instead of letting Joe Blow admin decide to simply turn off security to make it work.

    In summary, both technologies allow you to blow your own foot off if you aim the gun properly and squeeze the trigger. So what -- we were allowed to do that before these technologies came along and preventing you from being able to blow your own foot off will only slow adoption and cause more feet to be blown off.
  • Some people just have to do low-level stuff in a high-level application. People can write malicious code for that, but that's the price you pay.

    The little bit of C# I've looked at has shown that .NET does a lot to reduce the amount of old-fashioned pointers you need. Most of that has been wrapped up into things like references and delegates, which can be tracked and managed.

    They could have also prevented C++ from coexisting with the .NET framework, but I think that would have reduced a huge selling p
    • It's integration that's the difference. And to my mind .NET comes off much better. Because like it or not, you will need to use raw C at some stage, and if you can put it directly into your application, you're less likely to make a mistake passing things than with JNI. It feels strange to be rooting for MS, but in this case they really are the better option.

  • Ah, yes... SOAP... (Score:2, Interesting)

    by Anonymous Coward
    "See, it's XML over HTTP, so no need to change your firewall configuration". Security? Ah!

    And Microsoft bought into it because they needed something to interoperate with the rest of the world, and they couldn't do a 180 and use CORBA without "looking bad".

    And now we get that XOP turd (discussed here [slashdot.org] [slashdot.org]), because somebody wisened up and realized that XML was just bad at byte framing, and, yes, we need binary data.

  • From the 'Yeah, well, duh!" department (Score:3, Interesting)

    by scovetta ( 632629 ) on Monday February 07, 2005 @04:06PM (#11600493) Homepage
    JNI is an absolutely necessary part of Java. How do you think System.out.println() really works? Down through the (many) layers of calls within standard Java classes, you eventually get to a JNI call. In fact, without JNI, Java wouldn't be able to access the network, files, console, etc. It's like saying the keyboard is responsible when you type format c: (or when you click-click-click for the younger generation).

  • C++ support in Java vs .NET (Score:5, Interesting)

    by DrXym ( 126579 ) on Monday February 07, 2005 @04:21PM (#11600643)
    Yes Java supports C++ native calls, but look at how bloody painful it is to do it. You have to define an interface, run it through a stub compiler, implement the stubs and use helpers to marshal types back and forth between C++ and their Java equivalents. It involves lots of files and lots of fiddling about.

    The consequence of this is that no-one uses JNI unless they absolutely positively have to. It's a pain and life is much easier if everything is in Java. Thus with the exception of a few esoteric things such as SWT, most libraries are pure and portable.

    Now contrast this with .NET. Writing native C++ and wrapping it in a garbage collection safe class involves no stub generation and can be done in a single file - the assembly info, interface and gc wrapper can all be specified in situ. Consequently it's a lot easier to pull C++ into a .NET application. MS DevStudio 2003 even has wizards to do it. It is also a lot easier to call DLLs and ActiveX from .NET since MS provide PInvoke and COM Interop to do just that.

    Now on the face of it, this is all well and good, especially if you have a lot of legacy crap to port. But by the same token it means many more .NET apps are tainted than on Java. The problems this causes for portability should be obvious.

    And this is called "Microsoft having their cake and eating it". They can expound portability and present the facade that .NET is cross-platform, when in reality they provide tools and wizards to ensure it remains anything but. Apps that are infested with native instructions and OS-specific calls are by definition unportable.

    Mono demonstrates the problems faced in porting .NET to other platforms. Mono must literally pull in the whole winelib in order to cope with the number of tainted .NET apps that attempt to call out to Win32. And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).

    And I don't see the situation getting any better. Perhaps if Mono gains momentum it might put the brakes on tainted code, but there is a long way for that to happen. I believe the only way Mono is going to make an impact is if ships with a cross-platform IDE with tools that default to its open source stack. This is almost a reality since ICSharpDevelop & MonoDevelop are both fairly complete IDEs but there is nothing yet which defaults to the open source stack and runs on all major platforms.

    • And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).

      From the Darwine FAQ [opendarwin.org]:
      It means that WineLib is now working on Mac OS X, and that developers should be able to recompile their Win32 Apps using WineLib and make them work in Mac OS X.
      • I know about Darwine (hence the for now in my original post), but this project is only a port of the Win32 API. That might help for PInvoke but it won't help you if you're invoking unsafe C++ DLLs or other x86 instructions. Phase two of Darwine supposedly integrates winelib with an x86 emulator but it hasn't happened yet.

        But even if / when that occurs it's not ideal. In fact it's terrible. To run .NET apps on the PPC, not only do you need Mono but also winelib and an x86 emulator!

        As a corporate entity M

    • to paraphrase: "it's harder to write insecure code, therefore it's more secure."

      sounds like security by obscurity to me...

      that's a good thing, right?

    • Yes Java supports C++ native calls, but look at how bloody painful it is to do it. You have to define an interface, run it through a stub compiler, implement the stubs and use helpers to marshal types back and forth between C++ and their Java equivalents. It involves lots of files and lots of fiddling about.

      You seem to be confusing JNI with the old unstandardised Java 1.0 mechanism. There is no need for stub compilers and type marshalling any more. You just write your code to access the Java data direct
    • Mono demonstrates the problems faced in porting .NET to other platforms. Mono must literally pull in the whole winelib in order to cope with the number of tainted .NET apps that attempt to call out to Win32. And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).

      I'm not really an expert on .NET programming (I've written a couple of desktop apps and played around a little more extensively with ASP.NET), but I understood the problem to be that the Windows.Forms

  • Comment removed (Score:4, Funny)

    by account_deleted ( 4530225 ) on Monday February 07, 2005 @04:49PM (#11600982)
    Comment removed based on user account deletion
  • Goesling's comments made me laugh. .NET can run unmanaged C/C++ code, therefore is unsecure. Well, Java can do the same thing, with JNI (and JNI is necessary in some cases.. anyone know how to read the MAC address of your NIC without it, for example?)

    Essentially, Don's comments are:
    a) .NET is as secure as Java wrt unmanaged code
    b) .NET is more convenient wrt the same

    which is completely correct, IMO.
  • A typesafe language is no replacement for secure programming knowledge, several vendors offer classes in that realm:

    http://www.liveammo.com/LiveAmmo_Secure_Programmin g_Training.htm [liveammo.com]

    and

    http://www.cerias.purdue.edu/secprog [purdue.edu]

Slashdot Top Deals

There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann

Close