Javapocalypse • Hacker News Board

Re: Javapocalypse

#21

Post by troels » Fri, Jun 14, 2013, 1:04 PM UTC

StavrosK wrote: post #18

bru wrote: post #14

Earlier quoted context omitted.

>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. And backed by a huge company. Relatively fast. More reasons there: http://c2.com/cgi/wiki?WhyJavaIsGreat > exception-related problems A common hack it to wrap your code in a dumb try/catch block at the uppermost level. That way there is no scope-related probl…

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...

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.

Re: Javapocalypse

#22

Post by ryandvm » Fri, Jun 14, 2013, 1:05 PM UTC

spacemanaki wrote: post #15

StavrosK wrote: post #12

This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…

Which API were you using? Java's HttpUrlConnection is notoriously badly designed [0] On Android (and elsewhere of course) you can use Apache's HttpClient instead which is a bit less horrible [1]. Part of this problem is checked vs unchecked exceptions, and some of the older APIs in Java use checked exceptions too heavily, IMHO. On top of that, I think all the Java IO stuff provides a pretty leaky abstraction over the…

The Android team has dropped support for Apache HttpClient. The party line is that if you are targeting Gingerbread or newer (and you should be), then use HttpURLConnection.

http://android-developers.blogspot.com/2011/09/androids-http...

Re: Javapocalypse

#23

Post by StavrosK » Fri, Jun 14, 2013, 1:09 PM UTC

troels wrote: post #21

StavrosK wrote: post #18

Earlier quoted context omitted.

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...

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.

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).

Re: Javapocalypse

#24

Post by brazzy » Fri, Jun 14, 2013, 1:12 PM UTC

spacemanaki wrote: post #15

StavrosK wrote: post #12

This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…

Which API were you using? Java's HttpUrlConnection is notoriously badly designed [0] On Android (and elsewhere of course) you can use Apache's HttpClient instead which is a bit less horrible [1]. Part of this problem is checked vs unchecked exceptions, and some of the older APIs in Java use checked exceptions too heavily, IMHO. On top of that, I think all the Java IO stuff provides a pretty leaky abstraction over the…

> I'd be curious what other people think about this.

I think that checked exceptions are a failed experiment in language design. They basically force you to leak abstractions all over your code, reintroducing a lot of the pain of error codes.

Re: Javapocalypse

#25

Post by yareally » Fri, Jun 14, 2013, 1:13 PM UTC

StavrosK wrote: post #12

This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…

If Java turns you off, you could try Scala on Android.

https://news.ycombinator.com/item?id=5873229

Re: Javapocalypse

#26

Post by kyllo » Fri, Jun 14, 2013, 1:13 PM UTC

bru wrote: post #14

StavrosK wrote: post #12

This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…

>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. And backed by a huge company. Relatively fast. More reasons there: http://c2.com/cgi/wiki?WhyJavaIsGreat > exception-related problems A common hack it to wrap your code in a dumb try/catch block at the uppermost level. That way there is no scope-related probl…

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.

Re: Javapocalypse

#27

Post by StavrosK » Fri, Jun 14, 2013, 1:15 PM UTC

yareally wrote: post #25

StavrosK wrote: post #12

This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…

If Java turns you off, you could try Scala on Android. https://news.ycombinator.com/item?id=5873229

I heard that that had very large startup costs due to the Scala VM (IIRC), which is unfortunate for what I'm making (a remote control app) :/

Re: Javapocalypse

#28

Post by sfjailbird » Fri, Jun 14, 2013, 1:16 PM UTC

StavrosK wrote: post #18

bru wrote: post #14

Earlier quoted context omitted.

>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. And backed by a huge company. Relatively fast. More reasons there: http://c2.com/cgi/wiki?WhyJavaIsGreat > exception-related problems A common hack it to wrap your code in a dumb try/catch block at the uppermost level. That way there is no scope-related probl…

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...

  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.

Re: Javapocalypse

#29

Post by AYBABTME » Fri, Jun 14, 2013, 1:17 PM UTC

StavrosK wrote: post #12

This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…

Java is verbose. Tooling is great, however.

For exceptions, there are two types. Checked exceptions and runtime exceptions.

* Checked exceptions need to be explicitly handled in your code, or it doesn't compile. * Runtime exceptions can just happen, you don't need to check them. I personally don't really like the runtime exceptions because they can hide in thousands of place and throw when you don't expect it. However, you don't need to check them so it makes for less verbose code... but it's like putting your head in the sand.

To reduce verbosity of exception handling, I find a pseudo-solution is to just propagate the exception up the stack and deal with it later. It depends for what exception, but for instance, a MalformedUrlException for which you KNOW the Url is fine, can be checked much higher in the call stack. You will save yourself the local verbosity, which hides meaning, and really if the Url is malformed, you might not want the app to keep running; if it's hard-coded you should expect it to be right. It's in the same spirit of Go's `regexp.MustCompile(string)` that makes a compile error if the hardcoded string you give it is not a valid regex.

That being said, Java is a daily pain, but the extensive tooling makes it usable.

Re: Javapocalypse

#30

Post by StavrosK » Fri, Jun 14, 2013, 1:19 PM UTC

sfjailbird wrote: post #28

StavrosK wrote: post #18

Earlier quoted context omitted.

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...

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.

Isn't this the same as "public void myFunction throws WhateverYouDontWantToHandleException" (i.e. letting it propagate up implicitly)?