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

51–60 of 129 posts

Re: Javapocalypse

#51

Post by StavrosK »

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.

It does, but when you have to learn Java and Android development in one go, learning Scala on top of that (since all the docs are in Java), is pretty daunting.

Re: Javapocalypse

#52

Post by kyllo »

pjmlp wrote: post #46
kyllo wrote: post #26

Earlier quoted context omitted.

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

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.

Re: Javapocalypse

#53

Post by nahname »

AYBABTME wrote: post #29
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. Howeve…

Checked exceptions. When your code is so instable, you make failure part of the API.

Re: Javapocalypse

#54

Post by 6ren »

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…

Great and fair summary. But what do you mean by lack of type (...) polymorphism?

Re: Javapocalypse

#55

Post by cjg »

dm3 wrote: post #45
shawabawa3 wrote: post #36

Earlier quoted context omitted.

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.

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.

Re: Javapocalypse

#56

Post by famousactress »

AYBABTME wrote: post #29
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. Howeve…

Yeah, this is the argument I got tired of and why I jumped ship out of developing in Java for over a decade: "Java is pretty painful, but don't worry.. the tools are so good you don't have to write much code."

Re: Javapocalypse

#57

Post by AYBABTME »

sfjailbird wrote: post #41
AYBABTME wrote: post #35

Earlier quoted context omitted.

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

The idea is that if an exception has to be thrown, it will throw as early as possible, making it pretty obvious during development that there's a bug - whenever you try to run your app it will exit with an error about the MalformedUrl. Notice I said he/she should catch the exception in the static block and log it, pretty hard to have an issue tracking where the error comes from.

You can't check at compile time that the Url is valid, but if as soon as you load the program, it crashes with this exception, it will be hard to ignore and the mistake won't be hidden. Since you catch the exception that's thrown a static time, there's no ClassDefNotFoundException.

See examples of this concept in Go:

http://golang.org/pkg/regexp/#MustCompile http://golang.org/pkg/text/template/#Must

The better solution would be to have a compile time error, but I don't think Java can do that.

Post reply on HN