> Some of the Northern Sky's former constellations were placed in the less populated regions between the traditional brighter constellations just to fill gaps. In the Southern Sky, new constellations were often created from about the 15th century [...] European countries [...] often supported and popularised their own constellation outlines. In some cases, different constellations occupied overlapping areas and included the same stars.
FWIW, javascript:// bookmarklets don't work on the standard Chrome home / new tab page, but data URL bookmarklets work everywhere. Here's my bookmarklet for Day Of Year...
data:text/html,<script>now=new Date();alert(`Today is DOY ${1+Math.floor((now.getTime()-new Date(now.getFullYear(),0,1).getTime())/8.64E7)}`);</script>
The reference is to a previous licensing change, which made it less free, with Oracle shaking down groups using the Oracle JDK. They've changed their terms before and could do so again with future releases.
src/main/java is a convention that started with Maven; it's simple to change in the project build file (pom.xml). Otherwise, it's due to the fact that a package namespace in Java must correspond to a directory tree.
You generally don't write Java using bash/cd/vim; the IDE presents classes and package paths and puts files where they need to be. "Where is my code" is not something you need to explicitly think about.
In contrast, javascript/typescript files are often poorly organized and it's frequently necessary to look for code via grep-like tools. Yes sure, someone could organize js/ts files well, but it actually takes mental effort and coordination among the whole team.
Java was heavily inspired by smalltalk, which IIRC didn't give you a "filesystem" view of your project - it was an integrated environment with a proprietary storage format. Also IIRC early versions of IBM's VisualAge for Java maintained this paradigm. I think the "everything is individual files, but the IDE maintains them" was actually a pretty good compromise.
Simplifying conventions a bit here couldn’t hurt is another way of looking at it. Maybe instead of the long src directories it could be simplified to app and tests top level directories for example.
For a simple HelloWorld or a PoC development a flat list of .java files would work, but once you go past that (20+ files or so) a standardized directory structure is an important element of managing the complexity.
And using the JAVA ecosystem standard makes it easier for fellow/future developers to continue the support and expansion
What is the proposed alternative exactly? I like main vs test. I like isolating java files from other languages or templates. I like the src directory bucketing sources from other root project build files and output artifacts. I have a ton of wishes for java improvements but this is functionally not an issue in day to day work.
True, however since already the Visual Cafe, JBuilder and Visual Age days, Java IDEs have tried to provide a Smalltalk like experience, given where the community was coming from, so the concept of a virtual image mapped into the file system has always been present.
As such, code browsers always made this quite easy.
The fact that Eclipse provides a Smalltalk like code browser isn't an accident, rather its Visual Age roots.
It is only a problem when one makes the point to navigate through the source, outside Java tooling.
This is indeed supremely irritating. Besides this deep nested directory structure every 'public class/interface/enum/record' have to in their own file. This whole thing creates tons of files and directories with trivial amount of code.
Every top-level public(ish [1]) type declaration requires its own file. It may be irritating but it also brings some clear advantages for compilation speed. You can be irritated by many small files or by longer compilation times.
When you compile a file, the compiler quickly finds all other file dependencies and compiles (or just parses) only them, i.e. given a single file, the compiler knows exactly where to find all the declarations of all the types used in it. This property may not matter for languages that don't have good separate compilation anyway -- and few languages do, which is why people coming from other languages may find the restriction weird -- but Java's separate compilation is excellent. That turns out to also greatly help in-memory compilation for an upcoming feature where we can choose to compile files lazily, on demand: https://openjdk.org/jeps/8304400
To see that that is, indeed, the reason for the restriction, notice that it is only required for public(ish) top-level types. Non top-level public types can also be easily located, and non-public top-level types that are stored in files that don't match their names can only be referenced by code in that file (more precisely, the compiler is allowed to emit an error if they're referenced elsewhere). See the bottom of §7.6 of the JLS: https://docs.oracle.com/javase/specs/jls/se20/html/jls-7.htm....
Anyway, the point is that the restriction is there for a good reason. We sometimes entertain removing that restriction (and maybe someday we will), but the compilation benefits have so far turned up to be quite useful. We like our efficient separate compilation -- I don't think any other mainstream language does it as well as Java -- and may be able to get even more out of it.
[1]: Really, any top-level class that is referenced by name from other files.
I like the Java conventions with all the files belonging to a package in individual nested directories of their own. It makes things systematised and easier to sort in my head when dealing with large projects with thousands of source files.
lossless? large sizes? multi-band (> 3) data? transparency? animation? I work in software support of scientific imaging, and jpeg-xl looks to be the only format to date that supports those features in addition to excellent compression and royalty-free licenses (we currently use jpeg-2000 which has no good/fast open-source implementation, we really on an expensive proprietary license with lots of restrictions on redistribution, in fact our industry is largely moving back to TIFF now with the storage factors you mentioned, but using 10x the disk space is non-trivial).
Yes. And with "records" (record classes, something with the characteristics of a tuple or struct) you can get further away from getter/setter boilerplate code.
I just wish records had an easy way to facilitate and/or associate a builder with them. Wishful thinking, out of scope for what they are. And of course, it's not hard to write a FooBuilder that's defined to help construct a Foo record.
If Java records could be told to have a private constructor, I'd be completely satisfied with them. I just don't like the ability for callers to be able to directly instantiate a record without having gone through my builder to do so. I want to completely enforce that my record is instantiated with all its invariants dealt with properly. A builder is a very nice way of doing that.
I wanted to experiment with creating a "Rust-like" option and result type for Java and so figured that I would need records and pattern matching for this and I ran into exactly what you are talking about here with records and public constructors.
My solution was to create a sealed interface that permitted the None and Some records as the only classes to implement it. Those records are not available outside the package, while the interface is exposed. Using default methods in the interface I could expose a state "create()" method which would then instantiate the appropriate None or Some record. In this way you control the exposure of the construction of the specific record implementations of your interface.
You can then either interact with the option through the methods on the interface, .isOk(), .unwrap(), etc, etc, or with the upgraded pattern matching in switches with this release you could have something like
switch(option) {
case option when option.isNone() -> blah
case option when option.isSome() -> foo
}
Its not as pleasing as Rust matching directly on Some and None, but it gets you pretty close.
This is absolutely possible in Java and the only less-than-ideal part is the generic type having to be specified in the None case (but a trivial method fixes that as well)
This can be used just like rust and similar languages:
switch (option) {
case Some(var x) -> println(x);
case None -> // TODO
}
Hell, you can just further pattern match inside Some, like `Some(Point(var x, var y))`
Java is built upon it's community :), look no further: https://github.com/Randgalt/record-builder, although hiding the constructor behind the builder is not something I am sure supported by that library
Yes, agreed. But not in a clean "fluent" style. There's something nice about the fluent style that appeals to me (at least).
And I don't like having to provide one constructor for every optional (default) value, when its omitted. There's just not as nice of a style. The "telescoping" constructor pattern is just really hard to use, read and maintain.
AFAIK Java was GPL'd by Sun (before the Oracle purchase). This resulted in the OpenJDK, which is the basis for all distributions of Java. Oracle is a big contributor to the development, but so are many others. You can get a pure OpenJDK or any of a number of branded JDKs like those from Eclipse, BellSoft, etc. You can get non-free distributions with support too. A sticking point for a number of years was the TCK (Technology Compatability Kit) used to validate Java, but that too was GPL'd. Java has evolved quite a bit since being open sourced. IMHO C# has some great features, but Java is great for certain things. For instance, making native apps for Mac, Win, and Linux based on modular libraries from the JDK is now fairly easy (and with a modern UI using the OpenJFX framework).
Asking honest question here - did Oracle change the terms back so that one can now develop and distribute applications using their JDK without fees so long as one does not also re-distribute/bundle their jdk with your application(s)? I just read something along those lines having thought that one couldn't use their JDK for anything without fee anymore.
If so, is there a reason to go with OpenJDK over Oracle other than GPL purity?
And if you write "polyglot" html (html written as syntactically correct xml) then you can use xpath or other tools to extract data from it (i.e. from tables).
