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

Everything about Java 8

techempower.com

Post reply on HN
Print view View original

161–170 of 182 posts

Re: Everything about Java 8

#161

Post by PySlice »

smackfu wrote: post #157
PySlice wrote: post #148

Earlier quoted context omitted.

Yeah, I guess it sucks if you work with Bignums. I would be happy if BigInteger and BigDecimal were promoted String-level language support: still implemented as classes, but with compiler support. They could add indexing [] for collections, but I can live with .get() and .put(). Some people seem to think that if they don't use, then it doesn't matter. In many business applications, you don't even need floating point…

This same logic can be used to defend any "little feature". Language design is all about where you draw those lines.

That logic is just a starting point (just to avoid the "I don't need it, why can't you be just like me?"), not the whole thing.

Then you have to take into account a few other criteria, such as [1] internal coherence in the language, [2] difficulty in implementation (and explaining to others) [3] what your target audience is, and what they want, [4] what competitors are doing.

I think full operator overloading would hurt [2], but special-casing Bignums would not hurt [1], [2] at all (as I said, JSP EL already have +,-,*,/, etc. , String already have +, +=).

[3] This is what this thread is all about, no need to repeat :-D

And [4]... Well in this case Java is really playing catch up.

Re: Everything about Java 8

#162

Post by edwinnathaniel »

jiggy2011 wrote: post #101
mbell wrote: post #94

Earlier quoted context omitted.

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

What if a 3rd-party API only works on Beans? (i.e. doesn't support private properties).

Re: Everything about Java 8

#163

Post by edwinnathaniel »

mercurial wrote: post #95
mbell wrote: post #94

Earlier quoted context omitted.

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

With dependency injection frameworks, you don't really need setters anyway. I add getters only as needed, unless it's a public API.

2 things: 3rd-party API that only works on "beans" and thin object (not your Services or DAOs that use DI heavily).

Re: Everything about Java 8

#164

Post by edwinnathaniel »

nollidge wrote: post #53
gjulianm wrote: post #13

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…

And the two things I notice Java has that C# does not (static methods on Interfaces, and functional interfaces) have completely viable alternatives in C# (extension methods, and Action/Func, respectively). This really smacks of catch-up.

You can tweak JVM but you can't tweak CLR. While it's not Java vs C# the language but the VM/Runtime and the language is almost tight together (Mono is an exception).

Re: Everything about Java 8

#165

Post by edwinnathaniel »

fierarul wrote: post #110

Very interesting read. So, nothing new on the Swing side?

Oracle seems to move to JavaFX. JavaFX is still at its infancy but it shows some promises: iOS + Android (soon), cross-platform installer on desktop OSes (Windows, Mac AppStore) that doesn't require JVM (JDK/JRE) to be installed first.

It's ugly in terms of the UI but the infrastructure is there.

Re: Everything about Java 8

#166

Post by edwinnathaniel »

dougk16 wrote: post #141
johnyzee wrote: post #120

Earlier quoted context omitted.

You should give GWT a go. Compile time is a valid complaint, though it can be mitigated by only producing a single permutation (browser specific output) while in development, rather than the default five-six. Also note that during development you usually don't compile but run in "dev mode", a browser plugin that runs against your actual Java code. Performance after compilation is certainly not a problem, on the contr…

Another valid complaint is that dev mode runs quite slow, particularly if you're developing something like a game. I read an article about how they are addressing this so that dev mode runs almost as fast as the compiled result, but can't find the link now. Maybe it's already live? Been half a year since I've used GWT. But I second the recommendation overall. One thing I learned the hard way though, is that their wid…

> Doing UI in Java is too clunky for me no matter what library I'm using though, so YMMV.

For sure. C#, Java, C++ are all clunky. Maybe it's the nature of the ecosystem.

This is one thing I hate about GWT: it offers tons of upside (sprites, bundles, i18n, unit-test in JUnit IF using MVP) but the downside is in the area of big-consideration of pain point.

Re: Everything about Java 8

#167

Post by mercurial »

edwinnathaniel wrote: post #163
mercurial wrote: post #95

Earlier quoted context omitted.

With dependency injection frameworks, you don't really need setters anyway. I add getters only as needed, unless it's a public API.

2 things: 3rd-party API that only works on "beans" and thin object (not your Services or DAOs that use DI heavily).

You can't do much with 3rd-party APIs. For thin objects, a best practice is to keep them immutable by having only getters, but then you generally end up with Builder boilerplate.

Re: Everything about Java 8

#168

Post by johnyzee »

edwinnathaniel wrote: post #166
dougk16 wrote: post #141

Earlier quoted context omitted.

Another valid complaint is that dev mode runs quite slow, particularly if you're developing something like a game. I read an article about how they are addressing this so that dev mode runs almost as fast as the compiled result, but can't find the link now. Maybe it's already live? Been half a year since I've used GWT. But I second the recommendation overall. One thing I learned the hard way though, is that their wid…

> Doing UI in Java is too clunky for me no matter what library I'm using though, so YMMV. For sure. C#, Java, C++ are all clunky. Maybe it's the nature of the ecosystem. This is one thing I hate about GWT: it offers tons of upside (sprites, bundles, i18n, unit-test in JUnit IF using MVP) but the downside is in the area of big-consideration of pain point.

With GWT it is possible to pretty much build your UI in HTML and simply inject key components, with event handlers etc., into the DOM structure. You would use an HTMLPanel and add(Widget widget, String id). Few people seem to be aware of this.

I used this approach to build TeamPostgreSQL (demo at http://teampostgresql.herokuapp.com/), where the designer built the entire interface in HTML and I just inject GWT widgets in the right places.

Re: Everything about Java 8

#169

Post by tragomaskhalos »

mikeash wrote: post #158
tragomaskhalos wrote: post #124

Earlier quoted context omitted.

Well this is clearly a matter of taste; the visual implication of movement ( http://images.google.com/images?q=diversion+sign+chevrons ) is quite elegant IMHO, and the precedence seems natural also. But others' mileage obviously varies ...

I disagree that the precedence is natural. Without looking it up, and without compiling it, what do the following (IMO quite reasonable in general) lines of code do? cout As for the visual implication of movement, I have no objection whatsoever to using the << operator for stream operations in general. However, I strenuously object to doing this in a language which already defines them as bitshift operators. Repurpos…

Point taken, but small beer IMO; I use parens in boolean expressions because I can never remember the precedence of && vs ||, so would naturally use them here too.

And I don't buy the fact that Yes the << notation isn't perfect, but it is much nicer than named functions (and certainly superior to < (which Stroustrup initially considered)!). Adding arbitrary operators to the language would have required mechanisms to define associativity and precedence, which would have added a weight of complexity disproportionate to the reward.

Re: Everything about Java 8

#170

Post by djhworld »

trailfox wrote: post #45
j-m-o wrote: post #5

As a daytime Java developer who dabbles in Scala on the side, these changes look great. The inclusion of a Joda Time style time library is long overdue as well. I just wonder how many years before there's adoption from the general Java community.

As a daytime Scala developer who seldom uses Java anymore these changes are nice, but a far cry from what I get in Scala.

The Scala compiler takes so long in comparison to javac though
Post reply on HN