Live data from Hacker News

Everything about Java 8

techempower.com

101–110 of 182 posts

Re: Everything about Java 8

#101
post #94

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but... - Getters and setters, C# style. That is, instead of private int foo; public int getFoo() { return foo; } public void setFoo(int value) { foo = value; } write this: public int Foo { get; set; } which is both easier to write and makes code more readable and understandable. - Man…

> Getters and setters, C# style. That is, instead of I just stopped using getters and setters all together unless I have a real use for them. The most common reasons are: because they are required by some third party library or they are the external interface for whatever the module of code is doing. For all internal classes, if the field needs external access, just make it public. Most of the arguments I hear for us…

I think it's partly a defensive tactic to stop others playing fast and loose with your object state.

I used to write classes and then add fields and auto generate getters/setters.

Now I don't, I just make all the state private and if I find myself wanting a getter/setter I ask myself why.

Too much use of getters/setters is just reinventing the problem that private state was meant to avoid.

So for example rather than:

if(email.getState() == EmailState.SENT) {

I have:

if(email.wasItSent()) {

Re: Everything about Java 8

#102
>Non-final variable capture - If a variable is assigned a new value, it can't be used within a lambda. This code does not compile:

So, it sounds like that mean no closures? That's one of my favorite tools in c#.

Re: Everything about Java 8

#103
post #91

Earlier quoted context omitted.

There's basic language bigotry going on here: an aged internet meme declares that C++ operator overloading is bad because you can indeed, in theory, do idiotic counter-intuitive things with it. Yet the identical capability in Ruby, Scala and Haskell (inter alia) is deemed A Good Thing by the consensus.

It's not an identical capability. Scala doesn't technically have operator overloading, it has symbolic method names and operator syntax for methods. This means you can use any valid name as an operator. With C++, you can only overload the built-in symbolic operators. This means instead of choosing the best symbolic name to use as an operator you're forced to re-purpose some built-in operator like "<<". In Scala you c…

Yes I know that, but the point is that the "operator overloading is terrible" complaint typically cites either plainly daft straw men like "what if someone overrides + to mean subtraction", or else hones in on was stupid ..)

Conversely, there was an XML library for Scala posted on Reddit about a year ago that used things like as method names; clearly the freedom to concoct your own symbolic names is far more open to abuse than the oft-maligned C++ mechanism.

Re: Everything about Java 8

#104
post #81

Earlier quoted context omitted.

There's basic language bigotry going on here: an aged internet meme declares that C++ operator overloading is bad because you can indeed, in theory, do idiotic counter-intuitive things with it. Yet the identical capability in Ruby, Scala and Haskell (inter alia) is deemed A Good Thing by the consensus.

For me, and perhaps others, this is because C++ enshrines idiotic counter-intuitive operator overloading in its standard library.

Examples ?

Re: Everything about Java 8

#105

Can someone please show the java guys the .TryParse(String s) from C#? I'm convinced everytime I have to manually write the try catch clause for parse a kitten dies somewhere!

TryParse uses an out parameter. Java doesn't have that. AFAIK, the JVM has no way to represent pointers in any such fashion. It's sort of ironic that the JVM, with it's limited Java-only bytecode has attracted so many languages, while the CLR, which is designed to handle multiple languages in an efficient manner, has relatively few.

To me it's a huge deal how portable my software is. CLR is very much tied to Windows. I know that there are other implementations but they always lag behind.

Re: Everything about Java 8

#106
post #25
post #17

Java 8 looks good enough to make Java a reasonable candidate for Java.Next. Especially given that there doesn't appear to be a clear winner between the alternatives (Scala, Groovy, Clojure, Kotlin etc.). Java 8 seems to have borrowed a lot from Guava (Optional, Function, Predicate, Supplier etc.). Extension methods as well as default methods on interfaces would have been nice.

Mixins would be great too.

Or something similar to Clojure protocols.

Re: Everything about Java 8

#107
post #67

Earlier quoted context omitted.

It's a pain that operations can fail, but handling state when they do fail is a problem that exists whether your exceptions are checked or unchecked. Forcing all exceptions to be checked doesn't seem to help with the problem, but would rather cause a lot of code to simply declare that it throws Exception, rather than listing off all possible exception types that it doesn't handle (e.g. out of memory, SIGTERM received…

Failure types are generally classifiable; part of clean module design is in classifying your exceptions in a way that allows you to declare that a more or less granular exception types are thrown based on the actual failure mode(s) possible from your code. The 'throws Exception' behavior only emerges when people don't take the time to define how code can fail, which is something that is necessary to fully define an i…

Given that most code degrades into either wrapping checked exceptions into runtime exceptions or most methods having "throws Exception" declared...I think it's safe to say Checked Exceptions don't work well in the real world. There is a reason no other language created in computer history uses them.

Re: Everything about Java 8

#108

Can someone please show the java guys the .TryParse(String s) from C#? I'm convinced everytime I have to manually write the try catch clause for parse a kitten dies somewhere!

TryParse uses an out parameter. Java doesn't have that. AFAIK, the JVM has no way to represent pointers in any such fashion. It's sort of ironic that the JVM, with it's limited Java-only bytecode has attracted so many languages, while the CLR, which is designed to handle multiple languages in an efficient manner, has relatively few.

I started to reply that Microsoft could fix that by providing high-performance CLR implementations on all the platforms the JVM runs on.

But it occurred to me that even if they did so, a lot of people wouldn't trust them to continue to support the other platforms indefinitely. The only way around that would be for them to spin off the entire .NET division.

Microsoft being Microsoft, of course, they would never do any of this.

Re: Everything about Java 8

#109

Unless I am mistaking, Java 8 fails to address the major pain-point I have with Java: hash and array literals. For me, one of the big wins of both Clojure and Scala is being able to handle maps, sequences, etc. conveniently.

java's main principle: preserving backwards compatibility. this is why the iterations are so small and take so long. java tip: don't look at other languages or you'll get depressed at how easy things could be or even should be
Post reply on HN