Posted
by
samzenpus
on Monday May 01, 2006 @10:10PM
from the free-coffee dept.

capt turnpike writes "According to eWEEK.com, there's an internal debate going on at Sun whether to open-source Java. (Insert typical response: "It's about time!") Company spokespersons have no official comment, as might be expected, but perhaps we could hear confirmation or denial as early as May 16, at the JavaOne conference. One commentator said, "Sun should endorse PHP and go one step forward and make sure the 'P' languages run great on the JVM [Java virtual machine] by open-sourcing Java." Would this move Java up the desirability scale in your eyes? Could this be a way to help improve what's lacking in Java?"

all the things java was supposed to be great for, all the portability, consumer gadgets, smart coffee machines, etc. there's where Sun could really benefit most from open sourcing. There just isn't that much of a reason to use it on the net anymore, unless you work at a financial institution, the technology at large is just moving too slow. But when hobbyists can easily adopt java to connect the things around the house, that will be a big push forward for everyone. and open sourcing java only speeds up that barrier that keeps most java programmers working on desktops and servers...

"Will Sun Open Source Java?"No, haven't they already said that? Like hundreds of times? And does it really matter?

Sure it matters. A lot of people have issues with it because of the license. It would clearly expand the number of potential adopters to go open source. More adopters will mean better tools.

"Sun should endorse PHP and go one step forward and make sure the 'P' languages run great on the JVM [Java virtual machine] by open-sourcing Java.""No", who would run PHP on Java anyway? Why? Why would open-sourcing it help?

Well, I agree with the first part. But presumably integration will get better/faster in open source.

"Would this move Java up the desirability scale in your eyes?"No, Java is already desirable in my eyes.

But a lot of people would find it more desireable. You can trust that java won't go away in open source, whereas you can't really say the same as long as SUN is at the helm.

"Could this be a way to help improve what's lacking in Java?"No, what is lacking?

Mostly modernizing. The pace of java development is glacial, compared to say what is going on in C# or Ruby. People with specific integration issues that can't get sun to address compatibility problems are stuck.

People who complain that Java is slow, should be open-sourced, and so on have never seemed to had a clue.There's no doubt java is still slow in a number of contexts. There are also obvious opportunities for performance enhancement that could be addressed in an open source process. I recently benchmarked ten of my applications in c++ and java, java is about 2x slower for most of the cases I tried, and never faster. To me, that's perfectly acceptable, but java could make more inroads into other areas of computing if it was more competitive in performance. More inroads means more developers, and that means better tools, which is what I yearn for.

This same exact rumor has been spread several times before. And it always ends up with the same thing: it's a basic part of Sun's strategy to keep full control over Java, therefore it won't be open sourced. Now stop daydreaming.

Caucho [caucho.com] has been working on PHP compilation called Quercus [caucho.com] inside their application server Resin. This is fairly new, but they already have some fairly complicated applications like Drupal and Mediawiki working in it.

I don't have the Sun JDK on my Fedora system by default because of the Sun license.

Meanwhile, Microsoft has been adopting ocaml as the next big language [microsoft.com]. For once, Microsoft is technically ahead of its competitors -- ocaml [inria.fr] (which Microsoft did not produce) is very fast and safe, and from a technical standpoint is much more impressive than C# and Java.

Plus, ocaml can be used as a pure functional language -- such languages eliminate almost all the reason to use (error-prone, difficult to guarantee correctness with) threads. Pure functional code is inherently parallelizable any time the compiler can say "hey, no data dependency here".

Ocaml is picking up quite a bit of steam -- there are a slew of open-source libraries for it out there, it's the only safe language that I'm aware of that provides performance comparable to C and C++, yadda yadda yadda. The INRIA ocaml compiler is open source (though, annoyingly, QPL instead of GPL). The runtimes and the stuff that you stuff into your code is LGPL. I didn't realize that Microsoft was backing it and integrating ocaml support into Visual Studio until quite recently, though. There have been gtk+ bindings for ocaml for a while, but MS may actually be ahead of the OSS world in providing complete ocaml bindings.

If you've never used ocaml before, wait until the first time you break in the debugger at a problem...and then step *backwards* to watch the problem occurring. It's simply delightful.:-) Plus, it's even more concise than C (which is saying quite a bit), is safe and garbage-collected, has very strict typing (I've heard one ML fan say "If your code compiles, it's correct" in only half-jest)...ah.

What's particularly satisfying is that C was well-designed -- for a specific set of systems and circumstances that don't apply to most application software development today. Ocaml is the first language in a long time that I've seen where I can say not just that the language has good ideas, but that it is really well-designed. It's also a lot better-suited to application development than C is.

Interesting find. Imagine running Quercus within Kaffe, which would be comparable to Phalanger within Mono as both would be using GNU Classpath for Java support. GNU Classpath's development is moving along fast [kaffe.org]. Now that Linux distributions are incorporating Mono and GCJ, the.NET vs Java camps are beginning to merge, which is fascinating.

PHP is probably one of the best (worst) examples of what a language would look like if it was designed and developed incrementally in an open source community. It's hack upon hack upon hack. It's backward compatibility breaking changes is just about every point(!) release. Register_globals enyone? Magic quotes? Ambivalence towards types/objects - "type hinting". Arguably (and freely admitted by the designers) PHP is *not* a well designed language. It's a pragmatic ooops kind of language whose main advantage is a large (albeit somewhat amateurish) user base, and free availability.
Java on the other hand - if anything - tends to be over-engineered. Swing is actually more flexible than even.NET Windows Forms (which was designed later). It's easier to combine widgets, e.g. put textboxes inside tree nodes, etc. Swing may be a little slow, but nothing Java has ever had that "hackish" feel to it. It's always well thought out. Same thing could be said about JSF, JDO and certainly EJB.
Sun has always taken great care of minimizing BC breaking changes. Sun has always taken pride in being a little on the conservative side, i.e. only introduce well understood technologies. This has been received well by the enterprise developer community. PHP is nowhere near that yet. There's still tons of BC breaking changes in store for PHP developers when PHP finally will get namespaces, unicode support etc.
To put it simple, the primary virtues of Java is nowhere to be found in PHP. And frankly, if PHP is the way a language looks like when it's designed by an open source community, open sourcing Java would possibly destroy it. A model like eclipse where it's formally open sourced but in reality still maintained by a single, competent organization might work, though.

Release it under GPL. This way, no-one can "pull a microsoft" and create incompatible forks because whatever changes they make can be brought back into the main tree.

Secondly, make a testsuite available to use for free (but only when developing against the GPL version of the VM) so people can make sure their VMs are compatible.

Thirdly, if you are a company that wants to use the JVM embedded in your product and want a closed source licence (either to ship the JVM as is or to modify it), you would be able to get one from sun (just like it is now)

Forthly, there would be rules governing the use of the JAVA trademark.

So basicly, forks would be prevented by controling the trademark, having a solid testsuite available so people can make sure their VM is still 100% compatible and that they didnt make any changes that accidently broke things and by encouraging people to submit changes back to the main tree.

Plus, just look at other open source projects. There are a few people hacking on the Mozilla codebase and releasing their own stuff but most people just follow what mozilla.org puts out (and/or tries to get their changes into official mozilla.org tree somewhere). Most GCC development (with the exception of Apple OSX stuff and a few platforms like MingW which (for whatever reason) seem to end up second class citicens) is done on mainline. Same with pretty much all GNU projects.Along with WINE and a number of others.

The only time I have seen forks is the X fork where people didnt like the way xfree86 was being run and created x.org. These days most people have moved to x.org.

The licence and releases should cover all 3 flavors of java, J2EE, J2SE and J2ME.

Although relatively useless (if not harmful), these checked exceptions lead to a minimum of 122 extra CPU cycles per method invocation.

Mmm, the sweet tastiness of a piece of malarky. Care to back up the 122 cycles bit? Last I checked on Hotspot there is literally *zero* overhead for wrapping something in a try {... } catch (Exception e) { }. And why should there be? When an exception is thrown, all Hotspot needs to know is where to unwind the stack. It can look that up in the exception table (a one-liner), and only needs to bother with that after an exception has occurred.

I'm not sure if you're complaining about development of the language and standard library API, or development of Sun's implementation. The language evolves about as fast as is prudent, because they're committed to having the language not have badly-designed features that need to either be incompatibly dropped or painfully maintained. So Java gets features essentially as soon as C++ has made all the mistakes related to those features.

On the other hand, Sun's Java compiler has always had broken dependancy tracking (at least since I started using it heavily in 1999). (If a build has an error, the set of output class files may be such that the next run of the compiler skips a source file which needs to be compiled; this is mainly that it can generate the public class without generating other classes in the same file.) I think it's likely that, if Sun does open source the JDK, they'll get fixes for a number of annoying flaws of that sort pretty quickly, and things that are clearly wrong but aren't considered worth working on will be improved substantially.

Of course, there's essentially no chance that they'll relax their grip on the language standard, and they probably shouldn't, unless they turn it over to a standards body due to no longer being able to employ good language designers.

you are correct. but whatever we saved using java to get the project started, we have already spent trying to figure out why, oh, why java croaks on OutOfMemoryException when we have more than 8G of ram most of which is not being used.

on a more philosophical level, there is already an excellent VM that *can* use all the 8G and then some. it's called linux. using java to build apps because it's easy to program in is like using tonka trucks because those trucks are so much easier to handle than the real thing. after all, why pay commercial driver rates to drive a multi ton truck when you can get you own kids (for free) to 'drive' the tonka trucks.

i learned java back around '95, '96 and was really excited about it then. but after having used it on some really large projects, i have been really really disappointed and came to the conclusion that the only real contribution of the JVM was a serious neutering to most modern advances in the OS.

forget portable programming languages - use a portable OS - linux. and forget the V, use the M (tm).

anyhow, Guy Steel was right. i am looking at lisp right now (mostly for emacs tho).

I still fail to see the benefits of "open sourcing" Java. How will it be improved? It's not as if the engineers at Sun are stupid and don't know how to engineer enterprise software.

Honestly, that's part of the problem.

Enterprise developers are used to a very particular envelope. That involves putting up with a lot of large-company bullshit and unfriendly tools. People in other environments have different needs that are poorly served by Java. And actually enterprise people have those needs too; they're just used to suffering.

Take all of the C#-inspired improvements in Java 1.5, for example. Many of them are about programmer convenience and improved expressiveness, neither of which mattered much until C# was a threat. Or consider EJB 3.0. EJB sucked for years until Hibernate, an open-source project, came along and beat the snot out of it. EJB 3.0 is basically a straight import of Hibernate.

Or take Ruby on Rails: you can't write that in Java. Why? My theory is that in large companies, they'll let you go away for three months and build infrastructure. Plus, neither Sun nor an enterprise architecture group trusts programmers with the kind of heavy wizardry that Rails uses to make things happen. So again, Sun gets its ass kicked by an open-source project.

If they really open it up, perhaps Sun can harness some of that power. But I'd bet they won't do it properly; Java reeks of "cathedral" thinking, and that papa-knows-best mentality is hard to shake.

1) A free software license (GPL?) to allow for fast, active development, quick fixes of current problems, and license purity. Plus, imagine the boost if all those talented GCJ people put their efforts into the already rich Sun codebase!

2) Constant references! Please! Java's encapsulation is about as secure as Internet Explorer. A harmless getter method for a private member variable allows you to replace that variable with anything of your choice, because you effectively get a pointer to the member. The only current solution is to copy everything in the getter, which is unacceptably awkward and slow. So much for design by contract.

3) Sane memory requirements. Right now coding an inherently memory-intensive app in Java is very very difficult. I tried it once, and had to rewrite in C++ to get anywhere.

All of this is terribly ironic to me. I've worked with Java for about 6 years now. It's considered the Enterprise Open Source solution (because admin types typically confuse open source with "free and runs on lots of platforms) usually. So it's either Java or Microsoft in every shop I've ever worked for. No PHP. No Ruby. And often Java is paired up with Linux, MySQL, etc. So I find it funny (although I understand the point, but it's still funny) that people consider Java to be so difficult because it's closed source. In every shop where Microsoft is the choice, the decision is usually made because the stack is predictable. It's predictable because Microsoft controls every aspect of it from the database to the app server to the language you use to code on it. So open sourcing Java would probably have the unintended consequence of giving Java a perception problem in the eyes of manager types. It would become risky on the same level as Linux and MySQL and so instead of being the safe, "adult" part of that crazy open source stack, it would just become one more piece of it. Albeit a powerful one, but it would probably push more people into the arms of Microsoft. Sorry, but that's been my experience, given what I've witnessed in the industry lately.

I address question 1 elsewhere. There are legal barriers to convenient redistribution of the JVM.

Your second comment is a nonsequitor. My point is the Sun JVM is extremely greedy in allocating memory. You relate a story about a C/C++ project going poorly. Whether or not Java is a superior language and deployment environment for some types of applications (an argument I do not contest) is irrelevant to the fact that the Sun JVM significantly more memory than an equivalent program in a variety of other languages. There are many causes contributing to this, from the java gui classes, to common java programming style, to the Sun JVM memory fragmentation behavior and garbage collector. None of them is "fundamental". You could write better java code; you could clean up the gui classes or write better ones. The Sun JVM could be fixed or improved to have better behavior. On second thought I don't really know if the garbage collector semantics have any fundamental flaws, although I suspect they do not. In practice, however, all these problems do exist, and contribute to relatively plain longrunning java programs balooning to many tens of megabytes when other similar technologies (for example smalltalk) do not have any problems of the sort.

You may counter that java is nontheless a more practial virtual development environment than other available systems, a point I do not care to argue at this time. That is completely aside from the fact that the other comparable virtual execution evironments of comparable complexity do not suffer from nearly the same level of allocation bloat. Squeak for example executes a large virtual system complete with a wide variety of applications, runtime debugger and modifier, entire virtualized framebuffer, a comparably complex foundation library all within a few tens of megabytes, even when used over very long sessions. Java in similar situations will consume hundreds.

Really, i mean it. At the moment, it's hard to find good developers who can leverage the advantages of java. What advantages i'm talking about? Let me explain. I am managing a team of developers (senior & junior) developing a large piece of software. Basicly it's a j2ee app, but with a simple desing, avoiding entity beans, using hibernate etc..what we have done for all the project has been following the specs. we did not do any tricks for windows or any other os. We did not do any tricks for any app server. And now, our solution is able to work on three major os's that we have targeted in the beginning, without even recompiling. we really wrote once, and we're running wherever we need.Against the more productive avarage.net developer, the cost of a longer development schedule is a hard thing to defend againgst the management. Please don't start the usual, java is more productive if you know how to do this or that. We usually can't find guys good enough for that. If you can, then it's good for you. Generally our developers are not much experienced or skilled, and this is again related to our budget. We have a certain amount of money, and we are unable to hire the super developers that can use java in a very productive way.this is our reality, and under these circumstances, the only way we can win against the ms shops doing the same job, is to use our platform independence. we can come up with zero licence versions of our software for small customers, using linux, jboss and postgresql, and it just works. the eliminated licence cost gives us many advantages, and this is how we are going to win. Other than that, there are many problems in real life, like customers falling in love with.net windows forms, ms office integration requests etc. agains the advantages of.net, we have the huge advantage of depending on specs, and providing better cost alternatives.so, go ahead, make java open source, and starting from the one man utility developer to IBM, let everyone change anything since they believe it is a better method of doing x,y,z... So 3 years from now, working on the new major version, my software will no longer be easily portable to other configs. It will be possible, but it will cost me much more than today. That cost my friends, will make us go down in the not so long run.Having a technology based on strict rules, has it's own advantages. in case of java, i believe these advantages far outweight the cons, but that's just me. However, i don't think my argument will be nonsense for many enterprise development projects.

That is the reason that with SUSE you can decide yourself wether or not you use it or not. e.g. for the upcoming 10.1 version the CD1-5 are pure OSS. There is an additional CD6 that will hold the non-OSS stuff, like Opera and Java.

That way SUSE lies the choice with the user, not with the distribution. If the user still decides to use it (and many will) they still have all the advantages as they have with the different other packages that are included with SUSE, including security updates.

There have been rumors and "talk" about Open Source Java from Sun for YEARS now, and the higher-ups keep on saying, "no we can't do it or there will be a fork."

That's the reality. It's stupid, but it's the reality. What they don't seem to comprehend, no matter how obvious it may be, is that a fork in Java does NOT mean any changes to the JVM or java.* or javax.* or any other language changes. No! Forks have nothing to do with it!

What does this mean? For example, let's say Java goes Open Source, and so OpenBSD wants to include it. They would need to modify it to work with OpenBSD. That does NOT mean changing that language. It means changing the system calls it uses, etc. Yeah that's a FORK but it does not impact compatibility at all. Same with the idea of setting up Qt native peers for Swing (something I would love to see). That would be a fork, but would not introduce any language or specification changes.

So they need to stop their BSing about forks.

I think there are some other reasons why they aren't open sourcing it:

There may be patent issues. It may uses patent stuff that Sun can't really do much about.

There probably are copyright issues. It certainly uses code from outside of Sun.

It would take a heap of code auditing, legal hours and negotiating to sort out 1 and 2 above. Sun in its current state can't afford that.

It could dash their J2ME JVM market, which may be one of the few revenue streams they get from Java.

It could let one of their competitors, like BEA or Oracle, take the leadership on Java, or at least it could dethrone Sun from that position. Again Sun can't afford that.

So that's a pretty strong case for a "no". The case for a "yes" is that if they do it, it will help Java become truly ubiquitous. But will that mean more money for Sun? I don't see the case for that.

So as frustrating as it is, I just don't see the business case for open sourcing Java.

In the meantime, the real Open Source Javas (and components) like GNU CLASSPATH, GCJ, Kaffe, JamVM, etc, etc are really getting quite impressive. The OS community has really gotten behind a full OS Java system. I am sure that by the end of this year, you'll be able to run a fully OS compiled Tomcat, for example.

I have played around some with GCJ and it results in impressively fast executables. Faster than Sun Java. So maybe we shouldn't even care.

Yes, you're right, it does cover a lot of licenses. In order to be allowed to use the trademarked term "Open Source" however, whatever license they choose must (a) comply with the Open Source Definition [opensource.org], and (b) be approved [opensource.org] by the Open Source Initiative.

Sure, not all Open Source licenses are the ducks guts to all people, but there's pretty much an assurance of no evil in there. Even microsoft knows that!

Gets its ass kicked? I don't see many people moving from Java to Ruby. From Perl, Python, and PHP, people are switching to Ruby in hordes. But from Java? A trickle, if anything.

You are missing my point. I am saying the enterprise approach to things only applies to a selection of software projects. Sun has ignored the ease-of-use and low-barrier-to-entry criteria for years and years. This means that small projects correctly don't use Java because it's not economical. They uses PHP, Rails, and the like.

But large projects often start as small projects, so Sun is, presumably accidentally, driving a lot of users away from Java. There is no good reason for this; the world wanted Rails, and Sun missed the boat. When I look at the Alexa Global 100 [alexa.com], none of the up-and-comers I recognize seem to be using Java. I know that Craigslist, MySpace, and Flickr are built on those non-enterprise technologies you disdain; in a few years I'd bet will see some Ruby on Rails entries, but none for, say, Java Server Faces or Struts.

Enterprise developers are, by nature, unlikely to use Rails yet because they are relatively conservative. Java is, in many ways, the new COBOL. But Rails, which used Ruby's greater power to dramatically increase ease of use, now has created a substantial user base for Ruby.

And unlike Perl and PHP, Ruby has the potential to be an enterprise-scale language. It's a much better OO language than Java in many ways. With a few improvements, some supporting tools, and another five years, you will see Ruby invading enterprise shops if Sun doesn't counter effectively.

"I was once writing a serach engine in a language I didn't know how to use, and it took a gig of RAM to do something stupid that I told it to do"

Please, don't blame the language for your incompetence. I have this horrible feeling that the Flyweight pattern would have saved you much grief.

I haven't checked, so I could accept that Treemap is suboptimal for what you were trying to use it for. There's nothing that says you have to use it.

Disclaimer: I have in my possession (propriety commercial) code for a search engine that searches across over a gig of data. It takes up about 20MB of ram more than the data takes on disk in a flat file. It was written in a couple of hours.

Further disclaimer: I didn't write it. Although I did suggest a performance optimisation. It was returning results in under 10ms before the optimisation.

Where is the fat. Mmmm, well you bring us 1 tail of a contest. Lets assume it is real for a second and lets assume that the C/C++ team was competent.

It don't sound like they were but still.

Let me know point you to some of the most demanding applications in existence that push hardware to its limits.

Yes, games.

Now how many of the BIG titles that have your CPU and GPU groaning and gobble memory like it is candy are written in C/C++ vs Java?

This is as fair as your story for showing wich is the superior language.

The fucking fact is that it don't matter shit. I bet you could do the application you describe in perl as long as the person doing it is competent.

For fun, look up code that checks wether an IP has a valid format. You get the weirdest examples. Some look really cumbersome but would translate to fast code while some of the smallest regex would choke you cpu like a java GUI (Sorry had to get a java jab in to keep my cool license)

Frankly I think the fat is for a large part still there from the days of java applets that you got on your pentium with 32mb that took ages to load and then crash.

Funny thing, you still get those. They still take ages to load and then crash.

Java applets are offcourse not server side java BUT most people don't care. Reputation matters sadly enough.

Don't expect sympathy however as long as every java programmer says PHP don't scale. We all got our prejudices.

From the accounts I've read, SWT addresses the artifacts of Swing and AWT by making applications work really well on Windows, and really badly elsewhere. It targets the features of the lowest common denominator platform, instead of targeting the lowest common denominator features of all platforms like AWT does. Swing is better if you use a recent JVM with all the performance bugs fixed, and use the look and feel package that matches your platform.

You forgot to mention the fact that you *still* need the sun jdk to build the package, the fact that this is an 1.4 jdk, and you conveniently snipped the bit of the Description where it says that, really, "using it in a production environment is at your own risk".

But that's all irrelevant - just like the fact that this is a pkgsrc-wip package, which is a more or less independant addition to the package set, and in practice means that you cannot use the quarterly stable branches - the fact still remains:

Flame away if you will but every Java app I've used (on Windows) has been clunky, buggy, and hard to use. None of the standard keyboard shortcuts seem to work, the apps *always* seem to be sluggish, and to top it off, they look funny - they don't inherit any of the look and feel aspects of the desktop. Now some smart Java person will say all these problems are fixable but it seems to me that it takes more effort to put out a quality Java app then say, an MFC or other similar program. The lure of cross-platform portability is nice but not at the expense of usability.

I'll stick to C++ and code in native development environments thank you.

Sun don't allow redistribution or bundling of java JREs except under certain specific conditions. This makes java as a language unattractive to many organisations when compared with.NET and can also hurt developers tendering for work.

Lets take a hypothetical new company. So far, all they've done is bought Windows and installed their workstation and server population. Now they need an application to do Foo.

Team A propose a solution based on.Net. For the company, this means a single set of negotiations, one licence to review (Team A's app licence) and only 2 support contact points (Microsoft and Team A).

Team B propose a solution based on Java. Now the company would have to have their lawyers review 2 sets of licences as opposed to one (Team A and Sun), and their support contact points climbs to 3. It also increases overall administrative hassle, as Java has to be patched / updated outside of their OS / application lifecycle.

Team B automatically look less attractive to the company because their hidden costs are much higher. If Sun just allowed Team B to bundle the JRE with their application, this would go away. Of course, then the different problem of every application trying to install Java comes up, but that can be got around by providing a 'JRE bundled' and 'No JRE' version of the products.

If you think that companies won't bother to review Sun's licence before installing Java, you'd be wrong... I've consulted at 2 different places now where they had their lawyers review the GPL and Java's licence before allowing deployment of products licenced under those.

I diagree. Java is far to bloated and complicated. I've been using it since it first came out and I balk at the vast array of libraries you need to use or choose between to get anything done. I feel really sorry for anyone coming to it for the first time.

So basically Java is the Linux of programming languages? You must really hate choice and having a large amount of problems already solved for you. Java is not for those with NIH syndrome.

I doubt you will see much uptake from a PHP running on the JVM. When you port a langauge to the JVM, you typically leave behind the C bound modules, because they just DON'T play well with the JVM (frequently non-thread safe, etc). For this reason languages that have nothing to offer but their c bound modules (Perl, PHP) don't fair well. Languages like Python and Ruby that have significant things to recommend them as languages do much better.

I diagree. Java is far to bloated and complicated. I've been using it since it first came out and I balk at the vast array of libraries you need to use or choose between to get anything done. I feel really sorry for anyone coming to it for the first time.

I really don't understand this. Having a rich and versatile range of libraries is a problem?

Personally I use Ruby (on Rails) these days for web development: convention over configuration is, imo, a much more important advance in the art than object-orientation was.

And Java has had this for years. I use JDO to persist my Java objects (it is a far more powerful and versatile system than Rails - much faster, and can persist to non-relational stores as well). How much configuration do I need in principle to describe my schema? Nothing but a list of classes. By default, the schema is created and mappings are automatically set up based on the field names of my classes. By default, no configuration needed.