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

JDK 8 Release Notes

oracle.com

Post reply on HN
Print view View original

201–210 of 314 posts

Re: JDK 8 Release Notes

#201

Post by craigching »

nicobn wrote: post #163
jrabone wrote: post #56

Earlier quoted context omitted.

Because God knows, Java needs another logging framework. Seriously does ANYONE get any additional value out of the morass of crappy logging systems out there over and above System.out.println? Log4J is PARTICULARLY brain-damaged, with its refrain of "ooh, someone put a log4j.xml in their JAR (one of hundreds), that beats your log4j.properties.". Or SL4Js amazing performance of "1.6 doesn't work with Scala because of…

Never had a problem with slf4j on top of log4j. By the way, I use DEBUG in development and INFO in production. The ratio of logging messages between the two levels is about 1 for 50. Definitely an useful feature on top of System.out.println. I also change log levels for certain packages because some libraries are too verbose. Why are you so bitter ?

Agreed. I find it difficult to understand people griping so much about java logging. I know it's not perfect and I wish it were better, but it's really not that bad. Maybe if you come from Ruby or some other newer(ish) language, they only have one logging implementation (I don't really know the state of logging in other languages, so apologies) it's easy to point fingers. You learn your logging, use it, and be done with it.

I am currently in what you could consider log hell with a product based on OSGi. We have been using ops4j logging which has done a fantastic job of adapting the prevalent logging frameworks (log4j, slf4j, logback, and JUL) into the SLF4J API and we don't even have to think about it anymore.

Re: JDK 8 Release Notes

#202

Post by craigching »

gkya wrote: post #180
tieTYT wrote: post #158

Earlier quoted context omitted.

Yes, I can confirm this. Clojure seems like a good fit for tiny projects that are little more than scripts, but the start up time makes them kind of annoying to manually test. Fortunately Clojure does have a REPL.

The best cure to this problem is nREPL. It basically is an REPL server. There are plugins for Emacs (nrepl) and vim (vim-fireplace). With these tools, one may start a user repl and run tests within that. I have written a humble guide to set up Emacs for clojure here: http://gkayaalp.com/2014/01/28/taste-clojure.html#emacs My emacs configuration repository is gone thought; I'm using vim these days. A JVM with smaller…

> There are plugins for Emacs (nrepl)

I think nrepl for emacs has been replaced by cider (which still uses nREPL)

Re: JDK 8 Release Notes

#203

Post by jussij »

wsc981 wrote: post #173
meddlepal wrote: post #133

Earlier quoted context omitted.

Checked Exceptions and null. I write a lot of Java and I generally enjoy the language, but those two things; if Oracle could fix those somehow I would be extremely pleased. I'm so tired of writing null checks and I hope Optional is not the final answer since it too can be a null due to programmer error. I am really worried about Optional getting abused in Java 8... Actually, I waffle on checked exceptions; it seems e…

I'm so tired of writing null checks ... Could the null checks of Java be compared to the ones used in C#? My C# code is often littered with ternary operators to deal with null values. And that's still not as safe as the Objective-C approach where one can just send messages to nil[0] which is really awesome imo. I guess I kinda wonder if I could avoid the null checks in C# somehow ... I figured using a design by contr…

> I guess I kinda wonder if I could avoid the null checks in C# somehow

Without seeing your code it is hard to say, but using an object extension might work?

On many occasions I've used object extensions to hide checking code deep inside the extension.

C# really got that feature right.

Re: JDK 8 Release Notes

#204

Post by gkya »

democracy wrote: post #181
gkya wrote: post #156

Earlier quoted context omitted.

Few hundred milliseconds? I played with clojure a month or so ago and invoking lein repl was ~7.5 seconds.

I never worked with Clojure, but a simple java "hello world" starts and finishes within a second. Same with a simple java Swing UI "hello world" sample. If some application is doing something slow during initialization - it is not the platform itself, but the specific code to blame.

Lein starts a JVM instance for itself, then loads plugins, checks dependencies etc. and starts a new JVM instance for the program if necessary.

Re: JDK 8 Release Notes

#205

Post by gkya »

craigching wrote: post #202
gkya wrote: post #180

Earlier quoted context omitted.

The best cure to this problem is nREPL. It basically is an REPL server. There are plugins for Emacs (nrepl) and vim (vim-fireplace). With these tools, one may start a user repl and run tests within that. I have written a humble guide to set up Emacs for clojure here: http://gkayaalp.com/2014/01/28/taste-clojure.html#emacs My emacs configuration repository is gone thought; I'm using vim these days. A JVM with smaller…

> There are plugins for Emacs (nrepl) I think nrepl for emacs has been replaced by cider (which still uses nREPL)

AFAIK Cider is like SLIME, big and integrated. Emacs nrepl is just the repl connection, and is usually enough (at least, has been enough for me).

Re: JDK 8 Release Notes

#206

Post by jussij »

mahyarm wrote: post #186
cia_plant wrote: post #93

Earlier quoted context omitted.

No, actually, Java is a really bad language. It has a very complicated type system, but doesn't even allow you to express things like function composition or generic sums at the language level. Its syntax is stunningly verbose (e.g., no map literals; only now adding lambda literals; no type synonyms; no operator overloading). There is no macro system or method_missing or any other way of really extending the language…

Go work with C++, and you'll pine for Java.

And go work with C# and you'll pine for nothing.

I've used all three and after a few years of C#, the other two are just a distant memory.

Re: JDK 8 Release Notes

#207

Post by manojlds »

hibikir wrote: post #169
pron wrote: post #18

Earlier quoted context omitted.

A major cleanup of the Java libraries is scheduled for Java 9. The JVM actually does not surprise anyone who's been working with it for a while: it is downright the most performant, flexible and awesome runtime environment ever developed. I've been playing around with lots of languages and environments in my pretty long career and, in the past decade, have always come back to Java (or the JVM). It feels like driving…

The JVM has a couple of pretty significant problems when trying to work with functional-style languages. The biggest one is the way it deals with the stack: It's not in the heap, and it's pretty limited, so with something like scala, and more specifically with scalaz, you have to do some contortions to avoid overflows. 90% of usages of scalaz trampolines are nothing but ways to work around JVM limitations. I'd argue…

Azure?

Re: JDK 8 Release Notes

#208

Post by rurounijones »

bane wrote: post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

One reason I love JRuby.

The ruby language syntax with the power of the JVM and Java library interop.

As far as I am concerned that is a match made in heaven.

Re: JDK 8 Release Notes

#209

Post by edwinnathaniel »

puppetmaster3 wrote: post #197
edwinnathaniel wrote: post #140

Earlier quoted context omitted.

JS ecosystems in terms of quality, tooling, and engineering is already bad, can't be worse than that really... PS: No, yet-another-js-library-to-replace-jquery is not considered tooling. No, yet-another-replacement-for-grunt/bower/yeoman is not a good sign of the ecosystems. Java has Maven since 2004.

Maven is horible. Hth

It's awesome and other tools (bundler) are copying it or build on top of it (gradle, buildr, Ivy repo). XML is horrible, not Maven.

Python tools don't even come close. Ditto with .NET NuGet. Find me a tool that can compare feature by feature with Maven and still relevant for a long time.

Re: JDK 8 Release Notes

#210

Post by spiralpolitik »

I have to admit I thought Java was dead in the water after Java 6, but Java 7 while a fairly quiet release was a decent release and Java 8 actually moves the language forward into a better place. As for the future here's what I would like to see:

- Separation of language and libraries. Really the JDK should just ship with just a very small core of classes and everything else should be optional installed via a dependency or package manager. I know jigsaw is going in this direction, but I fear they are going to go the same way as J2ME with profiles. They should also clean up the cruft while they are doing this. This would allow the libraries to evolve separately from the JDK and even allow 3rd party framework to flourish while still keeping things reasonable manageable.

- Multiple return types. Scala has hacked around it, Python has them, Go has them. Bite the bullet and implement them so you can do sensible error handling without exceptions or returning `null`. While they are at it they could also fix the type system to finally allow `Integer hello()` and `String hello()` to exist in the same class.

- Implement Categories (or mix-ins). Seriously if I have to see another class called StringUtils or IntegerUtils I will gouge my eyes out.

- Get rid of the primitives. I read somewhere that this was on the cards for Java 10.

- Implement proper Generics.

- Implement @property just like Objective-C and .NET so that 80% of class files aren't getters and setters. I'm really surprised they never did this when they implemented annotations as this was the first obvious annotation to add. I know you can do it with Aspect J but you shouldn't have to. There was a JSR for this at one point but it seemed to disappear into the ether.

Post reply on HN