6 ms·

>What attracts people to the Java world? Portability, security (automatic memory, static typing, etc.): you cannot bore a hole in your feet when shoving a nail

• StavrosK 13y ago
  I think the last two reasons are the most important ones, as the first to are relatively common. About the try/catch, it sounds like something that'll come back to bite me in the ass, so it's a bit unfortunate that I have to pick between being verbose and handling exceptions that can never occur, or being terse and hacky...
  • troels 13y ago
    Well, in more forgiving languages, such as python, you are just implicitly being "hacky" as you put it. E.g. errors - if they ever occur - will happen in runtime. Java tries to move this to compile time, making them visible. It's a tradeoff really.
    • StavrosK 13y ago
      No, in Python you never silentrly ignore all exceptions (well, you can, but it's a big no-no). You can just opt to not handle them, but they'll crash your program. It's a tradeoff, as I know which exceptions are likely to become a problem and which aren't, and I can choose to handle the relevant ones and let it crash in the rare case that an exception I didn't think likely occurs. In Java, I have to handle malformed URL exceptions, even though I can see the URL in front of me, and if it's not malformed the first time, it'll never be. I see your point about runtime vs compile time, but my issue is with mandatory vs optional handling. I guess you can add "throws MalformedURLException" to let it bubble up, which is kind of the same thing, though (although you have to add all the exceptions you don't want to handle there, in that case).
      • shawabawa3 13y ago
        The reason is that Java is designed for enterprise, where "I know which exceptions are likely to become a problem and which aren't" cannot be trusted. With giant code bases and mediocre developers you kind of need to have checked exceptions or you'll have exceptions popping up in the most unexpected places. (I'm a Python dev and hate Java)
        • StavrosK 13y ago
          Ah, that clarifies it a bit. Python takes a more "we're all grownups here" approach, which I find suits me better. Go takes a similar approach, but I can see how Java meets a different need.
        • dm3 13y ago
          Unfortunately, mediocre developers are perfectly capable of learning to either catch and silently ignore checked exceptions (checked exceptions actually promote this habit, which can be successfully used in other languages with exceptions) or rethrow them as runtime exceptions. The good thing is - newer java libraries use unchecked exceptions in the vast majority of their APIs.
          • bjhoops1 13y ago
            When I come across exceptions that get silently "eaten" I want to throw the dev out of a window. I've lost days of my life tracking down inscrutable bugs only to find something like this: catch ( Exception e ) { /eat it/ }
          • cjg 13y ago
            That's not a good thing when you are trying to write absolutely bullet-proof code that will not fall over and can recover / retry robustly. A desktop top app is a good example of this. Network connection gone, disk full, file missing, etc. These things should not be fatal. Once the user gets back within WiFi range, empties their recycle bin, or plugs in some external storage device, the code should be able to continue sensibly. In this situation, handling RuntimeExceptions at a high level loses all the context. Whereas, remembering to handle all the RuntimeExceptions every time you make a call is silly - they should be checked exceptions then the compiler can warn you. I've ended up wrapping a Java library to make sure that I got checked exceptions to avoid this problem. Of course, some methods in Java throw checked exceptions some throw RuntimeExceptions. Most of these choices are sensible, but sometimes you have a hard-coded URL and you know it's not malformed. But equally, sometimes you have to catch a specific RuntimeException because that is a situation that you want to handle.
  • sfjailbird 13y ago
    try { *your stuff* } catch (WhateverYouDontWantToHandleException e) { throw new RuntimeException(e); } Then at the outmost level of your code somewhere you catch RuntimeException and tell the user a general error occurred or something. You will still get the root exception so you can log with stack trace and eventually implement some specific exception handling for it if necessary.
    • StavrosK 13y ago
      Isn't this the same as "public void myFunction throws WhateverYouDontWantToHandleException" (i.e. letting it propagate up implicitly)?
      • sfjailbird 13y ago
        No, that will force whoever is calling your method to handle that exception, now without knowing the actual context ("why does getWeatherForecast() throw MalformedURLException?" etc.). It also leaks an implementation detail, i.e. the use of URL-whatever. A RuntimeException, and any subclass of it, is unchecked and so the compiler does not force you to handle it.
        • StavrosK 13y ago
          Oh, right, you convert it to RuntimeException (ostensibly in multiple places where you don't want to handle the exception) and catch that one as a general exception. It makes sense now and sounds like a good solution, thank you.
          • tomjen3 13y ago
            It is a horrible solution, but it does work. IMHO, go was right to get rid of exceptions (stack traces are useful) and just return two values.
• kyllo 13y ago
  It's a batteries-included, statically-typed language that's safer and harder to get wrong than C/C++, but faster than any dynamic language, and it has a fast, high-quality JIT compiler with well-written warnings and errors. Overall it's a very safe choice. Unfortunately its extreme object-orientation, lack of type inference and polymorphism, lack of first-class functions and anonymous functions, and awkward error handling, make it quite painful to actually write (at least without code completion and automatic refactoring), while encouraging a number of poor design choices and serious source code bloat. It's too high-level to be useful for systems or game programming, but it's not expressive enough to be very productive for programming at a higher level of abstraction, and it's useless for scripting. So, it's mostly used for building enterprise web services. And Android apps.
  • pjmlp 13y ago
    > Unfortunately its extreme object-orientation... Like Smalltalk, Eiffel, C#, VB.NET > It's too high-level to be useful for systems or game programming True if you are speaking about AAA games or writing kernels, for everything else lots of people seem to be quite successful using it. > So, it's mostly used for building enterprise web services. And Android apps. And in embedded environments powerful enough to run it, like windmills, electricity control meters, missile radar controls, blue ray players, J2ME mobiles, ...
    • kyllo 13y ago
      I don't know much about the other languages you mentioned, but C# is multi-paradigm, allowing certain functional and declarative programming practices that Java does not. It's much more expressive than Java.
      • pjmlp 13y ago
        How do you write pure functions and procedures outside classes in C#?
        • kyllo 13y ago
• kamaal 13y ago
  Joke? The only reason why large shops are attracted to the Java world is because the endless supply of low cost developers and a tooling ecosystem which helps such developers survive in that ecosystem. That is the No 1 reason every manager I've know has ever given for using Java.
• namdnay 13y ago
  What's sad about Java is that the whole type-safety, compile-time-checks, minimal-runtime-surprises etc has gone out of the window since the DI craze, so now we have a platform that is as "unsafe" as Python et al, whilst still being relatively heavy to set up etc.. I guess there's still the advantage of having extensive libraries..
  • davidcuddeback 13y ago
    DI = dependency injection, right? How does dependency injection throw type safety out the window? You can only inject types that are a subtype of the declared type. Overridden methods can't extend the types of checked exceptions that are thrown [1]. I fail to see the hole in the type system here. I'm not a Java programmer, but I use dependency injection all the time in other language, including dynamic languages like Ruby. I find it very helpful for isolating bits of code and making extendable interfaces. I'm genuinely curious if there's a major weakness lurking in DI that I haven't discovered yet. Please help me remove my blinders. [1] http://stackoverflow.com/questions/5875414/method-overriding-and-exceptions http://stackoverflow.com/questions/5875414/method-overriding...
    • ishbits 13y ago
      DI will defer the injection to runtime instead of compile time, so you don't get the benefit of type checking during the compile. I've been bitten by this in the past with SpringMVC. It usually ripples up quickly and has never been an issue in a released app.
      • justinmk 13y ago
        You must be talking about xml-configured DI. cf. Guice, which is compile-time checked: https://code.google.com/p/google-guice/wiki/SpringComparison https://code.google.com/p/google-guice/wiki/SpringComparison
        • namdnay 13y ago
          I really need to try that some time, thanks!