No one is opening those emails about privacy updates - <AUTHOR> https://www.cnbc.com/2018/06/15/gdpr-emails-going-unopened.html <comment><USER2> > As a result, some email marketers stand to lose 80 percent of their > marketing lists -- or face huge fines from the EU if they keep trying to > email these people without permission.

Oh... no...

<comment><USER3> Of course, someone who loses 80% of their list the first time they ask their audience if they're still interested _might_ consider giving some thought to what value they were actually providing in the first place.

<comment><USER4> The mantra in sales is that "no" really means "tell me more".

So I don't expect anyone in marketing and sales to consider this as anything other than a challenge to find new and more effective ways of getting their mail into people's inboxes.

<comment><USER5> And this is why, despite the efforts of my parents to raise a well-behaved son, I do not answer the phone when I do not recognize the number and directly add "sales executives" people to the junk list.

I do use commercial products, usually because I actually searched for them. I then contact the company, which is usually ready to come and give a presentation.

And then comes the thing which really amazes me. I always tell them very clearly , several times: I do not want to hear any marketing bs or the fact that what they are selling is important. I already know this.

I also tell them I will discuss in very, very deep details such and such topic and I want someone knowledgeable to come or call in.

What amazes me everytime is that they are so surprised when they loose a 5 digit contract because they did everything but what I asked them, and that I end the meeting after 15 minutes.

I know first hand that selling is though. I also know that for such contracts I've need to actually listen to simple requests from a prospective customer.

</comment></comment></comment></comment><comment><USER6> Because it would take ~76 days to read them all...

[http://lorrie.cranor.org/pubs/readingPolicyCost- authorDraft....](http://lorrie.cranor.org/pubs/readingPolicyCost- authorDraft.pdf)

My spam account was recently assailed:

[https://i.imgur.com/bFyXgrf.png](https://i.imgur.com/bFyXgrf.png)

Reading them takes time. Deleting them takes time. Dealing with them takes time. Posting this... ;-)

</comment><comment><USER7> "and some are using them to unsubscribe."* Even better.

The system is working!

I've said before that "newsletters" are mostly just spam. Now the recipients have spoken. They don't want to hear from you.

</comment><comment><USER8> This article is pretty bad. It gets a bunch of stuff wrong.

> The GDPR requires companies to send emails to people on their mailing list > who have never bought anything, asking permission to keep emailing them

Emailing those people was already illegal under PECR. GDPR hasn't changed the legality of sending unsolicited email to people that you don't have a business relationship with.

> "People are not opting back in," says Michael Horn, the director of data > science for digital marketing agency Huge. "It's one thing for your > customers who don't have a relationship with the brand to decline and not > respond, but you're also losing a sales channel."

GDPR does not force a business to get consent for all processing. This is a persistant myth. If you have an existing business relationship and you obtained the email address legally you can rely on legitimate interests.

> "You never read the terms and conditions when you sign up for some website.

GDPR requires companies to make their T&Cs a lot simpler and clearer. This is a good thing. If you know people aren't reading your T&Cs how can you expect those people to be bound by them?

> Under these regulations, companies are relatively free to send emails to > customers who have purchased something from them. But sending email to non- > customers is common practice in the email marketing world. A lot of > companies ask for email addresses when you visit their web site, even if you > don't buy anything. Others buy email lists from third parties.

This is what people are defending. Sending junk email to addresses that you've bought. Getting someone's email address for one purpose and use it for another. (And, again, these are already illegal under PECR).

> Although the GDPR rules are only for the EU, European citizens living abroad > get the same protections.

No. GDPR applies to EU residents.

Someone somewhere is making a lot of money giving people terrible advice about GDPR.

</comment><comment><USER9> And they're updated privacy policy still allows them to track whether people are opening e-mails or not... I wonder why most people don't seem to buy into the privacy claims :-)

</comment><comment><USER10> It seems to me that the whole privacy notice thing is another version of the "bury them in discovery" tactic that lawyers use. Only a lawyer can read and understand all of these policies.

What we need are privacy notices that describe in plain language how a company's policy deviates from some standard privacy policy that we do take the time to understand.

If I were renting a car, I'd need to know how its operation is different from other cars. I don't need to read about how to do everything.

<comment><USER11> > What we need are privacy notices that describe in plain language how a > company's policy deviates from some standard privacy policy that we do take > the time to understand.

And that's exactly one point the GDPR asks for:

(39) ... The principle of transparency requires that any information and communication relating to the processing of those personal data be easily accessible and easy to understand, and that clear and plain language be used. ...

So thank you, EU!

</comment></comment><comment><USER12> only becuase they offer zero ways to control data sharing and communication. it is a legal document, and as such as dense, useless, and meaningless for non-lawyers (even for lawyers not currently involved in litigation with either parties)

absolutely none of those email help the sender gets any closer to be gdpr compliant, but we knew that since the cookie fiasco. just more of the same.

where is everyone who were saying they would send the "nightmare gdpr letter to google" on day 1 of gdpr? claiming that no company in the world could comply? I guess nobody expected useless emails and popups with no data control options to be enough for every EU regulator.

<comment><USER13> I have sent a couple of requests and waiting for a month deadline to escalate. None of the companies replied.

</comment></comment><comment><USER14> Of course not. Nobody wants to read that shit. It's meaningless drivel to 99% of people. After a couple, you just consign them to hell unread.

</comment><comment><USER15> > Most Americans are not opening those emails

Hmm, the only way they would know this is if they are tracking folks when they open the email, right?

<comment><USER10> I think it's routine to include a link to an image in every email. When the URL is loaded, they know you've opened it.

But this isn't reliable. People who block images don't record that they opened it. It's entirely possible that this accounts for "No one is opening those" privacy policy emails.

<comment><USER16> I thought most email clients block third party images by default? Certainly Outlook, Thunderbird, and K9 do. This must skew those results somewhat.

<comment><USER17> I think I saw statistics somewhere that most people read their mail via the web interface of their email provider, not via a client, and I don't know whether web clients block remote content loading.

<comment><USER16> I thought that might be the case.

</comment></comment></comment></comment></comment><comment><USER18> It would probably not help or change anything for the average person, but I would love a Creative Commons style initiative for privacy policies. It should provide a quick overview and indicate what data is collected and how it is kept. I imagine that there must be some sort of similarities from one policy to the other to the kinds of data that are being collected and to the ways it's being stored. Enough such that you could make a privacy policy out of those sort of easily indicated modular/progressive parts that Creative Commons provides for copyright licenses.

</comment><comment><USER19> Much like nobody reads a Terms of Service agreement, the fine print, or anything else that is perceived as an obstacle by the user.

I suspect a large number of them are trashed or marked as spam.

</comment><comment><USER20> In other news, water = wet.</comment>


Show HN: Letterlist – Discover Amazing Email Newsletters - <AUTHOR> http://letterlist.com

<comment><AUTHOR> Some of the best content never appears online but in the secret world of our inbox. So I made this little site to share some amazing newsletters. Enjoy :)</comment>


Gmail of an old man with 0 mails blocked - <AUTHOR> I'm writing this here because of how frustratingly broken is google's and gmail's terms and services. My grandfather's Apple ID (and therefore iPad) is completely unusable because the apple id is blocked awaiting email validation.
Minewhile, the gmail account, which was used only for the Apple ID, and had no other uses whatsoever, is also blocked. Downloading the mail you can clearly see there is no activity in the gmail at all, except Apple ID, and somehow Google found this account as violating its terms and services.
Apple's and Google's security policies have become a Kafkaesque nightmare. They randomly trigger account locking for no reasons, apple's strict Apple ID renders your device unusable while gmail can apparently lock you out of 'terms of services violation' when you literally did nothing. Old people can randomly trigger those lock downs and end up with unusable devices. Why the hell is google allowed to lock you down from even receiving (not even talking about sending) emails when their stupid heuristics triggers a random lockdown? <comment><USER3> Had a similar situation with my mother's iPad and Yahoo. YahooMail wouldn't allow a password change because my mother, having suffered an injury, moved and gave up her landline phone number, and had no alternative verification mechanisms set up. The native iPad mail app still connected via a cached credential, but those credentials can't be backed up. The iPad power failed sporadically, so she lost contact with people, with no way to transfer credentials to her new device (on the rare instance the iPad would briefly start), and no way to reset the YahooMail password. The only solution I heard that might work is to buy a paid yahoomail account on her behalf (assuming there's some way to verify her identity) and see if someone in support can get her back on the right track so that she can keep getting her spam and point anyone contacting her to her new address.

I hope this stuff gets easier before I get to _my_ 90s.

</comment><comment><USER4> I get how extremely frustrating and angering this must be! I'd recommend chatting with Apple Support or calling Apple Support first, since there's no way to do anything similar with Google (AFAIK).

Not that this can prevent such an occurrence for others, but my guess is that providing a phone number while registering for Google services and verifying that number makes the user more trustworthy to Google than otherwise. This is a big compromise on privacy for someone like me (and I've anyway switched to other providers), but anyone who's tied to Gmail/Google and does not want to use paid and better alternatives could probably benefit from this.

</comment><comment><USER5> Welcome to the world of algorithms, unaccountably going about their business while we entrust them with more and more power.

</comment><comment><USER6> Take devices to Apple store. Get protonmail account. Done.

</comment><comment><USER7> Just go into your local branch and politely ask to talk to the manager. They have the power to override all mistakes and are reasonable rational people.

<comment><USER8> Do you mean an Apple Store?

If so, that's not very helpful advice for many people. The nearest Apple Store to me is about three hours away. That's better than it was a couple of years ago, when I would have had to have driven six or more hours to get to one.

<comment><USER7> I'm being a smartass commenting on how that era of human intractable business is dying or dead.

<comment><USER9> That's funny and all but when someone is asking for actual advice it is also treating them in a way that is similar to using someone who is already down as a soap box to tell your jokes. At least put a /s in there.

</comment></comment></comment></comment><comment><USER10> If you are using a free product, your opinion of how to make that product act is as important as someone on the other side of the planet screaming, i.e.,, do not matter. If you are in need of a reliable email provide, sign up with a provider, which will not do such things in return of paying them some money. Problem solved. Free products are free for a reason. Because you are the product. If you are not using your gmail, google is not recouping what it is spending on keeping your account alive. Why should they do such a thing ? Businesses are there to make money, not to lose it.

<comment><USER11> This is a terrible argument. Our personal lives and digital lives are becoming amalgamated to an extent never seen before.

Our emails, for better or worse, are mainly handled by private companies while giving the importance of physical addresses.

We can't expect everyone to understand the nuances of this and should protect them from abusive practices of private companies. E.g. You should be able to keep a readonly email even after getting banned so you can slowly move off of it.

Google shouldn't be able to just wipe out a good portion of your digital identity through an algorithm or a press of a button.

Maybe this sort of legislation would make them double think their business decisions and if they want to stay in this business. I suspect they would, email is a massive part of their industry footprint.

</comment></comment><comment><USER12> If I were in your shoes I'd use other products/services instead.

The problem with the "billion user audience" products/services is that they do not have enough people (if any) as support when stuff like this happens.

Try other services/products as suggested by other posters here. It sucks but it's the only solution to this problem.

Good luck.

<comment><USER13> _If I were in your shoes I 'd use other products/services instead._

Not a lot of grandparents have the ability to just throw away a $500 tablet.

<comment><USER14> the resale market is pretty good for apple devices

</comment></comment></comment><comment><USER15> [https://getsupport.apple.com/](https://getsupport.apple.com/)

</comment><comment><USER16> Having never used an iDevice, is this actually correct? Is a Apple ID/Account actually required to use the device?

Android devices certainly dont require a Google account or any other account to use.

<comment><USER17> No it's not required. But if you want to backup your data without a computer, you need an iCloud account.

</comment></comment><comment><USER18> Well, ianal, but I would say that apple cannot block you from your legally owned device, so maybe good old fashioned letter or visit to the Apple customer support is order.

</comment><comment><USER19> Sad story, indeed :( I'm currently slowly, but steadily migrating to fastmail, and I can feel the burden off my shoulders each service i re-reroute.

I hope this gets resolved soon, I also recommend switching mail providers.

</comment><comment><USER20> > Why the hell is google allowed to lock you down

Google can do whatever they want with the _free_ service they're _giving away_.

Hell, even if they charged you for it, they're still free to end the service for whatever reason they want.

> from even receiving (not even talking about sending) emails

It's not like receiving is free for them or even cheaper for them than sending.

It's interesting how it's common to think that the services that Google gives away are some kind of public service, that they're somehow obligated to provide, as if they were paid for by taxes or something.

<comment><USER21> It's funny how some people will arbitrarily become a right-libertarian to come to the defense of some company but wont follow that defense through to its conclusion.

Sure, Google is a company comprised of shareholders but it's also a publicly traded company, which invokes numerous protections and services of the State, which no private person could ever dream of getting for themselves.

Many governments have entangled themselves with google, which is one of the most compelling reasons for Alphabet's current enormity. They do sketchy things for intelligence arms of governments, law enforcement, etc., which is taxpayer-funded.

People who truly believe in the principles you're invoking here - the idea that private property rights allow people to do "whatever" - would disagree with your fundamental premise, which tells me that you don't apply this position in a principled way.

<comment><USER20> I'm not sure I understand you. What do you think I'm not following through on? What does Google being a publicly traded company or their offering services to government entities have to do with their right to decide who to give away services to?

> People who truly believe in the principles you're invoking here - the idea > that private property rights allow people to do "whatever"

That seems more generic than what I said.

I'm also not sure I'd call it a principle. If a man is giving away sandwiches to everyone, would it be invoking principles to say that he has no obligation to give a sandwich to each and every person? I think it's just a statement of fact.

> would disagree with your fundamental premise

Sorry, I'm not familiar with this type of language. What is this premise that you refer to?

EDIT:

> people will arbitrarily become a right-libertarian to come to the defense of > some company but wont follow that defense through to its conclusion.

I'm not sure if the idea I expressed is right-libertarian. If it is, then ok. However, saying that I become right-libertarian seems to imply that I believe in everything that is right-libertarian, which might not be the case. Is your idea of following through to stick with one of these labels and everything they imply and the exclusion of everything implied with every other label? I'm not sure people and their ideals can be categorized so neatly like that.

<comment><USER21> > I'm not sure people and their ideals can be categorized so neatly like that.

Right-libertarians can be. Ideological consistency, which disregards one's own personal abstract preferences, is the name of the game within that political ideology.

Many people take on the form of right-libertarians when its rhetoric can easily suit the practical outcomes they seek. Social media censorship, when it is in a left-leaning person's favor, is often justified by their claiming, "Twitter are a private company. They can censor whomever they want." A more controversial example is the "pro-choice" argument for abortion in the US, which commonly holds the position of self-ownership, from where the phrase "my body, my choice," derives.

Many, or dare I say, most constituencies who hold these positions - <USER2> with which I agree wholeheartedly, by the way - will fail to carry them over to other issues where its application is just as logical, if not more-so. A great example is the gun control debate, where these same people will fail to recognize the property rights of law-abiding, non-violent gun owners. This is an arbitrary inconsistency, one which cannot be defended with ideas, only with emotions and fury.

If you are going to take the very brave position of respecting property rights, you had better be ready to defend them consistently. Otherwise, you will encounter numerous ideological, not to mention practical, pitfalls with your argument.

<comment><USER20> > Right-libertarians can be. Ideological consistency, which disregards one's > own personal abstract preferences, is the name of the game within that > political ideology.

Just because a person might agree with a right-libertarian on a specific point, doesn't mean they now have to adopt everything about their ideology or apply it in everything without regard to differences in the topics at hand.

> Many, or dare I say, most constituencies who hold these positions - > positions with which I agree wholeheartedly, by the way - will fail to carry > them over to other issues where its application is just as logical, if not > more-so. A great example is the gun control debate, where these same people > will fail to recognize the property rights of law-abiding, non-violent gun > owners.

Are you sure they fail to recognize them? or perhaps they do to an extent, but they see there are other points to consider regarding guns specifically, points that perhaps they value more than the recognition of property rights on this specific subject.

> This is an arbitrary inconsistency, one which cannot be defended with ideas, > only with emotions and fury.

It very much is arbitrary, and I think that's fine. Gun control is not exactly the same problem as the abortion controversy, though they have some similar aspects. In the case of gun control, some people will feel that unlimited recognition of property rights with regards to guns would lead to public safety issues. Different people will want to stand on different points of that scale, valuing property rights vs public safety.

I think this can be defended with ideas. The emotions and fury come from people not being able to articulate their ideas, or their not understanding the ideas of others, or perhaps having mutual understanding but seeing that they're a minority in how they're affected by proposed policies that everyone else seems to agree on. It doesn't mean there's lack of ideas. Ideas and emotions/fury are 2 different things. You can't use them for the same, and are best left mostly ignored, if not taken as an indication that something is lacking in someone's communication.

> If you are going to take the very brave position of respecting property > rights, you had better be ready to defend them consistently.

Well, I think I've stated my point, but to conclude, I don't think respecting property rights necessitates holding them above all else. That a person sees the recognition of property rights on one topic as the most important aspect doesn't mean they now have recognize it as the most important aspect in every other topic.

Every topic involves different aspects whether that's public safety, the property rights of a potential mother with regards to her body, the right to life of a fetus, etc. Every person will arbitrarily value each aspect differently, see the trade-offs that the issue at hand necessitates, and choose their position accordingly.</comment></comment></comment></comment></comment>


Ask HN: What Are the Big Problems? - <AUTHOR> I'm leaving this open-ended, there's no specific criteria for responses.
I'm interested in both your list and the reasons why. Submitting your list before reading other's contributions would be preferred.
Optionally: who is (or isn't) successfully addressing them. Individuals, organizations, companies, governments, other. How and/or why not? <comment><USER2> They're all interconnected and in no specific order.

1\. Water - Access to clean, safe water is an increasing concern in some highly populated areas. We will see a serious water issue in the US plains in 30 years, jeopardizing agriculture in that area.

2\. Food - Currently we produce enough food but it's not evenly distributed. We also have some concerns over sustainability and environmental impact. Estimates say we can feed 8-12 billion people depending on advances in technology.

3\. Waste Management - Feces and trash are a major concern. Gates is sponsoring research on toilets that don't require much water and don't require expensive treatment plants. Composting toilets could save a lot of water and possibly allow for cheaper, more water efficient greywater systems. This tech can also allow you to build in areas that skeptics were not traditionally possible. Compostable materials like cellophane, mycelium, or plastic substitute made from cassava or corn would help with the trash issue.

4\. Housing/Land Management - I'm too dumb to explain this. Maybe Mark Twain said it best with his statement about buying land since they don't make it anymore. This especially plays into agricultural with the shrinking amount of land suitable for agriculture.

5\. Education - No, I'm not talking about college. Basic logic/philosophy, personal finance, and civics need to be prioritized in school. To overcome the other issues we need a cohesive effort to make a meaningful impact.

<comment><USER3> I watched the bill gates documentary on Netflix about his investing in waste management. Very interesting but makes you realise that even in the first world or waste management is so inefficient and wasteful.

</comment></comment><comment><USER4> Managing the resources on the planet in a way that every human being has good quality of life and doing this in a way that's sustainable in the long term and without resorting to oppression, dictatorships or active population reduction.

<comment><USER2> Do you have an example of state-wide passive population reduction that doesn't involve oppression?

Also, this is perhaps the more eloquent version of my answer.

</comment></comment><comment><USER5> Solid state batteries potentially can make electric cars more affordable with longer range and fast charging times.

Nuclear waste has been piling up since the first reactors went online and are stored onsite. The US designated Yucca mountain in Nevada as the long term storage site but due to NIMBY it has been in limbo meanwhile nuclear waste keeps growing.

Rising sea levels are estimated to displace many millions of people which will lead to refugee exodus with many eyeing Europe and the USA.

Increasing bitterness and division in US politics make it easier for demagogues who promise quick fixes to gain power. These charlatans may lead us to a path of self destruction.

</comment><comment><USER6> Wikipedia has lists of big unsolved problems in different fields:

[https://en.wikipedia.org/wiki/Lists_of_unsolved_problems](https://en.wikipedia.org/wiki/Lists_of_unsolved_problems)

<comment><AUTHOR> Just to clarify, "unsolved" and "hard" does not necessarily correspond with "big".

</comment></comment><comment><USER7> Education - how can we innovate so that kids get the best education tailored to their learning style and interests?

<comment><AUTHOR> Do you have any particular suggestions or concerns in this space?

<comment><USER7> There was an interview on one of the Knowledge Project podcast episodes last year. I was driving home from work, and it was raining, so I do not recall the exact episode. But the person mentioned that they were trying to learn drums. They found a video on YouTube that taught some specific thing they were looking for. The only issue was that there was 5 minutes of film in the beginning that had nothing to do with teaching the drums.

He made the point if you had a Hollywood production team and a subject matter expert, you could make amazing online educational videos that people would actually like to watch.

The closest thing I could find now is a high school history teacher making animations on YouTube called MrBettsClass.

There is so much potential here to expand this.

Then there is the other angle. Are there best practices we could do as a nation? Not common standards that lump everyone into one category, but actual things tailored for different types of children that could maximize their learning?

I adopted this notion that every child has the potential for genius after reading the book How to Teach your Baby to Read. Its been around since the 60s. I think it comes down to a lot of one on one time with the child. You try teaching something and adapt to how they respond. Technology can only help so much in this regard. You have to be a parent that is invested in helping your child.

</comment></comment></comment><comment><USER8> People hate other people. This causes huge amounts of damage, both to the hater and the hated.

Going a bit farther, people dehumanize other people, and then feel all right about treating them inhumanely. They do so based on race, gender, cis/trans status, politics, religion, sometimes even sports teams.

</comment><comment><USER9> Overpopulation is the mother of many big problems, the resources needed to support the ever growing population are destroying this planet

<comment><AUTHOR> How would you answer those arguing, variously:

1\. It's wealth inequality / extreme weath / the wealthy nations (say: OECD, G-8, G-20) which are the bulk of the impact problem.

2\. Technology will transcend any inherent global limits.

3\. Limits may exist, but Earth could sustain far more people, possibly trillions.

4\. Attempts to limit reproduction are authoritarian, eugenicist, and/or nationalistic.

</comment></comment><comment><USER10> One is to get out of ad-revenue driven business models for news and websites in general.

<comment><AUTHOR> Any suggested path(s) forward on that?

</comment></comment><comment><USER11> Quality Software : Yes, this is becoming more and more important and is overlooked at many levels. With more of our infrastructure, lives and the future of humanity in the hands of a bunch of software & hardware. We need to take things a tad bit more seriously. I believe this is not yet a big problem but it is becoming one.

[https://youtu.be/pW-SOdj4Kkk](https://youtu.be/pW-SOdj4Kkk)

[https://xkcd.com](https://xkcd.com)

<comment><AUTHOR> I'm presuming you meant [https://xkcd.com/2347/](https://xkcd.com/2347/)

</comment></comment><comment><USER12> I would say how do we help the poorest people in the world? How do we help homeless people in a holistic way and prevent homelessness. How do we counterbalance the power corporations have to sway governments to do things in their interest and against the public interest. All these things are probably connected. At the core how do we make society attitude more humanistic include myself.

The reason is well human decency for a start. And it is hypocritical to look down on people that harm other people if we are doing it systematically.

</comment><comment><USER13> US Fed printing money, igniting inflation and letting US economy going down the drain.

<comment><USER8> So far, inflation appears to be un-ignited. I'm not sure we can keep doing this forever. But so far, evidence for your fears is missing.

<comment><USER14> From the year 2000 to now there is 50.5% inflation. That is pretty good evidence to me. But hey...at least the stock market is up.

[https://www.usinflationcalculator.com/](https://www.usinflationcalculator.com/)

<comment><USER8> That works out to 2.06% a year. That's not "igniting".

I'm old enough to have seen 14% per year inflation in the 1970s, so 2% doesn't impress me as inflation igniting. More to the point... where's the inflation from QE in 2008? It, um, never really showed up. We continued creeping along at 2% a year, sometimes less. So I'd regard that as experimental refutation of the "Fed printing money, so inflation is going to ignite" thesis.

More precisely, I think the Fed printing money _can_ ignite inflation, if they print more than the economy grows. In 2008, they didn't do that with QE. They created $4 trillion, which almost exactly offset the $4 trillion that vaporized in the crash, and the result was that we avoided another Great Depression without igniting inflation. The Covid crisis... well, it's too early to tell, but they might pull off the same feat.

2% inflation per year since 2000 is evidence of great stability, not of out- of-control Fed money printing.</comment></comment></comment></comment>


How Sanjay Jha Overhauled Motorola's Culture - <AUTHOR> http://bits.blogs.nytimes.com/2009/10/29/how-sanjay-jha-overhauled-motorolas-culture/?ref=technology <comment><USER2> This is a problem.

1.

You have to put one person in charge of an app or project so that she takes care of maintenance. But putting one person in charge - as the article says - "gives executives no incentive to say their product line is on the decline and the technology used by a rival group will be the next big trend."

2.

But if you don't put one person in charge, the problem of getting good ideas improve. But it raises another problem: maintenance suffers. No one takes the responsibility of maintenance.

Its a catch-22. I think there has to be a mix of both the models: 1. Hierarchy for accountability. 2. Councils for idea generation. 3. And a mechanism that both models work well together.

<comment><USER3> I think putting one person in charge ,while may cause a decrease in the number of good ideas, overall it will result in less distractions and bring in more focus into the product, also the ideas that get through are executed much more efficiently. Also as the article stated that by using the earlier model they did miss on lot of transitions, that can be avoided as well.

</comment></comment><comment><USER4> Isn't it Dr. Jha ?</comment>


An Opinionated Guide to Modern Java Development, Part 1 - <AUTHOR> http://blog.paralleluniverse.co/2014/05/01/modern-java/ <comment><USER2> I like the changes in Java 8, but I'm concerned about Java fragmentation between Oracle/OpenJDK and Android. It seems Android is stuck on Java 1.6 (since Dalvik is not "true Java" and is more like a VM that happens to implement a language very similar to Java 1.6). There's now a huge gap between 1.6 and 1.8. It's not just syntax like lambda and default methods. It's also the supporting API changes in collections (streams) and others. Dalvik was based on Apache Harmony which is a dead project and will never get the Java 8 API changes implemented. Does anyone know if Google is going to do something about Java 8 and Android?

<comment><USER3> There is a good reason that Sun didn't want this to happen and tried to stop it in court — successful against Microsoft, failed against Google. If I remember right, most everyone on here was rooting for Google to win and continue to fragment the language.

<comment><USER4> The question is what Oracle would lose by licensing real Java to Google at reasonable conditions. Mobile non-Android Java is deader than dead.

<comment><USER5> > Mobile non-Android Java is deader than dead.

Lots of embedded devices make use of J2ME, e.g. cars, manufacturing, electricity monitoring...

<comment><USER6> How many of those will get Java 8 updates?

</comment></comment></comment></comment></comment><comment><USER7> I'm back to java after having an unsatisfying experience 2 years ago with Spring MVC, (this time i use the "play framework"), and it seems to confirm my intuition that the language itself is really just fine. The problem lies more in bloated frameworks and corporate culture where everything needs to be standardized, regulated, and the purpose of a mandatory non-free training session.

Add to that the fact that every single topic is covered by at least 3 or 4 libraries, and you get a more complete view of the situation.

<comment><USER8> How's Play! compare to Spring? I'm working on a bloated Spring whale (1.5M LoC, 485 Spring XML config files) and wondering if something like Play! can do it better, or if complexity is simply a beast that will inevitably turn any project into a turgid mass.

I ask since friends at Google will laugh at a bar if you even say "Spring," but I'm curious what else can do it all (Guice/Gin?). Perhaps nothing can and the trick is to simply have small, cohesive projects linked by common REST (et al) API's and to merely skirt complexity entirely. However, for workflow and state management, you'll inevitably need some common integration point.

<comment><USER9> I did a side project in Play! some time ago. While it was generally OK to use, Java in Play is definitely a second class citizen compared to Scala. Most documentation (which btw is sorely lacking) concerns how to do stuff with Scala and you'll have to figure out how to do the same in Java yourself.

Even worse, breaking backwards compatibility between even minor releases seems to be standard for this framework. So once you've finally managed to find some piece of documentation from some random source on the net (as again, the official documentation is pretty much a joke) you'll find that it doesn't work at all because it was written with Play! 2.0 in mind which is different from 2.1 which is different from 2.2 and so on.

Once you figure it out, it's a pretty nice framework. It's a shame so little attention seems to be paid to exposing that in a better fashion.

<comment><USER10> > Java in Play is definitely a second class citizen compared to Scala

Much agreed. I started a side project with a quick deadline with Java in Play and switched to Scala (even though I had to learn Scala) just because they played better together.

</comment></comment></comment></comment><comment><USER11> One of my opinions these days on javadoc is that you should be minimalist. Have nothing to say about the return type? Don't add @return. Same for @param. Just a sentence about the method/field/class? Just a single line /* * ... */ is fine. Have nothing of value to say on a method/field/class (e.g. a getter), don't add javadoc at all. I'm growing weary of large files with tons of redundant javadoc lines to make some checkstyle/pmd rule happy.

<comment><USER12> Seconded.

I always bristle when I see javadocs that include things like 'returns an object of [x] type that...' You're dealing with strong types, the signature provides all this information _already._ That, combined with good variable names, should do a lot of the documentation for you.

If you wanna document a method, document what problem it solves. Document any gotchas (or better yet, redesign them out o_~). Don't just repeat what reading the method's signature already tells me.

<comment><USER13> That pisses me off but the following is much worse. The commit comment that goes:

"checked in abstract_class.cpp"

Duh!

<comment><USER14> I do that a lot, or rather my commit messages are usually "mumble" or "fixed this" or "awookga". I feel this is more justified than the javadoc case because you can always just leave out javadoc, whereas the VCS forces me to put a commit message.

<comment><USER15> Just a humble suggestion, but perhaps you should enter a message which states the _intent_ or the _functionality_ of the change more explicitly. (If you're just doing a topic branch, then sure, just say "wip" or "blah", but please clean it up with "git rebase -i" before merging.)

<comment><USER16> Yes, even something trivial like "fixes whitespace" is better then nothing, but even better is squashing or amending a previous commit. Some systems prevent this...at my workplace once you've pushed to origin, there is no changing the past so saying something like "Added derp.java to fix broken build from <commit hash>" is very helpful.

</comment></comment></comment></comment></comment></comment><comment><USER17> > But the modern Java developer uses Gradle

I'm a little skeptical of this. More like the developer in the future uses Gradle. Usually when I go to a project's home page, I see documentation on how to include the Maven dependency, not the Gradle dependency. It's pretty obvious how to convert one format to the other, but my point is I think most people are using Maven.

<comment><USER5> Gradle is mainly being pushed by Grails and Android development.

I don't know of any other project using it. We are always doing Maven or Ant.

If Gradle is the future I hope it gets improved, I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling.

<comment><USER18> > I gave up on Android Studio given its dependency on Gradle and how it drags > my dual core with 8 GB to its knees when compiling

That could be the slow, dynamically-typed Groovy in Gradle that's dragging your machine. Gradle needs to bundle another build language. Since the goal of statically-typed (and hence speedier) Kotlin is to make it easier to write IntelliJ IDEA [1], on which Android Studio is built, instead of using Java, the logical choice is Kotlin.

Gradle's developer says they'll happily support any community effort to create additional build script engines other than Groovy, but it isn't a priority for them right now [2]. Perhaps the Kotlin team need to kick off a Kotlin build engine for Gradle (though because one of the Kotlin developers was a victim of the Groovy++ fiasco, I'd understand if the Kotlin people are hesitant about having anything more to do with Groovy ecosystem software like Gradle).

[1] [http://blog.lunatech.com/2011/08/24/scala-ceylon-kotlin- goal...](http://blog.lunatech.com/2011/08/24/scala-ceylon-kotlin-goals)

[2] [http://www.gradle.org/overview](http://www.gradle.org/overview)

<comment><USER5> Kotlin was exactly the reason I was thinking to move from Eclipse ADT to Android Studio.

So far I have been using the Eclipse ADT/CDT for my hobby development, mainly with C++ (just graphics stuff).

Then I thought to try out Kotlin instead, but could not. It was worse than waiting for my NDK C++ builds to finish, with the whole computer at 100% CPU usage.

I ended up filing a ticket, like many other developers already did.

</comment></comment></comment></comment><comment><USER14> The #1 thing you need to make Java usable is to abandon the JavaBean conventions. When every field requires 8 lines of boilerplate it's no wonder the code looks ugly (YAGNI, and if you do need it it's two keystrokes in your IDE to "encapsulate field"). public final fields are fine, and can get your data classes something close to readable.

I'd stick with maven for the build rather than Gradle; it's completely declarative and all the tools understand it. Learning a new language just to configure your build tool seems excessive.

<comment><USER19> For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could be better though.

<comment><USER14> > For starters, you can see Groovy as "Java without semicolons"

Not if you have to read other people's code, or understand examples you find on the internet.

> I went from Maven to Gradle and never looked back. It's superior in most > ways.

What's it better at? I want my build tool to be simple; maven compiles my source and does my releases, and the main thing I have to configure is just a list of dependencies (in an admittedly verbose format). I'm actually a scala programmer, but I use maven rather than SBT because it seems to me that having lots of logic in the build system could only lead to bad things. So what are the things you see it helping with?

<comment><USER19> See my reply to vorg regarding Groovy. As a developer the argument "I don't want to learn something new" is invalid.

Gradle offers the declarative nature of Maven without pushing it down your throat. You don't have to write a plugin for something that can be expressed in 3 lines of Groovy (but you can, if you want to!). Instead of adapting your build to Gradle, Gradle adapts to your needs. That's often a point of criticism from Maven users, because every Gradle build looks different. But that's the point: Everyones needs are different. Of course that only applies if your build is beyond the standard compile/test/release configuration. A simple configuration looks pretty much like a Maven POM (minus the tag soup).

</comment></comment></comment></comment><comment><USER20> I'm using Java for the first time because of Android. I had played with Java when it first came out but have stayed with C/C++/C# for almost everything.

I have to say that my Java experience isn't as unpleasant as I thought it would be. I always thought C# is what Java should have been but after learning a little idiomatic Java the reality is quite okay, really.

<comment><USER21> In a lot of ways C# is still a much superior language than Java, but the JVM (I'm thinking HotSpot) is tremendously better than the CLR.

<comment><USER5> I follow Grail and now Truffle development since the days of the Maxime VM.

Looking forward to the day the reference JVM becomes a meta-circular one.

</comment></comment></comment><comment><USER17> That pluggable type system looks amazing. One thing that's weird to me is how java included a new Optional type (seems similar to Haskell's Maybe), but the compiler (afaik) doesn't prevent you from setting an Optional field to null. Something about that doesn't feel right. (Side Note: Optional isn't serializeable. Also... what's the best practice for using Optional when I'm using JPA? Can it be used in my Entities?)

I believe Jetbrains/Intellij-IDEA has created annotations for @NotNull/@Nullable, but afaik these just create warnings in the IDE. Maybe you can configure IDEA to mark these as compiler errors, but I don't know if my peers using netbeans/sublime/whatever would be able to notice when they write code that IDEA will refuse to compile.

I want compilation to FAIL in these cases.

<comment><USER22> The main issue with non-nullable types in OOP, in my mind, seems to be defaults. Quite simply, when you don't initialize an primitive, you get a 0, and when you don't initialize an object, you get a null. Not all fields must be initialized by the time the constructor ends, so some kind of valid default exists.

Enforcing non-nullability would involve somehow enforcing that the variable is always valid before use some other way, like how "final" is enforced in the constructor, but it should be possible.

Unless you make it default, though, it won't be as "elegant" as the haskell Maybe, and doing so would net you a very very different language.

<comment><USER5> Outside the JVM world, Eiffel does it.

In the JVM world, Kotlin and Ceylon do it as well.

</comment></comment></comment><comment><USER23> A lot of people love to hate on Java, but it's a surprisingly dynamic language and there is a ton of great testing, networking, and many other libraries available.

One of the things I appreciate about Java is the ability to take large teams and just have their stuff work together, without having unhuman discipline around super subtle rules (eg: C++)

Also, IntelliJ is a must have!

<comment><USER24> In what way is Java a "dynamic language" ?

<comment><USER25> I think "dynamic platform" would be more accurate. Java has typically been a fairly conservative language sat on a much more interesting VM, a VM which has rather more features in common with dynamic languages like Smalltalk than you'd expect.

<comment><USER23> but you can always escape with cglib and rock out.

So even though java the language isnt dynamic, you can do a lot more at runtime, than with these new-fangled languages like Go and Rust.

</comment></comment></comment></comment><comment><USER26> I love Java, especially Java 8. But as the article points out, what frustrates me is threading. You can't do much without quickly running into threading issues. I played audio files in a game I made and it created up to 2,000 threads and crashed. Once I wrapped audio in an explicitly created thread this issue magically went away. Any kind of UI, timers, file I/O and network activity also involves threads.

The really horrible thing about these threads in Java is how hard it is to not share memory across them, because if you do terrible things happen. In other platforms you don't have to involve threads unless you want to, and you definitely aren't boxed into a situation where it becomes easy to accidentally share memory across theads.

I like Go's way of handling this. node.js is single threaded but the event loop makes it possible to do non-blocking IO without crazy Jave thread issues. Using synchronized, atomic properties and locks is not the right way to do these things as your code gets really complicated when trying to do basic things.

That gets me to my other pet peeve with Java. Just how much boiler plate there is to do basic things like opening up encrypted TLS TCP connections. Tons of cruft.

Anyway, having said that, I love Java and use it, but these things need addressing. I like Scala's Akka, I hope Java comes around and improves the horrible thread situation. I will have to check out Quasar. I know I just need to become more familiar with threading in Java in general. I'm actually pretty new to Java.

<comment><USER27> Sounds like it's the implementation of the audio library using thread in the wrong way. Has nothing to do with threading in Java. Nodes could have the problem of starving the audio playback if other parts of your code hogging too long of processing time. It's just shifting the problem around.

<comment><USER26> I'm not using an audio library. I'm just using Clip and AudioInputStream

</comment></comment></comment><comment><USER28> Good article, lots of opinions but the title forewarns. For me, Eclipse is still very good and if anything, more stable than in earlier years. I've tried NetBeans and the free IntelliJ but though those are fine, Eclipse is better for me. The real trick is to _not_ store your code in the workspace (which is ironically where the project wizards default to unless you change it). Store your code in as an example, svn for Subversion, git for Git, etc. Use the workspace as just a shell to manage Eclipse preferences and such.

<comment><USER29> As an eclipse user this suggestion intrigues me, but I'm not sure what the workflow would actually look like. Do you have a pointer to an article or something? Thanks.

<comment><USER28> Sorry no link, co-workers and as "smrtinsert" said, Git or for me having both Git and Subversion projects makes life easier keeping source separate from the workspace.

<comment><USER29> Do you use the link source tab of the "Java Build Path" to point to the project directory in the source control directory?

<comment><USER28> Nope, never used that. For Git it's straightforward, I have one Git repo per project I manage with Git. just use Import Project. The code remains where it is at.

For SVN, I use Checkout and uncheck "Use default workspace location" and specify the location of the code.

</comment></comment></comment></comment></comment><comment><USER30> The biggest take I have from this post is that apparently they have created go-like lightweight threads for the JVM with Quasar ([http://docs.paralleluniverse.co/quasar/](http://docs.paralleluniverse.co/quasar/)) which is really interesting.

If I understand correctly, Quasar uses bytecode instrumentation to enable user-mode threads for the JVM, and they claim they did benchmarks that show X6 to X12 better performance than native JVM threads: [http://blog.paralleluniverse.co/2014/02/06/fibers-threads- st...](http://blog.paralleluniverse.co/2014/02/06/fibers-threads- strands/#benchmarking-fibers)

This is really something that caught my attention.

<comment><USER5> The initial JVMs already had Go like threads, aka green threads, with red threads being OS ones.

The language specification does not require a specific implementation and with time all JVMs moved to red threads.

There are a few JVMs around that still support green threads as threading model.

</comment></comment><comment><USER31> Something that really resonates with me from the linked PDF ("Blue-collar language") published in 1997:

> What I found most interesting in watching people use Java was that they used > it in a way similar to rapid prototyping languages. They just whacked > something together. I was initially surprised by that, because Java is a > very strongly typed system, and dynamic typing is often considered one of > the real requirements of a rapid prototyping environment. [...] you find out > fast when something goes wrong.

Despite working in JS and Python, sometimes I feel more comfortable hacking something up in Java, because every missing method or undefined variable is an unavoidable short-term TODO.

</comment><comment><USER32> I appreciate the modern Java style espoused here, it's much further away from the horrible overdesigned & pointless configuration style I often see with Java.

However, the author doesn't really understand _why C++_ and dismisses it quickly. The short answer is C++ gives control and abstraction on demand, an unusual combination. Java trades control in exchange for GC.

<comment><USER5> > The short answer is C++ gives control and abstraction on demand, an unusual > combination.

Ada, Modula-3, the Oberon language family as well.

But they lacked a proper OS vendor support and faded away.

Ada seems to be raising up, thanks to GNAT and continuous security issues with C and C++. At least from its increasing presence at FOSDEM.

<comment><USER32> Well, yes. And more than a few other languages that got left in the dustbin of our history. But as for today...

I actually am personally very keen on seeing where Rust goes here, but it isn't 1.0 yet (which will be the signal for me to start writing in it seriously ).

<comment><USER5> Me too, alongside D, .NET Native and the Graal/Truffle compilers.

</comment></comment></comment></comment><comment><USER12> Ironically the Java ecosystem could stand to use some garbage collection of its own: there's a ton of old, outdated info out there that both colors people's impressions of the language and teaches new players a whole manner of bad habits. I appreciate what this article's going for and hope there'll be follow-ups.

I use Java daily and though there's undoubtedly room for improvement (I'm looking forward to when tooling better supports stuff added in Java 8), I think a lot of the negativity that surrounds it is undeserved. There's definitely bloated XML-infested frameworks out there but the core's a real workhorse.

<comment><USER31> > old, outdated info out there

I'd love it if the JDK had a "learner mode" that _disabled interned string literals_. Then newbies experimenting with `assert(str1 == str2)` wouldn't leap to false conclusions.

<comment><USER14> == should never have been used for that method, which is very rarely what you want. The right thing is probably to deprecate == on nonprimitive types, replacing it with a longer name that's clearer about what it means.

<comment><USER33> Or make == call .equals and add a .referenceEquals method for the case where you actually want to check for reference equality.

This is what Scala and C# do.

<comment><USER14> That would indeed be nice, but is incompatible with Java's approach to backwards compatibility.

</comment></comment></comment></comment></comment><comment><USER34> > In this example, Java is rather annoying, especially when it comes to > testing the type of a message with instanceof and casting objects from one > type to another.

Using instanceof is an antipattern 99% of the time, easily avoided with proper API design. In this case a simple enum type would help with appropriate getType() method on the event; or a polymorphic event API with dedicated method types for each event (LifecycleEvent marker interface with ExitEvent subtype containing onExitEvent(ExitMessage m), etc), or ... or ...

Writing an intro to Java + touting your company's API + blaming Java for yourco's API problems: seems like bad form.

Which reminds me: can someone explain how actors is any different than using messages and queues for concurrent programming? Unless it also implies "magic translation of messages to method calls" which makes me uncomfortable (bad memories of CORBA/Web services)

<comment><USER35> Agree that instanceof is wrong and discredits the article.

I'm not sure if this is what you meant, but here is how polymorphism along with the double dispatch pattern would work: NaiveActor#handleLifecycleMessage will need to delegate to the event subclass, which will in turn select the appropriate method on NaiveActor.

Example of subclass of LifecycleMessage:

            class ExitMessage implements LifecycleMessage {
                @Override
                void handle(BasicActor actor) {
                   actor.handleExitMessage(this);
                }
            }

In NaiveActor:

            @Override
            protected void handleLifecycleMessage(LifecycleMessage m) {
                m.handle(this);
            }

            @Override
            protected void handleExitMessage(ExitMessage m) {
                if (Objects.equals(m.getActor(), myBadActor) {
                    System.out.println("My bad actor has just died of '" + m.getCause() + "'. Restarting.");
                    spawnBadActor();
                }
                return super.handleExitMessage(m);
            }

It's been my experience that many developers resort to instanceof or enum type flags because they don't believe polymorphism actually works in real world situations such as this.

<comment><USER34> There's something wrong with this approach, though: it couples ExitMessage and BasicActor, in that BasicActor would have to have a method for each event type, resulting in lots of empty methods, etc.

What I'm describing is a marker interface for eventing, with specific subtype APIs:

      interface LifecycleListener { }

      interface StartListener extends LifecycleListener {
          void onStart(Foo f);
      }

      interface ExitListener extends LifecycleListener {
          void onEnd(Foo f);
      }

along with a single registration method (perhaps a LifecycleObservable API, or in a class also offering event-firing methods):

      Disposable addLifecycleListener(LifecycleListener l)

The benefits to the client code are numerous: clarity (dedicated methods for events), declarative code ('implements' section documents interactions), performance (no dispatching in client code).

[Note, Disposable here represents a dispose() function to deregister the listener, avoiding the classic pair of void register/deregister methods. Often I find void methods represent a missed opportunity ... wishing Java was more like Smalltalk here]

The service side has to jump through some hoops to efficiently dispatch, using class equality or instanceof at registration time to pre-select listeners. This code could certainly use pattern-matching but personally I think it would look identical. If anything, I'm glad that pattern-matching isn't available in this case, to at least alert framework devs to the problem and not push it off to tons of switching on the client.

</comment></comment></comment><comment><USER36> It's ironic, I'm slowly trying to move my development over to scala. I'll likely integrate gradle in to my stack (still use maven =/ mainly because I know all of its weird quirks)

What have people's experiences with gradle been? I'm not a huge fan of groovy hence why I stayed away from it.

<comment><USER37> IMO Gradle has made huge improvements the past couple years (when I first started using it a few years ago it was incredibly unstable) but if you are a semi-power user of Maven I think you're going to find yourself frustrated using gradle still for a couple reasons (I've looked into this for my work recently, moving away from Ivy). Note I haven't extensively used Gradle, this is just from research:

\- Intellij has incredible Maven support, and by this point almost all the bugs have been worked out. Gradle support is improving, but our company has dozens of modules, a mix of Java / Clojure source code, and depends heavily on Intellij automatic source linking working correctly, dependency propagation working 100% successfully, etc, and it's really easy for small bugs to become blockers. Last I checked there were still a number of pretty frustrating bugs related to this

\- The Jenkins maven plugin is great, and the Gradle one is mediocre. For example, it does not even handle automatic triggering of downstream builds (this is absolutely critical for us [https://issues.jenkins- ci.org/browse/JENKINS-19941](https://issues.jenkins- ci.org/browse/JENKINS-19941))

\- Gradle pretty decent plugin support by now, but is not yet as exhaustive as what you'll find with Maven (there's a maven plugin for basically everything now)

\- This may have been resolved, but I had issues configuring getting Gradle to update snapshot dependencies, which was really important to us.

In the end I decided to migrate to Maven to avoid these headaches. I think I will try to use Gradle for personal projects, but I don't feel comfortable migrating our company stack there yet.

<comment><USER36> Really appreciate the insight, this is what I have found as well. Especially using intellij, it's still hard to beat. I'm always on the look out to use new stuff, but I'd rather wait a bit..

If I go hybrid JVM, I will likely just use SBT instead.. I think I'll keep an eye on gradle and see if it matures though.

One of the reasons I still use maven is like what you mentioned: the tooling, I don't find myself using xml most of the time (despite knowing it like the back of my hand anyways)

</comment></comment></comment><comment><USER38> The position of things like Netty and Undertow at the top of the techempower benchmarks has me a little intrigued. How much hassle is it to write websites with servlets like that?

<comment><AUTHOR> A bit of a hassle, but Comsat will make it dead-easy (right now Comsat runs on top of any servlet container, but it will also run directly on top of Netty/Undertow). Take a look at our Comsat web actors: [http://blog.paralleluniverse.co/2014/01/28/web- actors-1/](http://blog.paralleluniverse.co/2014/01/28/web-actors-1/)

</comment></comment><comment><USER39> I went from Java to Scala and am back to Java 8, and couldn't be happier with my choice. We are also using the latest Spring 4 framework which plays well with Java 8.

A lot of the Spring + Java haters haven't really looked at all the improvements have happened to both Spring and Java recently, either that or they just like to bounce off what they read online without any actual experience.

It's a solid stack for a backend, and I have built the whole platform on in without a hitch.

</comment><comment><USER40> What about dependency injection in modern java - is Guice or spring still the de facto standard?

<comment><USER28> I try to avoid it as much as possible. It's confusing at least to me and makes maintaining code over a long haul an arduous dull process. I'm getting to the point where I prefer straight JDBC over Hibernate too. It takes longer to code but I've seen speed increases of several times over Hibernate in those situations. JDBC code is just linear but I feel it's easier to maintain in the long run.

<comment><USER41> I agree. Hibernate has become a downright liability at times in our codebase. These days I only use it in new code for query parameterization and result row transforms into models.

Speaking of which, if anyone knows of a good library for query parameterization alone, let me know...

<comment><USER42> JDBI is quite good: [http://jdbi.org/](http://jdbi.org/)

<comment><USER43> We use JDBI @Truecaller together with Metrics library. Not only it is clean and tidy, it also gives you immediate profiling around your database calls. This is priceless in a big service oriented environment. With it, you can exactly see the rate of happening (mean/last 1/5/15 minutes average) and latency (mean/avg/std-dev/75/95/98/99/99,9percentiles) for each database query. I wouldn't want to go back to manual logging and optimization hell. JDBI+Metrics opens a totally new dimension to your monitoring/profiling/optimization!

</comment></comment></comment></comment></comment><comment><USER44> I have come full circle in a way. I started learning Java in school and built a few, small things for Android and the desktop. Then I was "all like;" I am going to learn the hotness which was(is?) Node. Node is what it is and I didn't really care for it. Then I moved on to Python and I really like it. Python is awesome for many, many things but GUI applications are not one of them. I have since returned to some Android development and I am diving into a CRUD web app in Java. Simple stuff, but it needs to be fast.

Looking forward to part 2 and more!

</comment><comment><USER45> Why do people seem to think "opinionated" is a virtue these days?

<comment><USER14> Because, particularly in Java-land, if you're not opinionated you end up providing a FactoryFactoryFactory. A beginner is in no position to weigh up the pros and cons of the different build tools available, so it's better for a guide to simply make a recommendation and explain that one than to give the beginner a confusing choice.

</comment></comment><comment><USER46> >But the modern Java developer uses Gradle...there are quite a few things that are quite, though not very, common, but still require dropping down to imperative Groovy.

This is the first time I have heard of Gradle, but why would I use a build tool that requires me to learn Groovy. If I already know Java I wont be learning something new just to build a Java project.

I find a lot of development tools/frameworks make me learn B just to get started with A, its really frustrating for someone with limited experience IMHO.

<comment><USER47> I wouldn't say you need to actually learn Groovy to get going with Gradle. The example build.gradle files are fairly self-documenting, and you'll be modifying them more than writing them from scratch.

Easier to read than a pom.xml, for sure.

<comment><USER46> >Easier to read than a pom.xml, for sure.

In that case I will have to check in out on a side project. My current projects at work are using Ant or Maven and I dont really like sorting through the pom.xml especially if someone else set it up.

</comment></comment></comment><comment><USER48> I have to agree with the first comment on the blog. Gradle is strictly worse than Maven - it's basically Ant reinvented with Groovy. It leads itself to poorly maintained, complex build files, and the only good parts are the bits that use Maven under the hood (so just use maven ;-)). It's also slow.

Also, if you seriously want to use an Actor framework in Java, you should use Akka - the lead devs really know their stuff, and are active in Java concurrency circles (JSR-166).

</comment><comment><USER49> I'd like to hear thoughts on CheckedExceptions in part 2. IMO, they are a disaster - most projects degrade into all methods having a "throws Exception" clause. But I'm not sure if there is any consensus on how the CheckedException haters like myself work around them. I use Runtime exceptions everywhere, but it's a pain/boilerplate to convert them.

<comment><USER50> I think some of the additions in Java7/8 will make them a little easier to work with. The worst thing used to be the necessity to nest multiple try/catch blocks, or repeat identical code between separate catch blocks because different components throw different errors. This is now dramatically helped by the multi-catch and other additions.

Like you, I use a lot of RuntimeExceptions, but I think in it's important not to overlook the benefit of checked exceptions: if you're trying to write reliable software looking up and understanding every possible failure mode of every API you are calling is an almost unbearably tedious and impossibly boring task. In principle, having the compiler check and tell you "Hey, there's this error that could occur and you haven't defined how your code is dealing with that" is a tremendously useful thing. Our human tendency to focus only on the successful path through our code and then ignore all the possible failures is terrible bias if you're trying to make code that behaves the right way under ANY circumstance. So I support checked exceptions, and I hope the new improvements in Java make them more workable and accepted. There probably need to be more improvements, something long the lines of STM type features before we'll get there though, I think.

<comment><USER49> 1) try introducing a Checked Exception in a commonly used method. Soon you'll be updating 100s or 1000s or methods.

2) checked exceptions don't play well with interfaces (APIs) for similar reasons. any interface user must change their code simply because some new checked exception bubbles up now

3) checked exceptions lead to terrible error handling and hiding bugs/system problems. instead of letting exceptions bubble up - java coders almost always write code that either swallows or simply logs the exception and continues along as if nothing happened. If my bank deposit fails, I don't want the failure to just end up in a log file - I want to know it! Exceptions were designed to usually bubble up and be exposed/handled in a standard way at the top level thread. They are usually not recoverable.

4) they lead to bugs. I very rarely see anyone handle the statement/resultset handling of JDBC code correctly.

5) if they are such a good idea, why does no other language ever created has them?

<comment><USER50> > 1) try introducing a Checked Exception in a commonly used method. Soon > you'll be updating 100s or 1000s or methods.

Try doing that in a code base without checked exceptions. You just created 100s or 1000s of unrecognised errors in other code without realising it. The problem is not the checked exception. The problem is you changed something 100s or 1000s of things are relying on to add a new failure mode.

> Checked exceptions lead to terrible error handling and hiding bugs/system > problems. instead of letting exceptions bubble up - java coders almost > always write code that either swallows or simply logs ....

Well, I agree up to a point. But that is much to do with how tedious and verbose the error handling itself is which is more about the language than the concept of checked exceptions.

> they lead to bugs. I very rarely see anyone handle the statement/resultset > handling of JDBC code correctly.

see above

> 5) if they are such a good idea, why does no other language ever created has > them?

Well, you can also say, if they are such a bad idea, how come one of the world's most popular and used language builds them into all its core APIs? They can't be _that_ terrible or Java would never have got so popular ....

<comment><USER49> I think you are falling into the trap of thinking you can usually recover from an exception. Exceptions are usually caused by one of two things:

1) system error (no more DB connections, hard drive full, etc)

2) a bug

neither of these are recoverable, you just need to stop the task at hand and notify someone that the situation needs to be fixed. Trying to handle it and recover is usually a fools errand that results in hiding the problem

There are cases that you do want to handle exceptions. In these cases, yes catch the exception and handle it. But these cases are the 10% case, hence the default behavior of making the caller handle the exception isn't desirable.

This link from 2003 articulates the point better than I can: [http://www.artima.com/intv/handcuffs.html](http://www.artima.com/intv/handcuffs.html)

<comment><USER50> If Java forced you to handle the exception that would be convincing, but it doesn't. It merely says, if you don't want to handle it, add to your signature that you throw an exception so that at least someone upstream has a chance to know that the error might occur. I'm not arguing at all btw that the way Java does it is good. Merely that there's a case for checked exceptions, especially if you are actually trying to write "reliable" software.

</comment></comment></comment></comment></comment></comment><comment><USER51> Not a single mention of Guice or even dependency injection?

Seems like a gaping omission in a guide that claims to be about "modern" Java.

<comment><USER52> Dependency injection and any othee type of code indirection is evil imo. Anything that breaks the ability to find your way in a codebase with something other than grep brings more pain in the long run than it saves.

<comment><USER53> grep is a that good even for for c++ or dynamic mojo. Java is statically typed and has many ides and tools that understand code structure.

<comment><USER53> isn't that good

</comment></comment></comment></comment><comment><USER54> > ...simplicity of Maven...

Did I read that right?

</comment><comment><USER55> Does anyone here do Java development sans IDE -- like, say, with Emacs?

<comment><USER56> When I taught programming I made my students do all their programming in notepad++/sublime text.

</comment></comment><comment><USER57> If you have come to this post expecting to read something related to modern Java for the web, and have come back unsatisfied, then here is something to make up for that: yeoman's jhipster generator: [http://jhipster.github.io/](http://jhipster.github.io/)

Presentation: [http://jhipster.github.io/presentation/](http://jhipster.github.io/presentation/)

</comment><comment><USER58> What did the Eclipse team do so wrong to fall so fast?

Also, what are Maven's fatal flaws? I don't consider XML a flaw.

</comment><comment><USER59> Another great Java resource (though admittedly the current edition is focused on Java 7) is "The Well-Grounded Java Developer" by Evans & Verburg [1].

[1]: [http://www.manning.com/evans/](http://www.manning.com/evans/)

</comment><comment> loup-vaillant > _depending on the exact usage, a large Java program can be slightly slower, > as fast, or a little faster than a comparable C++ codebase_

This is probably true but…

Does anyone here have any data to back that up?

</comment><comment><USER60> Oddly, this resource is blocked in Russia, so I was not able to read the article from my ipad. WTF with this country. Anyone knows if I can penetrate Great Russian Firewall on ios?

</comment><comment><USER30> > But enough writing Go in Java. Let's try Erlang.

Nice

</comment><comment><USER61> _Quasar is an open-source library made by us_

Quite enjoyed the article until that got jammed in there.

<comment><USER10> Modern Guide to Java... using our tools.

</comment></comment><comment><USER62> +1 for markdown inline docs.

A simple, obvious, useful idea I hadn't seen before.

</comment><comment><USER63> modern java

</comment><comment><USER64> You always know to expect a dreary, look-my-language-is-modern-too article when "opinionated" features in the title. This one didn't disappoint.</comment>


Things They Don't Teach You In Design School - <AUTHOR> http://designreviver.com/tips/10-things-they-dont-teach-you-in-design-school/

<comment><USER2> Solid advice for recent grads. Most of the list pertains to software engineers, too.

To add to #4 - "You must be able to handle irrelevant criticism": when I was working as a junior developer, my mentors would intentionally throw in a hideous design element if they were going to present a prototype to product management or design.

This would give certain product management types something obvious to point out and fix, and offend designers so much they'd work to get us prettier assets ASAP. The better PMs were able to see through the trick and focus on the real problems.

I thought this was stupid until I saw how well it worked.

<comment><USER3> Haha, The PM's at my office actually would pull a reverse on that technique. Noting a flaw they would just say something like: "Oh no problem, the engineers at competitor X probably just got lucky when they did it..." the guy in question was very smooth so it was a challenge to your pride without seeming overly jerky.

</comment></comment><comment><USER3> All great points, I would add "You need to learn to speak the language of engineers, marketers, and managers" This is usually the biggest challenge for designers. Many get stuck speaking a language of aesthetics that fly over the head of most people. I manage a design team and have a rule during reviews not to use the word "Like". This forces everyone to be objective and use terminology that makes sense to many stakeholder groups.

</comment><comment><USER4> _Make sure your client signs a contract

This is sometimes annoying, especially when you think that you can trust the client,_

This is such a stupid thing to say. Our society is built on written laws and contracts. They aren't annoying and they're much better than the alternative: having enough firepower to physically threaten someone if they break your verbal agreement :/</comment>


GoldBug: Secure Instant Messenger - <AUTHOR> http://goldbug.sourceforge.net/ <comment><USER2> I'd go with OTR for this and the website supposedly answers this. While I don't fully understand their answer, they seem to be saying that OTR is an add-on rather than an integral part of the protocol and hence Goldbug is to be preferred over OTR.

However, there are various reasons why transport and encryption should be different things (among others: I can use the same OTR keys etc. over ICQ/XMPP/MSN and possibly even Skype). Is there an added benefit of Goldbug over OTR, such as obscuration against network-wide attackers (à la Bitmessage)? Or is their 'decentralised' approach the only thing going for them? – which I also get by running my own XMPP server.</comment>


Show HN: Txtodo – a day-to-day todo list for coronavirus quarantine - <AUTHOR> https://txtodo.app/ <comment><USER2> How's building on SWIFT UI? We will be using it for the first time for a client.

<comment><AUTHOR> TLDR: I like it.

Working with SwiftUI is fantastic – I always had trouble getting the storyboards to work properly (not really a nocode guy). The rapid changes and control over _every detail_ that SwiftUI provides, while at the same time managing the things you don't need to handle yourself (such as with the Spacer struct), is really a big step in the right direction for Apple.

With that said, there's still a lot to be done – it doesn't totally feel finished. When you run into these missing bits – like a loading indicator – you have to write wrappers around UIKit components.</comment></comment>


Brijit - The Story of a Dead Startup - <AUTHOR> http://bonchibuji.blogspot.com/2008/05/brijit-story-of-dead-startup.html

<comment><USER2> "They got money and contacts, so what to worry about? Maybe that led to the downfall."

...but did they have the hunger? Time, money and contacts are a near perfect receipe so it is surprising thay gave up so easily (as it seems). Were the people passionate enough? Did they fight for survival, and really want to stay alive?

Until we know more about the details of what happended is such speculation worthwhile?

<comment><AUTHOR> well..they chose the worst path by just closing it up when they ran short of investor money.as I have pointed out, they could have at least survived on the reviews written by their own editors..also, even though they had a high profile person in the news industry as an investor,they gave up very easily..</comment></comment>


Turkish Power outage was a cyber attack - <AUTHOR> https://twitter.com/TedasElektrikAs/status/582970541562335232 <comment><USER2> I live here in Turkey and the power outage was a real pain more than anything else. My family that lives outside the country was more worried about me than people in the country were.</comment>


Is machine learning the future of mobile gaming? - <AUTHOR> https://www.staticcatgames.com/2020/06/machine-learning-and-the-future-of-mobile-gaming.html <comment><USER2> A big part of games for mobile is psychological manipulation and ideology transmission. Even if a Gann can generate something playable, Publishing giants will want more control of content to ensure addictive behaviour patterns are funneled into micro-transactions, behaviour can be surveiled and prediction models validated, and content that fits the companies ideology (militaristic, patriarchal and nationalistic) is presented.</comment>


Firefox Lockbox Now on Android - <AUTHOR> https://blog.mozilla.org/blog/2019/03/26/firefox-lockbox-now-on-android-keeping-your-passwords-safe/ <comment><USER2> Posted here previously[0]

[0]: [https://news.ycombinator.com/item?id=19491880](https://news.ycombinator.com/item?id=19491880)

</comment><comment><USER3> I spent a lot of time figuring out how to import passwords into Firefox. So far, there doesn't seem to be a way to do this. Importing from Chrome only catches a handful of the passwords (seems to be currently broken). There isn't an option to import from .csv, which is unfortunate. I tried ffpass, which didn't work either. Seems to be a big oversight.

</comment><comment><USER4> Nice, would like to see some comparisons with 1Password and LastPass (free tier)

</comment><comment><USER5> Be great if they had a direct download of the APK.

</comment><comment><USER6> interesting, "incompatible with all your devices".

Wonder if it's a region or android version thing.</comment>


Optimising Assembly Like an 80's Hacker - <AUTHOR> http://retrocode.blogspot.com/2008/09/optimising-assembly-like-80s-hacker.html

<comment><USER2> Heh... That takes me back.

I remember a puzzle in an old demoscene document: Assuming EAX contains all zeros except for a byte value in AL, what is the shortest number of instructions needed to copy AL's value to the other three bytes in EAX?

The puzzle was hard not because the task was particularly difficult but because the audience had spent so long optimizing assembly for speed that the hopelessly inefficient one-instruction answer would not occur to them.

(Answer: <http://home.sch.bme.hu/~ervin/codegems.html#17>)

<comment><USER3> According to the Intel IA-32 Optimization Reference Manual, integer multiplication has a 3 cycle latency. What's "hopelessly inefficient" about 3 cycles?

( Source: [http://download.intel.com/design/processor/manuals/248966.pd...](http://download.intel.com/design/processor/manuals/248966.pdf) )

<comment><USER2> On earlier-model processors, it could be as bad as 40 cycles. You really didn't want to touch multiplication (or division!) back then. I recall programmers went as far as calculating memory offsets for a 320x200 screen as (x + (y << 8) + (y << 6)) instead of (x + y * 320).

<http://home.comcast.net/~fbui/intel_i.html#imul>

</comment></comment></comment><comment><USER4> I just bought a C64, an Atari 130XE, a TI99/4A, and an original Gameboy on eBay. I've been tinkering with chiptunes lately, and wanted to use the Real Thing. My first five or six computers were Commodore 8 bit machines...it's amusing to go back to that world.

I just read a code analysis for one of Rob Hubbard's music routines, and that was pretty interesting. The size of software back then is mind-blowing today. And what's interesting is that I couldn't even use a very high level language (like Ruby or Perl or Python) to write a music player, plus the music, in the same number of lines, without resorting to loading libraries that are comparatively very large. The move away from specialized chips to very powerful generic processors has interesting repercussions.

I guess a lot of kids of the 80's are reaching the point where they get to feeling nostalgic, because I've seen a lot of 8-bit retro related activities of late. Chiptunes are bigger than ever (_why just released a chiptune library, for instance), someone just made a Haskell library for writing BASIC programs, and pixel art is also showing up everywhere. Weird how that happens. I guess the 70s and 80s had their 50s and 60s flashback with Happy Days and such, so it shouldn't be surprising that our generation is doing the same.

</comment><comment><USER5> Retro programmers: Respect.</comment>


The LaTeX ifthen package [pdf] - <AUTHOR> http://texdoc.net/texmf-dist/doc/latex/base/ifthen.pdf <comment><AUTHOR> Posted because I thought this was satire, but apparently it is for real.</comment>


Show HN: Run – Easily manage and invoke small scripts and wrappers - <AUTHOR> https://github.com/TekWizely/run <comment><USER2> I recently looked at many task runners. I settled on my own personal task runner only because of familiarity. I would switch to either of these if I wasn't so heavily invested in my own tool.

[just]([https://github.com/casey/just](https://github.com/casey/just)) [task]([https://github.com/go-task/task](https://github.com/go-task/task))

I'm not sure what Run does that the two above don't.

<comment><AUTHOR> Hi @mmgutz,

Thanks for linking these other projects - I'm going to add a section in my README linking to other projects that people might find useful for their various use cases.

Go-task feels like a build tool and not really a general task runner.

Looks like Just brings a lot of similar features and I will definitely be looking into it deeper. However it still touts itself a build-tool at heart.

Run is NOT trying to be a build tool - It wants to be a script/wrapper manager and so the feature set is trying to optimize for that.

Thanks for the question - I hope that helps - Please let me know if you have any other questions or comments.

BTW: Can you link to your "own personal task runner" ? I'd love to see it and others might find it useful, too.

</comment></comment><comment><USER3> HN is known for snark so I should say I'm genuinely not trying to be snarky. I don't understand why I would use this over a Makefile. The biggest difference is that "run" autogenerates nice help output?

<comment><AUTHOR> Hi @brian_cloutier,

A couple of things that come to mind (although I should probably flesh out a section on the README for this):

* Auto-Generated Help From comments - There are patterns for adding a 'help' target in make that generates light documentation for the targets - I maintain a gist for such a pattern in a different github account.

* Per-Command Shell - bash, python, ruby, you decide !

* Per-Command Options/flags - With documentation!

* Positional Arguments - By default, make treats all non-variable arguments as targets, so you can't say "make action argument"

* Commands Executed in One Sub-Shell - By default make executes each line of a recipe in a separate sub-shell, requiring you to use '\' to link multiple lines into a single recipe.

No doubt make is useful for this, hence why all my dev friends use it, but make was not designed to manage non-build-related targets, and has some cracks in it with regards to that use case.

I think (hope) run can prove useful as a dedicated tool for this use case.

Thanks for the question - I hope that helps - Please let me know if you have any other comments or questions.

<comment><USER4> Thanks for that list as well!

Would you be so kind to also answer the question why one would use it over pure bash scripts?

<comment><AUTHOR> Hi @kariert,

I think a first answer could be answering with a question:

"Why do so many people use makefiles to just manage tasks/scripts/wrappers instead of using pure bash scripts"

One reason may be that they are already using make in their project for actual build targets, but I see many pure task-only makefiles out there, so its not the only reason.

I think another reason is ease of use - The syntax is very terse and you can get a useful task runner with just a few lines of text.

With regards to Run, one of the additional features it brings is the ability for your 'commands' to be any type of script and not just bash.

You could have small scripts coded ruby, python, perl, etc all mixed together and managed within a single Runfile.

Thanks for the question - I hope that helps - Please let me know if you have any further comments or questions.

</comment></comment></comment></comment><comment><USER5> Having gone through writing a couple of iterations of these, I went back to settling on `PATH="./scripts/:$PATH"`, which in my project root dirs (where I spend 99% of my time anyway on the shell) just works.

Sure, this could be augmented with per-folder environments, fancy runner syntax, but less is more for me in this regard.

Ninja update: Anyway, I like what OP is doing here, seems like a lot of things are done right in this. :)

</comment><comment><USER6> reminds me of [https://github.com/tj/robo](https://github.com/tj/robo).

Great job on releasing this. I was just thinking about all the scripts in my makefile. Separation of concerns. I'll be giving it a try.

<comment><AUTHOR> I must admit robo is clever for using YAML where I built an entire parser to do somewhat the same thing :)

<comment><USER7> In your defence, Robo doesn't appear to handle arguments or let you write single-file scripts, at best you can make it run an external script.

</comment></comment></comment><comment><USER8> This would be an interesting alternative to travis-ci or appveyor scripts (where you are locked in to that tech). By using this you can have scripts that run local or run on CI, and just have a one liner on travis-ci to call Run.

<comment><USER9> I was thinking the same thing, as I just had to create a bunch of ci scripts to preload a Firestore db and cloud functions for a pipeline using a gcloud emulator.

</comment></comment><comment><USER7> This is a great project, and I will be using it to both replace old scripts and make new ones.

Also, if you give me a week (I might be able to do it today or tomorrow tho), I'll submit a PR for an Archlinux PKGBUILD.

<comment><AUTHOR> Greetings!

Yeah I haven't done much with Package managers (PKGBUILD, brew, etc) and thinking this project might be my excuse to start learning them.

Thanks for your kind words and offer for a PR - I'll keep an eye out for it !

<comment><USER7> Here it is: [https://github.com/TekWizely/run/pull/2](https://github.com/TekWizely/run/pull/2)

<comment><USER10> That was a very short week!

</comment></comment></comment></comment><comment><USER11> This looks pretty nice, and I like the idea of a universal help/getopts syntax that can work over different execution engines (python, bash, etc.)

I just did a new install at home, and may try reimplementing some of my utility scripts in terms of this just to see how it plays.

</comment><comment><USER12> How does run compare with expect[1]?

1: [http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.htm...](http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.html)

<comment><AUTHOR> Greetings!

I would say that expect is quite a different beast entirely. I think of expect more as an interactive scripting language. Something you might use in place of bash to write a small script that requires user interaction.

Run is more of the tool you might use to organize your expect / bash / etc. scripts and easily invoke them.

Pretty much every dev I know has used makefiles as a means to organize small, non-build-related, scripts and shell wrappers. Run hopes to be a better tool for doing that.

Thanks for the question - I hope that helped - Please let me know if you have any other questions or comments.

</comment></comment><comment><USER13> Good work.

I have done something similar by creating bash functions in a file then sourcing that, making them available as and when I want.

This looks nice though.

</comment><comment><USER14> Nice work, TekWizely! This looks looks like a well thought out little tool with a good niche.

<comment><AUTHOR> Thanks @a_band - Please don't hesitate to submit a bug report (or feature request!) if you get a chance to play around with it.</comment></comment>