Notices tagged with java

@jussi I used #FunctionalProgramming in #javascript before I knew it was called FP. Now my #Java applications (with Java being a long-time #OOP proponent) slowly turn more and more functional. I like this article: these paradigms don't conflict, can benefit from each other, and can be mixed within the same #software application.

Web development comparison: #SpringBoot (#Java) vs #ExpressJS and #NodeJS (#Javascript): https://www.devamountain.com/post/web-development-comparison-springboot-vs-expressjs/

RT @yuriy_tymchuk@twitter.com What are the most used words in #Bible, #Reuters, #Java and @pharoproject?@twitter.com A nice fact and cool slides from the master's thesis defense of @oleks_lviv@twitter.com https://t.co/ZANhevGNjR https://t.co/Dfcq3j4yOn

The #Java #programming #language of course has a long history with passing #Runnables into #thread runners and executors. We see it all over the place in #Swing and #JavaFX. It just always felt clunky to me. And that feeling got lifted, mostly, with Java gaining #lambdas.

I remember when my #CSharp colleagues first introduced me to the concept of lambdas. We were very excited.

May the remaining limitations Java imposes on lambdas get lifted soon!

We see hints to this model in #Java's #Optional class, with its #ifPresent(Consumer) method, and its #ifPresentOrElse(Consumer, Runnable) method.

And it's a shame that we can't apply this model to Strings or anything else implementing an isEmpty() method: the Java #programming #language won't let us #subclass most of its core classes.

It feels easier to implement this in a #trait-based language like #RustLang.

I like #eventDriven #software #architecture ever since I encountered it both in #JavaScript and in #VisualBasic. When I switched to the #Java #programming #language, it happened when Java still had to gain #lambdas. Applying an event-driven paradigm with that version of Java felt out of place and unelegant. But ever since #Java8 I find myself slowly returning to event-driven choices.

Every now and then, #EclipseIDE completely freezes up when I tell it to clean up my #java code formatting. It won't recover and I have to crash it. I'm using Eclipse 2018-12 (4.10). Have you experienced this? If so, did you solve it? How?

@cringe You could talk about it right here. I'll see it. Or you could talk about it on IRC: in the ##java and #java-talk rooms. Or, if you don't want near-realtime talk, you could talk about it on Reddit: r/java and friends.

A problem I found when implementing this, is race conditions during #concurrency on #mutable collections.

And that may be specific to the #java #programming #language. The proposed architecture uses #lambda function forms. And if those have to change a value that needs to live on outside their scope, then java insists that the reference to value must be effectively final, immutable.

And that causes us to code some odd structures that are neither elegant nor simple to understand.

A problem I found when implementing this, is race conditions during #concurrency on #mutable collections.

And that may be specific to the #java #programming #language. The proposed architecture uses #lambda function forms. And if those have to change a value that needs to live on outside their scope, then java insists that the reference to value must be effectively final, immutable.

And that causes us to code some odd structures that are neitger elegant nor simple to understand.

We see parts of this in the #Java #programming #language when we look at the #Optional class. Other languages also have optionals and maybes.

Their functionality is conditional: if present, do something. Otherwise, do something else.

With Java specifically, the Optional ability feels like an afterthought. Other languages may fare better. But what Michael advocated, is to make the condition part of the problem domain.

2 Years ago when I first had to implement #OAuth into a #java-based #APIClient, I knew little about OAuth. So I searched for and found a library. It is named #ScribeJava.

And I learned that the #APIServer with which I communicated had implemented OAuth wrong, causing me to override half of what ScribeJava could do out of the box. Grrr.

The other week I implemented the simple client-necessary request for an #OAuth2 #BearerToken, specific to a different APIServer. Half an hour: it works!

#TypeInference in the #Java11 #programming #language still is in its infancy. We recognize that when our toolsets start failing to infer the types of our variables and method results due to us making the data types more verbose and more explicit. Thanks, #Java.

They meant it as a joke: "Comment your code!"

https://www.reddit.com/r/ProgrammerHumor/comments/aixtq1/comment_your_code/

But.

#Java, #PMD, and #Sonar require us to insert a warning disabler in our code just to stop them from signaling that something lacks verbose comments.

If I think my code is straightforward, I hate it when my toolset forces me to add redundant comments.

This in response to the earlier revelation that a #java method can't have more than an integer count of arguments, so we can't pass in more than 65,535 lines of a file (because the 65,536th argument is for the implied "this" argument). And my file happens to be slightly larger than that. By about 130,000 lines. Gzipping and Base64 encoding reduced that to a single line of roughly 10,000 characters, which is accepted by the #java11 #compiler.

Today I learned: to save gzipped contents into a #java source file (for instance for unit testing), copy-paste doesn't work, as the java #compiler won't accept the raw #gzip characters in a java source file. Instead, first #Base64-#encode the contents, and paste that into the source file. Base64 converts anything to [a-z0-9]/i, which is accepted by javac. #TIL

Oh, dear.

Today I happened upon the arguments limit for the #java #programming language.

I've used that language for years. This is the first time I encountered that compilation error.

Apparently the #JVM spec states in §4.3.3 that a method descriptor can have no more than 255 arguments, including the normally implied /this/ argument.

I used a #varargs parameter with 1000 items. That's too many for Java!

The problem with this is not, that there are no solutions to work around this #inheritance limitation in the #Java #programming language. Solutions exist.

It's just that implementing those would require yet another load of copy-pasted, #duplicated #boilerplate #code, which is exactly what I was aiming to avoid by using a base interface in the first place.

You're making it difficult to design clean architectures, Java.

Very difficult.

That required changing the declarations of the subclasses.

First: IMessage. Success!

Then IPair. No problems yet.

Then ILocateFiles. Uh-oh. Cracks are appearing. Alright: manageable.

Then NamePair. Kablammo! No more #inheritance for me.

Thanks, #Java #programming language, that's exactly the level of #objectOriented architecture I always desired.

Not.

And as long as IEmptive is referred to as Consumer<? super IEmptive>, the world is fine, and #Java is fine.

But that has a drawback: the auto-generated parameter value for the consumer is an IEmptive, rather than, say, a ReadFrom or a UserToken. That forces a type cast. This isn't necessary with Optional.ifPresent(Consumer).

So, can I get rid of that typecast?

The first thing I tried, of course, is to add a type parameter to the IEmptive interface declaration, much like Optional.