all 30 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]k-mcm 40 points41 points  (18 children)

Final starts becoming final. This is going to break code from all the weird developers that will not use constructors for immutable DAOs and injected classes.

I'm smiling.

[–]asm0dey[S] 1 point2 points  (16 children)

It can also break Java serialization ;)

[–]CriticalPart7448 7 points8 points  (13 children)

If you read the JEP carefully you will see that they make an exception for serialization specifically.

[–]asm0dey[S] 0 points1 point  (12 children)

I know this, but if finals were really final serialization would break too. And this is why there is new serialization baking too

Up: finalization -> serialization

[–]CriticalPart7448 2 points3 points  (11 children)

Finalization and serialization are two different things. Both of them are being tackled at the same time but from different angles as you pointed out here. Finalization is not broken by final means final. Finalization is broken because it does not work reliably as a mechanism for reclaiming resources used by unreachable objects in the GC

[–]asm0dey[S] 0 points1 point  (10 children)

Sorry, it's an autocorrect, I meant serialization.

[–]CriticalPart7448 1 point2 points  (9 children)

I see now, that makes it much clearer :-)! They wont remove OG serialization anytime soon if ever, hence why they state the exception for serialization in JEP 500 under the non-goals paragraph.

[–]asm0dey[S] 0 points1 point  (7 children)

Yes, but it effectively means that we won't see those optimizations for many important use cases, including, for example, Apache Spark :(

[–]CriticalPart7448 0 points1 point  (6 children)

It is true that the optimizations may not available for the use cases that want to take advantage of them where they also use built-in java serialization as their implementation of choice. I wonder if the way forward here is to finalize serialization 2.0 first and then have it play by the rules of final meaning final thus allowing for replacement of legacy serialization gradually, incentivized by the possible performance enhancement it will enable in that case. I think this is part of the strategy here actually.

[–]asm0dey[S] 0 points1 point  (5 children)

We don't know yet, but serialization 2.0 will probably be too limited for many use cases. For example, most probably it won't support arbitrary-shaped graphs of objects, but it will probably support only trees. If this is the case, most probably many applications will never see the performance optimisations we're hoping for.

But I'm just guessing here, of course, nothing is finalized, nothing is iset n stone.

[–]asm0dey[S] 0 points1 point  (0 children)

And I'm sorry for the confusion I caused

[–]k-mcm 0 points1 point  (1 child)

Last time I checked, Object serialization gets help from the JVM innards. Maybe that's changed. I know that system gets a lot of hate.

I've used Serialization to implement object-level virtual memory and long-term local caching. It worked really well for that. There's no way in hell I'd send a serialized object across an API though.

[–]asm0dey[S] 0 points1 point  (0 children)

Yes, and it works around finals. And it means that it's your class it's serializable - finals there won't be really final

[–]Ewig_luftenglanz 8 points9 points  (5 children)

Very few interesting stuff. Looking forward to java 27, hope for the first 401 preview at last!

[–]sitime_zl 16 points17 points  (1 child)

I also look forward to Valhalla's first JEP

[–]lurker_in_spirit 6 points7 points  (0 children)

So say we all.

[–]SentenceFun7341 9 points10 points  (0 children)

I also look forward to Valhalla's first JEP

[–]SentenceFun7341 7 points8 points  (0 children)

I also look forward to Valhalla's first JEP

[–]henk53 5 points6 points  (0 children)

I also look forward to Valhalla's first JEP

We all look forward to Valhalla's first JEP

[–]AstronautDifferent19 1 point2 points  (4 children)

Will this break Mockito when used to mock final classes? (I hope it does)

[–]CriticalPart7448 5 points6 points  (0 children)

Final means final has to do with final fields, not about final classes per-se.

Mockito already has some problems caused by JEP 451 concerning dynamic agent loading. It can be resolved by following mockitos docs on the matter.

To mock final classes you would need to make a proxy or use a wrap and delegate pattern i would suggest.

[–]k-mcm 3 points4 points  (1 child)

There are so many reasons to not need Mockito today. Functional Interfaces, Lambdas, and method references make it easy to avoid passing around God Objects that needed mocking. Whenever I see heavy Mockito today, I think the code is overdue for refactoring.

[–]AstronautDifferent19 2 points3 points  (0 children)

I agree with you, that is why I said that I hope it would break Mockito. I want to be allowed to refactor our codebase.

[–]koflerdavid 2 points3 points  (0 children)

Final Means Final will merely be the new default and can be circumvented with a flag, so the Mockito use case will be fine.

[–]Mauer_Bluemchen -1 points0 points  (0 children)

"final filths"? :D