hutteman · HackerTrans

8 yıl öncediscuss

It's a bad thing because it would prevent new players from entering that market.

How could anyone successfully create a new competing product once the majority of the market uses the cheap Netflix+Hulu-only package, locking them out from any potential competitors?

hutteman

11 yıl öncediscuss

No, it's essentially a way to automatically map between manually written SQL and custom object types; you can use MyBatis with annotations only; no XML required.

The advantage is that, as you're writing and embedding actual SQL, you can take advantage of any database-vendor-specific extensions to SQL, plus you can easily run, debug and test such SQL from another tool. Having full control over the actual SQL also means you don't risk potentially horribly inefficiently generated SQL, or risk running into unexpected N+1 scenarios. At the same time, you don't have to deal with JDBC and instead get a DAO layer that uses strongly typed objects.

Of course the disadvantage is that you lose portability; moving for instance a MyBatis/SqlServer app to Oracle will mean verifying, testing and potentially rewriting every single SQL statement in your app. If you're willing to accept that risk though, MyBatis is a great lightweight library to manage your database access layer.

hutteman

12 yıl öncediscuss

I would say in most cases: no.

Due to backwards compatibility concerns, no existing Java APIs that may currently return null can ever be changed to return Optionals instead, so nulls need to be dealt with regardless. Also, there's technically nothing stopping an Optional value from actually being null itself, or from developers calling Optional.get() without checking isPresent(), just like they might currently use a reference without checking for null.

I personally really wish jsr305 had been adopted in Java8, and their existing APIs retrofitted with these annotations.

http://www.oracle.com/technetwork/articles/java/java8-option... describes Optional, and compares it to how in Groovy, the safe navigation and elvis operators allow you to write code like this:

   String version = computer?.getSoundcard()?.getUSB()?.getVersion() ?: "UNKNOWN";

With Java 8 Optionals, this instead becomes:

   String version = computer.flatMap(Computer::getSoundcard)
                            .flatMap(Soundcard::getUSB)
                            .map(USB::getVersion)
                            .orElse("UNKNOWN");

which is not only much longer and arguably uglier, but also forces developers to suddenly have to worry about applying lambdas using flatmap vs map, where conceptually you're really just dealing with method calls.

New languages like Kotlin solve this much better in my opinion by introducing nullable vs nonnullable types. While Java can unfortunately never adopt this due to backwards compatibility issues, @Nullable and @Nonnull will do most of the time, and hopefully we'll see operators like ?. and ?: in future versions of Java.

comments