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

101–110 of 129 posts

Re: Javapocalypse

#101

Post by doktrin »

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…

> the compiler kept complaining about unhandled exceptions (I know the URL is fine, it's a fixed string I can see, it's not going to throw MalformedURLException, I don't want to catch it, thank you. What? I can't compile without it?)

Checked exceptions bugged me as well when I was first introduced to Java. I honestly still don't like the fact that exception handling is enforced at the compiler level. It feels intrusive.

I did write a short blog post on the subject, which may be helpful. As a disclaimer, I'm not a full time Java dev.

http://tmblr.co/ZJpjTubrVmRw

Re: Javapocalypse

#102

Post by namdnay »

ishbits wrote: post #93
davidcuddeback wrote: post #88

Earlier quoted context omitted.

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…

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.

Yeah, it's not a big risk to production, but it just makes the development loop that much more frustrating. There's nothing more annoying than building, deploying, starting, before discovering that you mispelt a bean name...

Re: Javapocalypse

#104

Post by justinmk »

ishbits wrote: post #93
davidcuddeback wrote: post #88

Earlier quoted context omitted.

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…

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.

You must be talking about xml-configured DI.

cf. Guice, which is compile-time checked:

https://code.google.com/p/google-guice/wiki/SpringComparison

Re: Javapocalypse

#105

Post by swah »

RivieraKid wrote: post #84
pkolaczk wrote: post #64

Earlier quoted context omitted.

Scala is such a language, at least to me it was a pain to go back to Python after learning Scala. And Scala's tooling is IMHO better than Python's these days, although still not as smooth as Java's.

I experimented with Scala for a while but got turned off by 1) very slow compilation 2) complicated and unelegant syntax.

Me too, mainly 1, which makes you feel the language is slow. Contrast with Go (a much simpler language, but feels modern because it compiles so cleanly).

Re: Javapocalypse

#106

Post by charleslmunger »

namdnay wrote: post #102
ishbits wrote: post #93

Earlier quoted context omitted.

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.

Yeah, it's not a big risk to production, but it just makes the development loop that much more frustrating. There's nothing more annoying than building, deploying, starting, before discovering that you mispelt a bean name...

This sounds Spring-specific. Using Guice, that's not an issue.

Re: Javapocalypse

#107

Post by sivanmz »

Java is just not made for quick prototyping. In production, the URL will come from somewhere, not written by hand, so it would need to be checked anyway. Sadly there's no quick-prototyping mode in Java where you can say, just call this URL string an don't bother checking.

Another example is the inability to just read a local file into a string with a simple API call. It's this way, again, because in production the program has to reason about paths and file systems and can't make assumptions about the validity (or size) of the file you just want to load and play with.

In production code, no matter the language, you have to guard against these issues. The nice thing about objects (immutable, anyway), is that once constructed and validated, they do not require tedious validation at every method and client they are passed into. That actually results in less boilerplate, and less test writing.

So just remember, Java always assumes your code is production-bound and requires upfront planning and checking. That's why it's unpleasant to prototype with.

Re: Javapocalypse

#108

Post by sivanmz »

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 just not made for quick prototyping. In production, the URL will come from somewhere, not written by hand, so it would need to be checked anyway. Sadly there's no quick-prototyping mode in Java where you can say, just call this URL string an don't bother checking. Another example is the inability to just read a local file into a string with a simple API call. It's this way, again, because in production the program has to reason about paths and file systems and can't make assumptions about the validity (or size) of the file you just want to load and play with.

In production code, no matter the language, you have to guard against these issues. The nice thing about typed objects (immutable, anyway), is that once constructed and validated, they do not require tedious validation at every method and client they are passed into. That actually results in less boilerplate, and less test writing.

So just remember, Java always assumes your code is production-bound and requires upfront planning and checking. That's why it's unpleasant to prototype with.

Re: Javapocalypse

#109

Post by deadairspace »

afandian wrote: post #4
jstsch wrote: post #2

With the domain java.no, this headline sounded like a plea to stop all Java development ;)

My first thought was "I bet this is another abuse of TLDs, what are the chances this is actually Norwegian". Pleasantly surprised.

From wikipedia: [.no] domain registrations are limited to organizations with a presence in Norway and registration at the Brønnøysund Register Centre.

Re: Javapocalypse

#110

Post by kyllo »

tomjen3 wrote: post #85
kyllo wrote: post #67

Earlier quoted context omitted.

Type inference = the compiler being able to figure out what types your variables, function arguments, and return values are without you having to explicitly tell it. Polymorphism = the ability to write one function that works for multiple types. So for example, if you want to implement a sorting algorithm, you can write one function that is capable of sorting ints, floats, doubles, chars, and Strings. Java doesn't ha…

Java has polymorphism, your type can implement (I think) comparator and that should be it. Of course, that doesn't work for int, float, etc because those types aren't objects, but then you typically don't have an array of those.

Huh? You don't typically have an array of primitives? Says who?

In Java, with the exception of String[], you would normally only use an array with primitives. If you're working with objects you would want to use a different data structure such as a linked list.

Post reply on HN