Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Javapocalypse

jz13.java.no

Post reply on HN
Print view View original

41–50 of 129 posts

Re: Javapocalypse

#41

Post by sfjailbird »

AYBABTME wrote: post #35
StavrosK wrote: post #32

Earlier quoted context omitted.

Thanks for clarifying checked vs unchecked. Your comment makes perfect sense, and is what I expected. The thing is that I really don't like handling an exception higher than where it makes semantic sense (which is the actual call, in this case), so propagating higher is even less clean, for this specific example. I guess the problem here is the checked exception, but I can see the rationale, if it's impossible to opt…

What you could do is initialize the Url in a static block or in a `{{ }}` block and handle the exception there. You would still have the exception handling, but not in your logic, and the static block would ensure that if the Url is indeed malformed, the exception will throw as soon as the class is loaded in memory, instead of only when the Url is instantiated during in logic. So somewhere up in your class, you'd wri…

Putting it in a static block is bad advice, there are many other places you could put initialization.

What happens if a static block throws an exception is that the class will not be loaded, and every other time the code refers to the class it will get a ClassDefNotFoundException, which can lead to a 'fun' time tracing the actual issue. Hence why static blocks are not used very much (though it can be convenient).

Re: Javapocalypse

#42

Post by sergiosgc »

brazzy wrote: post #24
spacemanaki wrote: post #15

Earlier quoted context omitted.

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.

You don't need to leak abstractions on exceptions. Libraries should wrap the exceptions and provide meaningful exceptions, not dependent on the exact implementation. Example:

  public String setCache(String key, String value) throws CacheUnavailableException,CacheWriteException {
    try {
    ...
    } catch (SocketException e) {
        throw new CacheUnavailableException(e);
    } catch (SomeMemcacheException e) {
        throw new CacheWriteException(e);
    }
  }
This will allow library clients to catch exceptions that mean something to them, not exceptions that only make sense if you know how the library is using memcache.

Re: Javapocalypse

#43

Post by mordae »

Hmm, the video makes me wonder.

What if the button software was written in Java and did, in fact, nothing. Perhaps with a nice 40-something line stack trace in the log file. Meanwhile, a completely new worm targeting the Java platform crashed most of the infrastructure.

Re: Javapocalypse

#44

Post by victorf »

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…

Checked exceptions seem like a great idea, but I can see how the execution of them is irritating. If I were to do Android I would go directly to Scala, which looks pretty awesome.

Re: Javapocalypse

#45

Post by dm3 »

shawabawa3 wrote: post #36
StavrosK wrote: post #23

Earlier quoted context omitted.

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…

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)

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.

Re: Javapocalypse

#46

Post by pjmlp »

kyllo wrote: post #26
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…

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 han…

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

Re: Javapocalypse

#48

Post by RivieraKid »

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 you described is mostly a problem of the standard library. Sometimes it's too low-level and it's better to use 3rd pary libraries for things like HTTP. There should definitely a way to create urls without having to check exception (ie. it would throw a RuntimeException that doesn't need to be checked).

Java 7 also lacks very useful features like lambdas, mixins, nested methods etc.

However, Java is a good choice for many projects, because it has fantastic tooling, lots of libraries and it's relatively fast. The tooling is really a huge advantage of Java. When I refactor Java code in Eclipse, I sometimes wonder how would I do this when it was Python (which I use for smaller projects).

I wish there was a language combining the pros of Java & Python...

Re: Javapocalypse

#49

Post by pjmlp »

victorf wrote: post #44
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…

Checked exceptions seem like a great idea, but I can see how the execution of them is irritating. If I were to do Android I would go directly to Scala, which looks pretty awesome.

Except it generates bigger and slower executables than Java tooling does, although ProGuard helps a bit.

Re: Javapocalypse

#50

Post by StavrosK »

RivieraKid wrote: post #48
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 you described is mostly a problem of the standard library. Sometimes it's too low-level and it's better to use 3rd pary libraries for things like HTTP. There should definitely a way to create urls without having to check exception (ie. it would throw a RuntimeException that doesn't need to be checked). Java 7 also lacks very useful features like lambdas, mixins, nested methods etc. However, Java is a good choice…

Hmm, yeah, I see what you mean. I think Go does a pretty good job of being a middle ground between Java and Python, it has the static typing with all the tooling advantages it brings, without the annoying need to be explicit about everything. I think you'll like it.
Post reply on HN