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

91–100 of 129 posts

Re: Javapocalypse

#91

Post by RivieraKid »

StavrosK wrote: post #23
troels wrote: post #21

Earlier quoted context omitted.

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…

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

That's a very good point. Malformed URL would mean that there's an error in the program. It's not an exceptional situation, like e.g. user entered malformed URL into a text field.

In these cases you should simply throw AssertionError immediately. But that still results in unnecessarily verbose code. Ideally, there should be two constructors, one that would throw an unchecked exception (URL.create(...)) and one that would throw a checked exception (URL.createOrThrow(...)). (You can create an unchecked constructor yourself.)

Re: Javapocalypse

#92

Post by skyebook »

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…

> It's too high-level to be useful for systems or game programming

I plead with you to check out http://jmonkeyengine.org and see for yourself

Re: Javapocalypse

#93

Post by ishbits »

davidcuddeback wrote: post #88
namdnay wrote: post #69

Earlier quoted context omitted.

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

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.

Re: Javapocalypse

#94

Post by Roboprog »

RivieraKid wrote: post #87
StavrosK wrote: post #50

Earlier quoted context omitted.

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.

I quite like Go but I see it mostly as a C++ replacement, not Java or Python replacement. Java has far better tooling. It also has quite weak type system (no gnerics). Dart is closest to my ideal of a general purpose language.

Go tooling will likely get better as time allows IDEs / plugins to be written.

It remains to be seen if the Go language will grow significantly from one major release to the next, and how frequent any such changes will be. (it might stagnate, as well)

Sun / Oracle have demonstrated the last 10 years that they do not intend to improve the Java language itself (COBOL with separate compilation, user defined types, field accessors and subclassing is good enough for all!), but will only keep rolling out new "Enterprise" libraries / frameworks.

Re: Javapocalypse

#95

Post by Roboprog »

Roboprog wrote: post #77
StavrosK wrote: post #19

Earlier quoted context omitted.

I used this in the end: http://loopj.com/android-async-http/ , it exposes an interface that does not make me shudder, and I am guessing that is a very good thing. I should read about checked exceptions more, I don't currently understand the difference between checked and unchecked. I don't hate that answer, I was just hoping it wouldn't come to that :P Getting used to a language to get one's job done is fine, but it'…

A checked exception is one that the compiler forces you to write a check for. An unchecked exception ("the good kind") is one that you could write a check for if you want to. You probably want to have at least one exception "catch" block somewhere, such as within a message/event handler loop, but checked exceptions force you to write the error catch at the place where a routine is called, and MANY such checks for oth…

Alas, as much as I like golang, this is one area that it seems to have got worse than Java: error codes instead of exceptions, preferably unchecked exceptions like C# uses (and other languages, I presume)

Re: Javapocalypse

#96

Post by kyllo »

neilk wrote: post #75
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…

It's not quite fair to say Java lacks polymorphism, it just doesn't extend to primitive types.

Well, apparently "polymorphism" in the Java world just means that subclasses can override the superclass's methods. http://docs.oracle.com/javase/tutorial/java/IandI/polymorphi...

Yes, the Java 1.5+ generic data structure classes that take parameterized types allow a sort of polymorphism, but only for objects (including wrapper classes), but it's not quite as powerful as functional polymorphism.

For example, in SML you can swap an ordered pair of any two datatypes with one line of code:

fun swap(x: 'a, y: 'b): 'b * 'a = (y,x)

And to illustrate my other point about type inference, this is also legal SML and does the same thing. You can leave the type annotations off and the compiler will figure them out for you:

fun swap(x,y)= (y,x)

where x and y can each be any datatype.

I don't really know Scala but from reading about it I get the impression that it also allows this.

Have fun doing it in Java though... you'll have to implement your own generic ordered pair class.

Re: Javapocalypse

#97

Post by Gonzih »

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…

Welcome to javaland, where simple things take lot of time and lot of working time is spend doing java and not a real work.

Re: Javapocalypse

#98

Post by RyanZAG »

Yhippa wrote: post #81
RyanZAG wrote: post #68

Earlier quoted context omitted.

The standard method for getting around this in the java world is to create 'sane' libraries (in the case of android http, something like http://loopj.com/android-async-http/ ) and then just use the library. The strong point of Java is just how many libraries there are - you often don't need to touch the actual built in Java APIs. On the server side (non-android) this has gone even further through the use of new annot…

I feel something as commonplace as making a HTTP GET or POST should be standardized at this point. There are many implementations which still require a decent amount of boilerplate.

The core java library has mostly been kept unchanged for a decade now (I think?). Java 8 is doing the largest change to it in a long time by changing the collections to work with lambdas.

The main goal behind the standard Java library (from what I have gathered) has always been to provide a mid-level API to most possible functionality in an OS so that library developers can develop simple Java libraries that work across all platforms supported by Java. The big changes to the JRE libraries in the early years of Java was really what caused all of the big problems Java has had. Since the JRE stopped evolving, (server side) Java has really thrived with most code being very easily deployable anywhere and everywhere in the enterprise.

If you're going to program in Java, you should use libraries for commonplace tasks, and you should use an IDE to autocomplete package names and 'run' blocks. If you do this, Java really does work very well. For huge classes of coding tasks, the excessive boilerplate and compile time checks / exceptions can make it possible to tell very quickly if code is correct or not even without tests which is a major boon for code review purposes in enterprise.

Ultimately what I'm trying to say is that Java really does work very well and has come a very long way in creating a very productive environment for large projects, and it's why Java is so popular and heavily used even when at first glance it looks terrible.

Re: Javapocalypse

#99

Post by gizmo686 »

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…

>I'm wondering how people deal with this issue

Using an IDE in Java is almost a necessity. With that, people mostly just get use to it.

I recently had to return briefly to Java (also for android). All I had to do was recursively chmod a directory. This is something that once seemed simple to do in Java, and indeed it is still simple. However now when I write that code I am painfully aware of how unnecessarily long and complicate it is. However, the larger project involve cross compiling python with c-extensions (and external c dependencies), so I do appreciate the relaxation that comes with Java boilerplate.

Re: Javapocalypse

#100

Post by rickmode »

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 old enough that the current best practices recommend using the language and libraries differently than originally intended.

For new developers that want to do more than trivial things in Java, reading "Effective Java" will help you avoid many of the pitfalls in the language.

As an example, the current best practice around exceptions is that checked exceptions were a mistake. Don't use them in new code. For code that must deal with checked exceptions, you can create your own general exception class derived from RuntimeException, then use a try/catch block to throw your own runtime exception that wraps the checked exception. (But do this smartly; for cases like IOException with web stuff, it is sometimes easier to add "throws IOException" to all your related methods than to exhaustively catch and rethrow.)

As a second example, do not use the JDBC library directly. It is very poorly designed and direct usage can very easily lead to resource leaks. Use something like Spring's JDBC templates or roll your own. (I generally find Spring to be a bloated mess, but the JDBC template stuff is very useful.)

But perhaps the best bet is to use a more modern JVM-based language (of which my favorite is Clojure), though use of these alternatives on Android may be problematic.

Post reply on HN